ktransformers 框架 v0.2.4 post1版本并发性能测试 && 系统资源占用对推理性能影响测试

测试环境

CPU	内存	GPU	系统版本
8461v * 1	DDR5 4800*8	3090 24G	Ubuntu 22.04

另外，测试使用官方发布docker v0.2.4post1镜像。

测试模型

• DeepSeek-R1-Q4_K_M
• DeepSeek-R1-UD-Q2_K_XL
• DeepSeek-V3-0324-Q4_K_M

测试项目

1. 并发性能测试

测试步骤如下：
a. 测试单并发下吞吐数据，并以此作为基准性能；
b. 测试4并发下吞吐数据，并关注显存、内存占用情况；

测试结果：

模型	并发数	prefill (token/s)	decode (token/s)
DeepSeek-R1-Q4_K_M	1	约 40 - 50	10 左右
DeepSeek-V3-0324-Q4_K_M	1	约 40 - 50	10 左右
DeepSeek-R1-UD-Q2_K_XL	1	约 50-60	13 左右
DeepSeek-R1-UD-Q2_K_XL	4	30 + 17 + 27 +17 ≈ 91	3.9 + 4.8 + 4.5 + 5.4 ≈ 18.6

另外，显存、内存占用数据如下（命令参数–max_new_tokens 4096 --cache_lens 32768 --chunk_size 256）：

模型	并发数	显存占用	内存占用
DeepSeek-R1-Q4_K_M	1	15981MiB	369.9g
DeepSeek-V3-0324-Q4_K_M	1	16705MiB	369.9g
DeepSeek-R1-UD-Q2_K_XL	1	15724MiB	214g
DeepSeek-R1-UD-Q2_K_XL	4	15724MiB	214g

由上述测试数据可得：

1. 在单路CPU场景下，并发可提升总吞吐量约 40%（多轮测试下来约 30% ~ 50%，手动测试数据不严谨）；
2. 资源占用只与启动命令配置的参数有关（最大token生成数、并发数量），在启动服务后，无论是否启用并发线程，均不影响资源占用；

另外，这里注意到Q2.71动态量化版本模型占用显存与Q4KM版本基本一致，或许是因为Q2.71量化版本保留了密集层专家的4位精度，这与KT框架将密集计算部分放置到GPU的思路一致，使得显存占用并未降低，但内存占用是与模型大小趋势基本一致的。

2. 测试系统资源占用对推理性能影响

在加载完Deepseek模型后，显存资源还剩余约8G，这里通过以下测试来验证多个模型并行（占用显存、GPU算力、内存）情况下，KT框架推理性能是否受到影响。

2.1 占用显存情况

测试模型：ktransformers + DeepSeek-R1-UD-Q2_K_XL
陪测模型：llama.cpp + qwen2.5-7b-q4_K_M

测试前置（环境）：
– 在KT框架加载模型完成的情况下，使用llama.server加载qwen2.5-7b_q4_K_M.gguf模型（显存占用约7G）

测试步骤：
a. 在qwen模型仅加载到显存，未触发推理的情况下，收集KT模型吞吐量数据；
b. 在KT模型推理过程中，使用qwen模型并行进行推理，收集KT模型吞吐量数据；

测试结果：

是否占用显存	是否占用算力	prefill (token/s)	decode (token/s)
是	否	55	13
是	是	54	5.7

结论：仅占用显存时，KT框架推理性能不受影响，占用显卡算力时，KT Prefill性能基本不受影响，decode性能受到较大影响；

2.2 占用内存/CPU情况

测试模型：
– ktransformers + DeepSeek-R1-UD-Q2_K_XL （内存未溢出情况）
– ktransformers + DeepSeek-R1-Q4_K_M（内存溢出，使用共享内存情况）
陪测模型：llama.cpp + qwq-q4_K_M

说明：由于测试环境总内存为384G，加载Q4模型后内存占用约98%，此时模型可以全部运行在内存中，当加载了qwq模型后，由于内存不足，此时会有部分共享内存（nvme pcie4硬盘）被使用，此测试目的：验证内存溢出情况下，KT框架是否优先占用实体内存。

测试前置（环境）：
– 在KT框架加载模型完成的情况下，使用llama.server加载qwq-q4_K_M.gguf模型（内存占用约19G）

测试步骤：
a. 在qwen模型仅加载到内存，未触发推理的情况下，收集KT模型吞吐量数据；
b. 在KT模型推理过程中，使用qwq模型并行进行推理，收集KT模型吞吐量数据；
c. KT加载Q4模型，同时将qwq模型加载到内存不推理，收集KT模型吞吐量数据；
d. 在KT模型推理过程中，使用stress占用CPU，但为KT保留足够的核心（strss+kt核心小于系统总核心数），收集KT模型吞吐量数据；
e. 在KT模型推理过程中，使用stress占用CPU，且占用部分KT核心（strss+kt核心大于系统总核心数），收集KT模型吞吐量数据；

模型	是否占用内存	是否占用算力	prefill (token/s)	decode (token/s)
Q2.71	是	否	60	12.4
Q2.71	是	是	41	8.8
Q4	是	否	5	4
Q2.71	否	是（未占用KT核心）	46	12.5
Q2.71	否	是（占用KT核心）	19	1.9

结论：

1. 只占用内存，内存未溢出时，若未占用推理资源，则KT推理性能不受影响，若占用推理资源，则KT Prefill、Decode性能均受影响（这点与显存不同）；
2. 若占用内存导致内存溢出，则Prefill、Decode性能均大幅下降。
3. 占用空闲CPU，但有足够资源给KT使用时，KT Prefill性能受影响，Decode性能不受影响；
4. 占用空闲CPU，使KT没有足够计算资源时，KT Prefill、Decode性能均受较大影响；

总结

根据上述测试，这里可以得到系统性能与KT吞吐性能的关联关系：

系统资源	Prefill性能（有无关联）	Decode性能（有无关联）
GPU空闲显存	无	无
GPU空闲算力	无	有
CPU空闲算力	有	无
空闲内存	无	无
内存带宽	有	有

因此根据上述结论，在不影响KT推理性能的前提下，利用服务器资源的正确方式应当是：

1. 不占用内存，CPU密集型任务，可以在限制占用的前提下与KT服务并行；
2. 需要占用一定内存的任务，可以与KT服务错开执行；
3. 需要占用显卡资源，且不会导致显存溢出的任务，可以与KT服务错开执行；
4. 任何会导致内存或显存溢出的任务，都不应执行。

转载声明：此博文未经本人允许，不得转载，请勿爬取