跳到主要内容

推理优化:快和省的三层功夫

这一章讲四件事: 先分清两种瓶颈——计算受限,和内存带宽(数据搬运的速度)受限,预填充和解码恰好各占一种,这决定了优化的方向; 指标怎么量——延迟要拆成 TTFT/TPOT,「每秒能吐多少」要配上 goodput,利用率要用 MFU/MBU 而不是厂商面板; 模型层优化——推测解码、KV 缓存与注意力变体、内核与编译器; 服务层优化——连续批处理、预填充-解码解耦、提示词缓存、并行化。 它在全书的位置:适配技术(提示、RAG、微调、数据)到本章收尾,下一章把所有组件拼成完整架构。

1. 顶层全景:三种瓶颈,三层优化​

推理 = 用训练好的模型对输入算出输出。书里给的三层优化框架,配了一个射箭比方:模型层优化是磨箭,硬件层优化是练射手,服务层优化是完善整个流程1:

  请求 → [推理服务:接收/路由/批处理/缓存] → [推理服务器:模型跑在芯片上] → 响应
              ↑ 服务层(不改模型)              ↑ 模型层 + 硬件层(可能改行为)
              
  图说:模型层优化可能改变输出质量(不同提供商的同一模型,基准成绩就有差异),
        服务层优化按书里的要求「不应改变输出质量」,只挪资源[^2]。

动手优化前先做诊断:你的系统卡在哪一种瓶颈上。

2. 两种瓶颈:快不起来只有两种原因​

计算受限:完成时间由计算量决定——典型例子是密码破解,要做的数学运算太多2。内存带宽受限(简称带宽受限):完成时间受限于数据搬运速度——内存到处理器之间的传输跟不上3。

一个术语陷阱书里特意挑明:系统背景的人说「内存受限」指带宽不够,AI 背景的人说「内存受限」指容量不够(就是「CUDA out of memory」那种 OOM)4。读优化文献时先对齐口径。

判断方法靠算术强度:每访问 1 字节内存执行了几次运算。算术强度高 → 计算受限(加芯片算力有效);低 → 带宽受限(加带宽有效),性能分析工具能画出「屋顶图」直观显示5。关键结论6:

阶段干什么瓶颈为什么
预填充并行处理输入 token计算受限一次算多少取决于算力
解码逐个生成输出 token带宽受限每步都要把整个模型的权重搬一遍

Stable Diffusion 这类图像生成是计算受限,自回归语言模型的解码是带宽受限7。由于两个阶段瓶颈不同,生产上常把它们拆到不同机器上各跑各的(§6.2)8。

3. 指标:延迟、吞吐、利用率,各有一个坑​

3.1 延迟拆开量:TTFT 与 TPOT​

总延迟一个数不够用,自回归生成要拆成两段9:

  • TTFT(time to first token,首个 token 时间):对应预填充阶段,用户希望聊天机器人瞬时响应,长文档摘要则可以等;
  • TPOT(time per output token,每输出 token 时间):对齐人类阅读速度即可——快速阅读者读一个 token 约 120 ms,所以 TPOT 在 120 ms 左右(每秒 6～8 个 token)就够大多数应用,做得更短用户也感知不到10。

整体延迟 = TTFT + TPOT × 输出 token 数。还有一个 Anyscale 的实验数字帮你分配资源:100 个输入 token 对延迟的影响,大约等于 1 个输出 token11。两个坑12:一是 CoT/智能体场景里模型生成了不展示给用户的中间步骤,用户感知的首 token 时间远长于模型的 TTFT,有团队为此用「首个 token 发布时间」(time to publish)单列这个口径;二是平均值会说谎——10 个请求里 9 个 100 ms 左右、1 个 3000 ms,平均被拉到 390 ms,看起来比典型情况慢得多;要看百分位(把所有请求按快慢排队后的名次)——p50 就是队伍正中间那个的成绩,通常看 p50/p90/p95/p99。

3.2 吞吐量与 goodput:成本怎么算​

每秒能吐出多少个输出 token,行话叫吞吐量(TPS)。

并发(同一时刻挤进来许多请求)的能力,看每分钟请求数(RPM,基础模型一个请求动辄数秒,RPS 不够细)13。吞吐量直接决定成本,书里给了一笔完整账14:

  假设:算力成本 2 美元/小时,吞吐量 100 TPS
    解码:每 100 万输出 token ≈ 5.56 美元
           若每请求平均 200 个输出 token,1000 个请求 ≈ 1.11 美元
    预填充:每分钟 100 个请求 → 1000 个请求 ≈ 0.33 美元
    ── 1000 个请求总成本 ≈ 1.44 美元 ──
    
  图说:分词器不同 token 数就不同,跨服务比较请用「每次请求的成本」[^16]。

延迟与吞吐是一对权衡:LinkedIn 的总结是,愿意牺牲 TTFT 和 TPOT 的话,吞吐量翻倍甚至翻三倍并不罕见15。所以又有了 goodput(有效吞吐量):每秒满足 SLO(软件级目标,如「TTFT ≤ 200 ms 且 TPOT ≤ 100 ms」)的请求数——每秒完成 10 个请求、只有 3 个达标,goodput 就是 316。

3.3 利用率:别信 nvidia-smi 的百分比​

nvidia-smi 显示的「GPU 利用率」只统计「芯片处于活跃状态」的时间占比——一块每秒能做 100 次运算的芯片,每秒只做 1 次照样显示 100%17。真指标有两个18:

MFU(模型每秒浮点运算利用率)= 实际吞吐量 ÷ 峰值算力下的理论吞吐量。MBU(模型带宽利用率)= 实际使用的内存带宽 ÷ 理论带宽。MBU 可以当场复算,这是本章的主走查(数全部出自书里)19:

  模型:70 亿参数,FP16(每参数 2 字节),实测吞吐 100 TPS
  
  实际内存带宽 = 参数量 × 字节数 × 吞吐量
              = 7×10⁹ × 2 × 100 = 1400 GB/s
  
  芯片:A100-80GB,理论带宽 2 TB/s
  MBU = 1400 GB/s ÷ 2000 GB/s = 70%
  
  图说:顺带看定量化的价值——带宽公式里每参数字节数是乘数,
        8 位权重直接把带宽消耗砍半(这就是第 10 章量化在本章的回报)。

瓶颈类型和利用率指标对得上号:计算受限的工作负载 MFU 高、MBU 低;带宽受限的反之20。还要防「峰值 FLOP/s 包装」营销——厂商用特殊形状的稀疏矩阵刷峰值数字,用户实际很难跑出高 MFU21。参照系:训练任务 MFU 超过 50% 通常算表现良好;预填充的 MFU 天然高于解码22。

4. 硬件底座:加速器、内存三层、电费​

  • CPU vs GPU:CPU 少量高性能核心(高端消费级 64 核),GPU 几千个小核心——因为神经网络的运算 90% 以上是矩阵乘法,高度可并行23。已部署系统里推理成本可占 ML 总成本高达 90%,所以推理专用芯片(Apple Neural Engine、AWS Inferentia、Meta MTIA)成为趋势24;
  • 内存三层:片上 SRAM(超过 10 TB/s,但容量一般不超过 40 MB)→ GPU 专用 HBM(256 GB/s～1.5 TB/s,消费级卡 24～80 GB)→ CPU DRAM(25～50 GB/s,容量可到 1 TB)25。离计算单元(芯片里真正干活的运算部件)越近越快也越小——许多优化(比如 FlashAttention)本质就是在跟这个层次结构博弈;
  • 功耗:A100 有 540 亿个晶体管,H100 有 800 亿;一块 H100 以峰值性能跑一年约 7000 kWh——参照物:美国普通家庭一年约 10,000 kWh,一块芯片约等于一个家庭的七成用电26。

5. 模型层优化:磨箭​

5.1 压缩老三样与「输出比输入贵」​

压缩三件套里,量化(第 10 章)和蒸馏(第 12 章)已讲;剪枝是把不重要的参数置零或移除——「彩票假设」证明某些网络剪掉 90% 以上非零参数不损准确率,但实践中不常见:实现难、提升相对小、硬件未必利用得了稀疏性27。最受欢迎的压缩手段至今是权重量化,但它有物理极限——每个数值不能低于 1 位28。为什么解码值得花这么大力气?因为一个输出 token 的成本大约是输入 token 的 2～4 倍,而且自回归逐个生成,100 个 token 要等 10 秒(按每 token 100 ms)29。

5.2 推测解码:让小模型打草稿​

推测解码的直觉:响应里很多 token 其实很好猜,不必每次都动用大模型30。流程四步(走查)31:

  ① 草稿模型(快而弱)一口气生成 K 个候选 token:xt+1 … xt+K
  ② 目标模型(你要的那个)并行验证这 K 个
  ③ 从左到右接受最长的一致前缀,比如前 j 个
  ④ 目标模型补生成 1 个 token(xt+j+1),回到 ①
  
  结果:最差也产出 1 个;最好产出 K+1 个,其中 K 个是白赚的

它成立靠三条32:验证可并行(把「解码特征」变成了「预填充特征」);简单 token 弱模型也能猜对;解码本来带宽受限、有空闲的 FLOP 可以免费验证。K 越大验证次数越少但接受率越降,要试;代码这类高结构文本接受率高。实证:DeepMind 给 Chinchilla-70B 配了个 40 亿参数的同架构草稿模型——草稿 1.8 ms/token 对目标 14.1 ms/token,整体延迟降低一半以上且不损质量;PyTorch 里 50 行代码就能实现,vLLM、TensorRT-LLM、llama.cpp 都已内置33。

两个变体34:带参考的推理——输出与输入大量重叠时(检索问答、改代码、多轮对话——来回聊很多次的那种),草稿 token 直接从输入里复制,不要草稿模型,实测 2 倍提速;并行解码——干脆同时生成 x(t+1)…x(t+k)(给定「the cat sits」,不管下一个是 on 还是 under,再下一个多半是 the),Lookahead 用雅可比方法迭代验证,Medusa 给原模型加多个解码头、树状注意力选最优序列,NVIDIA 宣称在 H200 上让 Llama 3.1 提速 1.9 倍。

5.3 KV 缓存与注意力优化​

生成下一个 token 要用之前所有 token 的键值向量;KV 缓存把算过的存起来复用,避免每步重算(训练时不需要——训练里整个序列已知,可一次并行算完)35。但缓存本身吃内存。书里的算例,一字不差可复算36:

  KV 缓存内存 = 2 × B × S × L × H × M(字节)
    B 批次大小, S 序列长度, L 层数, H 模型维度, M 每数值字节数
  
  Llama 2-13B(40 层,维度 5120),批次 32,序列 2048,FP16:
    2 × 32 × 2048 × 40 × 5120 × 2 字节 ≈ 54 GB
    
  对照:5000 亿参数模型、批次 512、上下文 2048 → KV 缓存 3 TB,是权重本身的 3 倍[^39]

注意力优化的三板斧37:

  1. 重新设计注意力(要动架构,只能训练/微调时做):局部窗口注意力(只看邻近 1000 token,1 万 token 序列的缓存降到 1/10)、跨层注意力(相邻层共享键值,三层共享 = 1/3)。

    多查询注意力,以及把查询头分成小组、组内共享键值的分组查询(GQA,注意力的一个改法)属于同一族。Character.AI 的组合拳:平均对话 180 条消息的负载下,三招并用把 KV 缓存压到 1/20 以下;

  2. 管理 KV 缓存:vLLM 的 PagedAttention 把缓存切成非连续内存块(像操作系统分页),减少碎片;再加 KV 量化、自适应压缩、选择性保留;

  3. 写内核:不改设计不改存储,改计算本身的代码——FlashAttention 把多个算子融合成一次计算,是为 A100 设计的,到 H100 就有了 FlashAttention-3。内核 = 为特定芯片优化的专用代码,写它要懂内存层次,CUDA/Triton/ROCm 是常用语言38。

5.4 编译器把这一切串起来​

模型代码要在特定硬件上跑,得先「底层化」(lowering)成硬件兼容的形式,干这活的工具叫编译器(torch.compile、TVM、MLIR、XLA、TensorRT 内置编译器)39。PyTorch 团队给 Llama-7B 做过四步走查:torch.compile → 量化 INT8 → 量化 INT4 → 加推测解码,吞吐量逐级上升40。许多公司把专有内核当商业机密——跑得又快又省的内核就是竞争优势41。

6. 服务层优化:不碰模型,只挪资源​

6.1 批处理:三班车​

批处理的比喻书里用得很完整:单独处理每个请求是人手一辆车,批处理是挤公交——载得多,但可能每人都慢一点42。三班车43:

方式规则缺陷
静态批处理坐满才发车第一个请求要等最后一个到齐
动态批处理坐满或到点发车(如 100 ms 窗口)发车时批次可能不满,浪费算力
连续批处理有人下车立刻补人上车实现复杂(Orca 2022 提出)

前两种还有个对 LLM 特别痛的问题:必须整批完成才返回——同批一个请求生成 10 个 token、另一个要 1000 个,短请求干等长请求。连续批处理让完成的响应立即返回、空位立即补新请求,是现代推理服务器的标配44。

6.2 预填充-解码解耦与提示词缓存​

§2 说过预填充(计算受限)和解码(带宽受限)瓶颈不同,塞在同一块 GPU 上会互相争抢:新查询带来的预填充任务会挤占现有解码任务的算力,TPOT 被拉长。解法是把两步分配到不同实例——论文证实这能在满足延迟要求的同时显著提高吞吐,中间状态的传输开销在现代集群(NVLink 高速互联)里并不显著。实例配比:长输入优先保 TTFT 时预填充:解码取 2∶1～4∶1;短输入优先保 TPOT 时取 1∶2～1∶145。

提示词缓存利用提示词里的重叠片段(系统提示词、长文档、对话历史)只处理一次46。账很直白:系统提示词 1000 token、每天 100 万次调用,每天省下约 10 亿个重复输入 token 的处理47。厂商已跟进:Gemini 缓存 token 便宜 75%(另收存储费);Anthropic 宣称最高省 90% 成本、降 75% 延迟——上下文越长省得越多48。

6.3 并行化:四种拆法​

资源不够、模型太大时按维度拆49:

  • 副本并行:多复制几份模型,最容易,同时服务更多请求;多大规模的模型配多大内存的卡是个装箱问题(40 GB 的卡放三个 13B 还是一个 34B?);
  • 按张量(矩阵就是二维张量)并行:把一次矩阵乘法切到多卡,推理最常用,能跑大模型还能降延迟,代价是通信开销;
  • 流水线并行:模型分段接力(训练常用);因为有额外通信,延迟敏感的推理场景一般避开它;
  • 上下文并行 / 序列并行:长输入按位置拆到多机,或按算子(注意力/前馈)拆到多机。

书里的小结给了选用经验:影响最广的四件套是量化(适用广)、张量并行(降延迟+跑大模型)、副本并行(易实现)、注意力优化(Transformer 专用)50。

7. 作者的判断与证据​

  • 「解码是主要矛盾」(有证据):输出 token 成本 2～4 倍于输入、带宽受限的机制分析、以及整个推测解码技术族的存在动机。
  • 「指标必须拆开看」(有证据):平均值误导的十个请求数例、goodput 的 SLO 定义、nvidia-smi 利用率的批评——都是可复算的。
  • 「优化可能改变模型行为」(有证据):Cerebras 2024 年的实验显示不同推理服务商的同一模型基准成绩有差异;书里把它当选购推理服务时的检查项。
  • 「了解优化有助于评估 API」(作者判断,写给 API 用户):大多数开发者不会自己实现这些技术,但懂行才能看懂报价单和延迟报告。

8. 边界与局限​

  • 120 ms 阅读速度、MFU>50% 等参照都是「截至本书撰写时」的行业经验,硬件换代后会漂移。
  • PyTorch 四步优化的吞吐提升图来自官方博客,书里明确注明「这些优化步骤对模型输出质量的具体影响尚不清楚」。
  • 推测解码的收益依赖接受率,而接受率因任务而异——书里没给跨任务的系统性数据。
  • Medusa 1.9 倍等加速数字来自厂商(NVIDIA)自述;「峰值 FLOP/s 包装」的批评同样适用于加速倍数宣传。
  • 并行化一节只讲了概念与适用性,没有给出分布式系统的实现细节。

9. 可带走的​

  1. 先诊断瓶颈再动手:算术强度低 = 带宽受限(加带宽),高 = 计算受限(加算力);预填充是计算受限,解码是带宽受限——这不是巧合,是逐 token 生成的宿命;
  2. 延迟拆成 TTFT + TPOT × 输出 token 数;TPOT 做到 120 ms(人类阅读速度)即可,省下的资源挪去压 TTFT;
  3. 平均延迟会说谎,看 p50/p90/p95/p99;智能体场景用户感知的首 token 时间远大于模型 TTFT;
  4. 利用率别看 nvidia-smi,看 MFU/MBU;MBU = 参数量 × 字节数 × 吞吐量 ÷ 理论带宽,7B/FP16/100 TPS = 70%(A100)——量化直接给这条公式打折;
  5. 输出 token 单价是输入的 2～4 倍,逐 token 生成是慢与贵的根源;
  6. 推测解码是性价比之王:弱模型打草稿、大模型并行验证,Chinchilla 实测延迟减半、质量不损、50 行代码;
  7. KV 缓存是长上下文的隐形炸弹:13B/批次 32/2048 上下文就要 54 GB;窗口注意力、GQA、PagedAttention、FlashAttention 是四件常备武器;
  8. 批处理用连续批处理(公交车下客即补客);预填充与解码拆机跑,配比按「保 TTFT 还是保 TPOT」定;
  9. 系统提示词、长文档、对话历史——能缓存的重叠片段都缓存,1000 token × 100 万次/天 = 10 亿 token/天的处理量;
  10. 用 API 的也要懂这些:同一模型不同提供商成绩会不同(优化改变行为),报价差异背后是这章的每一项技术。

10. 原文地图​

主题原书章原文位置
三层优化框架第9章text/16-ch09.txt:30(搜「模型、硬件和服务」)
推理服务器第9章text/16-ch09.txt:77(搜「推理服务器」)
两种计算瓶颈第9章text/16-ch09.txt:92(搜「计算受限」)
计算受限:密码破解第9章text/16-ch09.txt:98(搜「密码破解」)
带宽受限定义第9章text/16-ch09.txt:104(搜「带宽受限」)
内存受限的术语歧义第9章text/16-ch09.txt:110(搜「内存受限」) · text/16-ch09.txt:115(搜「OOM」)
算术强度与屋顶图第9章text/16-ch09.txt:127(搜「算术强度」)
预填充计算受限、解码带宽受限第9章text/16-ch09.txt:139(搜「Stable Diffusion」) · text/16-ch09.txt:154(搜「预填充是计算受限」) · text/16-ch09.txt:160(搜「解码是内存带宽受限」)
预填充初始化 KV 缓存第9章text/16-ch09.txt:148(搜「初始化KV缓存」)
拆到不同机器第9章text/16-ch09.txt:172(搜「不同的机器」)
在线 vs 批处理 API第9章text/16-ch09.txt:195(搜「50%」) · text/16-ch09.txt:198(搜「更低的延迟」)
流式模式第9章text/16-ch09.txt:222(搜「流式模式」)
TTFT 定义第9章text/16-ch09.txt:268(搜「TTFT」)
TPOT 与 120 ms第9章text/16-ch09.txt:275(搜「TPOT」) · text/16-ch09.txt:278(搜「120 ms」)
整体延迟公式、100 输入≈1 输出第9章text/16-ch09.txt:293(搜「TTFT+TPOT」) · text/16-ch09.txt:296(搜「100个输入token」)
time to publish、中间步骤不可见第9章text/16-ch09.txt:304(搜「time to publish」) · text/16-ch09.txt:319(搜「长得多」)
平均值误导(3000 ms)、百分位第9章text/16-ch09.txt:322(搜「3000 ms」) · text/16-ch09.txt:325(搜「p50」)
吞吐量与 RPM第9章text/16-ch09.txt:331(搜「吞吐量」) · text/16-ch09.txt:340(搜「每分钟请求数」)
成本算例 5.56/0.33/1.44 美元第9章text/16-ch09.txt:343(搜「5.56美元」) · text/16-ch09.txt:349(搜「1.44」)
每次请求成本比较第9章text/16-ch09.txt:355(搜「每次请求的成本」)
LinkedIn 吞吐翻倍第9章text/16-ch09.txt:358(搜「翻倍」)
goodput 与 SLO第9章text/16-ch09.txt:361(搜「有效吞吐量」) · text/16-ch09.txt:364(搜「200 ms」)
nvidia-smi 的坑第9章text/16-ch09.txt:373(搜「nvidia-smi」) · text/16-ch09.txt:382(搜「100次运算」)
MFU 定义第9章text/16-ch09.txt:385(搜「MFU」) · text/16-ch09.txt:393(搜「20 TPS」)
MBU 定义第9章text/16-ch09.txt:396(搜「500 GB/s」)
带宽公式与 1400 GB/s、70% 算例第9章text/16-ch09.txt:402(搜「参数量」) · text/16-ch09.txt:414(搜「1400 GB/s」) · text/16-ch09.txt:423(搜「70%」)
MFU/MBU 与瓶颈对应第9章text/16-ch09.txt:429(搜「较高的MFU」)
峰值 FLOP/s 包装第9章text/16-ch09.txt:432(搜「包装」)
训练 MFU>50%第9章text/16-ch09.txt:437(搜「50%」)
AlexNet 与 GPU第9章text/16-ch09.txt:483(搜「AlexNet」)
CPU vs GPU、矩阵乘 90%第9章text/16-ch09.txt:496(搜「高性能核心」) · text/16-ch09.txt:499(搜「90%」)
推理成本占 90%、专用芯片第9章text/16-ch09.txt:513(搜「高达90%」) · text/16-ch09.txt:519(搜「Inferentia」)
内存三层:DRAM/HBM/SRAM第9章text/16-ch09.txt:596(搜「25～50 GB/s」) · text/16-ch09.txt:605(搜「256 GB/s」) · text/16-ch09.txt:614(搜「10 TB/s」)
CUDA/Triton/ROCm第9章text/16-ch09.txt:617(搜「ROCm」)
晶体管 540 亿/800 亿第9章text/16-ch09.txt:623(搜「540亿」)
H100 一年 7000 kWh、家庭对照第9章text/16-ch09.txt:626(搜「7000」) · text/16-ch09.txt:634(搜「10,000 kWh」)
TDP 与最大功耗第9章text/16-ch09.txt:643(搜「1.1～1.5倍」)
射箭类比第9章text/16-ch09.txt:678(搜「射箭」)
提供商优化改变行为第9章text/16-ch09.txt:687(搜「Cerebras」)
剪枝与彩票假设、不常见第9章text/16-ch09.txt:719(搜「90%」)
权重量化最受欢迎、1 位极限第9章text/16-ch09.txt:722(搜「最受欢迎」)
输出 2～4 倍、100 token=10 s第9章text/16-ch09.txt:733(搜「10 s」) · text/16-ch09.txt:734(搜「2～4倍」)
推测解码四步第9章text/16-ch09.txt:740(搜「推测解码」) · text/16-ch09.txt:746(搜「长度为K」;若定位失败搜「草稿模型」)
验证并行、空闲 FLOP第9章text/16-ch09.txt:773(搜「预填充过程的计算特征」) · text/16-ch09.txt:784(搜「空闲的FLOP」)
K 的权衡、接受率第9章text/16-ch09.txt:787(搜「接受率」)
Chinchilla 1.8 vs 14.1 ms第9章text/16-ch09.txt:790(搜「1.8 ms」)
50 行代码、框架集成第9章text/16-ch09.txt:793(搜「50行」)
带参考的推理 2 倍第9章text/16-ch09.txt:796(搜「带参考的推理」) · text/16-ch09.txt:802(搜「两倍」)
并行解码、the cat sits、Medusa第9章text/16-ch09.txt:814(搜「并行解码」) · text/16-ch09.txt:817(搜「the cat sits」) · text/16-ch09.txt:820(搜「Medusa」)
KV 缓存与训练不需要第9章text/16-ch09.txt:868(搜「KV缓存」) · text/16-ch09.txt:877(搜「不需要KV缓存」)
注意力 O(n²)、缓存线性第9章text/16-ch09.txt:886(搜「线性增长」)
3 TB = 权重 3 倍第9章text/16-ch09.txt:889(搜「3 TB」)
KV 缓存公式与 54 GB 算例第9章text/16-ch09.txt:925(搜「Llama 2-13B」) · text/16-ch09.txt:928(搜「54 GB」)
窗口注意力 1/10、跨层 1/3、GQA第9章text/16-ch09.txt:934(搜「十分之一」) · text/16-ch09.txt:940(搜「三分之一」) · text/16-ch09.txt:943(搜「分组查询」)
Character.AI 180 条消息、1/20第9章text/16-ch09.txt:946(搜「180条消息」)
PagedAttention第9章text/16-ch09.txt:952(搜「PagedAttention」)
FlashAttention第9章text/16-ch09.txt:961(搜「FlashAttention」) · text/16-ch09.txt:1023(搜「FlashAttention-3」)
内核与四种加速技术第9章text/16-ch09.txt:973(搜「内核」) · text/16-ch09.txt:1014(搜「算子融合」)
底层化与编译器第9章text/16-ch09.txt:1026(搜「底层化」)
PyTorch 四步案例、商业机密第9章text/16-ch09.txt:1032(搜「Llama-7B」) · text/16-ch09.txt:1056(搜「商业机密」)
服务优化不改输出质量第9章text/16-ch09.txt:1072(搜「不应改变输出质量」)
公交车比喻、三种批处理第9章text/16-ch09.txt:1078(搜「公交车」) · text/16-ch09.txt:1084(搜「静态批处理」) · text/16-ch09.txt:1087(搜「100 ms」)
短请求等长请求、连续批处理第9章text/16-ch09.txt:1090(搜「10个响应token」) · text/16-ch09.txt:1099(搜「连续批处理」)
解耦:争抢与 NVLink、配比第9章text/16-ch09.txt:1111(搜「争夺资源」) · text/16-ch09.txt:1114(搜「NVLink」) · text/16-ch09.txt:1122(搜「2∶1」)
提示词缓存与 10 亿 token第9章text/16-ch09.txt:1128(搜「提示词缓存」) · text/16-ch09.txt:1143(搜「10亿」)
Gemini 75%、Anthropic 90%第9章text/16-ch09.txt:1151(搜「75%」)
副本并行与装箱问题第9章text/16-ch09.txt:1171(搜「副本并行」) · text/16-ch09.txt:1172(搜「装箱」;若定位失败搜「40 GB」)
张量并行、流水线并行第9章text/16-ch09.txt:1187(搜「张量并行」) · text/16-ch09.txt:1211(搜「流水线并行」)
上下文/序列并行第9章text/16-ch09.txt:1217(搜「上下文并行」) · text/16-ch09.txt:1220(搜「序列并行」)
小结四件套第9章text/16-ch09.txt:1258(搜「副本并行」)

Footnotes​

  1. 出处:「第9章」第 30 段(text/16-ch09.txt:30,搜「模型、硬件和服务」)与第 678 段(text/16-ch09.txt:678,搜「射箭」)。 ↩

  2. 出处:「第9章」第 98 段(text/16-ch09.txt:98,搜「密码破解」)。 ↩

  3. 出处:「第9章」第 104 段(text/16-ch09.txt:104,搜「带宽受限」)。 ↩

  4. 出处:「第9章」第 110 段(text/16-ch09.txt:110,搜「内存受限」)与第 115 段(text/16-ch09.txt:115,搜「OOM」)。 ↩

  5. 出处:「第9章」第 127 段(text/16-ch09.txt:127,搜「算术强度」)。 ↩

  6. 出处:「第9章」第 154 段(text/16-ch09.txt:154,搜「预填充是计算受限」)与第 160 段(text/16-ch09.txt:160,搜「解码是内存带宽受限」)。 ↩

  7. 出处:「第9章」第 139 段(text/16-ch09.txt:139,搜「Stable Diffusion」)。 ↩

  8. 出处:「第9章」第 172 段(text/16-ch09.txt:172,搜「不同的机器」)。 ↩

  9. 出处:「第9章」第 257 段(text/16-ch09.txt:257,搜「分解为」;若定位失败搜「整体延迟」)、第 268 段(text/16-ch09.txt:268,搜「TTFT」)与第 275 段(text/16-ch09.txt:275,搜「TPOT」)。 ↩

  10. 出处:「第9章」第 278 段(text/16-ch09.txt:278,搜「120 ms」)。 ↩

  11. 出处:「第9章」第 296 段(text/16-ch09.txt:296,搜「100个输入token」)。 ↩

  12. 出处:「第9章」第 304 段(text/16-ch09.txt:304,搜「time to publish」)、第 322 段(text/16-ch09.txt:322,搜「3000 ms」)与第 325 段(text/16-ch09.txt:325,搜「p50」)。 ↩

  13. 出处:「第9章」第 331 段(text/16-ch09.txt:331,搜「吞吐量」)与第 340 段(text/16-ch09.txt:340,搜「每分钟请求数」)。 ↩

  14. 出处:「第9章」第 343 段(text/16-ch09.txt:343,搜「5.56美元」)、第 346 段(text/16-ch09.txt:346,搜「0.33美元」;若定位失败搜「预填充成本」)与第 349 段(text/16-ch09.txt:349,搜「1.44」)。 ↩

  15. 出处:「第9章」第 358 段(text/16-ch09.txt:358,搜「翻倍」)。 ↩

  16. 出处:「第9章」第 361 段(text/16-ch09.txt:361,搜「有效吞吐量」)与第 364 段(text/16-ch09.txt:364,搜「200 ms」)。 ↩

  17. 出处:「第9章」第 373 段(text/16-ch09.txt:373,搜「nvidia-smi」)与第 382 段(text/16-ch09.txt:382,搜「100次运算」)。 ↩

  18. 出处:「第9章」第 385 段(text/16-ch09.txt:385,搜「MFU」)与第 396 段(text/16-ch09.txt:396,搜「500 GB/s」)。 ↩

  19. 出处:「第9章」第 402 段(text/16-ch09.txt:402,搜「参数量」)、第 414 段(text/16-ch09.txt:414,搜「1400 GB/s」)与第 423 段(text/16-ch09.txt:423,搜「70%」)。 ↩

  20. 出处:「第9章」第 429 段(text/16-ch09.txt:429,搜「较高的MFU」)。 ↩

  21. 出处:「第9章」第 432 段(text/16-ch09.txt:432,搜「包装」)。 ↩

  22. 出处:「第9章」第 437 段(text/16-ch09.txt:437,搜「50%」)。 ↩

  23. 出处:「第9章」第 496 段(text/16-ch09.txt:496,搜「高性能核心」)与第 499 段(text/16-ch09.txt:499,搜「90%」)。 ↩

  24. 出处:「第9章」第 513 段(text/16-ch09.txt:513,搜「高达90%」)与第 519 段(text/16-ch09.txt:519,搜「Inferentia」)。 ↩

  25. 出处:「第9章」第 596 段(text/16-ch09.txt:596,搜「25～50 GB/s」)、第 605 段(text/16-ch09.txt:605,搜「256 GB/s」)与第 614 段(text/16-ch09.txt:614,搜「10 TB/s」)。 ↩

  26. 出处:「第9章」第 623 段(text/16-ch09.txt:623,搜「540亿」)、第 626 段(text/16-ch09.txt:626,搜「7000」)与第 634 段(text/16-ch09.txt:634,搜「10,000 kWh」)。 ↩

  27. 出处:「第9章」第 719 段(text/16-ch09.txt:719,搜「90%」)。 ↩

  28. 出处:「第9章」第 722 段(text/16-ch09.txt:722,搜「最受欢迎」)。 ↩

  29. 出处:「第9章」第 733 段(text/16-ch09.txt:733,搜「10 s」)与第 734 段(text/16-ch09.txt:734,搜「2～4倍」)。 ↩

  30. 出处:「第9章」第 740 段(text/16-ch09.txt:740,搜「推测解码」)。 ↩

  31. 出处:「第9章」第 746 段(text/16-ch09.txt:746,搜「长度为K」;若定位失败搜「草稿模型」)与第 767 段(text/16-ch09.txt:767,搜「K+1个token」)。 ↩

  32. 出处:「第9章」第 773 段(text/16-ch09.txt:773,搜「预填充过程的计算特征」)、第 776 段(text/16-ch09.txt:776,搜「更容易预测」)与第 784 段(text/16-ch09.txt:784,搜「空闲的FLOP」)。 ↩

  33. 出处:「第9章」第 787 段(text/16-ch09.txt:787,搜「接受率」)、第 790 段(text/16-ch09.txt:790,搜「1.8 ms」)与第 793 段(text/16-ch09.txt:793,搜「50行」)。 ↩

  34. 出处:「第9章」第 796 段(text/16-ch09.txt:796,搜「带参考的推理」)、第 802 段(text/16-ch09.txt:802,搜「两倍」)、第 817 段(text/16-ch09.txt:817,搜「the cat sits」)与第 820 段(text/16-ch09.txt:820,搜「Medusa」)。 ↩

  35. 出处:「第9章」第 868 段(text/16-ch09.txt:868,搜「KV缓存」)与第 877 段(text/16-ch09.txt:877,搜「不需要KV缓存」)。 ↩

  36. 出处:「第9章」第 904 段(text/16-ch09.txt:904,搜「计算公式」;若定位失败搜「2×B×S×L×H×M」)、第 925 段(text/16-ch09.txt:925,搜「Llama 2-13B」)与第 928 段(text/16-ch09.txt:928,搜「54 GB」)。 ↩

  37. 出处:「第9章」第 898 段(text/16-ch09.txt:898,搜「三类」;若定位失败搜「注意力机制的效率」)、第 934 段(text/16-ch09.txt:934,搜「十分之一」)、第 940 段(text/16-ch09.txt:940,搜「三分之一」)、第 946 段(text/16-ch09.txt:946,搜「180条消息」)与第 952 段(text/16-ch09.txt:952,搜「PagedAttention」)。 ↩

  38. 出处:「第9章」第 958 段(text/16-ch09.txt:958,搜「内核」)与第 961 段(text/16-ch09.txt:961,搜「FlashAttention」)、第 1023 段(text/16-ch09.txt:1023,搜「FlashAttention-3」)。 ↩

  39. 出处:「第9章」第 1026 段(text/16-ch09.txt:1026,搜「底层化」)。 ↩

  40. 出处:「第9章」第 1032 段(text/16-ch09.txt:1032,搜「Llama-7B」)与第 1053 段(text/16-ch09.txt:1053,搜「80 GB」)。 ↩

  41. 出处:「第9章」第 1056 段(text/16-ch09.txt:1056,搜「商业机密」)。 ↩

  42. 出处:「第9章」第 1078 段(text/16-ch09.txt:1078,搜「公交车」)。 ↩

  43. 出处:「第9章」第 1081 段(text/16-ch09.txt:1081,搜「静态批处理」)、第 1084 段(text/16-ch09.txt:1084,搜「静态批处理」;若定位失败搜「坐满」)与第 1087 段(text/16-ch09.txt:1087,搜「100 ms」)。 ↩

  44. 出处:「第9章」第 1090 段(text/16-ch09.txt:1090,搜「10个响应token」)与第 1099 段(text/16-ch09.txt:1099,搜「连续批处理」)。 ↩

  45. 出处:「第9章」第 1111 段(text/16-ch09.txt:1111,搜「争夺资源」)、第 1114 段(text/16-ch09.txt:1114,搜「NVLink」)与第 1122 段(text/16-ch09.txt:1122,搜「2∶1」)。 ↩

  46. 出处:「第9章」第 1128 段(text/16-ch09.txt:1128,搜「提示词缓存」)与第 1131 段(text/16-ch09.txt:1131,搜「长文档」)。 ↩

  47. 出处:「第9章」第 1143 段(text/16-ch09.txt:1143,搜「10亿」)。 ↩

  48. 出处:「第9章」第 1151 段(text/16-ch09.txt:1151,搜「75%」)。 ↩

  49. 出处:「第9章」第 1171 段(text/16-ch09.txt:1171,搜「副本并行」)、第 1178 段(text/16-ch09.txt:1178,搜「40 GB」)、第 1187 段(text/16-ch09.txt:1187,搜「张量并行」)、第 1211 段(text/16-ch09.txt:1211,搜「流水线并行」)与第 1217 段(text/16-ch09.txt:1217,搜「上下文并行」)。 ↩

  50. 出处:「第9章」第 1258 段(text/16-ch09.txt:1258,搜「副本并行」)。 ↩