为什么推理比训练重要 12 倍

François Chaubard 把今晚的 YC Paper Club 定成推理夜。他开玩笑说自己不知道推理该画成什么样，所以幻灯片是万圣节主题，然后转到他真正关心的问题：凭什么要为推理服务这么较真？

他说 YC 一直在看推理，因为他以前做过一家 AI 公司，训练和推理都重要，卡住的永远是推理。要在规模上做好、还不被销售成本——COGS，有些做软件的人从来没学过这个词——把利润吃光，很难。

过去十年，把推理做对比大约多出了 2200 亿美元市值。今晚台上有四家公司；Together AI 也在阵容里，由研究负责人 Dan Fu 代表。

Chaubard 喜欢拿训练 FLOPs 和推理 FLOPs 比，而 DeepSeek 是少数两边都公开的实验室。训练 DeepSeek V3 大约要 280 万 H800 小时。每天推理大约 4.3 万 H800 小时——这个数字已经旧了，真实负载更高。

就算用这些过时数字，这份权重文件一年的推理 FLOPs 也大约是训练的 6 倍。给文件两年可用寿命，推理大约重要 12 倍，共享同一套权重的用户越多，这个比例还会往上爬。

所以他写论文或挑模型时，希望大家尽量压训练 FLOPs——并且对推理 FLOPs 多上心十二倍。大多数 NeurIPS 的 scaling 图，包括 Chinchilla，横轴仍是同等训练 FLOPs。这个领域该开始画同等推理 FLOPs 了。

模型服务商真正靠的是 COGS。刚出来的数字暗示 DeepSeek 毛利率大约 80%，有人被吓到；Chaubard 的读法是，毛利来自他们在推理侧发明了多少东西。

如果推理服务就是一次 `model.forward`，这些事凭什么复杂？对不住在 LLM 栈里的人来说：请求以 token ID 进来。你对 prompt 做 prefill——除非这段前缀已经在缓存里，最好是 DRAM 里的热数据，或者在 LRU 后面的 Redis、SSD 之类的地方。

然后是 decode 循环。训练和 prefill 时，模型 FLOP 利用率（MFU）也许能到 50%：黄仁勋承诺 2×10¹² FP8 FLOPs，你拿不到那么多，一半已经算赢。Decode 可能只有 5%。这里随便一点，代价很贵。

Fu 和其他人盯的 KPI 是：首 token 时间（prefill 要多久）、每一步 decode 的每输出 token 时间、吞吐（每 GPU 小时多少 token），以及有效吞吐（你真正按服务水平交出去的 token）。

DeepSeek 刚公布的数据中心数字：prefill 不含缓存命中大约每 GPU 6 万 token/s，输入缓存命中率 96%，命中时每 GPU 150 万 token/s。首 token 时间大约 400 毫秒，P99 大约一秒。Decode 吞吐每 GPU 1.4 万 token/s——对照缓存命中的 prefill 那 150 万——所以芯片设计者在追的瓶颈是 decode。

缓存命中率由流量形状决定。智能体复用前缀，这些数字会很好看。家长新开一个 ChatGPT 线程——「天气怎么样？」——完全没有 KV cache，每次都付全额 prefill，所以不是每个产品都能看到那 150 万。

现场抓住的数字是 KV cache 保留时间。DeepSeek 在用户闲置后仍把 PB 级的用户 KV 状态留 72 小时，96% 的输入缓存命中率才有可能。这既是存储和隐私政策，也是 kernel 技巧。

另一个行话是算术强度：你从 DRAM 搬 4 字节到 SRAM，在上面做多少 FLOPs？RNN 和扩散很强——传一张图或一份噪声，反复砸同一套权重。LLM 很差，这就是上一期 Paper Club 讲者 Volo 给扩散语言模型找的理由。Chaubard 实验室里 Herman 的下一个概念模型，也是同一路。

模型 FLOP 利用率和模型带宽利用率问的是：H100 标称的 2×10¹² FP8 FLOPs 和 TB 级内存带宽，测试时你真正拿到多少。屋顶线分析取峰值 FLOPs，与每秒字节数乘以每字节 FLOPs，两者的较小值——你最好能好到哪里的上界。

Chaubard 把推理工作分成三堆，哪条想法该进哪堆，照例会吵。第一，模型创新：混合专家，K 个 expert 大约能把测试时 FLOPs 摊成 1/K；SSM 和稀疏注意力，这样不必每层都付全额注意力；以及多头潜注意力，在序列维上压缩。

量化——有些演示已经到 2 bit——和蒸馏在同一堆。一旦你有一个宁可不去服务的大模型，如果活只需要小的，就蒸馏成小的。

第二，kernel 和 runtime 创新：RadixAttention、FlashAttention、PagedAttention。这里很多是经典操作系统和数据库理论。前缀树和基数树是生产数据库变快的办法；Tri Dao 在 FlashAttention 里对 GPU 做 tiling，是一次大跳跃；PagedAttention 是 GPU DRAM 的虚拟内存和缓冲池，按 Chaubard 的讲法，它和基数注意力互斥。

第三，harness 创新。好懂的是路由——Focal 做过——不是每个请求都打到那个又大又血腥的模型上；你可以瀑布下去，或只在需要时用工具调用升上去。投机解码跑一个草稿模型，大模型来验证。Chaubard 最喜欢的是递归语言模型：永远不要把完整上下文倒进 KV cache；让模型去取它需要的，缓存会小很多。每个 harness 都必须做压缩；他和 Sabri、Dan Simran 的一个实验室项目做出了「cartridge」。

想听更深一讲的人，他指向 Percy Liang 的 CS 336 第 10 讲，以及 Dwarkesh 对 Ryner Pope 的访谈。然后他把晚上交给靠这个吃饭的人：Together AI 研究负责人、Hazy 校友 Dan Fu；Ollama 创始人兼 CEO Jeffrey Morgan；Luminal 创始人兼 CEO Joe Fioti；以及 SGLang 核心开发者、论文第二作者 Liangsheng Yin，他刚发短信说要晚到。

Dan Fu 感谢 Chaubard 的总览，说他会走完一次推理请求的整个生命周期：从 API 往下穿过数据中心，到 GPU 上的 kernel，再把 token 送出来。这场是更长一版的压缩；幻灯片上有六个加速，他划掉了一半。

开源 AI 从未这么大。Together 一个略旧的数字：每月 400 万亿 token。差不多同一时间 Google 公布了 Gemini 流量，这家「不起眼的小创业公司」大约做到了八分之一。今年早些时候，OpenRouter 超过一半的 token 是开源模型；市场部要他提一句：Together 曾经有一天在 token 量上超过 OpenAI。

这些开源模型还便宜。质量几乎一样——有时一样甚至更好——每年成本最多能低 10 倍。Together 花很多时间问：怎么给所有想要 token 的人，在世界上造出更多 token。

Together 想做一家 AI 原生云：AWS 的类比，但面向你建一家 AI 公司需要的那些块——预训练、微调、推理，以及给智能体的沙箱。公司大约 80 名研究员，很多是博士，现在盯着让 GPU 更好用。

负载不一样。做编码时，他们关心缓存命中率、你让 Claude Code 或 Cursor 去建东西时轮次之间的空闲、生成代码必须流得多快，以及首 token 对整段回复完成的 SLA。这些约束驱动优化。

请求打到 REST API，会走普通互联网——Cloudflare、DNS——落到装着 KV cache 的数千块 GPU 集群上。先是请求级路由：这份活该给哪个副本。然后人类文字变成 0 和 1。然后是 prefill 和 decode 的批循环。然后 token ID 再变回文字。

路由是负载均衡加缓存亲和。旧的 Web 服务世界里，你用轮询躲开热机器。语言模型里，把同一用户送回已经吃过他代码库的那块 GPU 是赚的，因为后续轮次可以跳过那份活。本事在于把负载摊到各个数据中心，同时别错过已经驻留的 KV cache。

分词看起来简单，其实不简单，因为请求带着工具调用进来——搜索、grep、一条构建命令、互联网。模型是矩阵乘法和注意力；它不会浏览。你交给它一份工具列表，它吐出一次调用，你必须把 schema、恢复，以及分词器层面的解析做对。Jeff 会从用户侧接着讲。

核心调度器把进来的流组批：等一块空闲 GPU，或等上一个请求结束。这些选择定下吞吐对延迟的取舍。同一批 GPU 上更多用户，还是更快的首 token。Fu 的例子是 Google 搜索里的 Gemini：第一个答案非常快，后面聊天感觉更慢——多半是调度不同，也许连模型都不同。

Prefill 是处理 prompt。把整份代码库倒进去，GPU 必须理解它；这受算力限制，MFU 高，算术强度高。Decode 一次吐出一个或几个 token。每个词都要把全部权重从 GPU 内存重新装到计算单元上：受内存带宽限制，完全另一种动物。Together 花很多时间把这两件事拆到不同的 GPU、并行方式和 kernel 上。

GPU 做完活，token ID 被反分词，作为文字流回去。Fu 说这是管道里看起来简单的那一头。剩下的策略问题是：什么时候释放 KV cache，这些 token 要驻留多久，好让下一轮能复用。

Together 大概想六个杠杆。Kernel 是 GPU 程序：注意力、MoE、mega-kernel。拆分把 prefill 和 decode 放到不同 GPU 上，这会改变用户体验和每 GPU 的 token 数。并行是体量逼出来的：Kimi K3 按 FP4 是 3 万亿参数，大约 1.5 TB，一块 B300 只有 280 GB，模型必须切开——怎么切，就是并行问题。

路由，请求进了数据中心之后，是给哪个副本。最后两个杠杆更靠近模型：投机解码，小草稿模型去猜大模型的下一个 token，对上了就留下；以及量化——每个权重实际存多少 bit。时间不够，Fu 只讲 kernel、并行和量化。

Kernel 要紧的是 prefill 和 decode 里的数学：矩阵乘法、注意力，以及其他。有些算子好调；LayerNorm、RMSNorm 和散落的 softmax 算术强度极低，单独给它们写 kernel 会浪费 GPU。这也是历史上端到端训练 FLOP 利用率大约 50%、decode 大约 5% 的一个原因。

老办法是盯着前向，找出能挤的地方，再派一组 kernel 工程师进去。Together 一直在用智能体自动做这件事——内部项目叫 Together Compiler，Fu 承认它其实不是编译器，以后会换个更好的名字。

这个循环由真实流量驱动，因为编码负载和聊天负载点亮的 kernel 不一样，他们坚持走完整的生产研究循环。这是推理侧递归自我改进循环的开始。

并行存在，是因为权重装不进一块 GPU；切开能换来算力和带宽。张量并行把一次矩阵乘法切开，最后做 reduce。流水线并行一层一层切网络。数据并行把不同序列送到同一套权重的副本。游戏是每 GPU 的内存、你能写哪些 kernel，以及互联允许什么。

DeepSeek 每 GPU 小时 38 美元这个数字，一个核心驱动是大规模 scale-up 域。直到最近，NVIDIA GPU 只能八块高带宽互通，所以你切八路；切十六路就掉到慢路径上，服务就死了。新机架把 72 块 GPU 高带宽连在一起，于是可以把单个 MoE expert 放到不同 GPU 上。

一块 GPU 上一个 expert、服务海量 token，看起来又像一次肥的矩阵乘法——GPU 擅长的那种。专家并行的演示已经有好几年；新工作是让它可靠。GB 机架会掉节点。如果一组 72 卡副本依赖每一块芯片，一块挂了，你就丢了 72 块 GPU 的算力，除非你能补救。Together 一直在建这种韧性。

量化看起来简单：几百篇论文，挑一个方案。其实不简单，因为它打到终端用户质量。模型用 BF16 训练，每个参数两个字节；3 万亿参数的模型是 6 TB。计算是模糊的，所以常常能收到 8 bit 或 4 bit，答案仍然对。Together 死磕的问题是：哪套方案能保住体验。

他们从系统侧知道，硬件为了每 GPU 的 token 想要哪种量化。他们也知道有人在这些端点上建公司。模型上线前，Together 自己先用：Claude Code 搜不了，就会看见坏掉的工具调用；更笨的模型会在基准和端到端评测上露出来。

有一个循环让每个模型反复写 Flappy Bird。鸟不拍翅膀了，量化就搞坏了什么。真正的游戏是严格的评测循环：基准、智能体评测、内部试用——而不只是一个聪明算法。

一个成功案例：他们和 MiniMax 合作上线 M3，他还漏嘴说了 M3.1。MiniMax 当时很难量化到 NVFP4，Together 想要这个格式，因为它是 NVIDIA GPU 上对的格式。幻灯片上，原始 FP8 模型是淡紫；MiniMax 自己的方案是亮粉；Together 的橙色方案对得上原始模型，这意味着更多 token，以及一条从训练走到能赚钱的推理的路，好让 MiniMax 去养下一个模型。

回顾：请求被路由到一个副本，带着工具调用被正确分词，排队组批，做 prefill 和 decode——常常在不同 GPU 上，用不同 kernel 和并行——然后 token 才回来，给编码和聊天用。

如果你的 CFO 正在为 Claude Code 的账单喘你脖子，他有一个开源模型的销售二维码；如果你想做这件事，另一个码是招聘。掌声，然后提问。

一位听众有两个问题。第一，Together 怎么拿 NVFP4 质量和 MXFP8 原版比——GSM8K、困惑度、MMLU？第二，是什么样的互联跳跃，让 Grace Blackwell 芯片能在旧的八卡域之外做成 mesh？

Fu 说他们公布几项公开基准，有的已经饱和：AIME 到了 90 多分。动一分就是现实世界的警告。他们还看各层激活的 KL 散度，然后是从每次过往失败里刮来的几百个端到端智能体案例，再加上 Flappy Bird 这类循环，以及把模型喂回 Together Compiler。如果模型再也优化不了自己的 kernel，就出问题了。

说到 NVLink，他不是硬件的人——他最接近硬件的经历是一只 Hugging Face 小盒子。GB 机架很狂：每托四块 GPU 用粗线缆打进一个大交换机，all-reduce 走那条路。他不是从 8 卡跳到 72 卡的专家；他只是很爱用。

再被追问他们实际拿什么测——因为买家永远看不见那套私有套件——Fu 重复这个组合：公开基准、他们自己的智能体循环，以及中间的一切。没有单一分数能告诉你量化站住了。

另一个问题关于 MiniMax 量化图：他们是从头训练、多跑了预训练轮次，还是只把数字转了一下、没有微调？那根亮粉柱看起来像一次天真的类型转换。

很多方案量化之后还想再训一遭。Together 躲开那些，除非你自己握着原始数据集——模型会忘事。他们给 MiniMax 做的是免训练：校准数据、一篇他们发布的叫 Scale Search 的论文，以及对那一百种免训练方法里到底组合哪几种，做得非常勤勉。

Chaubard 在必须往下走之前再塞进最后一个问题：decode 侧 Fu 还在等哪些新架构——SSM、扩散语言模型，以及其他可能让 decode 不那么受内存带宽限制的想法？

Fu 的博士做的是 SSM，当时的说法是没人会用，transformer 会吃掉世界。几年后它们进了大模型。Kimi K3 的 KDA，略有争议地，是一层 SSM 风格的线性注意力。稀疏注意力闲置很久，现在在生产里。扩散语言模型现在是默认的投机者。

他的学生一直在玩循环模型：让 token 多次穿过同一组层，这样可以拉高训练 FLOPs，却不增大权重。他们觉得这是个怪想法。后来发现 OpenAI 和 Anthropic 已经在做。他说，现在抛出一个能跑的架构想法，它可能出现在 GPT-6 或 GPT-7 里；从想法到产生影响，时间已经这么短。

Ollama 联合创始人兼 CEO Jeff Morgan 把镜头拉开：开源模型的 token 并不都一样。Chaubard 的幻灯片已经列了一堆推理公司；很快会有几百、几千家服务商。如果你在开源模型上构建，你需要一套办法，跨它们衡量质量。

Ollama 2023 年起步，是一个在本地跑开源模型的开源项目。当时流行的模型——Llama 和朋友们——能装进一块 H100、一台笔记本或一台小服务器。目标一直是给开源权重做出 OpenAI 和 Anthropic 级别的开发者体验。

后来模型变得巨大。今年早些时候 Kimi、GLM 和 MiniMax 交出了 5000 亿到万亿参数的模型，Ollama 上线了 Cloud，让开发者把本地那套体验带到数据中心。它已经成了美国和欧洲最大的独立开源模型云之一。

这意味着他们花很多时间，在很多模型、很多服务商之间做出一致的开发者体验：最新权重、速度、可靠性。其中很大一块活在 Fu 刚讲的那个路由盒子里。不同服务商擅长不同模型；可靠性和抢先用上最重要。

这套架构，看起来就像 Ollama 的财富 500 强客户离开闭源模型、为了成本或掌控时自己会建的东西。理想情况下，路由靠汇聚服务商拿到全世界最好的。同一家服务商内部也会出现同样的问题：不同硬件、地区、团队和引擎。

头条挑战：不是每个人都用同一种方式上线模型，这同时也是特性，因为团队优化方式不同，有人甚至在世界各地的 Mac mini 上跑。客户关心成本、智力、速度，以及地区/隐私。这四项里任何一个坏苹果，都会变成最小公约数。

失败模式包括过度量化、坏硬件、错误的权重版本，以及工具调用。解析 JSON 看起来简单；从失败调用里恢复、强制 schema、把分词器层面的解析做对，并不简单。采样方案各不相同。定制 kernel 和 KV cache 精度，只在长上下文里露馅。有时模型甚至被套上错误的名字上线，而每个聊天机器人仍声称自己是友好助手。

这不是新闻，规模比坊间传说更糟。人人都在谈开源对闭源的差距。单看开源模型，最差服务商和最好服务商之间的差距，可以比那个开源闭源差距更大。Together 和某个其他端点给人的感觉可以像两个产品，你事先看不见，因为 OpenAI 和 Anthropic 训练人们去期待一致的 token。

2024 年一篇论文测了 31 个 Llama 端点，发现有的表现更接近 GPT-3.5，而不是另一份同样的 Llama。编码智能体上问题会严重得多：长上下文、长地平线，一次调用接一次调用。一个不算难的 15 步编码任务，每步相对目标输出偏 10%，大约会错 79%。80% 的出错率会毁掉产品，智能体负载越难，这件事越糟。

你没法亲手读每 GPU 160 万 token。蛮力办法是评测。Artificial Analysis 跨服务商重跑基准并排名。Kimi K2 上，多数服务商挤成一团；右边几个偏了。评测能抓住糟糕量化，因为它们测的是模型当初怎么打分。又贵又慢，所以你没法持续跑。

去年年底 Moonshot 受不了服务商在 Kimi 上做工具调用的样子，交出了 Kimi K2 工具调用校验器和排行榜。它掀起了一场把调用做对的竞赛。其他实验室也做过类似的事。如果你训练了一个模型，给人一套测试 harness，就是确保他们跑对的办法。

Ollama 正在看的一种更便宜的路由办法是分布检验：把服务商 API 和参考权重比，量差距。一次测试大约一美元，对照天价基准账单。它可能漏掉细微的量化损伤，也说不出为什么，而且你仍然需要一份在跑的参考模型。

Logprob——下一个 token 的概率分布——更便宜：一个 token，对照基线，看端点有没有漂。他们是不是换了地区、升级了 vLLM 或 SGLang、打了补丁？有一篇论文用这个办法找出一堆静默服务变更。坏处是：很多 API 不再暴露 logprob，而且你只能看见相对过去的漂移，所以一个一开始就差的起点会一直看不见。

Ollama 现在做的是不留用户数据的请求形态内省：工具调用通过率、错误、输出长度分布。DeepSeek 风格的引擎进过死循环；你可以从请求形态抓住它。请求接请求，维持一个滚动分数。OpenRouter 那种 Exacto 风格的路由，属于同一路。

北极星是开源权重上接近 OpenAI/Anthropic 的体验。那些实验室跑在 TPU 上，足够在意到一个很小的 TPU kernel bug 会变成质量复盘。开源生态里怎么走到那一步？实验室可以交出大得多的服务栈，而不只是 Hugging Face 权重，外加应用团队写的、并不是他们内部在跑的示例代码。

DeepSeek 刚开源了 DeepInfer，它的定制推理引擎，于是你可以拿着权重，有一定把握去瞄那个每 GPU 小时 38 美元的数字。实验室也在和 Fu 这样的团队合作，上线前就量化，让 API 和开源文件对得上——不像旧世界里，第三方事后量化才能塞进 MacBook。发布官方量化权重正在变成常态。

你也可以把工具调用和推理提取拉到 harness 里，让每个服务商都按同一种方式解析。Morgan 觉得有一家创业公司可以做：给模型处在关键循环里的应用监控 LLM 质量。还有一篇他喜欢的论文：现代 NVIDIA GPU 有可信执行环境，能证明权重和服务软件——一枚指纹，证明你跑的是真东西。超前，但有意思。

一位听众问多轮智能体的 prefill 准入间隔——工具调用对长上下文 prefill——问题没完全落到点上。Morgan 指着 logprob 那页：发一个单 token 的 prompt，对照基线随时间量 logprob。你可以把 prompt 拉长，看上下文过 20 万 token 时下一个 token 的准确率，有些服务商会在那里悄悄截断窗口。这不是完整评测，而这正是重点。

有人问量化方对着公开评测爬山：如果排行榜就是目标，你就没有在保住模型。Morgan 听过这种担心，尤其在一个冲向最便宜 token 的市场里。Ollama 和客户的做法是服务商看不见的、针对流量的私有测试，质量投诉通常也是这样进来的——把环闭合。

Chaubard 说他最初把 Ollama 当本地运行时用，行业冲向云，而 Recursive 的 Flint 发布（Richard Socher）之后，本地模型又回来了。这对 Ollama 意味着什么？

Morgan 说现在本地栈很多——Apple silicon 上的 MLX 在那里驱动 Ollama。一位听众提到 Calibri 从磁盘上服务 Qwen 3.5 MoE。同样的质量问题存在于桌面、他们刚拆箱的 DGX Spark、M5 Ultra，以及公司自己的 GPU 小房间。不只是服务商；每周更新的引擎也是。

他们很高兴做 Recursive 的 Flint 的发布伙伴。开源模型是蛮荒西部：Ollama 和 Hugging Face 上每样东西都有二十种量化，这正是意义所在，也是你如果给客户做线上服务、就需要比完整基准更轻的测试的原因。在本地，这个问题同样重要。

他认为 Ollama 的未来是人们混着用。今年最难的编码任务需要云端模型；MacBook 上超强的本地模型会把一部分活拉回来。路由问题不再是云服务商对云服务商，而变成本地对云。谢谢，掌声。

Luminal 联合创始人兼 CEO Joe Fioti 说他们是一家编译器公司，这听起来少见，直到你注意到编译器就是 GPU 小时到 token 的转换函数。这个函数好不好，决定你亏钱、赚钱，还是赚很多钱。

他们的编译器建立在等式饱和上，这是一种相当新的技术；他们相信自己是最大的工业用户，也是把模型编译到多种硬件上的正确办法。他认为 NVIDIA 数万亿美元价值里很大一块，是 CUDA 有一套支持很好的软件生态。把模型映射到复杂芯片上，仍然没有解决。

对他们来说，更好的教训是编译期搜索。这样可以跳过一动物园的改写启发式，以及每次新模型出来都要重写的 kernel 库。一个很小的共享编译器核心，给推理 ASIC 的后端，他们跑在 NVIDIA、AMD、TPU、Trainium 和其他加速器上。

任意时刻他们大约在做每月 80 或 90 万亿 token——不是 Together 那个量，但他们只有八个人。这场演讲讲为什么对 LLM、扩散，以及真正赚钱的生物模型，这条路比典型的 MLIR 栈更好：egglog、等式饱和是什么意思、他们怎么组织 IR，以及怎么把搜索做大。

神经网络没那么复杂：稠密线性代数，算子甚至都不多。Luminal 把模型煮成大约 14 或 15 个原语——加、乘、求和，诸如此类。整个 PyTorch，大约 2000 个算子，都能不丢信息地拆进这一套。他们不是图灵完备；Fioti 喜欢说他们是 PyTorch 完备。

他们甚至没有矩阵乘法原语：一次矩阵乘法是一次广播乘法加一次求和归约。这种 RISC 风格的瓶颈，让你避开从每个 PyTorch 算子到每个硬件算子的全对全映射。

超优化是 1990 年代的编译器研究想法，从未在生产里起飞。它说你应该用代价函数搜索程序的每一种形态，而不是事先知道怎么降低。降低空间是指数的。普通厂商雇编译器团队，每个新模型、后端和数据类型都跟着涨——500 或 1000 人，仍然是一个不完美的编译器。

另一条路是很小的原子改写规则，陈述等价，然后让搜索决定何时应用什么。等式饱和正是做这件事：写小的等式规则，把搜索空间长大，再走一遍。

IR 是一张计算图 DAG。E-graph 非破坏性地应用这些规则。普通改写做模式匹配再替换，把匹配到的毁掉——你最好当时是对的，因为回不去。在 e-graph 里你加上右侧，两边都留着。按每一种顺序应用每一条规则，直到不再出现新东西：饱和。然后抽出具体图，编译，在硬件上跑，计时。

一张图：从 A × 2 / 2 开始。规则把图长大——A × 2 是左移一位，诸如此类——直到饱和的 e-class 里既有原来的除法，也有 A 本身。你证明了 A × 2 / 2 = A，却没有人去写那条启发式。

改写规则是 Lisp，因为引擎作者喜欢 Lisp：交换律，x + y = y + x（在 IEEE 浮点里并不完全成立，这是一个很长的旁支），常量折叠，让已知的 a + b 从运行时程序里消失。

这套原语 IR 跨后端共享。每块芯片带来自己实现的算子，层次不同：一个读写 SRAM 的 GPU tensor-core MMA 是其中一种。你给新后端画像的办法，是写改写规则，把那些算子等同于编译器已经理解的东西；等价会传播。加上一块看起来完全不像上一块的硬件，工作量相对很小，这就是你避开庞大编译器团队的办法。

硬件是分层的：线程、warp、thread block（一个 SM）、一块 GPU、一个节点。IR 是多层的，好让厂商库和社区 kernel 插在它们真正编程的那一层。等式饱和是跨这些语义说什么等于什么的正经办法。

例子：从 CPU 来的主机级 cuBLAS 矩阵乘法；来自 CUTLASS、cuBLASDx 或 Hazy Research 的 ThunderKittens、给单个 GPU 核心编程的 thread-block 算子。因为编译器能跨层推理，它可以把更低层的子图融进一个 mega-kernel——也可以不融。Mega-kernel 很时髦，在非常大的模型上并不总是最优，所以一次前向可以两种都混。

最后一个问题是代价模型：你怎么说程序 A 比 B 好？一份准确的 GPU 代价模型是许多个博士的工作。八人公司没法给每块芯片写一份。本着 bitter lesson 的精神，最好的代价模型是没有：在真实硬件上跑候选。纸上看着傻的招，有时在 GPU 上会赢。

他们不会给 e-graph 里的每个程序做 profiling。子图上的屋顶界让他们剪掉那些即便最好情况也打不过已测等价物的东西。不过多数时候，他们仍然在自己真正要服务的芯片上量。

一段 kernel 代码生成的短视频信息量不大；只是看起来很酷。然后是例行广告：他们做成了少见的事，让一家编译器公司赚钱。他们跑一套异构云——每月 80 万亿 token、几百万张图——因为编译器是通用的，他们会服务蛋白质折叠和其他「古怪」模型，而不只是流行的 LLM。八个人，在招人，把古怪硬件商品化。他说 lumina.com，指的是 Luminal。

有人喜欢 RISC 风格的 IR，问他们把机器学习放宽的数值性质嵌进了多少。Fioti 提过 IEEE 754 里的结合律；机器学习常常不在乎归约顺序。这是进语言本身，还是只进代价模型？

结合律和交换律要紧，因为它们改变数值精度。树状求和不是顺序求和。数值搞砸了，输出 token 质量就搞砸了，正是 Morgan 讲的那种服务商质量问题。他们显式地给精度建模。有些改写仍然有用，因为硬件不对称：NVIDIA tensor core 可能从 SRAM 取输入 A，从另一块内存空间取输入 B。

另一位提问者看不出怎么给每个候选在硬件上跑整个模型，如果你只给一个 kernel 做 profiling，会漏掉争用。另外，搜索空间看起来比已经很慢的 TensorRT 还大一个数量级。

Fioti 说，一次全模型 profiling 可以不到 10 毫秒，所以大约每秒能跑一千次。搜索用的是标准工具，主要是遗传算法；像 MuZero 那样的学习式搜索是以后的事。他们大概只探索空间的 1% 的 1%，也不追求全局最优——只要一个大约 99% 那么好的局部最优，这容易得多。

编译时间是明确的取舍：推理客户不在乎你编译一天，只要结果在数百万块 GPU 上快 1–10%。用户设一个时间预算——一小时、十小时——直到收益递减。它合理地扩展，直到不再合理。

他们会不会把生产 profiling 喂回搜索，还是纯编译期？他们用的形状尽量接近云运营商能拿到的真实流量：他们知道客户会送来的张量尺寸。改写规则假定是对的，所以他们与其核对应案，不如给行业相关的形状计时。

调试一个把许多架构降到许多芯片上的编译器很痛苦。Luminal 把 PyTorch 的高层算子标签留作元数据，用 PyTorch profiler 找瓶颈，并倚仗 egglog 的礼物：如果输出程序错了，要一份证明——从输入到输出的那串改写——找到那条无效规则。

一位评论者喜欢把不支持的算子踢回 CPU，但在 IR 里展开算子通常会伤害融合。延迟代价是什么？Fioti 说他们确实会融合。展开是为了到达原语 IR；降低时会再次搜索融合形态。屋顶线检查如果显示一个 kernel 多搬了一个数量级的 DRAM 流量，就足以否决它。中间层看起来是展开的；搜索必须找回那些模式，再融回去。

有人听出来这门语言不是图灵完备，所以不受 Rice 定理约束：你可以推理程序会做什么。他们在哪里用这一点？

这是故意的。超优化在 1990 年代死在 C 上，C 是图灵完备的，编译空间近乎无穷。他们编译稠密线性代数，只是全部程序里很小的一片——PyTorch 完备，不是图灵完备。他们可以解析地数内存空间之间搬了多少字节，推导屋顶线，而不必跑模型，所以他们剪得这么狠，profiling 的空间这么少。

搜索包不包含量化、投机解码和并行，还是只有 kernel？一般来说不包含。他们拿一张前向图，在这一次前向内部端到端编译，然后住在 vLLM 和 SGLang 里，搭那些引擎的投机解码。论点是：大部分 alpha 在复杂的并行拓扑和一团乱的前向；他们不搜索引擎层。

RadixArk 的 SGLang 核心开发者 Liangsheng Yin 开玩笑说，他以为这是论文阅读俱乐部，准备了一半讲 SGLang 原论文、一小块讲当前开源工作，然后现场又加了几页幻灯片。

故事从 2023 年底开始，当时人们手里的开源模型是 Llama，智能体负载还是猜测：工具调用、并行子智能体，有点像未来的 Claude Code。如果你分叉一个子智能体，大量上下文共享在同一个 KV 池里，后续 prompt 很短——进出发动机很多次。当时没有服务引擎能高效复用前缀。

所以他们做了 RadixAttention：自动复用共享前缀，只算新的后缀。所有智能体上下文作为一棵树活在引擎的内存系统里——实现上是基数树——而不是每个请求孤立的 KV 团块。

画面是一段很长的系统提示，然后一个智能体做认证、另一个做评审，共享那段提示，做不同的活。内存有限，所以后缀会被驱逐。内存管理真的就是那棵基数树，调度也围着它建。

驱逐时，内存不够就丢掉用不到的叶子，策略按负载调。感知缓存的调度要紧，因为 prompt 是交错到达的。如果你重排它们，可以按复用上下文 A 的顺序组批，而不是把 A 和 B 交错、冒着驱逐的风险。这个想法让 SGLang 变成了服务引擎：内存系统里的一棵基数树。

到 2024 年中，他们把它做成了通用 LLM 引擎——0.2 版——覆盖 Llama 8B 到 Llama 3.1 405B 的在线和离线服务。组批、驱逐和前缀匹配，都意味着给等待中的请求排序、赋优先级。

GPU 变快了；CPU 没有。朴素调度准备第一批、跑、把结果拷回来，再准备第二批。GPU 还慢的时候，不到 10% 的空泡没关系。GPU 更快之后，CPU 侧的空泡就明显了。

重叠调度把设备到主机的同步推迟一轮，让关键路径上没有阻塞的东西，并在 GPU 还在跑当前批时准备下一批。第一批还在跑，就发射第二批。DeepSeek 刚发布的推理栈用了同样的零开销想法。在 Hopper 上相对朴素也许是 1.1 倍；在 GB 设定的 Blackwell 上可以到 2 倍。

智能体和缓存的故事还在继续，因为 GPU 内存永远太小。用户过几分钟、几小时或几天再回来。你必须把前缀放在某个地方。这就是 HiCache，现在已经是标准招数：GPU 内存、主机内存和内部存储当作 L1、L2 和 L3。每个 token 可以住在其中一层，策略管命中率和加载时间。他们的实验里 TTFT 降了 56%。

朴素 transformer 不适合长上下文和便宜部署，所以架构一直在变：开源和闭源模型里的滑动窗口注意力、循环或 Mamba 风格的状态、Kimi 的 KDA、按 token 更新的固定形状内存。天真的修法是每种层类型一个内存池。这并不简单，因为缓存共享必须在它们之间一致。

要在位置 10 命中缓存，你必须匹配到那里的全量注意力 KV。如果滑动窗口是 4，你还需要 token 7–10；如果只留到 8，就没有窗口命中，只能重算。要在 10 共享前缀，你需要恰好在 10 的循环状态。分开管这些池，高效共享会变成一团乱。

把缓存命中率从 95% 拉到 99%，不是 4% 的赢：算力大约能砍 5 倍。每个池一棵基数树带来兼容性头疼，锁住一段前缀意味着在一套外部策略下协调全量注意力层、窗口层和循环层。

统一基数树不再把这些组件当成独立的。它是覆盖完整 token ID 的语义树——无论什么架构，仍然有 token——其他内存挂在这个控制器上。每个组件保留自己的匹配、驱逐和内存规则，但树来协调它们，这样智能体负载不会泄漏或浪费内存。

负载对配比意见不合。用户 A 活在 4K 上下文，用户 B 在 128K，另有人在一百万 token。全量 token 缓存必须覆盖长的那些；滑动窗口也许只需要最后 128。你没法按固定比例预分配池子，还在一台引擎上服务所有人。

所以除了统一树，他们还做了统一内存池。以前按算出来的比例预分配。现在分配一整堆物理内存，没有每池上限：全量 token 缓存从一边长，窗口 KV 和循环状态从另一边长，按用量来。长上下文拿到更多全量 token 页；短上下文把更多让给窗口和状态。

大多数 kernel 想要连续的物理内存。自由分配和驱逐，会打出两个池子在中间碰头时无法复用的洞。压缩用低延迟拷贝 kernel 把碎片打包，并重映射虚拟页 ID——虚拟 ID 不动；只改底层映射。这才让混合服务灵活。

他们也把 SGLang 风格的推理带进了训练循环。Miles 是 RadixArk 的强化学习框架，完全异步跑，生成和训练不停；SGLang 做 rollout。他希望你看见这条弧：RadixAttention，然后是通用开源引擎，然后是 Miles 甚至扩散，给开源 AI 基础设施加油。

他以下个月的 SGLang 峰会收尾——特邀讲者、一个报名二维码——并开放提问。时间没了，所以没有问答。Chaubard 感谢 Yin 和整晚其他人，Paper Club 结束。