2026-09-19 00:00:00
上一篇文章《vLLM PK Ninfer, 到底谁的速度更快?》里说”等我再压榨压榨，把 Qwen 3.8 27B 的速度整到极限”。现在迷上了 AI 模型调优，今天就把 Qwen 3.8 27B 压榨到了极限：
下面是两组配置（124 和 104）的真实端到端吞吐对比，均包含 TTFT，五项中位数也全部由 124 领先：
| 工作负载 | 124 | 104 | 124 领先 |
|---|---|---|---|
| 新代码，单流 1024 token | 65.88 tok/s | 64.19 tok/s | +2.64% |
| 重度代码编辑，单流 1024 token | 122.90 tok/s | 96.19 tok/s | +27.77% |
| 中文解释，单流 512 token | 33.22 tok/s | 32.05 tok/s | +3.65% |
| 8 路并发，每路 512 token | 296.89 tok/s | 180.37 tok/s | +64.60% |
| 5K prefill | 3176.10 tok/s | 2127.73 tok/s | +49.27% |
TTFT 同样明显改善：
| 项目 | 124 | 104 | 降低 |
|---|---|---|---|
| 新代码 | 0.103 s | 0.365 s | 71.84% |
| 重度编辑 | 0.842 s | 2.062 s | 59.19% |
| 中文解释 | 0.102 s | 0.430 s | 76.29% |
| 8 路并发 makespan | 13.80 s | 22.72 s | 39.27% |
| 5K prefill | 1.582 s | 2.361 s | 33.01% |
太爽了，错过算力舱就错过了世界上性能最快的 Qwen 3.8 27B。
2026-09-19 00:00:00
最近发现很多人说 Ninfer 这个专门为 Qwen 系列优化的推理框架性能很猛。
我这两天用 Qwen 3.8 27B 测试了一下，在开启 CUDA Graph 的情况下，反而 vLLM 性能更强，Decode 和 Prefill 性能全面超越 Ninfer。
Qwen 3.8 27B 的 Fresh Code 解码速度最高达到 63.34 TPS，Prefill 最高达到 3230 TPS，TTFT 更是低到 0.15 秒。
下面是 Ninfer 和 vLLM 两组配置的基准测试数据，vLLM 是优化后的配置：
| 性能指标 | Ninfer | vLLM | Ninfer 相对 vLLM 的性能差距 |
|---|---|---|---|
| 新代码 Decode | 55.57 tok/s | 63.34 tok/s | -12.3% |
| 重度编辑 Decode | 83.38 tok/s | 80.59 tok/s | +3.5% |
| 中文说明 Decode | 40.19 tok/s | 37.84 tok/s | +6.2% |
| 新代码 TTFT 性能 | 0.374s | 0.150s | -59.8% |
| 4.3K TTFT 性能 | 2.081s | 1.363s | -34.5% |
| 5K Prefill | 2,042.62 tok/s | 3,230.79 tok/s | -36.8% |
| 8x512 并发吞吐 | 170.92 tok/s | 232.47 tok/s | -26.5% |
| 8x1,024 并发吞吐 | 209.60 tok/s | 254.97 tok/s | -17.8% |
| 250K Prefill | 327.91 tok/s | 720.10 tok/s | -54.5% |
| 250K TTFT 性能 | 762.659s | 347.278s | -54.5% |
可以看到，在绝大多数场景下 vLLM 配置都更快，差距最悬殊的是 250K Prefill 和 250K TTFT，Ninfer 相对 vLLM 落后了 54.5%。
vLLM 优化后，三类单流 Decode 提升约 8.6%～14.5%，5K Prefill 提升 60.7%，并发吞吐提升约 15.6%，250K Prefill 提升 13.6%。
等我再压榨压榨，把 Qwen 3.8 27B 的速度整到极限。
2026-09-19 00:00:00
不需要 ComfyUI 即可用 MiniMax H3 生成视频。
昨晚对 MiniMax H3 做了一个优化，通过把 BF16 Qwen3-VL 32B 这个编码器做了量化，把 64GB 显存占用压缩到 16GB，这样编码器就可以和 H3 的视频生成模型共存。
通过这样的优化，就可以把原来 H3 只能生成预先准备好的提示词，改成通过编码器实现一个”文本翻译器”，把用户的文字提示词转换成视频模型能理解的数据，最后交给 MiniMax H3 生成视频。
最后直接通过调用 MiniMax H3 的 API，文本即可生成视频，不需要安装 ComfyUI。
2026-09-18 00:00:00
DeepSeek 模型调优并发技术分享。最近都在调优 DeepSeek V4 Flash 的 TP2 模型，简单来说就是两台算力舱同时通过 TP2 的技术跑 DeepSeek。因为两台机器的显存总共超过 256 GB，所以即使是非常大的 DeepSeek 也可以提供 1MB 的超大上下文。
最近用户反馈多个并发的时候，第二个 Prefill 会等很久。今天上午研究了一会，发现跟 vLLM 的 --long-prefill-token-threshold 参数有关。
--long-prefill-token-threshold 是限制单个 Prefill 请求一次调度迭代中最多处理的 Tokens 数量，默认是 2048，最大可以设置成 4096。
最开始我移植 DeepSeek 的时候，觉得这个值设置为 2048 肯定够了。早上研究才发现，这个值不能设置得很大。因为太大了，vLLM 就会让第一个 Prefill 充分执行；当 Prefill 的值达不到 2048 的时候，后续的 Prefill 就会被排队。
需要调小这个值，给 vLLM 增加调度多个 Prefill 的机会。我测试了一上午，最后发现 1024 这个值最好。
当设置为 1024 时，8 并发同时请求，后续的 Prefill 可以从最大的 90 秒的等待时间下降到 7 秒左右，而总吞吐只下降了 2.5%。
如果继续下降到 512，虽然后续请求的 TTFT 还会继续下降，但是总吞吐量就会下降到 15% 以上。
https://manateelazycat.github.io/pics/deepseek-tp2-prefill-tuning/prefill-threshold.png
从上面的测试数据可以看出：
今天的 AI 模型调优核心技术就分享到这里。欢迎大家购买懒猫 AI 算力舱 + 懒猫微服套餐，CEO 亲自给你调优 AI 模型性能，把设备的性能压到极限。
2026-09-16 00:00:00
我还是太爱 Qwen 3.8 27B 了，虽然没有 GPT 那么全能，但是只要是明确的任务，详细说好了，真的是指哪打哪。
很多朋友会问为什么不用解码速度更快的 Qwen 3.8 Flash Next？因为我这两三周都在做 AI 模型移植的工作，我发现 Qwen 3.8 Flash Next 这个模型训练的还是不够严谨，上下文非常长的时候，会出现乱码的情况，只能靠 Pi Agent 温度配置来缓解，而 Qwen 3.8 27B 各种稳定呀。
我现在都用 GPT 做规划，让 27B 去执行，效率杠杠的。
用 Pi Agent 配 Qwen 3.8 27B 修复博客视频问题的过程：
