LLM 性能与 Infra

学习目标

本章关键词

承上：回顾与定位

Day 13 已能证明请求实际经过哪些 backend；本章把正确性基线升级为跨尺度性能账本，从单设备测量延伸到集群通信、状态调度和服务目标。

本章讲解

先写实验契约，再启动计时器

一次可比较基准至少固定模型与哈希、量化格式、runtime commit、线程和绑核、prompt token 数、输出上限、采样、并发、供电及散热。先 warm-up，再执行足够重复次数并保留原始样本。若两轮测试的输入长度或温度不同，p95 与 tokens/s 没有直接可比性。把这些字段保存为机器可读 manifest，可让固件或模型升级后自动复跑。

TTFT 与生成速度必须拆开诊断

TTFT 包含排队、模板化、tokenize、context 准备、prefill 和首轮采样；稳定 decode 则主要反映逐步读取权重与 KV、执行小批矩阵和采样输出。长 prompt 会显著拉高前者，长 context 与带宽压力会拖慢后者。应在相同请求上打单调时钟时间戳，并报告 prompt tokens/s、ITL 分布和 output tokens/s，而不是只给总耗时。

用瓶颈假设驱动下一项观测

看到 CPU 利用率低，不应直接断言“算力富余”：线程可能等待内存、锁、GPU 同步或网络背压。先由 trace 找最长阶段，再提出可证伪假设。若怀疑带宽，改变量化或 context 并观察速度与 bytes moved；若怀疑计算，改变核心数或频率；若怀疑 copy，记录分区边界。每次只改一个变量，让证据能区分相关性与因果。

先画数据移动层级，再谈算力

一个 kernel 中最热的标量可能停在寄存器，线程块复用的数据进入片上 SRAM/shared memory，模型权重、激活与 KV cache 主要驻留 HBM；跨卡张量经 PCIe 或专用 scale-up 互连，跨节点 collective 经过网卡与交换网络，checkpoint 最终落到本地 NVMe 或远端对象/并行文件系统。每向外一层，容量往往更大，但延迟、能耗和争用也上升。算术强度描述每搬一个字节能完成多少计算；Attention、MoE dispatch 和 embedding lookup 的瓶颈可能完全不同。工程分析应给每条边标注字节数、频率、并发者与拓扑，而不是笼统地说“GPU 很快”。HBM 容量决定模型能否放下，HBM 带宽决定许多逐 token kernel 的上限，节点内互连影响 TP collective，节点间网络影响 DP、EP 与 checkpoint 恢复。峰值 FLOPS 只有在数据及时到达计算单元、kernel 形状合适且通信被隐藏时才可能转化为有效吞吐。

六种并行是在不同维度切同一个训练图

数据并行 DP 复制模型、切输入 batch，并在反向后规约梯度；张量并行 TP 在单层内部切矩阵或 attention head，因此每层都可能触发 all-reduce 或 reduce-scatter/all-gather，最依赖低延迟高带宽节点内互连；流水线并行 PP 按连续层切 stage，搬运 stage 边界激活，并以 microbatch 填充流水线，气泡和负载不均是关键成本。上下文并行 CP 切长序列维度，需要交换 attention 所需的 K/V 或中间结果；专家并行 EP 把 MoE 专家分散到 rank，通过 all-to-all dispatch/combine 搬 token，路由倾斜会让少数专家拖住全局。FSDP/ZeRO 则切参数、梯度与优化器状态：计算前 all-gather 所需参数，反向后 reduce-scatter 梯度，再释放完整副本。它们不是互斥按钮，真实作业常用多维 device mesh 组合，但每新增一维都增加布局转换、故障面与调参空间。

在线推理有两个阶段、两类延迟和一个持续增长的状态

Prefill 并行处理 prompt token，通常能形成较大的矩阵乘，决定 Time To First Token；Decode 每轮只生成少量 token，却要读取所有层的权重和历史 K/V，常受内存带宽与调度开销约束，Inter-Token Latency 决定流式体验。KV cache 让系统不必为旧 token 重算 attention，但其容量随并发、上下文长度、层数、head 数和 dtype 增长。PagedAttention 把逻辑连续序列映射到可分页物理 block，降低外部碎片并支持灵活共享；prefix cache 复用相同前缀 block，但命中率取决于模板规范化、租户隔离与路由局部性。continuous batching 在每个 decode 迭代接纳和移除请求，减少静态 batch 的空槽，却使排队策略、抢占与尾延迟成为一等问题。吞吐必须在给定 TTFT/ITL SLO 下报告，超时后才完成的 token 不属于有效服务能力。

用 SLO、可观测性和故障演练闭环容量规划

服务入口应记录输入/输出 token、模型和 tokenizer 版本、采样参数、租户、deadline 与 trace id；路由器记录选择原因、prefix 命中和队列估计；worker 暴露 TTFT、逐 token ITL、batch 宽度、KV block 使用率、抢占、OOM 与错误；网络侧观察 collective 或点对点传输字节、拥塞和重试。容量模型至少区分短问答、长上下文、批处理与多轮会话，因为均值流量会掩盖长 prompt 对 Prefill 和 KV 的冲击。压测要回放到达过程与长度分布，并同时报告 p50/p95/p99 和 SLO goodput。故障演练包括杀 worker、降速网络、填满 KV、破坏一个 checkpoint 分片以及滚动升级不兼容 runtime。只有当系统在这些条件下能拒绝、降级、回滚并留下证据，峰值 benchmark 才能变成可运营的容量结论。

代码或命令示例

record(model, quant, prompt_tokens, output_tokens, hardware, temperature)
measure(TTFT, ITL_p50, ITL_p95, tokens_per_s, joules_per_token)
# 集群侧再记录 collective、KV 占用、goodput 与失败恢复时间

动手实验

工程陷阱

延伸阅读

• NVIDIA GenAI-Perf 指标（官方/原始资料）
• Megatron-LM：大规模 Transformer 的并行训练（官方/原始资料）
• vLLM / PagedAttention 原始论文（官方/原始资料）

启下：下一章如何使用本章能力

终章把模型包、runtime、异构 backend、MCU/Host 安全边界、能耗、回退、OTA 与可观测性收束成可交付的端侧 LLM 产品。

下一天： Day 15 · 端侧 LLM 产品化