kvcache-ai/ktransformers
1
0
Fork 0
mirror of https://github.com/kvcache-ai/ktransformers.git synced 2026-11-05 01:07:28 +00:00
Code Issues 469 Projects Packages Wiki Activity

[GH-ISSUE #1152] [Feature] docker运行0.2.4post1版本只能使用一颗CPU #800

New issue
Closed
opened 2026-10-29 14:44:38 +00:00 by bsakaguchi · 17 comments
bsakaguchi commented 2026-10-29 14:44:38 +00:00
Owner
Copy link

Originally created by @wishfay on GitHub (Apr 16, 2025).
Original GitHub issue: https://github.com/kvcache-ai/ktransformers/issues/1152

检查清单

  • 1. 如果您提出的不是新功能而是问题，请在讨论区发起讨论 https://github.com/kvcache-ai/ktransformers/discussions。否则该 issue 将被关闭
  • 2. 为方便社区交流，我将使用中文/英文或附上英文/中文翻译（如使用其他语言）。未附带翻译的非英文/中文内容可能会被关闭

需求背景

step1: 运行docker没问题

docker run -it --gpus all --privileged --shm-size 256g --name kt --network=host -v /data:/data approachingai/ktransformers:v0.2.4-AVX512 /bin/bash

step2: 进入docker运行kt也没问题

python ktransformers/server/main.py
--port 10002
--model_path /root/autodl-tmp/DeepSeek-V3-0324
--gguf_path /root/autodl-tmp/DeepSeek-V3-0324-GGUF/UD-Q2_K_XL \ --max_new_tokens 1024
--cache_lens 32768
--chunk_size 256
--max_batch_size 4
--backend_type balance_serve

问题

通过lscpu可以看到我的机器里面有两颗至强处理器:
NUMA node(s): 2

当kt开启推理的时候，使用htop可以看到其中的一颗cpu是几乎跑满了，但是另一颗cpu就没干活，导致CPU运行率一直是49%

如何可以把另一颗CPU也用起来呢？

相关资源

补充一下，我是直接下载的docker镜像
approachingai/ktransformers:v0.2.4post1-AVX2

Originally created by @wishfay on GitHub (Apr 16, 2025). Original GitHub issue: https://github.com/kvcache-ai/ktransformers/issues/1152 ### 检查清单 - [x] 1. 如果您提出的不是新功能而是问题，请在讨论区发起讨论 https://github.com/kvcache-ai/ktransformers/discussions。否则该 issue 将被关闭 - [x] 2. 为方便社区交流，我将使用中文/英文或附上英文/中文翻译（如使用其他语言）。未附带翻译的非英文/中文内容可能会被关闭 ### 需求背景 ### step1: 运行docker没问题 docker run -it --gpus all --privileged --shm-size 256g --name kt --network=host -v /data:/data approachingai/ktransformers:v0.2.4-AVX512 /bin/bash ### step2: 进入docker运行kt也没问题 python ktransformers/server/main.py \ --port 10002 \ --model_path /root/autodl-tmp/DeepSeek-V3-0324 \ --gguf_path /root/autodl-tmp/DeepSeek-V3-0324-GGUF/UD-Q2_K_XL \ --max_new_tokens 1024 \ --cache_lens 32768 \ --chunk_size 256 \ --max_batch_size 4 \ --backend_type balance_serve ### 问题 通过lscpu可以看到我的机器里面有两颗至强处理器: NUMA node(s): 2 当kt开启推理的时候，使用htop可以看到其中的一颗cpu是几乎跑满了，但是另一颗cpu就没干活，导致CPU运行率一直是49% 如何可以把另一颗CPU也用起来呢？ ### 相关资源 补充一下，我是直接下载的docker镜像 approachingai/ktransformers:v0.2.4post1-AVX2
bsakaguchi commented 2026-10-29 14:44:39 +00:00
Author
Owner
Copy link

@jizhilong commented on GitHub (Apr 16, 2025):

如果是提 feature request 的话，我觉得 ktransformers 已经支持了多 CPU 的。下面的截图中来自我这的一台服务器，可以看到相关进程的 cpu 使用率达到了 2400+%，相当于用满了 24 核的算力:

Image

对应了启动参数中的 --cpu_infer 24:

 jizl@zhao-MZ73-LM1-000:~/tmp$ ps -ef|grep cpu_infer
root        3670    3403 99 4月15 ?       1-05:56:43 python -m ktransformers.server.main --model_path /models/deepseek-ai/DeepSeek-R1 --gguf_path /models/unsloth/DeepSeek-R1-GGUF/DeepSeek-R1-Q4_K_M --cpu_infer 24 --chunk_size 256 --max_new_tokens 8192 --cache_lens 40960 --max_batch_size 4 --port 8005 --optimize_config_path ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat-serve.yaml --force_think --backend_type balance_serve

lscpu 的输出结果如下：

架构：                    x86_64
  CPU 运行模式：          32-bit, 64-bit
  Address sizes:          52 bits physical, 57 bits virtual
  字节序：                Little Endian
CPU:                      32
  在线 CPU 列表：         0-31
厂商 ID：                 AuthenticAMD
  型号名称：              AMD EPYC 9135 16-Core Processor
    CPU 系列：            26
    型号：                2
    每个核的线程数：      1
    每个座的核数：        16
    座：                  2
    步进：                1
    Frequency boost:      enabled
    CPU(s) scaling MHz:   39%
    CPU 最大 MHz：        4305.8589
    CPU 最小 MHz：        1500.0000
    BogoMIPS：            7299.98
    标记：                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni 
                          pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfct
                          r_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512
                          bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid
                           decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid bus_lock_detect movdiri movdir64b overflo
                          w_recov succor smca fsrm avx512_vp2intersect flush_l1d debug_swap amd_lbr_pmc_freeze
Virtualization features:  
  虚拟化：                AMD-V
Caches (sum of all):      
  L1d:                    1.5 MiB (32 instances)
  L1i:                    1 MiB (32 instances)
  L2:                     32 MiB (32 instances)
  L3:                     128 MiB (8 instances)
NUMA:                     
  NUMA 节点：             2
  NUMA 节点0 CPU：        0-15
  NUMA 节点1 CPU：        16-31
Vulnerabilities:          
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                  Not affected
  Tsx async abort:        Not affecte
<!-- gh-comment-id:2808926205 --> @jizhilong commented on GitHub (Apr 16, 2025): 如果是提 feature request 的话，我觉得 ktransformers 已经支持了多 CPU 的。下面的截图中来自我这的一台服务器，可以看到相关进程的 cpu 使用率达到了 2400+%，相当于用满了 24 核的算力: ![Image](https://github.com/user-attachments/assets/c0d058aa-5072-4b39-8873-370e8bedf444) 对应了启动参数中的 `--cpu_infer 24`: ``` jizl@zhao-MZ73-LM1-000:~/tmp$ ps -ef|grep cpu_infer root 3670 3403 99 4月15 ? 1-05:56:43 python -m ktransformers.server.main --model_path /models/deepseek-ai/DeepSeek-R1 --gguf_path /models/unsloth/DeepSeek-R1-GGUF/DeepSeek-R1-Q4_K_M --cpu_infer 24 --chunk_size 256 --max_new_tokens 8192 --cache_lens 40960 --max_batch_size 4 --port 8005 --optimize_config_path ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat-serve.yaml --force_think --backend_type balance_serve ``` lscpu 的输出结果如下： ``` 架构： x86_64 CPU 运行模式： 32-bit, 64-bit Address sizes: 52 bits physical, 57 bits virtual 字节序： Little Endian CPU: 32 在线 CPU 列表： 0-31 厂商 ID： AuthenticAMD 型号名称： AMD EPYC 9135 16-Core Processor CPU 系列： 26 型号： 2 每个核的线程数： 1 每个座的核数： 16 座： 2 步进： 1 Frequency boost: enabled CPU(s) scaling MHz: 39% CPU 最大 MHz： 4305.8589 CPU 最小 MHz： 1500.0000 BogoMIPS： 7299.98 标记： fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfct r_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512 bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid bus_lock_detect movdiri movdir64b overflo w_recov succor smca fsrm avx512_vp2intersect flush_l1d debug_swap amd_lbr_pmc_freeze Virtualization features: 虚拟化： AMD-V Caches (sum of all): L1d: 1.5 MiB (32 instances) L1i: 1 MiB (32 instances) L2: 32 MiB (32 instances) L3: 128 MiB (8 instances) NUMA: NUMA 节点： 2 NUMA 节点0 CPU： 0-15 NUMA 节点1 CPU： 16-31 Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Not affected Mds: Not affected Meltdown: Not affected Mmio stale data: Not affected Reg file data sampling: Not affected Retbleed: Not affected Spec rstack overflow: Not affected Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Srbds: Not affected Tsx async abort: Not affecte ```
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@yeungtuzi commented on GitHub (Apr 16, 2025):

尝试把CPU数量设置为超线程数量+2

<!-- gh-comment-id:2809445012 --> @yeungtuzi commented on GitHub (Apr 16, 2025): 尝试把CPU数量设置为超线程数量+2
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@Azure-Tang commented on GitHub (Apr 16, 2025):

可以在docker内按照多numa的安装教程重新编译一遍~

<!-- gh-comment-id:2810016291 --> @Azure-Tang commented on GitHub (Apr 16, 2025): 可以在docker内按照多numa的安装教程重新编译一遍~
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@wishfay commented on GitHub (Apr 17, 2025):

如果是提 feature request 的话，我觉得 ktransformers 已经支持了多 CPU 的。下面的截图中来自我这的一台服务器，可以看到相关进程的 cpu 使用率达到了 2400+%，相当于用满了 24 核的算力:

Image

对应了启动参数中的 --cpu_infer 24:

 jizl@zhao-MZ73-LM1-000:~/tmp$ ps -ef|grep cpu_infer
root        3670    3403 99 4月15 ?       1-05:56:43 python -m ktransformers.server.main --model_path /models/deepseek-ai/DeepSeek-R1 --gguf_path /models/unsloth/DeepSeek-R1-GGUF/DeepSeek-R1-Q4_K_M --cpu_infer 24 --chunk_size 256 --max_new_tokens 8192 --cache_lens 40960 --max_batch_size 4 --port 8005 --optimize_config_path ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat-serve.yaml --force_think --backend_type balance_serve

lscpu 的输出结果如下：

架构：                    x86_64
  CPU 运行模式：          32-bit, 64-bit
  Address sizes:          52 bits physical, 57 bits virtual
  字节序：                Little Endian
CPU:                      32
  在线 CPU 列表：         0-31
厂商 ID：                 AuthenticAMD
  型号名称：              AMD EPYC 9135 16-Core Processor
    CPU 系列：            26
    型号：                2
    每个核的线程数：      1
    每个座的核数：        16
    座：                  2
    步进：                1
    Frequency boost:      enabled
    CPU(s) scaling MHz:   39%
    CPU 最大 MHz：        4305.8589
    CPU 最小 MHz：        1500.0000
    BogoMIPS：            7299.98
    标记：                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni 
                          pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfct
                          r_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512
                          bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid
                           decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid bus_lock_detect movdiri movdir64b overflo
                          w_recov succor smca fsrm avx512_vp2intersect flush_l1d debug_swap amd_lbr_pmc_freeze
Virtualization features:  
  虚拟化：                AMD-V
Caches (sum of all):      
  L1d:                    1.5 MiB (32 instances)
  L1i:                    1 MiB (32 instances)
  L2:                     32 MiB (32 instances)
  L3:                     128 MiB (8 instances)
NUMA:                     
  NUMA 节点：             2
  NUMA 节点0 CPU：        0-15
  NUMA 节点1 CPU：        16-31
Vulnerabilities:          
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                  Not affected
  Tsx async abort:        Not affecte

如果是提 feature request 的话，我觉得 ktransformers 已经支持了多 CPU 的。下面的截图中来自我这的一台服务器，可以看到相关进程的 cpu 使用率达到了 2400+%，相当于用满了 24 核的算力:

Image

对应了启动参数中的 --cpu_infer 24:

 jizl@zhao-MZ73-LM1-000:~/tmp$ ps -ef|grep cpu_infer
root        3670    3403 99 4月15 ?       1-05:56:43 python -m ktransformers.server.main --model_path /models/deepseek-ai/DeepSeek-R1 --gguf_path /models/unsloth/DeepSeek-R1-GGUF/DeepSeek-R1-Q4_K_M --cpu_infer 24 --chunk_size 256 --max_new_tokens 8192 --cache_lens 40960 --max_batch_size 4 --port 8005 --optimize_config_path ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat-serve.yaml --force_think --backend_type balance_serve

lscpu 的输出结果如下：

架构：                    x86_64
  CPU 运行模式：          32-bit, 64-bit
  Address sizes:          52 bits physical, 57 bits virtual
  字节序：                Little Endian
CPU:                      32
  在线 CPU 列表：         0-31
厂商 ID：                 AuthenticAMD
  型号名称：              AMD EPYC 9135 16-Core Processor
    CPU 系列：            26
    型号：                2
    每个核的线程数：      1
    每个座的核数：        16
    座：                  2
    步进：                1
    Frequency boost:      enabled
    CPU(s) scaling MHz:   39%
    CPU 最大 MHz：        4305.8589
    CPU 最小 MHz：        1500.0000
    BogoMIPS：            7299.98
    标记：                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni 
                          pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfct
                          r_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512
                          bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid
                           decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid bus_lock_detect movdiri movdir64b overflo
                          w_recov succor smca fsrm avx512_vp2intersect flush_l1d debug_swap amd_lbr_pmc_freeze
Virtualization features:  
  虚拟化：                AMD-V
Caches (sum of all):      
  L1d:                    1.5 MiB (32 instances)
  L1i:                    1 MiB (32 instances)
  L2:                     32 MiB (32 instances)
  L3:                     128 MiB (8 instances)
NUMA:                     
  NUMA 节点：             2
  NUMA 节点0 CPU：        0-15
  NUMA 节点1 CPU：        16-31
Vulnerabilities:          
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                  Not affected
  Tsx async abort:        Not affecte

谢谢！
通过添加了 --cpu_infer 126确实可以把两颗至强6430跑满，但是似乎推理速度并没有变快😑，之前不加这个参数单cpu是9.5tokens，现在双核也是这个速度😂

<!-- gh-comment-id:2811550810 --> @wishfay commented on GitHub (Apr 17, 2025): > 如果是提 feature request 的话，我觉得 ktransformers 已经支持了多 CPU 的。下面的截图中来自我这的一台服务器，可以看到相关进程的 cpu 使用率达到了 2400+%，相当于用满了 24 核的算力: > > ![Image](https://github.com/user-attachments/assets/c0d058aa-5072-4b39-8873-370e8bedf444) > > 对应了启动参数中的 `--cpu_infer 24`: > > ``` > jizl@zhao-MZ73-LM1-000:~/tmp$ ps -ef|grep cpu_infer > root 3670 3403 99 4月15 ? 1-05:56:43 python -m ktransformers.server.main --model_path /models/deepseek-ai/DeepSeek-R1 --gguf_path /models/unsloth/DeepSeek-R1-GGUF/DeepSeek-R1-Q4_K_M --cpu_infer 24 --chunk_size 256 --max_new_tokens 8192 --cache_lens 40960 --max_batch_size 4 --port 8005 --optimize_config_path ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat-serve.yaml --force_think --backend_type balance_serve > ``` > > lscpu 的输出结果如下： > > ``` > 架构： x86_64 > CPU 运行模式： 32-bit, 64-bit > Address sizes: 52 bits physical, 57 bits virtual > 字节序： Little Endian > CPU: 32 > 在线 CPU 列表： 0-31 > 厂商 ID： AuthenticAMD > 型号名称： AMD EPYC 9135 16-Core Processor > CPU 系列： 26 > 型号： 2 > 每个核的线程数： 1 > 每个座的核数： 16 > 座： 2 > 步进： 1 > Frequency boost: enabled > CPU(s) scaling MHz: 39% > CPU 最大 MHz： 4305.8589 > CPU 最小 MHz： 1500.0000 > BogoMIPS： 7299.98 > 标记： fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni > pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfct > r_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512 > bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid > decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid bus_lock_detect movdiri movdir64b overflo > w_recov succor smca fsrm avx512_vp2intersect flush_l1d debug_swap amd_lbr_pmc_freeze > Virtualization features: > 虚拟化： AMD-V > Caches (sum of all): > L1d: 1.5 MiB (32 instances) > L1i: 1 MiB (32 instances) > L2: 32 MiB (32 instances) > L3: 128 MiB (8 instances) > NUMA: > NUMA 节点： 2 > NUMA 节点0 CPU： 0-15 > NUMA 节点1 CPU： 16-31 > Vulnerabilities: > Gather data sampling: Not affected > Itlb multihit: Not affected > L1tf: Not affected > Mds: Not affected > Meltdown: Not affected > Mmio stale data: Not affected > Reg file data sampling: Not affected > Retbleed: Not affected > Spec rstack overflow: Not affected > Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl > Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization > Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected > Srbds: Not affected > Tsx async abort: Not affecte > ``` > 如果是提 feature request 的话，我觉得 ktransformers 已经支持了多 CPU 的。下面的截图中来自我这的一台服务器，可以看到相关进程的 cpu 使用率达到了 2400+%，相当于用满了 24 核的算力: > > ![Image](https://github.com/user-attachments/assets/c0d058aa-5072-4b39-8873-370e8bedf444) > > 对应了启动参数中的 `--cpu_infer 24`: > > ``` > jizl@zhao-MZ73-LM1-000:~/tmp$ ps -ef|grep cpu_infer > root 3670 3403 99 4月15 ? 1-05:56:43 python -m ktransformers.server.main --model_path /models/deepseek-ai/DeepSeek-R1 --gguf_path /models/unsloth/DeepSeek-R1-GGUF/DeepSeek-R1-Q4_K_M --cpu_infer 24 --chunk_size 256 --max_new_tokens 8192 --cache_lens 40960 --max_batch_size 4 --port 8005 --optimize_config_path ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat-serve.yaml --force_think --backend_type balance_serve > ``` > > lscpu 的输出结果如下： > > ``` > 架构： x86_64 > CPU 运行模式： 32-bit, 64-bit > Address sizes: 52 bits physical, 57 bits virtual > 字节序： Little Endian > CPU: 32 > 在线 CPU 列表： 0-31 > 厂商 ID： AuthenticAMD > 型号名称： AMD EPYC 9135 16-Core Processor > CPU 系列： 26 > 型号： 2 > 每个核的线程数： 1 > 每个座的核数： 16 > 座： 2 > 步进： 1 > Frequency boost: enabled > CPU(s) scaling MHz: 39% > CPU 最大 MHz： 4305.8589 > CPU 最小 MHz： 1500.0000 > BogoMIPS： 7299.98 > 标记： fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni > pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfct > r_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512 > bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid > decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid bus_lock_detect movdiri movdir64b overflo > w_recov succor smca fsrm avx512_vp2intersect flush_l1d debug_swap amd_lbr_pmc_freeze > Virtualization features: > 虚拟化： AMD-V > Caches (sum of all): > L1d: 1.5 MiB (32 instances) > L1i: 1 MiB (32 instances) > L2: 32 MiB (32 instances) > L3: 128 MiB (8 instances) > NUMA: > NUMA 节点： 2 > NUMA 节点0 CPU： 0-15 > NUMA 节点1 CPU： 16-31 > Vulnerabilities: > Gather data sampling: Not affected > Itlb multihit: Not affected > L1tf: Not affected > Mds: Not affected > Meltdown: Not affected > Mmio stale data: Not affected > Reg file data sampling: Not affected > Retbleed: Not affected > Spec rstack overflow: Not affected > Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl > Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization > Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected > Srbds: Not affected > Tsx async abort: Not affecte > ``` 谢谢！ 通过添加了 --cpu_infer 126确实可以把两颗至强6430跑满，但是似乎推理速度并没有变快😑，之前不加这个参数单cpu是9.5tokens，现在双核也是这个速度😂
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@wishfay commented on GitHub (Apr 17, 2025):

尝试把CPU数量设置为超线程数量+2

谢谢，不过应该是超线程数-2。
另外性能似乎没提升🤔，有点奇怪

<!-- gh-comment-id:2811554339 --> @wishfay commented on GitHub (Apr 17, 2025): > 尝试把CPU数量设置为超线程数量+2 谢谢，不过应该是超线程数-2。 另外性能似乎没提升🤔，有点奇怪
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@cyhasuka commented on GitHub (Apr 17, 2025):

尝试把CPU数量设置为超线程数量+2

谢谢，不过应该是超线程数-2。 另外性能似乎没提升🤔，有点奇怪

理论上来讲超线程不能加速计算，如果CPU数量设置的太高，可能还会发生线程间抢占，所以应该使用实际的物理核心。至强6430是32C64T，所以双CPU应该是设置为 --cpu_infer 65 (64+1, +1是为了给调度系统) 。htop里面显示跑了50%左右是正常的，说明实际的物理核心全部跑满

<!-- gh-comment-id:2811578140 --> @cyhasuka commented on GitHub (Apr 17, 2025): > > 尝试把CPU数量设置为超线程数量+2 > > 谢谢，不过应该是超线程数-2。 另外性能似乎没提升🤔，有点奇怪 理论上来讲超线程不能加速计算，如果CPU数量设置的太高，可能还会发生线程间抢占，所以应该使用实际的物理核心。至强6430是32C64T，所以双CPU应该是设置为 `--cpu_infer 65` (64+1, +1是为了给调度系统) 。htop里面显示跑了50%左右是正常的，说明实际的物理核心全部跑满
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@jizhilong commented on GitHub (Apr 17, 2025):

通过添加了 --cpu_infer 126确实可以把两颗至强6430跑满，但是似乎推理速度并没有变快😑，之前不加这个参数单cpu是9.5tokens，现在双核也是这个速度

建议把 lscpu 的结果和 top/htop 的原始输出贴出来，这样大家对 “跑满” 形成一致的理解。

例如，我这边使用的是 --cpu_infer 24 ，cpu core 数是 32，执行推理的时候，top 的输出如下图， 可以看到：

  1. userspace 的 %CPU 是 78.7% 左右，稍多于 24/32=0.75%
  2. top 的各进程 cpu 占用中，top2 的分别是 2400% 和 100%，加起来相当于用了 25 core 的算力， 25/32=78.1%。和 top 头部的整体统计对应

Image

另外，建议将 cpu_infer 调整到比实际 core 数少，例如你的总 core 数是 64 的话，你可以试试 --cpu_infer 60，原因如 @cyhasuka 所说，避免线程间抢占。

<!-- gh-comment-id:2811622221 --> @jizhilong commented on GitHub (Apr 17, 2025): > 通过添加了 --cpu_infer 126确实可以把两颗至强6430跑满，但是似乎推理速度并没有变快😑，之前不加这个参数单cpu是9.5tokens，现在双核也是这个速度 建议把 lscpu 的结果和 top/htop 的原始输出贴出来，这样大家对 “跑满” 形成一致的理解。 例如，我这边使用的是 `--cpu_infer 24` ，cpu core 数是 32，执行推理的时候，top 的输出如下图， 可以看到： 1. userspace 的 `%CPU` 是 78.7% 左右，稍多于 24/32=0.75% 2. top 的各进程 cpu 占用中，top2 的分别是 2400% 和 100%，加起来相当于用了 25 core 的算力， 25/32=78.1%。和 top 头部的整体统计对应 ![Image](https://github.com/user-attachments/assets/6c5d64d4-cbd1-4ba8-a059-2f0dc21c5cb1) 另外，建议将 `cpu_infer` 调整到比实际 core 数少，例如你的总 core 数是 64 的话，你可以试试 `--cpu_infer 60`，原因如 @cyhasuka 所说，避免线程间抢占。
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@wishfay commented on GitHub (Apr 17, 2025):

可以在docker内按照多numa的安装教程重新编译一遍~

尝试把CPU数量设置为超线程数量+2

谢谢，不过应该是超线程数-2。 另外性能似乎没提升🤔，有点奇怪

理论上来讲超线程不能加速计算，如果CPU数量设置的太高，可能还会发生线程间抢占，所以应该使用实际的物理核心。至强6430是32C64T，所以双CPU应该是设置为 --cpu_infer 65 (64+1, +1是为了给调度系统) 。htop里面显示跑了50%左右是正常的，说明实际的物理核心全部跑满

理解了，这么解释就通了！十分感谢！

<!-- gh-comment-id:2811749788 --> @wishfay commented on GitHub (Apr 17, 2025): > 可以在docker内按照多numa的安装教程重新编译一遍~ > > > 尝试把CPU数量设置为超线程数量+2 > > > > > > 谢谢，不过应该是超线程数-2。 另外性能似乎没提升🤔，有点奇怪 > > 理论上来讲超线程不能加速计算，如果CPU数量设置的太高，可能还会发生线程间抢占，所以应该使用实际的物理核心。至强6430是32C64T，所以双CPU应该是设置为 `--cpu_infer 65` (64+1, +1是为了给调度系统) 。htop里面显示跑了50%左右是正常的，说明实际的物理核心全部跑满 理解了，这么解释就通了！十分感谢！
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@wishfay commented on GitHub (Apr 17, 2025):

通过添加了 --cpu_infer 126确实可以把两颗至强6430跑满，但是似乎推理速度并没有变快😑，之前不加这个参数单cpu是9.5tokens，现在双核也是这个速度

建议把 lscpu 的结果和 top/htop 的原始输出贴出来，这样大家对 “跑满” 形成一致的理解。

例如，我这边使用的是 --cpu_infer 24 ，cpu core 数是 32，执行推理的时候，top 的输出如下图， 可以看到：

  1. userspace 的 %CPU 是 78.7% 左右，稍多于 24/32=0.75%
  2. top 的各进程 cpu 占用中，top2 的分别是 2400% 和 100%，加起来相当于用了 25 core 的算力， 25/32=78.1%。和 top 头部的整体统计对应

Image

另外，建议将 cpu_infer 调整到比实际 core 数少，例如你的总 core 数是 64 的话，你可以试试 --cpu_infer 60，原因如 @cyhasuka 所说，避免线程间抢占。

明白了，谢谢解答！

<!-- gh-comment-id:2811750841 --> @wishfay commented on GitHub (Apr 17, 2025): > > 通过添加了 --cpu_infer 126确实可以把两颗至强6430跑满，但是似乎推理速度并没有变快😑，之前不加这个参数单cpu是9.5tokens，现在双核也是这个速度 > > 建议把 lscpu 的结果和 top/htop 的原始输出贴出来，这样大家对 “跑满” 形成一致的理解。 > > 例如，我这边使用的是 `--cpu_infer 24` ，cpu core 数是 32，执行推理的时候，top 的输出如下图， 可以看到： > > 1. userspace 的 `%CPU` 是 78.7% 左右，稍多于 24/32=0.75% > 2. top 的各进程 cpu 占用中，top2 的分别是 2400% 和 100%，加起来相当于用了 25 core 的算力， 25/32=78.1%。和 top 头部的整体统计对应 > > ![Image](https://github.com/user-attachments/assets/6c5d64d4-cbd1-4ba8-a059-2f0dc21c5cb1) > > 另外，建议将 `cpu_infer` 调整到比实际 core 数少，例如你的总 core 数是 64 的话，你可以试试 `--cpu_infer 60`，原因如 [@cyhasuka](https://2git.xyz/cyhasuka) 所说，避免线程间抢占。 明白了，谢谢解答！
bsakaguchi commented 2026-10-29 14:44:40 +00:00
Author
Owner
Copy link

@wishfay commented on GitHub (Apr 17, 2025):

不过我感觉似乎测试下来的速度，推理只有9.5tokens/s，比官方数据要慢不少，不知道是为何？

具体的硬件配置如下：
cpu 至强6430*2
内存 ddr5 512G
显卡 rtx6000ada 48G
硬盘 nvme 4T

<!-- gh-comment-id:2811756846 --> @wishfay commented on GitHub (Apr 17, 2025): 不过我感觉似乎测试下来的速度，推理只有9.5tokens/s，比官方数据要慢不少，不知道是为何？ 具体的硬件配置如下： cpu 至强6430*2 内存 ddr5 512G 显卡 rtx6000ada 48G 硬盘 nvme 4T
bsakaguchi commented 2026-10-29 14:44:41 +00:00
Author
Owner
Copy link

@cyhasuka commented on GitHub (Apr 17, 2025):

不过我感觉似乎测试下来的速度，推理只有9.5tokens/s，比官方数据要慢不少，不知道是为何？

具体的硬件配置如下： cpu 至强6430*2 内存 ddr5 512G 显卡 rtx6000ada 48G 硬盘 nvme 4T

0.2.4的单batch好像确实是不如0.2.3快，我这里测试也是这样。你可以关闭多batch功能试试看。
另外我有个疑问，在启用双NUMA的情况下，DRAM占用会翻倍，对于DeepSeek-V3-0324-GGUF/UD-Q2_K_XL 模型，512G DRAM似乎是不太够的？

<!-- gh-comment-id:2811882196 --> @cyhasuka commented on GitHub (Apr 17, 2025): > 不过我感觉似乎测试下来的速度，推理只有9.5tokens/s，比官方数据要慢不少，不知道是为何？ > > 具体的硬件配置如下： cpu 至强6430*2 内存 ddr5 512G 显卡 rtx6000ada 48G 硬盘 nvme 4T 0.2.4的单batch好像确实是不如0.2.3快，我这里测试也是这样。你可以关闭多batch功能试试看。 另外我有个疑问，在启用双NUMA的情况下，DRAM占用会翻倍，对于DeepSeek-V3-0324-GGUF/UD-Q2_K_XL 模型，512G DRAM似乎是不太够的？
bsakaguchi commented 2026-10-29 14:44:41 +00:00
Author
Owner
Copy link

@yeungtuzi commented on GitHub (Apr 17, 2025):

生成速度主要取决于内存带宽，9.5这个成绩不算差

<!-- gh-comment-id:2813245786 --> @yeungtuzi commented on GitHub (Apr 17, 2025): 生成速度主要取决于内存带宽，9.5这个成绩不算差
bsakaguchi commented 2026-10-29 14:44:41 +00:00
Author
Owner
Copy link

@yeungtuzi commented on GitHub (Apr 17, 2025):

我之前一直是奉行物理核心-2原则的，不过后来看到数据超线程有点儿用（尤其是CPU核心较少的时候），就打开了zen4的超线程并增加线程数量，似乎性能有轻微提升。

发件人: Xuefei Wang @.>
发送时间: 2025年4月17日 13:09
收件人: kvcache-ai/ktransformers @.>
抄送: dahema @.>; Comment @.>
主题: Re: [kvcache-ai/ktransformers] [Feature] docker运行0.2.4post1版本只能使用一颗CPU (Issue #1152)

Reopened #1152https://github.com/kvcache-ai/ktransformers/issues/1152.

―
Reply to this email directly, view it on GitHubhttps://github.com/kvcache-ai/ktransformers/issues/1152#event-17300001030, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADLPPACS6FWVBZF4LVKLYNT2Z4ZQHAVCNFSM6AAAAAB3HE745CVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJXGMYDAMBQGEYDGMA.
You are receiving this because you commented.Message ID: @.***>

<!-- gh-comment-id:2813255757 --> @yeungtuzi commented on GitHub (Apr 17, 2025): 我之前一直是奉行物理核心-2原则的，不过后来看到数据超线程有点儿用（尤其是CPU核心较少的时候），就打开了zen4的超线程并增加线程数量，似乎性能有轻微提升。 ________________________________ 发件人: Xuefei Wang ***@***.***> 发送时间: 2025年4月17日 13:09 收件人: kvcache-ai/ktransformers ***@***.***> 抄送: dahema ***@***.***>; Comment ***@***.***> 主题: Re: [kvcache-ai/ktransformers] [Feature] docker运行0.2.4post1版本只能使用一颗CPU (Issue #1152) Reopened #1152<https://github.com/kvcache-ai/ktransformers/issues/1152>. ― Reply to this email directly, view it on GitHub<https://github.com/kvcache-ai/ktransformers/issues/1152#event-17300001030>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLPPACS6FWVBZF4LVKLYNT2Z4ZQHAVCNFSM6AAAAAB3HE745CVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJXGMYDAMBQGEYDGMA>. You are receiving this because you commented.Message ID: ***@***.***>
bsakaguchi commented 2026-10-29 14:44:41 +00:00
Author
Owner
Copy link

@wishfay commented on GitHub (Apr 17, 2025):

不过我感觉似乎测试下来的速度，推理只有9.5tokens/s，比官方数据要慢不少，不知道是为何？
具体的硬件配置如下： cpu 至强6430*2 内存 ddr5 512G 显卡 rtx6000ada 48G 硬盘 nvme 4T

0.2.4的单batch好像确实是不如0.2.3快，我这里测试也是这样。你可以关闭多batch功能试试看。 另外我有个疑问，在启用双NUMA的情况下，DRAM占用会翻倍，对于DeepSeek-V3-0324-GGUF/UD-Q2_K_XL 模型，512G DRAM似乎是不太够的？

好的，我试试看。
UD-Q2_K_XL模型一份是200GB，翻倍跑起来也就不到450GB，512GB好像是够的（我用btop监测感觉推理的时候没有特别多内存的交换）

<!-- gh-comment-id:2813413522 --> @wishfay commented on GitHub (Apr 17, 2025): > > 不过我感觉似乎测试下来的速度，推理只有9.5tokens/s，比官方数据要慢不少，不知道是为何？ > > 具体的硬件配置如下： cpu 至强6430*2 内存 ddr5 512G 显卡 rtx6000ada 48G 硬盘 nvme 4T > > 0.2.4的单batch好像确实是不如0.2.3快，我这里测试也是这样。你可以关闭多batch功能试试看。 另外我有个疑问，在启用双NUMA的情况下，DRAM占用会翻倍，对于DeepSeek-V3-0324-GGUF/UD-Q2_K_XL 模型，512G DRAM似乎是不太够的？ 好的，我试试看。 UD-Q2_K_XL模型一份是200GB，翻倍跑起来也就不到450GB，512GB好像是够的（我用btop监测感觉推理的时候没有特别多内存的交换）
bsakaguchi commented 2026-10-29 14:44:41 +00:00
Author
Owner
Copy link

@wishfay commented on GitHub (Apr 17, 2025):

我之前一直是奉行物理核心-2原则的，不过后来看到数据超线程有点儿用（尤其是CPU核心较少的时候），就打开了zen4的超线程并增加线程数量，似乎性能有轻微提升。
…

发件人: Xuefei Wang @.>
发送时间: 2025年4月17日 13:09
收件人: kvcache-ai/ktransformers @.>
抄送: dahema @.>; Comment @.>
主题: Re: [kvcache-ai/ktransformers] [Feature] docker运行0.2.4post1版本只能使用一颗CPU (Issue #1152)

Reopened #1152<#1152>.

―
Reply to this email directly, view it on GitHub<#1152 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLPPACS6FWVBZF4LVKLYNT2Z4ZQHAVCNFSM6AAAAAB3HE745CVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJXGMYDAMBQGEYDGMA>.
You are receiving this because you commented.Message ID: @.***>

原来如此，看来还得多试试看，哈哈

<!-- gh-comment-id:2813443132 --> @wishfay commented on GitHub (Apr 17, 2025): > 我之前一直是奉行物理核心-2原则的，不过后来看到数据超线程有点儿用（尤其是CPU核心较少的时候），就打开了zen4的超线程并增加线程数量，似乎性能有轻微提升。 > […](#) > > ________________________________ > 发件人: Xuefei Wang ***@***.***> > 发送时间: 2025年4月17日 13:09 > 收件人: kvcache-ai/ktransformers ***@***.***> > 抄送: dahema ***@***.***>; Comment ***@***.***> > 主题: Re: [kvcache-ai/ktransformers] [Feature] docker运行0.2.4post1版本只能使用一颗CPU (Issue [#1152](https://2git.xyz/kvcache-ai/ktransformers/issues/1152)) > > > Reopened [#1152](https://2git.xyz/kvcache-ai/ktransformers/issues/1152)<[#1152](https://2git.xyz/kvcache-ai/ktransformers/issues/1152)>. > > ― > Reply to this email directly, view it on GitHub<[#1152 (comment)](https://2git.xyz/kvcache-ai/ktransformers/issues/1152#event-17300001030)>, or unsubscribe<[https://github.com/notifications/unsubscribe-auth/ADLPPACS6FWVBZF4LVKLYNT2Z4ZQHAVCNFSM6AAAAAB3HE745CVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJXGMYDAMBQGEYDGMA](https://2git.xyz/notifications/unsubscribe-auth/ADLPPACS6FWVBZF4LVKLYNT2Z4ZQHAVCNFSM6AAAAAB3HE745CVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJXGMYDAMBQGEYDGMA)>. > You are receiving this because you commented.Message ID: ***@***.***> 原来如此，看来还得多试试看，哈哈
bsakaguchi commented 2026-10-29 14:44:41 +00:00
Author
Owner
Copy link

@cyhasuka commented on GitHub (Apr 18, 2025):

我之前一直是奉行物理核心-2原则的，不过后来看到数据超线程有点儿用（尤其是CPU核心较少的时候），就打开了zen4的超线程并增加线程数量，似乎性能有轻微提升。

我的硬件条件下 2 * 6454S (64c128t) + L4 + 1TD5 开启超线程并将 --cpu_infer 改成 129 ，速度会降低2-3tokens/s，可以看到发生了进程抢占导致速度降低。而最新的文档中已经改掉物理核心-2的原则，改为物理核心+1，总物理核心数参与计算，1个超线程进程参与数据交换。参见：KTransformers文档

<!-- gh-comment-id:2814271590 --> @cyhasuka commented on GitHub (Apr 18, 2025): > 我之前一直是奉行物理核心-2原则的，不过后来看到数据超线程有点儿用（尤其是CPU核心较少的时候），就打开了zen4的超线程并增加线程数量，似乎性能有轻微提升。 我的硬件条件下 2 * 6454S (64c128t) + L4 + 1TD5 开启超线程并将 --cpu_infer 改成 129 ，速度会降低2-3tokens/s，可以看到发生了进程抢占导致速度降低。而最新的文档中已经改掉物理核心-2的原则，改为物理核心+1，总物理核心数参与计算，1个超线程进程参与数据交换。参见：[KTransformers文档](https://kvcache-ai.github.io/ktransformers/en/fp8_kernel.html)
bsakaguchi commented 2026-10-29 14:44:41 +00:00
Author
Owner
Copy link

@wishfay commented on GitHub (Apr 22, 2025):

感谢各位大佬指导！

<!-- gh-comment-id:2820994662 --> @wishfay commented on GitHub (Apr 22, 2025): 感谢各位大佬指导！
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
auto/sync-sglang
gh-pages
docs/kt-ft-figure2-single-column-20261010
perf/bf16-grad-norm-20261010
docs/kt-ft-paper-20261008
release/20260911-carrier-repair
release/20260911-ci-python
release/20260911-pypi
ci/four-main-pypi-release
ci/model-e2e-acceptance
release/0.7.0.post3-frozen-pypi
fix/glm53-index-share-sync
release/0.7.0.post2-frozen-pypi
hotfix/0.7.0.post2-pypi-runtime
fix/avx2-wheel-feature-isolation
fix/release-self-hosted-runner
release/automate-kt-sft-pypi
support-glm5-next-djw
docs/deepseek-v4-flash-docker
ovowei-patch-3
support-glm52-djw
doc-reorg-entrypoints-support-matrix
bump-sglang-pr31
docs-v061-refresh
fp4-moe-amx
flatten-ktransformers-shim
archive-kt-sft
kt-kernel-torch-range-v061
sft-whl
sft
docs/gosim-2026-and-roadmap-link
ovowei-patch-2
ovowei-patch-1
revert-1918-fix/rocm-cpuinfer-stream-bridge
chore/kt-layerwise-prefill-main
chore/kt-layerwise-prefill-label
sft-rel
support-glm51-djw
release/v0.5.3
chore/kt-run-numa-nodes-unified
mtp
ksft-sglang
avx2
fix/sglang-kt-detection
layerwise-prefill-opt
feat/mistral-loader-support
fix-docker-build
minimax-m2.5
qwen3.5
add-maintainers
oql-doc
cli-dev-ljq
ljq-cli-dev-new
JimmyPeilinLi-patch-2
kimi_k2.5
oql-dev
experts_sched
JimmyPeilinLi-patch-1
ErvinXie-patch-1
ksft-llama
glm47_fp8
debug_llama
refactor_sft
ljq-cli-dev
refactor_sft_int4_debug
lut-nvfp4
fix-import
fix-deploy-djw
cpu-fix
ljq-dev-1
route-moe
sosp25-ae
v0.7.2
paper-ktft-v1.1
paper-ktft-v1
v0.7.1
v0.7.0.post4
v0.7.0.post1
v0.7.0
v0.6.4
v0.6.3.post1
v0.6.3
v0.6.2.post3
v0.6.2.post2
v0.6.2.post1
v0.6.2
v0.6.1
v0.6.1.post1
v0.5.3
v0.5.2.post1
v0.5.1
v0.5.0.post1
v0.5.0
v0.4.4
v0.4.3
v0.4.2
v0.4.1
v0.3.2
v0.3.1
v0.3
v0.2.4post1
v0.2.4
v0.2.3post2
v0.2.3post1
v0.2.3
v0.2.2
v0.2.2rc2
v0.2.2rc1
v0.2.1.post1
v0.2.1
v0.2.0
v0.1.4
v0.1.3
v0.1.2
v0.1.1
v0.1.0
Labels
Clear labels   
bug

   
duplicate

   
enhancement

   
good first issue

   
help wanted

   
pull-request
Mirrored from GitHub Pull Request

  
stale
No labels
bug
duplicate
enhancement
good first issue
help wanted
pull-request
stale
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
kvcache-ai/ktransformers#800
No description provided.