“不需要升级整套——你的部署更完善（锁版、systemd、鉴权、Claude Code 补丁），且 DSpark 在你机器上的实测数字（贪心中位 34.7）高于远端 MTP 的报道值。

值得单独摘两条过来（低风险、有实测收益）：

1. CPUSET 绑核：--cpuset-cpus 5-9,15-19 → 预期 +2–7%
2. GDN 池修正：96 → 8×4=32 槽，释放状态内存给 KV 池（并发 8 不变）

两条都只需重建容器，不碰模型权重。”

微信上一声令下，远端的 Hermes 就吭哧吭哧开干！每 10 分钟汇报一次进度。直到调优结束，又跑了两轮测试。

【调优后把测试报告发给DeepSeek V4 Flash 请他给写个总结】

本次针对 Qwen38 DSpark 推理服务完成了 CPU 调度与 GDN 状态内存两项联合优化。通过将容器固定到 10 个 3.9GHz X5 大核，降低了 draft 生成、验证循环及 radix cache 管理等 CPU 关键路径的调度抖动；同时将 max-mamba-cache-size 从 96 修正为与当前并发需求匹配的 32，释放约 1.2GB 状态内存用于扩大 KV cache 空间。

在相同 bench.sh 探针下，greedy 中位吞吐从 34.7 tok/s 提升至 45.7 tok/s，相对提升约 32%。其中 code 提升约 38%，reasoning 提升约 24%，free prose 提升约 12%；math 场景的峰值从 43.6 tok/s 提升至 53.2 tok/s，但该场景仍存在较大波动，需要增加样本进一步验证。

两次综合复测分别达到 45.8 tok/s 和 45.7 tok/s，差异仅约 0.22%，说明本次性能提升具有高度重复性，并非偶发结果。综合判断，原配置同时存在 CPU 调度和状态内存过度预留问题，两项改动在 DSpark 架构下形成了明显的协同优化效果。