vLLM 这篇 Kimi K3 优化，842 tok/s 那个数我反而没太在意。那是按合成接受长度 AL=6 跑的，AgentX 上的 1.8 倍也是拿 1… · @prolibertine · TwKit

@prolibertine

vLLM 这篇 Kimi K3 优化，842 tok/s 那个数我反而没太在意。那是按合成接受长度 AL=6 跑的，AgentX 上的 1.8 倍也是拿 16 张 GB300 去比之前 8 张的结果，口径有点松。不开投机解码、batch 1、TP16 是 256 tok/s，比原版快 1.88 倍，这个更实在。每层从 23 个 kernel、130 微秒压到 13 个、69 微秒。 文里更值得看的是他们自己承认的一句：agent 写出来的推理代码，已经快过他们 review 和维护的速度了。每个 kernel 逐行看懂根本看不过来，不看又怕线上出事。 他们的办法是改要求 agent 交什么。优化只许动这个模型自己的代码，支持哪些硬件、多大 batch 先划清，但全长上下文、结构化输出这些功能不许砍；测试得真跑到改过的那条路径上，最后拿 MRCR、AIME25 这种长上下文、长生成的评测兜底。 他们举了两个例子。编译器把激活读取挪到了同步等待前面，普通功能测试过了，审计才翻出来；还有几处数值问题，单独跑 kernel 测试复现不了，长评测里才冒头。 放到别的行当也一样，agent 产出一快，瓶颈就挪到验收上。人要审的是证据和边界，一行行读代码那套撑不了多久。

曝光 3 · 评论 0 · 点赞 0 · 书签 0