跳到正文
DEV Community· cognitalk·· 4 小時前AI 評分53

YC Paper Club 分享實錄：為何大模型推理的重要性是訓練的 12 倍

Why Inference Matters 12x More Than Training -- YC Paper Club | YC Paper Club分享实录：大模型推理的重要性是训练的12倍

AI 導讀

YC Paper Club 多位講者以 DeepSeek-V3 的訓練與日常推理用量估算，指出模型權重使用 2 年時，推理算力消耗可達訓練的 12 倍。分享梳理 Prefill、Decode、KV Cache、調度、內核、量化及編譯器優化，也指出同一開源模型在不同推理服務商可能出現質素差異。

正文

cognitalk


https://www.youtube.com/watch?v=mHNKuH-9OxU

YC论文俱乐部｜推理远比训练更重要：大模型推理系统、编译器与开源服务实践

说明：这份是YC Paper Club分享实录，多位行业专家依次演讲，核心观点：大模型推理的重要性是训练的12倍，围绕LLM推理成本、KV Cache、调度、内核、量化、编译器、开源推理服务质量、SGLang技术展开。

通俗整体解读

简单说：训练大模型是一次性“造模型”，推理是千千万万用户实际提问、AI输出答案的过程。很多人只关心训练算力，但真实业务里推理消耗算力是训练的十几倍，也是赚钱、控成本的关键。

打几个比方：

  1. 训练 vs 推理：训练好比花几个月打磨一本超级厚的百科全书；推理就是成千上万的人天天翻阅这本书。写书只花一次功夫，但无数人翻阅的总工作量，会是写书的十几倍。也就是文中说的推理重要性是训练12倍。
  2. Prefill（预填充）vs Decode（解码）：你一次性把一大段问题粘贴给AI叫prefill，像一次性读完你的全部问题；AI一个字一个字往外输出回答叫decode。解码是最大性能瓶颈，GPU实际算力利用率经常只有5%。
  3. KV Cache缓存：相当于把你刚刚读过的书页临时放在高速桌面上，下次接着聊不用重新再读一遍整本书；桌面空间（显存）有限，太久不用的书页要挪到硬盘。缓存命中率越高，花钱越少、回复越快。
  4. 推理质量坑：同样的开源大模型，不同云服务商跑出来效果不一样。就像同一本正版书，有的复印店复印模糊、缺页，哪怕书名一样，读起来体验天差地别。
  5. 推理编译器：相当于翻译官，把大模型代码翻译成GPU硬件最高效听得懂的指令，不用人工手写海量优化代码，靠搜索找最优执行方案。

分段详细要点（按文档token占比估算时间百分比）

第（一）部分 开场Francois演讲：为什么推理的重要性是训练的12倍（0%‑24%）

  1. 推理业务的现实商业价值
    • YC做大量推理赛道投资；演讲者本人曾经运营AI公司，实际落地中推理永远是业务瓶颈；推理直接决定销货成本COGS，是很多软件从业者容易忽略的指标。
    • 过去十年推理相关公司累计创造2200亿美元市值；DeepSeek公开的数据可以用来对比训练算力与推理算力。
  2. 12倍重要性的来源：训练FLOPs对比推理FLOPs
    • DeepSeek‑V3训练消耗约280万H800小时；日常推理消耗43000 H800小时/天，还只是旧数据，真实数值更高。
    • 按一年周期计算，推理算力消耗是训练的6倍；如果模型权重实际使用寿命按2年算，推理算力开销达到训练12倍；随着用户越来越多，推理占比会继续变大。
    • 批评现在很多学术论文只对比训练算力（ISO train flops），呼吁学术界更多关注ISO推理算力，做模型选型要把推理开销权重放大12倍看待。
    • 举例DeepSeek依靠推理侧创新，实现约80%毛利率，证明推理优化直接决定企业利润。
  3. LLM推理底层两个核心阶段：Prefill预填充、Decode解码
    • Prefill：处理用户输入prompt、token序列；可以利用KV缓存，如果输入已经缓存，不需要重复跑prefill；可以使用LRU缓存策略，把KV数据放在显存、内存甚至SSD，以此节省算力开销。
    • Decode循环：逐个生成输出token，是最大性能瓶颈。
    • GPU算力利用率MFU指标：prefill阶段MFU大约50%；decode解码阶段GPU利用率可能低至5%，硬件大部分算力被浪费。
  4. 推理系统关键KPI指标定义
    • Time to first token（首token时延TTFT）：prefill处理完，拿到第一个输出token的耗时。
    • Time per output token：每生成一个输出token耗时，代表解码速度。
    • Throughput吞吐量：每GPU小时产出多少token数量。
    • Goodput有效吞吐量：在满足服务质量SLA时延约束下的实际有效token产出。
  5. DeepSeek公开真实线上业务数据
    • 不命中缓存时，单GPU prefill吞吐量60000 token/s；输入KV缓存命中率96%。
    • 缓存命中场景，单GPU吞吐量高达150万token/s。
    • TTFT平均400ms，P99首token时延1s；decode阶段单GPU吞吐量14000 token/s。
    • 明显差距：prefill吞吐量远高于decode，解码才是真实业务瓶颈；KV缓存数据量达到PB级别，缓存保留时长设置72小时是高命中率的关键。
    • 业务场景差异：Agent业务缓存命中率高；普通普通闲聊、每次全新提问场景几乎没有缓存，需要反复执行prefill。
  6. 算术强度Arithmetic Intensity概念
    • 算术强度：从内存读取固定字节数据，能够执行多少次计算。
    • 扩散模型、RNN算术强度很高；LLM大模型算术强度很差，内存带宽成为限制。
    • 相关新架构：Diffusion‑LLM、SSM可以提升算术强度。
  7. 硬件性能衡量指标：MFU、MBU、屋顶线分析Roofline
    • MFU模型FLOPs利用率：硬件标称算力和推理实际达成算力的比值。
    • MBU模型带宽利用率：硬件内存带宽上限和推理实际使用带宽比值。
    • 屋顶线分析：程序理论性能上限，取硬件峰值算力、内存带宽*算术强度二者的最小值。
  8. 三大推理优化技术大类
    • 模型层创新：MoE稀疏专家模型、SSM状态空间模型、多头隐式注意力；量化压缩；模型蒸馏到大模型蒸馏到小模型。
    • 内核&运行时创新：Radix Attention基数注意力、Flash Attention、PageAttention；思想借鉴数据库、操作系统理论，基数树、虚拟内存分页管理KV缓存。
    • 调度框架（harness）创新：请求路由分级调度、瀑布式模型调用；推测解码Speculative Decoding；递归LM减少KV缓存占用；KV缓存压缩Compaction，文中提到Cartridges技术。
  9. 学习资源预告，引出下一位讲者Dan Fu（Together AI）
    • 推荐课程：Percy CS336 LLM from scratch Lecture10；Ryner Pope与Dwarkesh讲座。
    • 介绍到场嘉宾：Dan Fu(Together AI)、Jeffrey Morgan(Ollama)、Joe Fiaty(Luminal)、Lang Shang(SGLang)。

第（二）部分 Dan Fu演讲：一个推理请求完整生命周期，内核、并行、量化实践（24%‑49%）

  1. 开源大模型推理行业现状与Together AI介绍
    • 开源AI流量规模爆发：Together每月处理400万亿token，流量达到Gemini的1/8；OpenRouter平台过半流量跑开源模型；某些单日Together处理token规模甚至超过OpenAI。
    • 开源模型同等质量情况下成本可以低至闭源模型的1/10。
    • Together定位AI原生云：覆盖预训练、微调、推理、Agent沙箱；团队80名研究人员，核心聚焦推理性能优化。
    • 做推理优化需要针对不同业务负载做差异化优化（写代码Agent、普通聊天），关注缓存命中率、请求间隔、SLA时延约束。
  2. 一个推理API请求完整端到端全链路流程
    1. 请求路由Routing：成千上万GPU集群，不仅做负载均衡，还要尽量把重复请求发到同一个GPU，复用已经存在的KV缓存，不只是简单轮询负载均衡。
    2. Tokenization分词：不仅仅简单文本转token ID，还要处理工具调用tool call；保证工具调用解析正确性，会直接影响模型实际可用性。
    3. 全局调度批处理Scheduler：请求排队、合并batch；调度策略直接决定总吞吐量与响应速度；可以权衡：追求更高并发用户 or 追求更低延迟。
    4. Prefill预填充阶段：计算密集，MFU算力利用率高，算术强度高。
    5. Decode解码阶段：内存带宽绑定（memory‑bound）；和prefill硬件资源需求完全不一样；业界在研究prefill‑decode disaggregation（把预填充和解码跑在不同GPU）。
    6. 结果detokenization回译文本；KV缓存生命周期管理，决定什么时候释放缓存内存。
  3. 推理加速的六大方向，本次重点讲内核Kernel、并行Parallelism、量化Quantization
    • 其余方向：Prefill‑Decode分离Disaggregation、请求路由Routing、推测解码Speculative Decoding。
  4. 方向一：GPU内核Kernel优化
    • 内核就是GPU上执行的程序，矩阵乘法、注意力、Norm、Softmax全部靠内核实现。
    • RMSNorm、LayerNorm、Softmax这类算子算术强度很低，单独执行会拉低硬件利用率；这就是训练只有50% MFU、解码仅5% MFU的重要原因。
    • 传统方案：大量内核工程师手工开发、融合算子内核。
    • Together内部项目 Together Compiler（后续会改名）：利用AI Agent自动优化推理内核；以线上真实业务流量作为优化驱动；构建推理递归自改善RSI循环；针对模型+硬件+真实流量自动调优。
  5. 方向二：并行策略优化
    • 基础并行范式：张量并行TP、流水线并行PP、数据并行DP。
    • 硬件变革：Blackwell架构机柜，支持72个GPU高带宽互联；过去NVLink最多8个GPU高速互联，超过8个带宽暴跌。
    • MoE专家并行新机会：把MoE不同专家部署到独立GPU；单GPU只放一个专家，把稀疏计算变回GPU擅长的大矩阵稠密计算，显著提升吞吐量。
    • 工程难点：72 GPU大集群硬件故障率升高；单GPU故障不能让整个模型副本全部挂掉，需要高可用、故障容错机制。
  6. 方向三：量化Quantization
    • 原始训练精度BF16（每个参数16bit/2字节）；3万亿参数模型需要6TB显存。
    • 量化把权重压缩到8bit、4bit（NVFP4），降低显存占用，提升吞吐；但会带来模型质量风险。
    • Together建立完整质量闭环：标准benchmark、Agent自动化评测、内部大量dogfood真实测试；举例自动化小游戏Flappy Bird评测：如果量化损坏能力，写不出游戏就代表量化失败。
    • MiniMax M3模型实战案例：MiniMax原生NVFP4量化版本效果变差；Together使用无训练的量化配方（Scale Search技术），不需要微调重训练，校准数据+组合多种无训练量化算法，达到和FP8原始模型持平效果，帮助服务商低成本对外提供服务。
  7. 现场问答环节要点
    • 质量评测手段：不只有GSM8K/MMLU公开benchmark；还看各层激活KL散度；自建海量真实场景测试用例；Agent自动化评测；benchmark饱和后，细微分数变化很难发现真实缺陷。
    • NVLink硬件：依靠机柜内交换机+粗线缆实现72GPU互联。
    • MiniMax量化案例补充：方案属于无重训练量化，不使用模型原始训练数据集，避免模型知识遗忘，依靠校准数据与精心组合量化配方。
    • 对新兴架构看法：SSM、线性注意力、DLLM扩散大模型、循环Looped模型；很多曾经被认为没有实用价值的架构，已经悄悄进入主流大模型；学术idea落地工业界反馈周期变得非常短。

第（三）部分 Jeff Morgan(Ollama)演讲：开源模型的推理服务质量陷阱（49%‑69%）

  1. Ollama项目背景
    • Ollama最初2023目标：本地运行开源大模型，提供对标闭源模型开发者体验。
    • 模型规模膨胀之后推出Ollama Cloud，现在欧美头部独立开源模型云服务商；财富五百强大量企业使用。
    • Ollama Cloud核心组件是智能路由Router，对接多家第三方推理服务商。
  2. 核心论点： 同一套开源权重，不同推理服务商跑出来性能差距，可以大于开源‑闭源模型本身的差距
    • 市面上未来会有成百上千推理服务商；不同服务商硬件、量化版本、推理引擎内核、KV缓存实现各不相同。
    • 产生质量差异的来源：过度量化、损坏权重文件、Tokenizer错误、工具调用解析bug、采样参数差异、KV Cache精度问题、错误上下文长度限制、甚至部署错版本模型。
    • Agent场景问题放大：多轮链式调用，微小错误会不断累积；10%的单点错误率，多步coding任务最终错误率可以飙升到79%，直接摧毁业务。
    • 论文佐证：曾经31个不同Llama推理端点测试，同样Llama权重，部分端点效果接近GPT‑3.5，部分效果严重劣化。
  3. 监控推理服务质量的多种技术方案，各自优缺点
    1. 完整跑Benchmark评测套件：优点可以发现量化、大能力退化；缺点成本高、耗token，无法高频持续在线监控。
    2. 输出分布比对测试：拿参考模型输出分布，和API服务商输出分布做统计对比；成本较低；缺点很难定位根因，必须持有参考权重。
    3. Log‑probs对数概率监控：请求拿到下一个token概率分布，持续对比基线；调用成本极低；缺点很多API不开放log‑probs接口；只能检测相对于过去的漂移，如果基线本身就是错的就失效。
    4. 业务侧指标统计（无原始文本留存）：统计工具调用失败率、输出长度分布、检测无限生成loop异常；OpenRouter等路由系统采用该思路；只能发现表象，不能定位内部缺陷。
  4. 行业改善推理一致性的可行路径
    • 模型厂商发布完整可复现推理栈，DeepSeek发布DeepInfer推理引擎就是例子，第三方服务商可以直接整套部署。
    • 模型官方自己发布经过验证的量化版本，而不是社区下游自行量化。
    • 把工具调用、复杂解析逻辑上移到路由网关层，不要完全交给各个推理服务商实现。
    • 创业机会：专门做LLM推理质量持续监控服务。
    • 硬件TEE可信执行环境：GPU硬件证明当前加载权重与软件栈指纹，属于前沿构想。
  5. 现场问答要点
    • 长上下文监控：构造逐步变长prompt，监控长上下文下log‑prob漂移，检测服务商截断上下文窗口的问题。
    • 评测集被服务商“刷分过拟合”风险：使用客户私有定制评测集，服务商无法提前见过测试样例，防止刷公开benchmark。
    • 本地推理趋势：本地大模型能力提升，未来系统不仅需要云端多服务商路由，还要做本地‑云端混合路由；本地推理同样会遇到全部上述质量bug，并非只有云服务商才有问题。

第（四）部分 Joe Fiaty(Luminal)演讲：基于等价饱和Equality Saturation的AI编译器（69%‑88%）

  1. Luminal公司定位
    • 编译器创业公司；编译器直接决定GPU算力转换成token的转换效率，决定业务盈利亏损。
    • 核心技术：Equality Saturation等价饱和（egg‑log引擎），工业界较大规模落地该技术。
    • 现状：8人小团队，每月处理80‑90万亿token；支持Nvidia、AMD GPU、TPU、Trainium、各类推理ASIC硬件。
  2. 传统ML编译器痛点
    • 传统MLIR类编译器需要手写海量重写规则、算子库；模型种类×硬件种类组合爆炸；编译器团队需要几百上千人维护；新增硬件成本极高。
  3. Luminal编译器核心设计思路
    1. RISCV风格极简中间表示IR：把PyTorch两千多种算子全部拆解到14‑15个基础原语（add/mul/sum等稠密线性代数算子）；matmul矩阵乘法也拆解为广播乘法+归约求和。
    2. 编译器不追求图灵完备，但是做到PyTorch完备：只要PyTorch可以写的模型都可以导入编译。
    3. 超优化Super‑optimization + E‑Graph等价图（等价饱和）
      • 普通重写规则：匹配模式直接替换原图，丢掉旧信息，一旦改错无法回溯。
      • E‑graph等价饱和：应用等价规则时不删除旧计算图，把所有等价计算形式全部存入e‑graph；不断应用重写规则直到无法新增等价形式，这一步叫“饱和”。
      • 例子表达式 A*2/2，通过等价饱和自动发现等价于A，不需要人工专门写这条pattern规则。
    4. 放弃复杂理论代价模型，以真实硬件实测时间作为代价函数
      • 硬件性能建模难度极高；生成多个等价可执行程序，放到真实硬件跑，测量实际运行耗时，选择运行最快版本。
      • 可以结合屋顶线分析做搜索空间剪枝，不用穷举全部天文数字的方案。
      • 用户设置编译时间预算；编译阶段可以跑很久，但是编译完成后会服务海量请求，一次性编译开销可以摊薄。
  4. 多硬件后端支持方式
    • 对每款硬件描述硬件原生算子，写等价规则把硬件算子映射到内部极简IR；新增硬件后端工作量低。
    • IR是多层次，可以描述线程、线程块、SM、单GPU、多节点不同层级运算；可以调用cuBLAS、CUTLASS、ThunderKit各类外部库算子；支持自动生成Mega‑Kernel大融合内核。
  5. 数值精度的考量
    • 浮点结合律交换律不能无脑启用重写；不同归约顺序会改变浮点结果，会间接影响大模型输出token质量；编译器显式管控数值等价性。
  6. 现场问答要点
    • 编译性能：子图profiling毫秒级；不会遍历全部搜索空间，只寻找足够好的局部最优解，不追求全局最优。
    • 调试能力：e‑graph可以输出从输入图到错误输出图的完整重写证明链条，快速定位哪条重写规则出错；不支持算子回退CPU。
    • IR非图灵完备的好处：可以解析得到理论内存读写上限，做搜索剪枝；只处理稠密线性代数计算。
    • 边界：编译器只负责模型前向计算图优化；推测解码、调度、并行策略交给vLLM/SGLang推理引擎，编译器与之配合。

第（五）部分 Leon Shang(SGLang演讲)：Radix Attention基数注意力，统一内存与调度架构（88%‑100%）

  1. 技术诞生背景：Agent多子代理场景的痛点
    • Agent会大量复用相同系统提示词前缀；大量短prompt反复送入推理引擎；旧推理引擎很难高效复用共享KV前缀。
  2. Radix Attention基数注意力原始设计
    • KV缓存组织成基数树Radix Tree；多个Agent共享相同前缀KV，只保存一份拷贝；不同分支保存各自独有的后缀KV。
    • 内存淘汰策略：内存不足时驱逐未使用的叶子节点；调度器会重排请求batch，优先把共享前缀请求放一起，减少缓存被驱逐。
  3. Overlap Scheduling重叠调度
    • GPU越来越快，但是CPU处理batch准备的速度提升有限；旧调度模式下GPU会等待CPU准备batch，产生GPU气泡浪费算力。
    • Overlap调度：推迟主机‑设备同步操作；GPU正在跑上一个batch的时候，CPU并行准备下一个batch，不让GPU空闲。
    • 在Blackwell大集群场景，吞吐量提升最高接近2倍；DeepInfer也借鉴类似零气泡调度。
  4. 多级KV缓存 L1/L2/L3
    • L1：GPU显存，L2：主机内存，L3：外部磁盘存储；KV缓存可以在三级之间迁移；显著降低首token时延TRFT，实验降低56% TTFT。
  5. 新架构带来的缓存挑战（滑动窗口SSM/循环Recurrent模型）
    • 滑动窗口注意力、循环状态模型，它们的KV缓存格式和标准Full‑attention完全不一样。
    • 如果维护多套独立基数树，共享前缀匹配、内存驱逐、锁管理会出现大量兼容bug。
  6. Unified Radix Tree统一基数树（新一代SGLang设计）
    • 以原始完整token序列作为语义层构建统一基数树；滑动窗口、循环状态等各类内部存储作为组件挂载在树上。
    • 统一树作为总控制器，各个存储组件各自实现自己的匹配、驱逐、内存管理规则；解决混合架构模型的KV共享难题。
  7. Unified Memory Pool统一内存池 + Compaction内存压缩
    • 不再预先给不同类型KV缓存划分固定内存大小；整块物理内存动态分配，根据真实负载自动分配给full‑attention、window‑KV、recurrent state。
    • 内存反复分配释放会产生大量内存碎片；Compaction操作通过低时延内存拷贝重新整理物理页，修改虚拟页映射，上层虚拟ID不变，消除碎片。
  8. 拓展：Miles推理引擎嵌入RL训练循环
    • Miles、XLA项目，把推理引擎嵌入强化学习训练循环；支持完全异步执行，生成和训练可以并行跑不互相阻塞。
  9. 收尾预告XLA峰会，Q&A结束整个分享

來源：DEV Community · dev.to

#教學/實踐#推理#Agent#開源生態#DeepSeek