推理服务商Baseten在9月初发一篇博客，给LLM推理优化提出了一套分类语言：一类技术是在延迟、吞吐、成本之间做权衡，比如调batch大小、换并行策略、上量化；另一类技术是把整条“效率前沿”向外推，比如优化底层kernel、上推测解码、做prefill/decode分离。默认场景是拿GLM-5.3或Kimi K3做agentic coding，还默认开着KV cache复用和KV感知路由。
这套说法听起来很像一次工程洞察，但拆开看，它更接近一份没有坐标轴的地图——方向画得很清楚,却没标哪个点对应哪块硬件、哪个模型、多少并发。
两类技术，一个老问题的新说法
“效率前沿”这个词借自经济学,指资源约束下能拿到的最优组合。放到推理引擎里,batch size越大,单个用户等得越久,但GPU利用率越高,单位token成本越低,这是几年前continuous batching成熟后就摆在桌面上的老权衡。张量并行（TP）适合压延迟,专家并行（EP）拉宽了能撑吞吐,量化则同时改善延迟和吞吐,只是把代价转移到了模型质量上——尤其是低精度格式如MXFP4、NVFP4,这条前沿本身就很“锯齿”,不是一条平滑曲线。
真正有意思的是第二类:那些让延迟和吞吐同时变好的手段。kernel优化、推测解码（EAGLE-3、DSpark、DFlash）、prefill/decode分离,理论上是在给整个系统腾资源,腾出来的效率可以随便分配给速度或者规模。Baseten还举了个具体案例:KV感知路由在生产环境里让首token时间（TTFT）降了大约2倍。这是目前这篇文章里唯一有点分量的数字。
KV路由的2倍提速，具体但不通用
这个案例值得多说一句，因为它把默认场景里“KV感知路由已经开着”这个假设,变成了一个可感知的数字。KV感知路由（比如NVIDIA Dynamo的路由器）根据每个worker上缓存的prefill片段和当前decode负载打分,而不是简单轮询,这样能让重复请求命中缓存,少走一次昂贵的prefill计算。
但Baseten自己在文档里也承认，这个2倍是workload-specific的结果,不是通用引擎基准。agentic coding场景天然对这类优化友好——代码补全的上下文重复度高，前缀复用率也高。换成短对话、长文档摘要或者RAG这种低缓存复用的场景，同一套路由策略能带来多少提升，原文没说，档案里的检索也没找到公开数据。
- 结论.KV路由和推测解码在“高前缀复用”的agentic场景下收益最实在，离开这个场景收益会明显打折。
谁在讲同一套故事，谁又没给证据
几乎同一时间，Google Cloud发了一篇框架高度相似的文章，同样用continuous batching、paged attention、路由、推测解码、量化搭出一张“五种技术抵达效率前沿”的图。两家公司不约而同用了同一套比喻，这本身比任何一家的具体技术清单都更说明问题——“效率前沿”正在变成推理服务商共用的营销话术，而不是谁的独家洞见。
第三方评论者Superpower Daily点出了最扎实的一条批评:Baseten全文没给GPU型号、没给模型版本、没给并发扫描区间、没给prompt/output长度分布，也就没有任何一条曲线是可以被别人复现的。vLLM、TensorRT-LLM、SGLang三个主流推理引擎之间也不存在谁全面占优——vLLM/Speculators团队自己在做EAGLE-3、DSpark、DFlash等推测解码方案对比时，测试范围局限在Qwen3-8B、Qwen3-30B-A3B、Gemma-4-31B-IT这几个模型加特定硬件组合上，并明确警告结果会随模型架构和任务变化。
概念讲得清楚，坐标从未标出，这才是这类框架文章最该被追问的地方。
对做agentic coding类应用的开发者来说，实际能做的不是照抄Baseten的默认配置，而是拿自己的真实流量——固定住硬件和模型版本，扫一遍并发和前缀复用率，分别记录TTFT、单token间隔、p95/p99延迟和单位成本，再看这条曲线长什么样。别人画的效率前沿，终究是别人的workload画出来的。