Inside the Inference Stack Feat. Together, Ollama, Luminal, SGLang | YC Paper Club

Together AI 通过优化 GPU 利用率和量化技术，把单 GPU 每秒 token 产出做到 150 万，推理毛利率高达 80%。

开源模型真正的差距，藏在推理服务商

Dan Fu 是 Together AI 研究负责人，Jeffrey Morgan 是 Ollama 联合创始人兼 CEO，Joe Fiaty 是 Luminal 联合创始人兼 CEO，Leon Shaw 是 SGLang 与 Ready Start 的总裁。四个人站在云推理、模型路由、编译器和开源推理引擎的不同位置，却在讨论同一件事：一份模型权重，怎样才能稳定地变成用户拿到手的 token。这里的竞争不只是“模型够不够聪明”，还包括它是否被正确量化、是否留住了上下文、GPU 是否真的跑满，以及服务商有没有发现模型正在悄悄变样。

这期回答了 7 个问题：

1. 为什么同一个开源模型，换一家推理服务商，效果可能比换成闭源模型还大？
2. 训练模型与服务模型，创业公司到底该把优化资源押在哪一边？
3. KV Cache 为什么让“负载均衡”不再只是把请求平均分给机器？
4. 为什么推理编译器宁可花一天编译，也要在真实硬件上反复试错？
5. 模型量化后跑得更快，怎样确认它没有悄悄变笨？
6. 没有读取用户数据，路由平台怎样持续发现某家供应商的模型服务变差了？
7. SSM、扩散语言模型和循环模型，会怎样改写下一代推理成本？

被问及如何比较不同推理提供商的模型质量时，Jeff 给了一个很反直觉的判断：不要把“模型名”当成最终产品。2024 年一篇论文测试了 31 个不同的 Llama endpoint，也就是向外提供同一模型调用接口的服务地址。结果是，理论上同款的 Llama，有些表现已经更接近 GPT-3.5，而不是其他同款 Llama 服务。差异不必来自模型本身，可能出在权重版本、量化方式、采样策略、KV Cache 精度、推理引擎，甚至工具调用时的 tokenizer 处理上。

Jeff 的结论很直接："the gap between the worst provider for a model and the best provider is actually bigger than the gap between closed and open models."（同一模型最差与最好的服务商之间的差距，实际上可能大于闭源与开源模型之间的差距。） 这会改变企业的采购方式。过去可以问“该用 Llama 还是闭源模型”，现在还得问：哪一版权重、哪套服务栈、在哪个地区、由谁运维。

这种差异在一次问答里不一定显眼。真正危险的是 coding agent 这类长链路任务：一次任务大约走 15 步，如果每一步存在 10% 的输出偏差，最终出错概率可能高达 79%。单步看似“差一点”，连续叠加后却可能让 agent 根本走不到正确终点。短 benchmark 因此只能测出一部分问题，长上下文、多轮工具调用和多代理协作，才更接近真实的压力测试。

主持人 François 用 DeepSeek 公布的数据提出了一个账本问题：模型训练完成后，它还要在生产环境里跑多久、服务多少人？DeepSeek V3 的训练约用了 280 万 H800 小时，而其日常推理约为每天 4.3 万 H800 小时。按这个速度，同一份权重在一年内消耗的推理 FLOPs，也就是浮点运算量，约为训练时的 6 倍。如果一份权重能有效服务两年，这个倍数就来到约 12 倍。于是 François 的判断是："then it should be 12x more important."（那么它就应该重要 12 倍。）

这不是说训练忽然不重要，而是模型团队的优化目标要换算方式。训练阶段节省 1% 的算力，只发生一次。推理阶段少搬一次内存、少算一个重复前缀、让单张 GPU 多吐出一点 token，会在每天数万 GPU 小时里不断复利。尤其是生成阶段的 decode，也就是模型逐个输出 token 的环节，账单最容易失控。DeepSeek 公布的数据中，含缓存命中的 prefill 吞吐可达每秒 150 万 token，decode 则约为每秒 1.4 万 token，后者是明显瓶颈。

这也解释了为什么“GPU 理论算力”并不等于可售卖的 token。模型处理输入提示词的 prefill 更像大批量计算，生成答案的 decode 却要反复从显存取权重，受内存带宽限制更重。边界也存在：如果模型权重几周就被新版本替换，或者产品始终没有持续流量，推理相对训练的倍数会收窄。但只要模型能长期在线，推理就不是训练后的尾声，而是主要成本发生地。

被问到 SGLang 为什么最初要为 agent workload 设计 Radix Attention 时，Leon 回到了 2023 年末的一个判断：未来 agent 会不断分出子代理，它们会共享一大段背景，却各自处理不同的后缀任务。KV Cache 是模型处理过上下文后留下的中间状态，可以把它理解为“读过的内容留下的工作记忆”。如果两个子代理都带着同一份代码库和系统提示词进来，重算两遍就是把 GPU 时间倒进下水道。

SGLang 的做法，是把共享上下文放进类似 Radix tree 的树状内存结构中，只计算新出现的 suffix，也就是各自新增的后缀。内存紧张时，系统优先驱逐未使用的叶节点，而不是把仍被多个请求共享的前缀一起清掉。调度也不能再简单轮询：若 A、B 两类请求交错进入，A 的共享前缀可能在 B 的挤压下被驱逐；把请求重排成 cache-aware 的顺序，才能让同一前缀连续命中。

Leon 还把缓存扩展成分层结构：GPU 内存、主机内存和存储分别对应 L1、L2、L3。短期热数据留在 GPU，较久未用的上下文往下沉，需要时再取回。"In our experiment, this can lower the TRFT by 56%."（在我们的实验中，这可以把 TRFT 降低 56%。） 这意味着 agent 的性能不再只看单卡跑多快，更看系统是否认得出“这些请求其实在读同一份东西”。不过，缓存不是魔法：共享代码库、长期会话和多代理协作收益很大；每次都从零开始的新聊天，几乎没有前缀可以复用。

被问到 Luminal 为什么不用传统启发式编译，而选择 equality saturation 时，Joe 讲的是编译器的规模问题。传统做法像让工程师替每种模型、数据类型和硬件组合写一套“如果看到这种图，就用那种优化”的规则。模型架构越多，Nvidia、AMD、TPU、Trainium 等硬件越杂，规则组合就越膨胀。Joe 认为，团队可能因此扩到 500 甚至 1,000 人，仍然很难覆盖所有情况。

Luminal 先把 PyTorch 模型拆到约 14 至 15 个原始操作，例如 add、multiply、sum。连看起来很基础的 matmul，也会被拆成 broadcasted multiply 和 sum reduction。接着，它不急着指定唯一的优化路径，而是用等价变换不断生成候选程序图。不同于传统重写规则“改了就回不去”，equality saturation 会保留等价的多种写法，最后再从中挑执行最快的版本。

关键是怎么判断快。成本模型，就是用公式预测某段程序在硬件上的耗时，但现代 GPU 的内存、线程和核函数行为太复杂。Joe 的答案是："the best cost model is no cost model"（最好的成本模型，就是没有成本模型。） 候选方案直接编译到真实硬件计时，一次完整 forward pass 的 profiling 可在约 10 毫秒完成。Luminal 以 8 人团队运行每月约 80 至 90 万亿 token，正是把人力从维护海量规则，换到搜索和实测上。代价也很明确：编译可以花数小时甚至一天，但推理客户通常愿意用这段等待换取 1% 到 10% 的长期运行时提升。

被追问 Together 如何验证 NVFP4 量化质量，以及如何帮助 MiniMax 服务模型时，Dan 把量化从“压缩权重”的小技术，讲成了上线前的质量门禁。量化的目标，是用更低精度表示模型权重，减少显存占用和数据搬运，从而让同一批 GPU 生成更多 token。但少用比特不等于自动省钱：若模型在工具调用、复杂推理或长任务里突然失灵，吞吐再高也只是更快地产出错误。

Together 建了多层检查：内部 dogfooding，也就是员工先拿模型做真实工作；公开 benchmark；端到端 agent 评测；以及数百个由历史故障沉淀的测试案例。他们还让 agent 反复生成 Flappy Bird 游戏。如果量化后模型连让小鸟按规则飞行都做不好，团队就知道问题不只是某个分数掉了一点，而是推理链条可能断了。MiniMax 曾难以把模型量化到 NVFP4，Together 最终做出的版本匹配了原始 FP8 模型的表现，并将其用于服务该模型。

Dan 特别强调训练后不再训练的 training-free 路线。原因不是不能继续训，而是服务方通常没有完整的原始训练数据。如果量化后拿有限数据再训练，"the model will forget things."（模型会遗忘一些东西。） 公开 benchmark 也并非万能：一些分数已接近饱和，Dan 的经验是，波动超过 1 个点才可能意味着真实能力出了问题。因此，量化团队要测的不是“模型还会不会答题”，而是“用户真实的工作流是否还完整”。

被问到路由平台怎样在不逐条阅读用户 token 的情况下监测供应商时，Jeff 的回答是：监控对象不能只有延迟、错误码和价格，还要包括模型行为本身。一个服务商可能换了量化方案、升级了推理引擎、换了硬件，接口仍然返回 200，模型却已经悄悄漂移。对于把 LLM 放进业务关键链路的公司，这种“没报错但变笨了”比宕机更难处理。

一种办法是分布测试：把参考权重的输出与 API 输出做分布比较。另一种是看下一 token 的 log probabilities，也就是模型对不同候选 token 给出的概率分布。它的成本很低，一次请求只需观察少量输出，适合持续检测服务栈是否发生静默变化。但现实限制很朴素："Log Probs isn't on a lot of the APIs these days"（如今很多 API 都没有提供 Log Probs。） 即便拿得到，它更擅长发现“和过去不一样了”，却未必能说明一开始就是否正确。

还有更轻量的方式：不保留用户内容，只看工具调用失败率、请求形状和输出长度。模型若陷入无限循环，输出长度会异常；工具调用不断报错，也能构成报警信号。更前沿的方案是利用现代 Nvidia GPU 的 trusted execution environment，理论上可证明运行的是哪份权重、哪套服务软件。问题在于行业还没有银弹：分布测试和行为指标便宜，却往往只能发现漂移；完整 eval 能定位能力退化，却昂贵且难以持续跑。未来的“LLM 可观测性”，要补上的正是这层空白。

被问及哪些新模型架构最可能改善 decode 效率时，Dan 的答案不是押注某一个“下一代 Transformer 替代者”，而是指出很多过去被当作边缘思路的结构，已经开始进入真正的模型和服务栈。Kimmy K3 的 KDA，本质上属于 SSM 或 linear-attention 风格层。SSM 是状态空间模型，可用固定状态保存部分历史信息，不必每层都做完整注意力计算；稀疏注意力也已进入实际模型。

Dan 还提到，Together 已把 diffusion language models，也就是扩散语言模型，用进 speculative decoding，并称这是当前最好的做法。投机解码的思路是先让较小模型起草若干 token，再由大模型验证，正确的部分就能更快交付。另一条线是 looped models：让 token 多次经过同一组层，在不增加模型权重的前提下增加训练 FLOPs。Dan 的团队原先以为这很另类，后来发现 OpenAI 和 Anthropic 都在使用类似想法。

"the time to feedback and and time to impact is is so so quick now."（如今从获得反馈到产生影响的时间都非常非常快。） 这意味着研究选题和工程成本开始直接相连。一个结构只要能证明既能训练、又能在真实推理里省掉内存搬运或 decode 时间，就可能迅速进入主流服务栈。不过边界同样清楚：SSM、稀疏注意力、扩散语言模型和循环模型未必都会成为通用组件。有些会成为基础设施，有些只适合特定模型和特定请求形态，答案仍要靠生产环境来筛。

“开源与闭源的差距，可能小于同模型不同服务商的差距”，和“量化不是把精度调低，而是一次产品级质量审计”，指向的是同一件事：模型权重不是最终产品。用户买到的不是 Hugging Face 上的一组参数，而是服务商把参数放进硬件、缓存、调度、量化和工具调用链条之后，持续交付出来的行为。

同样，“推理路由的核心不是均分流量，而是让上下文留在原地”，与“推理编译器的护城河，不是更多规则，而是更敢让硬件实测作裁判”，也都在回答一个问题：怎样让同一份权重少做无用功。前者避免重复读上下文，后者避免凭经验猜硬件，最终都是把 GPU 时间尽可能变成可靠 token。

如果你在做 AI 产品，模型选型不该止于比较排行榜。还要看长任务会不会累积偏差，缓存命中是否符合自己的流量形态，量化后工具调用是否仍然可靠，以及供应商变更服务栈时你能否及时发现。模型能力决定上限，推理生产链决定用户每天实际摸到的那一部分。