AI 协作说明
本文由作者主导选题、技术判断与终稿审核；AI 工具协助完成资料检索、信息归纳、结构梳理与文字润色。文中观点、事实核验与引用准确性由作者负责。

资料核对时间：2026 年 9 月 20—21 日；数值格式与量化部分于 9 月 23 日补充核对。 本文以官方文档、项目仓库和原始论文为依据。项目的功能、维护状态与版本变化属于这一时间段的快照；学习优先级与选型建议是本文的架构判断。文中的容量计算和案例是分析示例，不是实测跑分。

大模型推理与部署已经形成一套横跨模型算法、计算内核、编译器、运行时和分布式服务的技术体系。一个请求从输入到生成结果，要经过模型计算、状态读写、请求调度和设备执行；当模型变大、上下文变长、用户变多或设备资源变少时，系统的主要矛盾也会变化。

理解这一领域，需要同时建立三张地图：技术栈地图说明每一层解决什么问题，开源项目地图说明能力由谁实现、怎样组合，学习路线图说明哪些原理值得深学、哪些实现按需选择。只列出 vLLM、llama.cpp、TVM、MLIR 等名字，很难回答这些问题。

本文的核心观点是：把“负载与约束 → 性能模型 → 系统分层 → 技术选择 → 验证与演进”串成闭环，比同时学会许多框架的启动命令更有价值。

阅读建议：第一至四节建立全景，第五至十节按需深入技术，第十一、十二节学习选型与验证，第十三节给出按天执行的 8 周课程与实践路线，第十四节补充按需阅读的论文和源码。若先想确定学习重点，可以读第一、七、十三节，再按所选方向补齐原理。窄屏阅读时，多列表格可横向滚动。

一、先建立全景：通用核心、技术分支与学习重点

1.1 推理与部署分别包含什么

推理（inference） 关注模型“怎样执行”：涉及数值计算、键值缓存（Key-Value Cache，简称 KV 缓存）等状态管理、生成循环、批处理与性能优化；部署（deployment） 则关注这套能力“怎样交付”：覆盖模型产物封装、运行环境、接口规范、容量规划、可观测性、版本升级与故障恢复。两者共同决定一个系统能否在质量、延迟和成本约束内持续稳定工作。

编译（compilation） 把模型的计算描述转换成适合目标设备执行的程序，是部署与推理优化中的重要技术环节。它可以提前发生，也可以在加载或运行期间发生；推理引擎也可以调用预编译算子。当前工具链常同时提供导出、编译和运行能力，分析时仍应区分程序转换、实际执行与系统交付各自负责什么。ExecuTorch 的准备与执行流程

本文主要讨论自回归大语言模型（Large Language Model，LLM），以及包含语言生成部分的视觉语言模型（Vision-Language Model，VLM）。训练、检索增强生成（Retrieval-Augmented Generation，RAG）和智能体（agent）会在影响量化、请求分布、上下文复用与服务行为时出现；它们各自的完整工程体系需要另外展开。

术语约定：token 保留英文，也称“词元”，不直接等同于一个汉字或单词；分词器（tokenizer）决定文本如何转换为 token。预填充（prefill）和解码（decode）是生成过程的两个阶段，下文为便于对照文档，也会使用英文简称。其他概念优先采用常用中文；译法容易歧义时保留英文，并在相关章节解释。

看待整个领域，可以使用两个彼此独立的坐标：

• 部署场景：云端在线服务、离线批处理、个人设备与移动/嵌入式端侧。
• 技术深度：使用与评估引擎、优化推理系统、开发编译器/算子/硬件后端。

端侧系统也会涉及复杂编译，云端系统也可以从成熟引擎开始。这两个坐标不能合并成一条“从简单到高级”的阶梯。

1.2 三种学习深度

先区分长期可迁移的知识、当前需要深入的实现，以及用于比较和跟踪的备选方案。

优先级随路线变化：图与编译的基本作用值得普遍了解，开发 MLIR 编译 pass 主要属于编译方向；大规模专家并行、预填充/解码分离对单设备实验通常是 P2，对混合专家模型（Mixture of Experts，MoE）集群则可能是 P1。“原理需要了解”与“实现需要精通”是两种不同的要求。

1.3 不同路线，共享基础但关注不同瓶颈

这些路线会交叉。例如，在线服务需要高效计算内核，端侧部署需要可靠调度；但每条路线都有自己的主要瓶颈。学习时先完成一个闭环，再扩展到相邻层。

二、架构师的起点：定义负载、约束与成功标准

2.1 不要先选框架，先写工作负载说明书

同一个模型，在离线批处理、交互聊天、长文档问答和端侧视觉助手中，可能需要完全不同的部署方案。

“支持某个模型”或“支持某种硬件”只是入口条件。 真正的支持对象是一个组合：

模型架构 × 权重/激活/KV 精度 × 输入形状 × 芯片型号 × SDK 版本 × 推理特性。

某组合能加载模型，并不意味着它支持长上下文、连续批处理、投机解码、CUDA Graph 等图执行机制和多卡通信的任意叠加。

2.2 四个不能互相代替的指标

1. 质量：业务任务完成率、准确率、长上下文能力、结构化输出正确率。
2. 延迟：TTFT、ITL、端到端延迟，以及冷启动/首次编译时间。
3. 容量：满足延迟目标时能承载多少并发、多少请求。
4. 效率：每个合格请求的成本或能耗，而不只是峰值 tokens/s。

首 token 延迟（Time to First Token，TTFT） 在客户端视角包含网络、排队、预处理和 prefill 等开销。每个输出 token 的平均生成时间（Time per Output Token，TPOT） 通常统计首 token 之后的生成过程，常见口径为：

1
2

TPOT = (请求结束时间 − 首 token 时间) / (输出 token 数 − 1)
       仅在输出 token 数 > 1 时有通常意义

token 间延迟（Inter-Token Latency，ITL） 描述相邻 token 的生成间隔。平均 TPOT 相同的系统，仍可能有很不一样的卡顿体验；网络流式输出一次合并多个 token 时，还要区分客户端事件间隔与引擎真实 token 间隔。vLLM 的基准测试实现给出了具体统计口径，比较结果前应先对齐定义。

服务等级目标（Service-Level Objective，SLO） 是为系统设定的可测量目标，例如延迟和可用性。尾延迟（tail latency） 关注延迟分布中较慢的部分，常用 p95、p99 等分位数表示。请求准入控制（admission control） 则根据容量与服务目标决定是否接收新请求。

对在线系统，更有用的是有效吞吐量（goodput）：本文按“单位时间内满足约定 SLO 的有效请求数”统计。单纯提高吞吐量，可能同时恶化排队和尾延迟。DistServe 正是围绕 TTFT、TPOT 约束下的有效吞吐量讨论系统设计。

本文建议将决策表达为：在质量、内存、功耗和 SLO 约束内，降低单位有效请求的总成本。 对端侧设备，总成本还包括电池消耗、温升、安装包与常驻内存；对集群，还包括网络、空闲容量、故障冗余和运维投入。

三、把技术放回各自的层：谁替代谁，谁依赖谁

flowchart TB
    A[业务负载与约束
质量 · 延迟 · 成本 · 功耗] --> B[服务与资源编排
路由 · 准入控制 · 扩缩容]
    B --> C[模型推理引擎
调度 · KV 缓存 · 模型执行]
    C --> D[图与编译系统
捕获 · 分区 · Lowering]
    D --> E[算子与设备运行时
计算内核 · 内存 · 通信]
    E --> F[硬件与互联
CPU · GPU · NPU]

这是职责分层，不是强制调用链。实际系统可能混合调用预编译算子、即时编译（Just-in-Time Compilation，JIT）生成的计算内核、厂商库和子图编译器，同一个项目也可能跨越几层。

这里要区分三个概念：算子（operator） 定义数学操作；计算内核（kernel） 是执行这些操作的具体实现；运行时（runtime） 负责执行期间的资源管理、任务提交等工作。一个算子可能调用多个内核，多个算子也可能融合为一个内核。图中的 lowering 指向更低层表示的转换，第八节会进一步说明。

几个尤其容易混淆的名字：

• Triton language 是计算内核语言/编译器；NVIDIA Triton Inference Server 是服务系统。
• TensorRT 与 TensorRT-LLM 是不同项目，后者的执行架构还在演进，不能凭名字推断其所有版本都必须构建 TensorRT 执行引擎（engine）。
• TorchDynamo 属于 PyTorch 图捕获编译链；NVIDIA Dynamo 面向分布式推理服务。
• GGUF 是模型文件格式，ggml 是张量计算库，llama.cpp 是建立在相关基础之上的推理项目。
• ONNX 主要是模型表示规范；ONNX Runtime（ORT） 是执行系统；ONNX Runtime GenAI 进一步提供生成循环等能力。ORT GenAI 文档

判断两个项目是否值得都深入，先问：它们处于同一层、服务同一类负载吗？ vLLM 与 SGLang 有大量重叠；vLLM 与 MLIR 则没有这种直接替代关系。

四、发展时间线：系统的主要矛盾怎样迁移

下面选取的是能解释技术演进的节点，不是完整编年史。论文日期采用首次公开版本或会议时间；项目发布和后端迁移另行标注，不能把它们当作技术的“发明时间”。

从这条线可以提炼三个方向：

1. 优化对象扩大了：单个算子 → 单个请求 → 多请求调度 → 跨机器状态与资源。
2. 模型与系统更紧密了：GQA、MLA、MoE、混合状态结构会改变内存、算子与通信设计。
3. 跨层接口越来越重要：只有计算内核快，或者只有调度好，都不保证端到端高效。

这是对上述资料的综合判断，不意味着每个项目都在走向相同架构。端侧设备与数据中心仍有明显不同的约束。

五、最值得长期投入的基础：性能模型与状态管理

5.1 预填充（prefill）与解码（decode）：同一模型的两种工作方式

预填充（prefill） 处理输入序列，为后续生成建立状态。线性层通常能形成较大的矩阵乘；长序列注意力又带来显著计算和访存压力。输入可以整段处理，也可以分块处理。

解码（decode） 在自回归路径上逐步生成，每步读取已有状态并追加新状态。批量大小（batch size）较小时，权重读取、KV 读取和计算内核启动开销往往比峰值算力更值得关注。增大批量能复用权重、提高矩阵乘效率，但会增加排队、KV 容量和调度压力。

因此，“prefill 计算受限、decode 带宽受限”是有用的经验起点，但绝非恒常不变的铁律。例如长上下文下的 prefill 同样会受限于注意力的显存带宽；而大批量并发、MoE 路由通信或投机验证下的 decode，也会迅速逼近算力上限。

在标准解码器中，应能跟踪以下形状变化：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

token → 词嵌入（embedding）→ 隐藏状态（hidden state）
  → Q、K、V 投影
  → 位置编码，例如 RoPE
  → 注意力（读取旧 KV，写入新 KV）
  → 输出投影、残差、归一化
  → MLP，或路由到多个专家
  → logits、采样、下一步请求状态

prefill：本轮 token 维度可较大
decode：普通自回归下，每条活跃序列通常贡献一个新 token

不需要先精通模型训练，但必须理解掩码（mask）、位置索引（position）、残差连接（residual connection）和采样语义。它们既决定性能，也经常是移植后“可以输出、但结果不对”的原因。几个高频术语与缩写应与具体含义对应起来：

MHA、GQA 与 MLA 的结构差异可对照 Transformer、GQA与 DeepSeek-V2原始论文。

5.2 先算是否装得下，再讨论跑得多快

推理内存至少包括：

1
2

总内存 ≈ 权重 + KV 缓存/其他持久状态 + 临时激活与工作区
       + 运行时/图执行/通信缓冲区 + 碎片与必要余量

以一个假设的 80 亿参数模型为例，若所有权重都按 4 比特理想打包，裸权重约为 4 GB，即 3.73 GiB。真实模型还要计入缩放因子（scale）、零点（zero point）、未量化层、对齐和可能的额外副本。因此，不能把“4 比特 × 参数量”当成设备最低内存要求。

对于各层配置相同、采用标准 MHA/GQA 的解码器，未考虑分片、共享与分页损耗时：

$$ M_{KV}=2\times L\times B\times T\times H_{KV}\times D\times s $$

其中，2 表示 K 与 V，L 是层数，B 是活跃序列数，T 是每条序列缓存的 token 数，H_KV 是 KV 头数，D 是头维度，s 是每元素字节数。不同序列长度不同时，用各自长度之和替代 B × T。

取 L=32, H_KV=8, D=128, T=8192, s=2：

• 单条序列的 KV 缓存约 1 GiB。
• 8 条同长度序列约 8 GiB。
• 若其他条件不变，KV 头数改为 32，则单条序列约 4 GiB。

这解释了 GQA 为什么会影响部署容量，也解释了“模型权重放得下”与“服务能承载目标并发”之间的差距。

必须警惕的架构边界：MLA 的低秩压缩状态、滑动窗口、跨请求前缀共享、不同层异构结构、混合 Mamba 状态以及张量并行都会重塑这个估算。不要试图用一个标准 Transformer 公式机械套用所有模型。DeepSeek-V2 论文、vLLM 混合 KV 管理设计

5.3 Roofline 性能模型：为什么 TOPS 不等于 token/s

Roofline 性能模型常译作“屋顶线模型”，用于联合分析算力与内存带宽对性能的限制。TOPS 表示每秒万亿次运算（Tera Operations per Second），比较时还要对齐数值精度与运算计数口径。一个简化的单设备性能上界是：

$$ P_{achievable}\leq\min(P_{peak},\ BW_{effective}\times I) $$

I 是算术强度（arithmetic intensity），即每搬运一字节完成多少次运算；P_peak 是计算性能峰值，BW_effective 是有效内存带宽，两项的运算计数口径需一致。实际可达性能还会受到并行度、形状、数值格式、片上容量和软件调度限制。NVIDIA 的 Roofline 分析说明

假设一次小批量 decode 必须从设备的片外内存读取 4 GB 权重，而有效带宽是 100 GB/s，那么仅权重读取的理想时间下界就是 40 ms。它没有包含 KV、计算、量化解包、同步和采样，不能作为实测预测；但足以说明，增加理论 TOPS 未必能解决问题。

优化应先按证据归类：

性能分析（profiling，也称性能剖析）的目标是建立因果链。 执行轨迹（trace）记录任务、算子或事件的时间顺序，用来观察等待与重叠；性能分析还需要结合计数器、采样和负载实验。仅看到某个“利用率”不高，不能直接确定瓶颈。例如，减少计算内核数可能更快，也可能因为融合后寄存器/片上存储不足而更慢。

六、核心优化方法：解决不同问题，可以组合使用

6.1 注意力、KV 和调度不是同一个优化层

上述机制分别可以从 FlashAttention 论文、PagedAttention 论文、Orca、vLLM 前缀缓存说明、调优指南和图执行设计继续深入。

一个实用的判断顺序是：先确认瓶颈，再选择机制，最后检查组合后的相互影响。例如，分页管理增加了可容纳的请求数，但更高并发也可能使 decode 的计算或通信变成新瓶颈。

还有两种“缓存”必须分清：精确前缀 KV 复用（exact prefix KV reuse） 要求状态语义一致；语义缓存（semantic caching） 根据相似问题复用回答，是应用层策略。它们的正确性条件完全不同，不能把命中率混在一起比较。

6.2 数值格式与量化：从数据表示到部署选择

FP16、BF16、INT8、INT4 是理解模型容量、带宽和硬件执行的通用核心知识。学习顺序是：一个数怎样表示 → 原值怎样映射到低比特值 → 权重与状态怎样保存 → 内核怎样计算 → 整个模型是否仍满足要求。

6.2.1 FP16、BF16、INT8、INT4 分别表示什么

数值格式（numeric format） 规定有限比特怎样表示数值；模型质量描述任务效果。浮点格式用符号、指数和有效数的小数字段表达不同量级；整数格式先表示离散整数，量化方案再赋予这些整数对应的实数含义。

浮点表中的小数字段不包含正规数隐含的最高有效位。FP16 与 BF16 虽然都占两个字节，但不能据此判断数值行为相同：在区间 [1, 2) 内，相邻正规数的间隔分别为 2^-10 和 2^-7；换成 BF16 可以扩大可表示范围，却可能丢失更多细微差异。格式结构与误差讨论可参考 TensorRT 数值精度说明；整数码域见 ONNX QuantizeLinear。

FP32 转为 FP16/BF16，通常作为浮点精度转换或混合精度的一部分讨论。INT8/INT4 量化还需要明确原值与整数编码之间的映射。FP8、FP4 也有各自的浮点编码，例如 E4M3、E5M2、E2M1；它们与同位宽整数的取值分布不同，具体变体、缩放规则与硬件支持需另行确认。低比特格式与量化方案

6.2.2 一个浮点数怎样变成 INT4

对均匀仿射量化，设缩放因子为 $s>0$、整数零点为 $z$：

$$ q=\operatorname{clip}(\operatorname{round}(x/s)+z,q_{\min},q_{\max}), \qquad \hat{x}=s(q-z). $$

$q$ 是保存的整数，$\hat{x}$ 是它代表的近似实数。假设使用 INT4 码域 [-8, 7]，s = 0.25、z = 0，舍入到最近整数，则可表示实数为 −2.00、−1.75……1.75：

这说明量化需要保存或约定 scale；单独把 −0.30 强制转换成整数，并不能得到上述含义。反量化恢复的是近似值，也无法自动找回已经丢失的信息。某些对称量化实现只使用 [-7, 7]，具体码域必须与后端一致；恰好位于两个整数中间时，还需统一舍入规则，例如 ONNX 的 ties-to-even。QuantizeLinear 规范

scale 较大时，能覆盖更宽的范围，但相邻可表示值间隔更大；scale 较小时，范围内更精细，却可能截断离群值。这正是校准和量化算法需要处理的取舍。

6.2.3 粒度、量化对象与 W4A16 要分别说明

对称量化通常采用零点为零的有符号表示；非对称量化通过非零零点平移可表示区间。量化参数还可以按不同粒度共享：

激活参数也可以离线校准后固定，或在运行时由当前输入统计得到。这里的“动态量化”涉及量化参数的获取时机，与“动态输入形状”是不同概念。

W4A16 表示相关计算路径中的权重采用 4 位表示、激活采用 16 位表示；仍需说明这 4 位是什么编码、16 位是 FP16 还是 BF16。W8A8 同样需要补充 INT8、FP8 等具体类型。仅凭这些缩写，无法确定整模型所有张量的类型。

至少分别记录四项：权重、激活、KV 缓存、累加器。例如，一个方案可以使用 INT4 权重、FP16 激活、FP16 KV，并在部分矩阵运算中使用 FP32 累加；这是可能的组合，是否支持由具体内核决定。降低权重位宽不会自动压缩 KV，累加器也不必与输入同类型。

6.2.4 模型文件为什么大于“参数量乘以位宽”

紧凑打包的 INT4 可以把两个数装进一个字节，但还需要量化参数、张量描述与对齐。先看一个纯粹的容量算例：假设 80 亿权重全部采用 INT4，每 128 个权重保存一个 FP16 scale，零点固定为零、不另存，并忽略其他开销：

1
2
3
4
5
6

INT4 权重：8,000,000,000 × 4 / 8 = 4.000 GB
FP16 scale：8,000,000,000 / 128 × 2 = 0.125 GB
合计：4.125 GB，平均每个权重 4.125 bit

同数量 FP16 原始权重：16 GB
本例压缩倍数：16 / 4.125 ≈ 3.88 倍

这里使用十进制 GB。真实模型还可能包含零点、未量化层、填充、索引和不同分组方式；运行时再增加 KV、激活、工作区，以及可能重新打包或展开的副本。因此，应分别测量磁盘模型包、加载后常驻内存、生成过程峰值内存。

还要区分文件容器与张量编码。例如 GGUF组织模型张量和元数据，同一个容器可以承载不同编码或混合类型；看到 .gguf 后缀，不能直接推断模型全为 INT4。

6.2.5 保存为低比特，计算时走什么路径

仅权重量化（weight-only quantization） 描述只对权重实施低比特量化的方案，并不单独规定设备指令。部分 W4A16 内核按块读取 INT4，在计算过程中解包、反量化到 FP16/BF16，再参与矩阵运算；转换可以融合在内核内部，避免先把全部权重展开成长驻浮点副本。其他路径可以利用目标硬件支持的低比特计算能力，前提是数值类型和缩放方式匹配。

flowchart TB
    W[紧凑 INT4 权重
分组 scale 等元数据] --> D[按块读取 · 解包 · 反量化]
    D --> M[浮点矩阵运算
FP16 输入 · FP32 累加]
    A[FP16 激活] --> M
    M --> O[按输出约定转换与写回]

检查真实路径时，要同时看计算类型、反量化位置、设备执行与额外副本。Q/DQ 图表达的数值语义，需要由后端转换成受支持的执行方案；一个转换操作在图中存在，不意味着运行时必然有一次独立搬运。TensorRT 显式量化与融合

低比特可能降低权重带宽压力，也可能因为解包、重排、转换或不合适的内核而增加延迟。量化选型要比较质量、权重容量、KV 容量、prefill、decode、能耗，并分别观察长输入和小批量生成。

6.2.6 量化流程、算法与格式怎样对应

训练后量化（Post-Training Quantization，PTQ） 从已训练模型出发做量化；量化感知训练（Quantization-Aware Training，QAT） 在训练或微调中模拟量化影响。它们是流程类别。INT4/INT8 是表示类型，下面这些方法则解决量化参数和误差分配问题：

算法依据见 GPTQ、AWQ、SmoothQuant。工程工具可从 LLM Compressor 算法选择指南了解。学习时先做一种格式的基线和误差分析，再选择与目标硬件相容的算法；MX 等带有特定缩放规范的格式，按所选工具链的实际需要补充。

6.2.7 部署选型与学习优先级

按以下顺序作出决定：确认芯片和引擎支持 → 建立参考精度基线 → 选择量化对象与格式 → 校准并检查误差 → 比较完整负载 → 决定采用范围。权重容量不足、KV 过大和计算耗时高，可能需要不同方案；PTQ 质量不达标时，再评估混合精度或 QAT 的收益与成本。

评估时先逐层/逐算子对齐，再用任务集检查退化。困惑度（perplexity）可以作为信号，不能替代中文任务、代码、长上下文和视觉理解测试。LM Evaluation Harness可复用标准流程，但仍需固定分词器、模板、任务版本、少样本示例与生成设置，并加入业务样本。

P0 必须掌握：常见格式、范围与精度、量化映射、参数粒度、权重/激活/KV/累加器区别、实际容量和计算路径。P1 按方向深入：一种量化算法及其目标后端实现。P2 按需扩展：暂不适用的特殊格式、其他同类算法与厂商位级实现。第十三节第三周的练习按这一顺序展开。

6.3 投机解码：额外计算能否换来更少的串行等待

投机解码（Speculative Decoding，也称推测解码） 的经典思路是：草稿模型（draft model）提出若干 token，目标模型（target model）一次验证，按接受规则保留候选前缀，再继续生成。在正确的拒绝采样（rejection sampling）算法与相应假设下，可以保持目标模型的输出分布；这不等于任意实现都与普通路径逐 token、逐比特相同。原始论文。“投机解码”也是飞桨官方文档采用的译名。

可以用下面的简化式理解收益，而不把“接受率”当成唯一指标：

1
2
3

投机路径的平均每 token 时间
≈ (草稿时间 + 目标验证时间 + 调度/状态管理时间)
  / 每轮平均实际提交的 token 数

EAGLE-3与 DFlash展示了这一方向的演进。对于 NPU，验证阶段的多 token 形状可能更有利于矩阵单元，但额外 KV、回滚、同步和草稿端放在哪里，都可能抵消收益。

学习顺序：先理解正确性与收益条件，再阅读一种实现。 当基础 decode 已经在高并发下充分利用算力时，投机执行还可能争抢资源；不要直接迁移论文中的加速倍数。

七、推理引擎地图：深入一个，能够比较其余

7.1 六个常见项目的架构侧重点

下表按架构侧重点组织，不代表性能排行榜。各项目都在扩展能力，选型应落到具体负载、版本、目标模型与硬件上。

建议采用“一主一对照”的学习方式：

• 在线服务路线：在 vLLM 与 SGLang 中选一个主引擎，使用同样的请求集比较另一个；硬件采用插件时，继续检查插件的能力边界。
• 端侧与本地路线：以 llama.cpp、MLC LLM 或平台原生方案 中的一条为主，围绕转换成本、内存与功耗比较另一条路径。
• NVIDIA 深度优化路线：选 vLLM 或 TensorRT-LLM 作为主工程，通过性能分析工具、计算内核和真实负载判断另一条路径的收益。
• Apple 平台实验：用 llama.cpp/MLX 建立模型、量化和测量能力；需要不同设备后端时，再分别验证对应的转换与运行链。

需要破除两点常见的刻板认知：

第一，llama.cpp 不能再被概括为“纯 CPU/Mac 本地工具”。 当前官方仓库已涵盖 CANN、Hexagon 等异构后端，并将 OpenVINO 标为进行中；具体能力应结合目标后端文档核验。Metal GPU 执行也不等于 ANE 执行。 llama.cpp 后端列表

第二，SGLang 也绝非仅仅是“结构化输出前端”。 它当前覆盖高性能连续批处理、预填充/解码分离（PD 分离） 、MoE 并行等全栈服务能力；但需注意，项目主页列出支持某种硬件，并不意味着所有高级优化在该硬件上都已具备同等的生产成熟度。SGLang 仓库

7.2 哪些工具只需要了解，不必同时深入

还应知道两类补充选项：LMDeploy 提供压缩、部署和服务能力，包含 TurboMind 与 PyTorch 执行路径，适合与主服务引擎进行目标模型上的比较；MNN 偏向轻量端侧推理，并有 LLM 能力，适合移动/嵌入式路线考察模型转换、运行时与应用集成。二者都值得放入选型地图，但没有理由在尚未完成一条主线之前同时精读全部实现。

7.3 2026 年需要特别留意的维护与迁移状态

• TGI 已进入维护模式，官方说明以小修复、文档和轻量维护为主，并推荐新选择考虑 vLLM、SGLang 或本地运行方案。对于新学习路线，不宜再默认把它作为主要投入对象。TGI 官方说明
• AutoAWQ 已弃用，相关功能迁入 vLLM 生态的 LLM Compressor。这里变化的是工具维护路径，AWQ 算法仍然值得理解。vLLM AutoAWQ 文档
• FasterTransformer 官方不再继续开发该项目，并将方向转向 TensorRT-LLM。它仍可作为历史实现参考，但不适合作为新部署主线。FasterTransformer 仓库说明
• TensorRT-LLM 的 latest 文档与 v1.3.0rc27 预发布分支发生后端变化：旧 TensorRT 执行引擎（engine） 后端移除，PyTorch 成为执行后端，基于它的 AutoDeploy 保留；新路径直接加载 Hugging Face 模型检查点，不再经过旧的引擎构建流程（engine build）。这不是说所有已发布旧版本都如此，也不是 TensorRT 产品被取消。 阅读旧教程时先核对版本。迁移指南、预发布记录

因此，建立学习路线时应追踪问题与接口；具体命令、目录和后端名称则跟随所固定的版本。

八、编译器与算子：模型怎样变成高效的设备执行

推理引擎最终要调用设备能够执行的计算。编译器和算子层决定模型如何表示、哪些操作可以融合、数据放在哪里以及怎样映射到硬件。所有路线都值得理解这一层的作用；只有需要改变其行为时，才需要深入特定编译器或计算内核实现。

8.1 先理解编译链中的动作

flowchart TB
    A[模型语义与权重] --> B[图捕获或导出
算子 · 形状 · 状态约束]
    B --> C[算子合法化与图优化
分解 · 融合 · 量化]
    C --> D[图分区
子图与设备边界]
    D --> E[Lowering 与代码生成
布局 · 分块 · 内存规划]
    E --> F[编译产物与运行时
加载 · 提交 · 同步]
    F --> G[正确性与性能验证]
    G -. 反馈 .-> C

中间表示（Intermediate Representation，IR） 是编译器能分析与变换的程序表示。lowering 在本文保留英文，指将高层表示逐步转换为更低层表示，在保持程序语义的同时落实循环、内存布局、并行和设备指令等细节。MLIR 的逐级转换示例

算子合法化（operator legalization） 指将不符合目标约束的操作改写为合法操作；这里的“合法”由转换目标定义。图分区（graph partitioning） 决定哪些节点或子图交给哪个后端执行。这些步骤可能在不同层次反复发生，图 4 表示概念流程，不限定编译器必须采用这一顺序。MLIR Dialect Conversion

MLIR 中的方言（dialect） 组织某类操作、类型和属性；编译 pass 是编译流水线中的处理单元，可以执行分析或转换。中文也会称 pass 为“编译遍”，本文保留 pass，便于对照源码。

深入编译路径时，需要能回答：一个算子的 lowering 为什么失败？是缺实现、形状不受支持、数据类型（dtype）不匹配，还是状态/控制流无法表达？某次融合为什么没有发生？编译器怎样证明缓冲区（buffer）可以复用？

8.2 编译相关项目不是一组平行竞品

依据：PyTorch compile 教程、export 教程、ORT Execution Providers、TVM 文档、MLIR、IREE、ExecuTorch 架构。

后端委托执行（delegation） 是把图或子图交给专用后端编译和运行；ExecuTorch 等项目把承担这一工作的后端组件称为 delegate，本文保留该名称。它与 ONNX Runtime 的 EP 都涉及后端接入，但具体接口并不相同。“执行提供程序”沿用微软中文文档中的称呼。ExecuTorch delegate 说明、微软 EP 文档

阅读 torch.compile 时，还应区分图中断（graph break） 与守卫条件（guard）：前者使计算无法连续捕获为同一张图，后者检查输入或运行状态是否满足复用已编译结果的条件。

“图捕获（graph capture）”也有上下文差异：TorchDynamo 捕获的是供编译器处理的程序计算图；CUDA Graph 捕获的是待重放的设备操作及其依赖。二者处于不同层次，可以配合使用。

两个容易踩到的版本问题：

1. torch.compile 默认路径可在 graph break 后回到 Python 执行，再继续捕获；torch.export 要求得到完整图，不能靠这种方式保留未捕获代码。fullgraph=True 又会改变 compile 对 graph break 的处理。不能只说“两个 API 都是导出模型”。
2. TVM 旧文章常以 Relay 为中心，当前文档则需要关注 Relax、TensorIR 等新的组织与表示。阅读教程前固定 TVM 版本，别把不同年代的 API 拼成一条部署流水线。

架构选择建议：若厂商已有稳定编译器，先围绕其接口完成模型适配；若缺少特定算子，增加计算内核或子图后端；只有现有接口无法满足关键模型与性能目标、且团队有长期维护能力时，才考虑大范围自研编译基础设施。

8.3 算子技术栈：先掌握硬件映射，再选择表达方式

领域专用语言（Domain-Specific Language，DSL） 针对特定计算方式提供表达能力。这里的 tile 指计算分块，tiling 指分块策略，数据布局（data layout） 描述张量元素怎样映射到内存或线程。GEMM 指通用矩阵乘（General Matrix Multiplication），GEMV 指通用矩阵向量乘（General Matrix-Vector Multiplication）。

在硬件优化路线中，优先掌握这些可迁移概念：计算分块、数据布局、向量/矩阵单元、片上存储、数据搬运、流水线（pipeline）、同步、双缓冲（double buffering）、边界处理与数值累加。 片上 SRAM 是静态随机存取存储器（Static Random-Access Memory），具体用途随硬件而异。Ascend C 的 CopyIn/Compute/CopyOut 与队列示例，是理解显式搬运和流水线的一个公开入口；它与 GPU 或其他 NPU 的具体存储、调度机制仍有差别。官方编程介绍

8.4 系统语言不是附属技能

Python 常承担模型描述、转换、实验、调度与系统集成；C++ 常出现在运行时、内存管理、设备接口和性能关键路径。需要掌握的工程能力包括：

• C++ 的对象生命周期、缓冲区所有权、并发与异步回调；掌握 RAII（Resource Acquisition Is Initialization，资源获取即初始化），通过对象生命周期管理资源。
• Python/C++ 边界、外部函数接口（Foreign Function Interface，FFI）、零拷贝（zero-copy）的实际条件，以及错误传播。
• CMake、交叉编译、应用二进制接口（Application Binary Interface，ABI）与动态库依赖、目标板部署。
• Linux 进程/线程、非统一内存访问（Non-Uniform Memory Access，NUMA）、CPU 亲和性、调试器与内存检查工具。
• 基准实验设计、日志/执行轨迹分析和最小复现。

“会写一个计算内核”和“能把它长期稳定地接入推理引擎”，中间往往隔着这些系统工程工作。

九、部署工程链：从模型产物到稳定运行

9.1 选硬件时，也在选择软件栈

设备选型要同时考虑算力、内存、带宽、互联和软件成熟度。GPU 不同代际的精度支持会影响计算内核选择；NPU 的矩阵/向量单元、片上存储、指令和 SDK 开放程度也有很大差异。数据中心加速器与手机 SoC 更不能只按同一个“TOPS”数字比较。

这张表表达常见关注点，不是给硬件类别下固定性能结论。某个端侧后端可能支持动态形状，某个高性能计算内核也可能只支持一组固定形状；要看实际支持范围与接口约定。

9.2 观察不同生态怎样连接模型与设备

这些项目展示了两类典型路径：通过成熟引擎及其后端执行模型，或把模型编译为设备可执行的图/子图，由运行时驱动。实际系统可以混合使用。前者更关注引擎的模型覆盖、调度和集成，后者更需要显式管理转换、形状、编译产物与运行时接口。

厂商在 GitHub 上发布 SDK、示例或二进制包，也不代表编译器、驱动与固件全部开源。选型时要逐层记录“可修改、可调试、可再分发”的边界，并确认实际授权条款。

9.3 第一步：明确支持范围，建立正确性基线

先选一个设备能容纳、架构清晰的模型，打通单请求推理。首次验证可以从小型稠密模型开始，再逐项加入目标模型结构、长上下文、多模态或并行特性。已有成熟引擎时优先复用其正确路径，避免同时改动模型语义、数值精度和执行后端。

支持范围与接口约定至少写明：

1
2
3
4
5
6
7

模型与分词器：具体版本、权重校验、对话模板（chat template）
模型语义：层数、头数、位置编码、掩码、缓存更新方式
输入范围：批量大小、上下文长度、预填充分块大小、图像尺寸/数量
数值格式：权重/激活/KV 格式、累加精度、量化元数据
设备环境：芯片、驱动、固件、SDK、编译器、运行时
允许行为：动态形状范围、容量超限处理、回退设备、最大并发
验收标准：质量、TTFT/ITL、峰值内存、功耗、稳定性

以高精度参考实现为基准，依次比较 词嵌入、单层注意力、MLP、logits 和生成行为。检查长短序列、不同位置索引、填充、缓存命中与未命中、缓存追加和截断等边界。

不要只对比一段“看起来通顺”的输出。浮点误差可能先出现在某层，经过多步采样放大；固定输入下的中间结果和 logits 更适合定位问题。

9.4 第二步：打通执行路径，确认隐藏的回退

在成熟引擎中，应先确认预期的量化计算内核、注意力后端和图执行路径实际生效；“配置了”不等于“使用了”。在图编译或异构部署路径中，还要检查子图分区。一个不支持的算子可能导致：

1
2

加速器子图 → 同步 → 拷贝/布局转换 → CPU 算子
          → 拷贝/布局转换 → 同步 → 加速器子图

回退本身可以帮助先获得正确结果，但若该边界在每层、每个解码步都触发，就可能成为主要瓶颈。统一内存也不自动消除布局转换、缓存一致性和同步成本。

因此，适配优先级应看关键路径时间与边界开销，不只是“还剩几个算子没支持”。一个非常小的缺失算子可能切碎整张图；一个较大的预处理算子留在 CPU 上，反而未必影响逐 token 路径。

一种可操作的分区评估是：

子图迁移收益 = 原路径耗时 − 新设备计算耗时 − 数据转换/传输耗时 − 新增同步和调度耗时。

ONNX Runtime 的 GetCapability() 和 ExecuTorch 的 delegate 机制提供了公开的分区设计样本。开发新设备后端时，还要和相应编译器对齐状态输入输出、布局和内存所有权。ORT EP、ExecuTorch 架构

9.5 第三步：分别处理动态形状、布局与状态内存

动态形状策略通常需要在以下方案之间取舍：

• 真正的动态执行：灵活，但优化和运行时成本需要验证。
• 形状分桶（shape bucketing）：按常见批量大小和序列长度划分若干组并预编译，未精确命中时选择能够容纳输入的更大桶。
• 填充（padding）与分块：换取规则形状，代价是额外计算或状态管理。
• 编译特化（specialization）与产物缓存：针对特定形状、数据类型等生成优化版本；热点路径快，但首次编译成本和产物数量可能增长。

对每种方案，同时记录冷启动、编译时间、稳态性能与内存。prefill 和 decode 可以采用不同编译策略，不必强求用一张完全相同的图覆盖所有情况。

布局规划要同时满足矩阵单元、向量算子、量化打包和 KV 访问需求。某次局部布局变换让一个 GEMM 更快，却可能使后续注意力多做一次完整转置。因此，应沿子图传播布局，再核算整体成本。

内存规划（memory planning） 要区分两类对象：临时激活和工作区（workspace，即计算所需的临时存储）可根据生命周期复用；权重、KV 缓存和请求状态则跨迭代存活。一次前向计算（forward pass）结束不意味着它们可以释放。编译器的静态内存规划与运行时的动态 KV 缓存管理必须明确责任边界。

9.6 第四步：从关键路径优化到端到端收益

先根据瓶颈选择优化层。如果主要时间花在排队，应调整准入控制与调度；如果花在预处理或同步，应优化数据路径；如果计算内核主导，再选择 GEMM/GEMV、RMSNorm、RoPE、注意力或量化解包等热点。以算子优化为例，过程应包括：

1. 固定形状/数据类型/布局与误差标准。
2. 建立原始实现和性能基线。
3. 分析 tile、片上容量、数据复用、同步和搬运。
4. 逐项优化，保存实验记录。
5. 接回完整模型，检查端到端延迟、内存和质量。

用 Amdahl 定律检查预期：若某计算内核只占总耗时 20%，把它加速到 2 倍，其他部分不变，整体加速约为 1 / (0.8 + 0.2 / 2) = 1.11 倍。这仍可能值得做，但必须知道收益上限。

性能分析工具（profiler）应关联主机端（host）、运行时、设备任务、内存和通信的数据；昇腾的公开文档就提供了框架层与 CANN 数据联动的样本。Ascend PyTorch Profiler

9.7 第五步：把推理单元变成稳定的产品能力

在线服务需要处理流式响应、请求截止时间、取消、准入控制、健康检查和扩缩容；端侧产品需要管理模型加载、内存压力、前后台状态、温升和离线更新。两者都要能观察错误、固定版本并回退。

如果进一步深入运行时与后端，至少要处理以下问题：

• 请求取消后，设备上的异步任务尚未结束时，谁持有缓冲区？
• KV 页何时回收？缓存条目被共享时如何避免提前释放？
• 发生内存不足（Out of Memory，OOM）时，是拒绝新请求、缩小批次，还是导致整个进程退出？
• 设备重置、模型切换、SDK 错误如何暴露与恢复？
• 编译产物、量化权重与运行时 ABI 是否一致？
• 长时间运行会不会泄漏、碎片化或因温升持续降速？

一个可交付的推理系统，要同时具备清晰的支持范围、可定位的问题和可回退的升级路径。 现成引擎可以承担其中很多工作，但系统的使用者仍需验证这些行为是否满足自身要求。

十、进阶方向：规模扩大以后，主要瓶颈怎样变化

10.1 并行策略：先决定切什么，再讨论用几张卡

这里的 EP 指专家并行，与第八节 ONNX Runtime 的执行提供程序（Execution Provider）同缩写、不同含义。流水线气泡是阶段间依赖或任务不足导致的设备空闲时段。

这些策略可以组合，但组合空间越大，测试与运维复杂度越高。参考引擎的具体实现和支持矩阵，而不是仅凭缩写设计系统。TensorRT-LLM 文档入口、SGLang

10.2 MoE：激活参数量小，不代表部署内存和通信都少

MoE 每个 token 只使用部分专家，减少的是一部分计算；完整模型仍有大量总参数需要放置、加载或按需调入。路由分布还可能使不同设备负载不均。

因此，MoE 部署同时涉及：

• 总参数决定的权重容量，以及每个 token 激活的参数量所对应的计算。
• 小批量专家 GEMM 的效率、权重精度与布局。
• token 分发（dispatch）、专家结果合并（combine）、全互换通信（all-to-all）和跨机拓扑。
• 热门专家、冗余部署、负载均衡，以及通信与计算重叠。

这也是 DeepGEMM 与 DeepEP 需要分开理解的原因：前者关注计算，后者关注专家通信。新模型采用 MoE，不意味着必须一开始就上复杂多机 EP；先根据容量和负载验证最简单可行方案。

10.3 PD 分离与 KV 基础设施：收益来自负载，成本来自数据流

预填充/解码分离（Prefill/Decode Disaggregation，简称 PD 分离） 把两个阶段放到不同资源池，使它们独立调度和配置。代价是 KV 状态需要跨资源边界传递，还要处理排队、路由、失败和容量不平衡；这一架构思路最早由 DistServe 论文 系统性提出并验证。

flowchart TB
    A[请求路由与准入控制] --> B[预填充资源池
Prefill]
    B -->|KV 状态传输| C[解码资源池
Decode]
    D[可选的 KV 缓存层] -. 加载复用 .-> B
    D -. 加载 .-> C
    C --> E[流式输出]

它们存在重叠，也存在集成关系；不能把四个项目作为四个完整推理引擎逐一替换测试。尤其是缓存复用，读取 KV 的时间必须小于省掉的计算和等待，才有实际收益。

这里的缓存卸载（cache offloading） 指把 KV 状态从加速器内存迁移到 CPU 内存、SSD 等存储层，需要时再加载。缓存复用回答“能否省掉重复计算”，缓存卸载回答“状态放在哪里”，两种机制可以组合。

缓存还具有语义边界：模型权重版本、低秩适配（Low-Rank Adaptation，LoRA）的配置、位置与 token 前缀、精度/布局、租户隔离都会影响复用条件。普通因果注意力（causal attention）中，任意中间文本片段不能因为“内容相同”就直接复用为精确 KV；非前缀复用可能需要重算或质量恢复策略。LMCache 的相关能力说明

对于单设备、本地交互或小规模服务，先理解机制与收益条件即可；当跨节点数据流、阶段干扰和缓存容量成为实际瓶颈时，再将其升级为需要深入的核心能力。

10.4 VLM：把整个输入链计入推理系统

一种常见 VLM 路径是：

1
2
3

图像/视频 → 媒体解码与预处理 → 视觉编码器 → 投影/连接模块
                                         ↓
文本 → 分词器 → 多模态序列组织 → LLM prefill → decode

不同模型也可能采用跨注意力等结构，不能照搬同一个部署模板。架构师需要额外关注：

• 图像分辨率、切图和视频帧数怎样改变视觉 token 数量。
• 编码器、投影层和语言模型是否使用不同设备/精度。
• 主机端预处理、编码器延迟、跨设备传输是否主导 TTFT。
• 动态形状与多图批次如何影响编译缓存和内存峰值。
• 量化后是否损伤 OCR、细节识别、空间关系等具体任务。

所以，LLM 解码器的 tokens/s 不能代表一个视觉助手的端到端体验。VLM 优化要分别测输入准备、视觉编码、prefill 和 decode，再决定优化位置。

10.5 当前值得跟踪的变化，而不是需要全部复现的论文

截至资料核对日期，本文建议持续关注四条方向：

1. 模型状态变得多样：GQA、MLA、滑动窗口与混合状态模型，使“所有层都是同一种 KV”越来越不够用。混合 KV 管理
2. 低精度向整条数据路径延伸：不只权重，还包括激活、KV、通信；支持情况要与计算内核和硬件共同验证。LLM Compressor
3. 推理资源围绕状态与阶段组织：长上下文、多轮对话和智能体负载使缓存、路由和阶段分离更有研究价值。Dynamo、Mooncake
4. 草稿生成与内核表达继续演变：投机方法与 Python 计算内核 DSL 都有新进展；先掌握成本模型，再选择具体实现。DFlash、CuTe DSL

这是从当前资料中提取的关注方向，不是所有部署场景都必须采用的路线。

十一、架构选型：四种场景，四种主要瓶颈

11.1 在线交互服务：在延迟目标内增加有效容量

先验证：模型质量、输入/输出长度分布、峰值到达率，以及 TTFT、ITL 和可用性要求。引擎支持、精度、单机容量与网络条件共同约束部署方案。

初始方案：选一个成熟服务引擎，从单实例建立基线，按容量需要增加副本或模型并行。先使用可观测的调度、缓存和准入控制策略，再考虑更复杂的跨节点优化。

投入重点：请求调度、KV、连续批处理、尾延迟、路由与故障隔离。NVIDIA、AMD 或 NPU 平台的差异，应落实到后端支持和完整版本组合上。

何时引入 PD 或 KV 缓存外置：测量显示 prefill/decode 互相干扰或跨请求复用有价值，且传输成本可以接受。上线前与原方案做消融实验，计入新增的故障和运维复杂度。

11.2 离线批处理：降低固定任务集的完成成本

先验证：数据规模、长度分布、质量要求、完成期限和失败重试语义。它通常不需要与交互式服务相同的逐 token 体验，但仍有任务完成时间约束。

初始方案：使用支持离线执行的推理引擎，按长度和容量组织批次，分片处理任务，保存可恢复的进度与输出。比较单机批处理、多个独立副本与模型并行的总成本。

投入重点：吞吐量、内存利用、数据供给、长度分组、幂等重试和输出验收。这里更大的批量可能合理，但仍需核算长尾任务、OOM 与失败恢复成本。

何时改变方案：任务供给不足、长度差异导致资源空转、模型容量超出设备，或总完成时间无法达标。优化对象由固定任务集的完成成本决定，不能直接照搬聊天服务的延迟最优配置。

11.3 端侧与本地应用：在资源边界内保证持续体验

先验证：质量、可用内存、持续功耗、热稳定后的持续性能、冷启动和离线要求。多模态应用还要计入图像/音视频的预处理和编码成本。

初始方案：根据平台，在 llama.cpp、MLX、MLC、MNN、ExecuTorch、Core ML 或 LiteRT 等路线中筛选一条可行路径。先打通端到端体验，再优化量化、模型加载和设备分工。

投入重点：权重与 KV 容量、精度、冷启动、内存生命周期、异构执行和应用集成。峰值 tokens/s 只是测量项之一，长时间使用后的速度与能耗同样重要。

何时改变方案：模型容量与质量难以兼顾、热降频不可接受、平台后端覆盖不足，或转换与更新成本过高。此时需要联合调整模型、精度和执行路线，而不只是更换 UI 或 API 包装层。

11.4 新硬件与专用加速器：控制适配边界与维护成本

先验证：厂商编译器、算子、运行时、驱动和通信栈的可用性与开放边界。明确目标是接入已有引擎、委托执行子图，还是开发更完整的执行栈。

初始方案：高精度参考实现 + 最小可用后端。用一个代表模型验证数值、形状、缓存和分区，再按关键路径补充算子或融合。对有现成插件的设备，优先验证插件方案。vLLM Ascend 的版本策略提供了观察全栈兼容关系的具体例子。

投入重点：编译器接口、布局、数据搬运、计算内核、状态内存和目标设备性能分析。性能成果必须回到完整模型上验证。

何时扩大自研范围：现有接口无法表达关键模型语义、频繁回退造成不可接受的成本，或模型演进长期受阻。扩大范围之前，应确认团队能够承担测试矩阵、编译器升级和长期回归维护。

11.5 一份够用的技术选型记录

每次重要选型可以写一页架构决策记录（Architecture Decision Record，ADR）：

1
2
3
4
5
6
7

问题：什么负载或交付要求促成这次决策？
约束：质量、SLO、内存、功耗、设备、团队与时间。
候选：当前方案、最小改动方案、替代方案。
证据：固定版本、代表负载、原始测量、正确性检查。
决定：采用什么，为什么收益足以覆盖复杂度？
代价：适配、模型更新、编译、运维、许可与供应商依赖。
退出条件：什么变化会触发重新评估？如何回退？

架构能力体现在边界与取舍上。 一条可持续增加模型、定位退化并可靠升级的部署链，才具备长期演进的基础。

十二、怎样做可信的比较：让每个结论都能被复查

12.1 基准测试必须覆盖负载分布

至少分开测量：

并发数与到达率不是同一个控制变量。 固定并发的闭环压测，会在请求变慢时自然减少新请求；固定到达率的开环压测更容易观察排队和过载。两种方式都可以使用，但要写清楚，并检查压测客户端自身是否先遇到 CPU、连接或流式解析瓶颈。

12.2 比较前固定这些条件

• 模型与分词器版本标识、模板、输入集、输出长度分布、采样和停止条件。
• 权重/激活/KV 精度、量化算法与校准集、质量评测口径。
• 芯片、数量、频率/功率设置、内存、互联，以及完整软件版本。
• 批量大小/每轮 token 预算、并行策略、上下文上限、缓存、图执行和投机设置。
• 预热、首次编译是否计入，测试时长、重复次数与测量窗口。
• 错误、拒绝、超时和取消请求怎样进入统计，不能从分母中悄悄消失。

不同分词器的 token 长度也不同。跨模型比较 tokens/s 时，应额外报告任务完成时间或字符/样本层面的业务指标，避免把 token 切分差异误认为系统优化。

推荐保存如下记录，而不是只截图一行吞吐量：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

实验编号 / 日期 / 配置文件 / 源码提交标识
模型、分词器、量化产物与校验信息
硬件、系统、驱动、SDK、运行时版本
请求集与到达方式；输入/输出长度分布
质量结果与失败样本
TTFT p50/p95/p99；ITL 分布；TPOT；端到端延迟
输出吞吐量、有效吞吐量（goodput）、错误/拒绝/超时率
内存峰值、稳态功耗、冷启动/编译时间
执行轨迹与热点归因
相对基线的唯一变化、收益、退化场景、结论适用范围

最后做消融实验（ablation study）：分别开关量化、缓存、分块、图执行、投机等机制。若同时换模型、换精度、换引擎、开缓存，就很难知道收益来自哪里。vLLM 持续基准测试说明可作为组织回归记录的参考。

12.3 稳定性与交付也是评测维度

服务型部署增加长时间压力、过载、取消、OOM、设备异常、升级/回退检查；端侧增加热稳定后的性能、前后台切换、资源争用和冷启动检查。

每个发布包应尽量包含固定依赖、模型与量化产物标识、编译配置、支持矩阵和验收结果。对于编译型后端，编译产物也应视为版本化交付物：它可能绑定设备、SDK、形状和精度配置。

十三、8 周学习路线：课程带路，每天实践，项目贯穿

前十二节回答“这一领域有哪些问题、技术和选择”。从这里开始，把它们转成可以执行的学习计划：每周解决一个主要问题，每天完成一个具体任务，同一个项目贯穿八周。 视频建立直觉，讲义核对推导，论文解释机制，文档与源码帮助实现；学习成果用代码和实测结果检查。

13.1 先明确投入、基础与完成目标

下面按每天可投入约 8 小时、每周 5 个主要学习日设计，共 40 个学习日，约 320 小时。第 6、7 天留作休息、补缺或复盘，不再追加必修任务。每日安排只规定材料、任务与产物，具体时间由实验难度调整。

这个投入适合在两个月内完成：理解通用推理原理，掌握一条主要执行路径，做出一项有证据的优化，交付可复现的部署与评测工程。 编译器开发、大规模分布式推理和端侧工程各自都有较深的学习空间；本计划在共同基础之后选择一个方向深入。

开始前做三项自测：

1. 能用 PyTorch 创建张量，解释矩阵乘、广播、维度变换和 softmax。
2. 能读懂模型前向代码，区分参数、激活、训练模式与推理模式。
3. 能创建 Python 环境、安装依赖、用 Git 保存代码，并定位一段报错。

缺少这些基础时，用 PyTorch 官方基础教程中的张量、模型与自动求导内容补齐，再做第 1 周实验。C++ 按方向补充，运行时与硬件后端方向尤其需要理解对象生命周期、内存和异步执行。

每天采用同一种学习顺序：先回顾昨日结果，再带着当天问题看课，然后实现、测量，最后记录结论。 每周精选的视频通常控制在约 4—6 小时的原始播放量，允许跳过已掌握的内容；主要精力留给推导、代码、排错与复测。AI 可持续协助读代码、搭实验和分析报错，具体用法见第 13.6 节。

下文的每日实验由本文围绕课程主题设计；标注 Lab 或 Assignment 的链接才是课程原有作业。完整大学课程的作业可能需要数天，不要求同时完成几门课的全部作业。

13.2 课程怎样选：三项主资源，按方向补充

课程与链接核对于 2026 年 9 月 21 日。 讲次必须和年份一起记录：本文采用 MIT 2024 秋季版、CS336 2026 春季版，以及下表注明的其他版本。课程适合讲原理，实际安装与命令仍应对照所用软件版本的官方文档。

这份组合的分工是：MIT 解释优化原理，CS336 补计算与系统基础，vLLM 短课提供可操作流程。 其他资源只在对应周次或技术分支中使用。同一主题已经理解并完成实验，就不必再完整刷一门相似课程。

几个直接影响执行的选择：

• 量化实验入口：MIT Lab 2：量化、Lab 4：LLM 压缩。先读说明，选取符合当周目标的一部分；第 3 周也提供本地最小实验。
• 系统实验入口：CS336 Assignment 2：Systems包含基准测试、性能分析等任务。第 2 周只选相关部分，完整 FlashAttention 与分布式训练作业放到后续深入阶段。
• 获取方式：DeepLearning.AI 的部分代码、项目或评分功能可能受登录和订阅条件限制，以课程页为准。本文的验收以自己的脚本和实验记录为依据，也可使用项目公开文档完成。
• 中文与付费资源：优先使用有明确版本、代码和练习的中文材料，例如上述 MLC 课程。其他付费课可以补充讲解与答疑；本路线不以购买某门课作为前提。
• NVIDIA 材料的迁移边界：学习瓶颈分析、量化和状态管理的方法；移植到 NPU 时，需重新确认内存层次、编译接口和运行时机制。2025 年回放中的命令也要结合第 7.3 节的后端迁移情况理解。

13.3 用同一个小项目串起 8 周

贯穿项目是：为固定任务集部署一个小型文本生成模型，逐步优化质量、内存和延迟，并交付可复现的比较报告。 起点可选 Qwen2.5-0.5B-Instruct这类小型稠密模型；它在这里承担低成本实验载体的作用，后续换模型时重新建立基线。

第 1 周固定以下内容，后续持续沿用：

• 模型身份：权重版本、分词器、对话模板、参考数值格式和生成配置。
• 质量样本：先整理约 30 个可核对答案的样本，包含信息抽取、简单问答、格式约束等；与量化校准文本分开。这个规模只用于学习和快速回归，产品验收仍需扩充。
• 性能负载：保存生成请求集的方法和随机种子，按实际 token 数控制输入长度、输出长度与到达方式；质量样本和性能请求集各司其职。
• 比较约定：同一硬件、同一模型、同一工作负载下比较；跨硬件或跨格式时标明变化，保留原始记录。

建议给学习项目建立如下目录，逐周添加自己的实现：

1
2
3
4
5
6

inference-study/
  configs/          # 模型、环境、量化与服务配置
  data/             # 校准集、质量集、性能请求集及生成脚本
  experiments/      # w01 至 w08 的可运行实验
  results/          # 原始结果、执行轨迹和测量元数据
  reports/          # 周报、性能基线、最终 ADR

先选设备，再决定哪些结果可以亲自测出来：

没有 GPU 不必停学，但需要区分“理解原理”“完成 CPU 模拟”和“在目标加速器上验证”三种成果。下面的端侧与编译分支会给出相应替换任务。

13.4 每天怎么推进：八周的任务与验收

每周先读“本周材料”，再按五天表执行。材料按当天问题选看；选修资源只在卡住或选择对应方向时使用。当天的完成标准就是表格最后一列；周末用本周验收判断是否需要补缺。

第 1 周：理解模型前向、KV 状态和内存需求

本周问题：生成一个 token 经过哪些计算，哪些状态需要保留，内存为什么随上下文增长？

本周材料：MIT 第 12 讲：Transformer 与 LLM；CS336 第 2 讲：PyTorch 与资源核算；模型官方运行示例。模型结构仍不清楚时补 CS336 第 3 讲；KV 实现卡住时选看 SGLang 短课的推理基础部分。回看本文第 5.1—5.3 节。

本周验收：能依据模型配置估算主要内存，解释 GQA 中查询头数与 KV 头数的区别，并用数值检查定位一个状态错误。这里比较的是固定输入下同一步的结果；随机生成得到不同文本，不能直接判定缓存实现错误。下周沿用这一参考实现。

第 2 周：建立性能基线，学会从执行轨迹定位瓶颈

本周问题：时间花在计算、访存、主机开销还是同步上，怎样证明？

本周材料：CS336 第 10 讲：Inference 视频及讲义，重点看性能模型与推理指标；第 5 讲硬件与第 6 讲性能分析部分。实验参考 Assignment 2的基准测试与 profiling 任务，使用其提供的基础模型实现即可，不以完成 Assignment 1 为前提。回看本文第 2.2、5.3、12 节。

本周验收：能从一段轨迹解释主要耗时，并区分引擎内部时间与客户端 TTFT。数值正确性继续沿用第 1 周检查。基础扎实时，可选做 Triton 融合 softmax 教程；完整 FlashAttention 和分布式训练作业留到后续，主线先完成可信测量。

第 3 周：做成一次真正可部署的量化

本周问题：位宽降低怎样影响误差、存储、实际执行与任务质量？

本周材料：MIT 第 5 讲：量化 I、第 6 讲：量化 II，再选看第 13 讲：LLM 部署中量化相关内容；vLLM 短课的模型压缩示例。MIT Lab 2、Lab 4 只选与本周目标对应的部分。论文从 AWQ、SmoothQuant 中选一篇，入口见第 14 节。

本周验收：模型能重新加载，质量集未混入校准集，能解释性能变化。数值模拟中的 INT4、磁盘上的压缩格式和设备真正执行的低比特内核是不同层面的结果，报告中要分别确认。设备缺少对应内核时，完成受支持格式的部署，并明确哪些低比特实验仅验证了数值误差。

第 4 周：部署服务，测清调度与缓存的作用

本周问题：单请求跑得快，为什么多个请求到来时仍会排队？量化和缓存怎样影响可服务容量？

本周材料：vLLM 短课的服务两节与基准测试/评测一节；vLLM 官方快速开始；CMU LLM Serving Part 1 讲义中调度与 KV 管理；MIT 第 15 讲：长上下文 LLM中 KV 与长输入成本部分。回看本文第 6.1、12 节。

本周验收：每个负载点至少收集 100 个请求并重复测量，保留失败、拒绝与超时；这个起步样本量适合排查趋势，可靠的 p99 结论需要更大的样本与稳定窗口。能解释连续批处理、KV 分页与前缀复用分别解决什么问题。Mac/CPU 路径使用本地后端实际支持的功能，缺少某项机制时以讲义和状态示意补充理解，记录为未实测。

第 5 周：理解导出、编译与运行时的接口

本周问题：模型怎样成为可执行产物，形状约束、图分区与设备回退分别发生在哪里？

本周材料：MLC 中文课程第 1 课整体介绍、第 9 课计算图优化；torch.export 教程与 torch.compile 入门；ExecuTorch 委托与分区说明。回看本文第 8 节。共同阶段只要求理解接口并完成小实验，深入编译实现留给路线 C。

本周验收：能区分导出、编译与设备执行，解释一次形状失败或后端回退。导出实验与 torch.compile 实验是两条用于对照的路径，后者无需先运行前者。带 KV 状态的完整 LLM 还需要处理状态传递、动态长度和内存生命周期，不能直接推断已经完成整模型适配。

第 6 周：选择一个方向，读通一条关键调用路径

本周问题：已有系统的关键决策发生在哪个模块，下一步应该改什么？

本周材料：从第 13.5 节的 A/B/C 三条路线中只选一条。服务路线选 SGLang 短课和引擎文档；本地路线选 MIT 笔记本部署实验与本地引擎文档；编译路线选 MLC 第 3 课与一个后端示例。课程用于定位概念，源码以固定版本为准。

本周验收：能根据代码解释一个关键行为，并指出可以修改的接口和不能假设的能力。A/B 路线对第二引擎的比较仅为回答一个具体问题；主要源码精读仍集中在一套系统中。代码量可以小，解释和证据必须完整。

第 7 周：完成一项优化，验证收益与退化条件

本周问题：第 6 周发现的瓶颈能否被改善，新增成本是否值得？

本周材料按问题选择：调度/缓存沿用 CMU 与引擎文档；投机解码看 CMU Serving Part 2、原始论文与 NVIDIA MTP 回放；性能分析可选 NVIDIA DeepSeek-R1 延迟优化回放。需要多卡时再补 CS336 第 7、8 讲。这一周只实施一种优化，由实测瓶颈决定，不要求把这些材料全部看完。

本周验收：能用测量解释优化为何有效或无效，不设“必须加速多少倍”的目标。若选投机解码，先核对当前引擎支持的方法，可从受支持的 n-gram 提议机制做小实验，再考虑额外草稿模型；记录接受率、验证开销及不同批量下的表现。小概率表只验证算法推导，不能替代完整实现的质量验证。MoE、PD 分离和 VLM 留作有对应需求后的扩展。

第 8 周：稳定性、复现与架构决策

本周问题：这套方案能否持续工作，另一台环境能否复现，怎样解释技术选择？

本周材料：以所选项目的部署、监控和版本文档为主，回看本文第 9.7、11.5、12.3 节。不增加新的必修课程，把时间留给验证与交付。

最终验收：形成代码、配置、质量结果、原始性能数据、稳定性记录与 ADR 的完整证据。两小时运行是学习项目的起步检查，生产稳定性需要更长时间和更完整的故障验证。报告只陈述实际测过的设备与功能，未验证的部分列出验证方案。

13.5 第 6 周的三条分支：选一条主线深入

路线 A 以请求和 SLO 为中心，路线 B 以设备资源和持续体验为中心，路线 C 以编译与执行机制为中心。三条路线都沿用正确性、性能基线和版本记录；选定之后，继续深入的重点由真实瓶颈决定。

13.6 怎样用 AI 加快学习，同时保留自己的判断

AI 最适合减少搜索、脚手架和排错成本。把前五周的固定模型、环境、指标和错误记录提供给它，得到的帮助通常比泛问“教我大模型部署”更具体。每日任务可以使用 AI，周验收要能自己解释。

关键代码不必全部从零手写，但至少能亲自修改其中一处，并预测它对状态、数值或性能的影响。用 AI 节省下来的时间，优先投入对照实验和理解失败原因。

13.7 四个检查点，以及落后时怎样调整

进度落后时先削减选修与比较范围，保留模型正确性、可信测量和完整交付。设备受限时缩小模型、长度和批量，区分原理验证与目标设备实测。八周后，再根据项目瓶颈选择多卡/MoE、PD 与 KV 外置、VLM 或端侧平台集成中的一项。

如果之后确定深入 GPU 内核，可考察 MLC 2026 Modern GPU Programming for ML Systems：它面向现代 GPU、布局和流水线，涉及 Blackwell 与 TIRx 等内容，适合作为具备相应硬件和基础后的进阶材料。当前八周先完成主线，后续课程由问题与设备条件决定。

十四、论文与源码怎么读：配合实验，按需深入

第十三节已经给出视频、讲义和实验入口。本节把论文与源码安排到对应周次：先用课程建立直觉，实验遇到具体问题时再深读。量化论文选一篇，服务机制读与当前实验相关的部分；分阶段服务和 MoE 材料放入后续选修。正文其余引用可作为遇到新问题时的索引。

阅读源码建议从一次请求的实际路径开始，设置断点或打印形状，再回头阅读模块设计。不要从仓库第一个目录一路向下读，也不要把记住目录名当成理解架构。

长期跟踪只需维护三个小清单：

• 固定环境清单：当前可工作的模型、引擎、插件、SDK、驱动和编译参数。
• 待解决瓶颈清单：按端到端影响排序，记录证据，不按热点词排序。
• 版本变化清单：只关注影响自身模型、硬件、精度、状态和接口的版本说明（release notes）；将新机制先放入独立实验。

最后，用五个问题检查自己的路线图是否真正建立起来：

1. 我能否根据模型与并发算出主要内存需求，并解释例外？
2. 我能否从执行轨迹判断瓶颈位于模型、调度、编译、计算内核、搬运还是通信？
3. 我能否说清当前选用的项目负责什么，以及替换它的代价？
4. 我能否在新硬件上建立正确性基线，处理分区、形状、量化和状态？
5. 我能否用质量、SLO、成本与维护证据证明一次优化值得保留？

如果能够回答这些问题，就已经拥有一套可以迁移到新模型、新框架和新芯片上的工程方法。具体项目会变化，理解约束、明确边界、测量瓶颈并验证取舍的能力，会长期有效。