NPU on 七月流火

大模型编译工程图谱：面向端侧 NPU 的技术栈、工具链与学习路线

Tue, 22 Sep 2026 22:23:59 +0800

AI 协作说明

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

资料核对时间：2026 年 9 月 23 日。 本文以官方文档、项目仓库、原始论文和课程主页为主要依据。工具链能力是这一时间点的资料快照，实际使用时应固定版本；学习优先级与选型建议是本文的判断。容量、延迟和分块数字均为分析示例，不代表设备实测。

一个大模型在 PyTorch 中生成了正确的结果，距离在端侧神经网络处理器（Neural Processing Unit，NPU）上高效执行，还有一系列问题需要解决：怎样表达随解码更新的状态，怎样把高层算子转换成硬件能接受的计算，怎样安排有限的片上存储，以及怎样让编译结果与设备运行时正确配合。

这些问题共同构成大模型编译工程。它既包含 IR 和编译变换，也包含量化表示、内存布局、设备接口与验证方法。对技术架构师而言，关键是识别每一层能决定什么、需要向下一层传递什么，以及一个局部优化能否改善完整生成过程。

本文与《大模型推理与部署工程图谱：技术栈、开源项目与学习路线》组成同一系列。上一篇建立推理与部署全景；本篇沿着模型语义 → 图与 IR → 编译优化 → 硬件映射 → 有状态执行 → 验证交付展开，把端侧 NPU 的约束放进每一步。

阅读建议：第一至四节建立全景与发展脉络，第五至七节理解编译核心，第八至十节比较工具链与运行边界，第十一、十二节学习选型和验证，第十三节执行 8 周课程与实践路线，第十四节按问题深读资料。想先决定学习投入，可先看第一、八、十三节。窄屏上的多列表格可以横向滚动。

一、先建立全景：大模型编译究竟要掌握什么

1.1 从数学运算走到可执行程序

机器学习编译（machine learning compilation） 将模型程序转换为适合目标环境执行的形式，同时保持约定的计算语义。其输出可能是机器码、设备命令、厂商图对象、序列化上下文，或包含多个子图和执行计划的模型包。

因此，“模型转换成功”“编译成功”“设备执行成功”“端到端更快”是四个需要分别验证的结果。编译也可能发生在不同时间：提前编译（Ahead-of-Time Compilation，AOT） 在运行前完成目标编译，常用于发布或部署准备阶段；即时编译（Just-in-Time Compilation，JIT） 在运行期间按需生成可执行代码或设备可加载的编译产物。编译之后仍需执行程序，才能得到推理结果。端侧可以采用两者组合。LiteRT 的 NPU 集成说明就同时提供 AOT 和设备端编译路径。

部署关注完整系统怎样交付，推理关注输入怎样经过模型生成结果，编译关注计算描述怎样转换为执行程序。三者在量化、形状、内存和状态上紧密衔接，工具链也经常同时覆盖这些环节。本篇以程序转换和硬件映射为观察重点：既检查产物本身，也回到实际推理验证它的效果。

本文主要讨论自回归大语言模型（Large Language Model，LLM）及其视觉语言模型（Vision-Language Model，VLM）扩展，设备包括移动片上系统（System-on-Chip，SoC）、嵌入式计算平台和带 NPU 的个人电脑。微控制器上的 TinyML、数据中心加速器和 FPGA 只在帮助比较机制时出现，具体容量与软件接口需要分别判断。

1.2 三种学习深度

优先级	应掌握的内容	可以检验的能力
P0：通用核心	张量语义、形状与状态；IR；图变换合法性；数值格式、量化表示与存储/计算精度；分块与布局；张量存活期与缓冲区生命周期；正确性与性能分析	看懂编译前后的程序，解释某次转换为什么正确、为什么可能更快
P1：方向主线	一套可修改的编译框架，加上一条目标硬件工具链；或一个导出/分区/运行时接入路径	定位失败、修改一个 pass 或适配模块，并验证完整链路
P2：比较与扩展	同层其他框架、暂不适用的领域专用语言（Domain-Specific Language，DSL）、自动调优新方法、其他厂商 SDK	说明解决的问题、依赖条件和替换代价，遇到需要时再深入

编译方向应把 IR、程序变换、形状与内存提升为主要学习对象。 推理服务中的路由、集群调度和多机通信，在这条路线中通常只需先理解接口；它们是否成为重点，取决于实际系统边界。

1.3 三条工作主线，共享同一套基础

主线	主要问题	深入位置
模型接入与图编译	新模型怎样导出，哪些算子需要分解，怎样量化和分区	前端、图 IR、模式匹配、后端接入
编译器与硬件映射	怎样把计算组织成目标芯片能高效执行的程序	编译 pass、分块、布局、内存规划、代码生成
编译与运行时集成	多份编译产物怎样共享状态，怎样加载、执行和升级	KV 接口、缓冲区、异步执行、产物兼容与性能分析

熟练使用厂商转换工具，可以完成很有价值的模型接入工作。若目标进一步深入编译器，就需要选择具有源码、IR 输出和测试入口的实现，练习修改与验证。两种能力可以在同一个项目中逐步衔接。

二、端侧 NPU 的约束，怎样改变编译问题

2.1 NPU 是一类硬件，具体能力来自芯片与软件组合

不同 NPU 的矩阵单元、向量单元、片上 SRAM、数据搬运机制、原生数值格式和可编程接口可能差异很大。名称相同的 INT4，也可能对应不同打包方式、缩放粒度或执行路径。

先为项目建立一张约束表：

维度	需要确认的事实	对编译的影响
模型与输入	模型结构、批大小（batch size）、上下文上限、图像尺寸与数量	算子覆盖、形状特化（shape specialization）、编译产物数量
数值格式	权重、激活、KV、累加器实际支持的类型	量化路径、混合精度与转换成本
片上存储	可用容量、分区、对齐、访问约束	分块、层组（layer group）、双缓冲与临时空间
外部内存	有效带宽、共享方式、可访问缓冲区	权重与 KV 搬运、布局转换、状态复用
调度与同步	提交开销、队列、事件、并发执行能力	融合粒度、异步生命周期、设备切换
交付环境	操作系统、驱动、SDK、运行时和编译器版本	可构建性、产物兼容、调试与升级成本

实际支持范围应写成：模型结构 × 输入形状 × 数值格式 × 芯片 × 软件版本 × 执行特性。某个 NPU 支持矩阵乘，并不足以证明它能高效执行任意模型的注意力、状态更新和完整生成循环。

2.2 Prefill 与 decode 给编译器不同的工作负载

预填充（prefill）处理一段输入；解码（decode）利用已有的键值缓存（key-value cache，KV cache），逐步生成新 token。对常见稠密 Transformer，小批量 decode 往往更受权重/KV 访存和固定开销影响；较长 prefill 则通常提供更大的矩阵计算规模。具体瓶颈仍需测量。

方面	Prefill	Decode
本次输入长度	一个或多个 token，长输入可分块	常见为每序列一个 token；投机解码的候选验证（speculative verification）可一次处理多个 token
主要形状变化	输入块长度、历史长度	本次长度较小，历史 KV 持续增长
编译关注	大矩阵映射、注意力临时量、输入形状分桶（shape bucketing）	小矩阵效率、KV 访问、提交与边界开销
接口要求	首次或带历史状态的批量写入	追加、长度维护、会话隔离与状态复用

两阶段采用不同执行图或编译策略很常见。2026 年公开的 TPU-MLIR 大模型编译论文进一步区分首次 prefill、携带历史 KV 的 prefill 和 decode，给出了将生成流程映射成多个编译入口的具体例子。

2.3 先估算容量，再讨论优化

对各层配置相同、缓存完整历史 K/V 的稠密 Transformer，可以先做以下近似：

$$ M_{\mathrm{weights}} \approx P\frac{b_w}{8},\qquad M_{\mathrm{KV}} \approx 2LBT H_{kv}d_h\frac{b_{kv}}{8}. $$

其中，$P$ 是参数量，$L$ 是层数，$B$ 是批大小，$T$ 是保存的历史长度，$H_{kv}$ 是 KV 头数，$d_h$ 是头维度，$b_w$、$b_{kv}$ 是位宽；此处假设 K/V 的头维度与位宽相同。分组查询注意力（Grouped-Query Attention，GQA）应代入 KV 头数，而非查询头数。多头潜在注意力（Multi-head Latent Attention，MLA）、滑动窗口注意力，以及混合注意力与状态空间模块的模型，需要按实际保存的状态另外计算。

例如，假设一个模型有 30 亿参数，权重全部以 4 bit 保存，原始权重约为 1.5 GB，约 1.40 GiB。另假设 28 层、8 个 KV 头、头维度 128、单请求、8192 token 历史、FP16 KV，则 KV 约为 896 MiB。这些是假设配置的容量计算，尚未计入量化元数据、未量化层、激活、工作区、重复打包和运行时预留。

更实用的总预算是：

1
2


常驻权重 + 持久状态 + 激活峰值 + 内核工作区
 + 格式转换/重复副本 + 运行时与系统开销

编译器能复用部分临时存储，但不能把仍在使用的 KV 当成普通临时激活回收。模型包的磁盘大小，也不能直接当作加载后的内存需求。

2.4 优化目标要同时包含启动与持续运行

端侧需要至少同时观察：编译时间与主机内存、安装包/产物大小、冷启动、首 token 延迟（Time to First Token，TTFT）、相邻输出 token 的间隔（Inter-Token Latency，ITL）、峰值内存，以及设备热稳定后的持续性能。TTFT 应注明从请求到达、模型调用还是其他时点开始计时。

TOPS（每秒万亿次运算，tera operations per second）是运算速率单位；厂商公布的峰值还取决于数值格式、稀疏性和运算计数口径。若 decode 的主要时间消耗在权重读取或图边界上，进一步提高矩阵乘峰值算力可能作用有限。架构选择应依据约定质量与资源限制下的完整生成成本，并把编译、模型更新和多设备维护计入其中。

三、把编译栈分层：表示、优化、执行各负其责

图 1 · 从模型语义到端侧 NPU 执行的编译链路两条后端路径可以组合；每个边界都需要保存语义、形状、精度与状态约定。

flowchart TB
 A[模型与参考结果
结构 · 权重 · 生成语义] --> B[捕获与导出
图 · 类型 · 形状约束]
 B --> C[图优化与分区
分解 · 量化 · 融合]
 C --> D[可扩展编译后端
张量 IR · 分块 · 内存规划]
 C --> E[厂商编译接口
SDK 图 · 图上下文]
 D --> F[编译产物
目标代码或设备命令
序列化图上下文]
 E --> F
 F --> G[运行时与驱动
加载 · 状态 · 缓冲区 · 同步]
 G --> H[CPU / GPU / NPU 协同执行]

3.1 IR 保存的是程序信息，层级取决于要做的决策

中间表示（Intermediate Representation，IR） 是编译过程中用来表达和变换程序的数据结构。高层表示保留模型算子与张量关系，较低层表示逐渐明确循环、内存和设备操作。Lowering 指向更低层表示的转换；本文保留英文，并用“逐层转换”解释其含义。它本身不表示降低数值精度。

表示层次	常见对象	这一层保留或决定什么
模型/图表示	包含 ATen 算子的 FX 图、ONNX、Relax、StableHLO、TOSA	算子语义、类型、形状、常量和数据依赖
结构化张量计算	MLIR Linalg、TensorIR	迭代空间、归约、分块、数据复用
循环与存储	SCF/Affine、Vector、MemRef 等	显式循环、向量化、缓冲区、访问方式
低层通用表示	LLVM IR 等	类型化低层操作、控制流、地址与调用约定；仍需后端生成目标指令
目标相关表示	专用 dialect、厂商图与命令	目标操作、执行单元、设备地址与同步
交付产物	机器码、设备二进制、图上下文、模型包	运行时可加载的程序及其依赖

这些对象并不构成必须逐个经过的统一流水线。其中 ATen 提供张量算子，FX 提供图表示与变换工具，导出图可以使用 ATen 算子集。PyTorch Export IR 规范

LLVM IR 也不等同于目标指令集，但可携带目标的数据布局、调用约定和内建函数（intrinsic）等信息。LLVM IR 语言参考

StableHLO、TOSA 与 ONNX 有不同的语义和生态定位；一个厂商后端也可能直接接收子图，内部完成剩余编译。StableHLO 的定位和 IREE 的编译阶段提供了两个不同层面的观察入口。

3.2 理解 MLIR，先理解少量结构

MLIR 的**方言（dialect）**组织相关操作、类型和属性的定义。**操作（operation）**可以表示算术、函数、内存访问等不同语义；**值（value）**由操作结果或块参数产生；**块（block）和区域（region）**组织程序结构，操作还可以包含区域。

在**静态单赋值形式（Static Single Assignment，SSA）**中，每个 SSA 值只定义一次，便于追踪定义与使用关系。但一个值可以引用可变缓冲区，SSA 并不禁止修改其中的内存内容。MLIR 语言参考

Pass 是编译器中的一个处理阶段，可执行分析或变换；多个 pass 组成编译流水线（pass pipeline），本文保留英文 pass。编写 pass 时不仅需要找到某种图结构模式，还要检查类型、属性、副作用和使用关系。MLIR 的接口（interface）、描述可复用性质与约束的 trait、验证器（verifier）和模式重写（pattern rewriting）机制帮助表达这些条件。MLIR Toy 教程适合从小程序逐步建立这些概念。

3.3 导出、分区与代码生成是不同扩展点

前端导入解决“模型怎样进入编译器”，需要正确表达模型的算子、常量、形状和状态。
**图分区（graph partitioning）**解决“哪些操作组成子图、交给哪个后端”，还要考虑精度、形状、依赖与边界成本。
代码生成解决“这段计算最终怎样执行”，可以生成内核，也可以调用已有库或厂商编译器。
运行时接入解决“产物怎样被加载和调用”，涉及缓冲区、生命周期、同步和错误传播。

例如，ExecuTorch 的分区器（partitioner）标记待委托给后端的图节点，后端处理编译信息，运行时再执行相应产物；这些责任可以分别扩展。ExecuTorch 后端与分区设计

四、发展脉络：从算子优化走向有状态的大模型程序

下面选择公开论文、产品能力和框架发布作为时间节点；年份表示该条事件的公开时间，不表示相关思想第一次出现。不同路线长期并行发展。

图 2 · 机器学习编译到端侧大模型编译的发展时间线关注每一阶段扩展了哪些可表达、可优化和可交付的能力。

2018
TVM：连接图优化与硬件相关优化
TVM 论文将模型图、算子实现和硬件映射放进统一编译框架，推动跨设备部署与性能可移植性的研究。
2020
MLIR 与 Ansor：可扩展表示与自动程序搜索
MLIR 论文讨论多层表示和可复用编译基础设施；Ansor探索自动生成、搜索与测量张量程序。
2022
TensorIR 与 TPU-MLIR：更明确地表达专用硬件
TensorIR强化张量计算原语与调度表达；TPU-MLIR展示图 dialect、目标 dialect 与逐阶段验证如何组织成编译器。
2023
ExecuTorch：框架导出与端侧后端协作
ExecuTorch 公开发布，围绕端侧运行时、硬件后端扩展与部署流程建立共同接口。
2024
可移植表示与状态接口进一步明确
StableHLO 1.0完善语义与兼容机制；Core ML 的状态模型能力把 KV 等持续状态纳入部署接口。
2025—2026
NPU 集成覆盖编译、运行与模型分发
LiteRT 与 Qualcomm、MediaTek 的集成，将厂商编译、设备执行和 AOT/JIT 路径连接起来。具体模型覆盖仍依赖后端与版本。
2026
TPU-MLIR：面向 LLM 的分阶段编译实践
面向 LLM 的 MLIR 编译方法给出首次 prefill、带历史 KV 的 prefill 和 decode 的分阶段组织，并讨论历史状态、层组与设备内存优化。这是该项目的一项公开实践，不表示这些思想始于 2026 年。

从这些节点可以看到一条持续发展的脉络：算子实现 → 跨层表示与优化 → 硬件后端协作 → 有状态程序与交付接口。新阶段并没有消除旧问题；矩阵乘、布局和内存仍然重要，但它们需要放回完整生成流程里评估。

五、前端与形状：先把模型语义完整带进编译器

5.1 torch.compile、torch.export 与 ONNX 的职责

工具/机制	主要用途	接入时需要确认
torch.compile	优化 Python/PyTorch 程序中的可捕获区域	图中断（graph break）、重编译、后端覆盖与运行时依赖
torch.export	得到可交给下游处理的张量程序与约束	输入范围、控制流表达、状态与图签名（graph signature）
ONNX 导出	生成使用 ONNX 算子集表达的模型	算子集版本（opset version）、动态维度、外部权重文件、下游算子语义
厂商专用转换器	将受支持模型转成厂商中间或交付格式	模型注册、转换约束、量化方式与实际目标芯片

torch.export 会记录保证导出图成立所需的形状约束；若声明的动态范围与程序推导出的约束冲突，导出可能失败。基于一组示例输入成功导出，不代表导出图适用于任意输入；还要遵守形状范围、被特化的参数及其他导出约束。torch.export API

工程上先导出一层或一个小模块，更容易定位问题。完整 generate() 还包含采样、停止条件和循环；有的系统保留这些控制在主机侧，有的将一部分下沉，不能从“模型已导出”推断控制逻辑的位置。

5.2 动态形状是一组决策，不只是一个开关

策略	适合的条件	主要代价
固定形状	输入规格稳定，后端特化收益明显	超出形状的输入需要其他处理路径
形状分桶	长度分布有可利用的常见区间	填充计算、路由与多份产物
有界动态形状（bounded dynamic shapes）	后端可处理一定范围的符号维度	可能按上界预留内存，部分静态优化受限
分块执行	长输入可拆成固定或受限长度块	调用次数、掩码与历史状态衔接
按需特化	热点形状反复出现，可承受首次编译	编译延迟、缓存空间、失效与版本管理

例如把输入长度分成 128/512/2048 三个形状桶时，一个实际长度为 129 的输入可能填充到 512 桶。填充占比容易计算，但耗时比例还取决于后端是否跳过无效区域、注意力实现和 KV 访问范围。应分别统计逻辑有效长度、实际执行形状和预留容量。

“接受可变长度输入”也不等于“所有底层内核都按完全动态形状执行”。OpenVINO GenAI 的 NPU 文档同时讨论静态形状策略、上下文容量配置及新增的动态输入支持，正好说明这些概念需要分层理解。

5.3 把状态接口写清楚

对一个带 KV 缓存的完整语言模型前向入口，至少要明确下列信息；它们可以作为显式参数，也可以由运行时的状态对象管理：

1
2
3


输入：本次 token ID（或嵌入）、已有 KV、有效历史长度、位置索引、掩码
输出：词表上的 logits、更新后的 KV 或状态更新约定
约束：本次长度 + 历史长度 ≤ 容量；会话与缓冲区归属明确

这里的 logits 是语言模型输出头（LM head）产生的未归一化词表分数。单独的注意力模块通常接收隐藏状态或 Q/K/V 张量，输出注意力计算结果；验证它时应比较相同位置的输出张量。只有接回模型其余层与输出头，才应比较词表 logits。编译器也可能只保留所需位置的 logits，接口应注明输出范围。

图上的“返回更新后 KV”，既可能实现为一次完整复制，也可能通过别名（aliasing）和原地更新（in-place update）复用存储。前端必须正确表达语义，后端和运行时才有机会选择低成本实现。过早抹掉写入关系，或误把状态当成常量，都会使后续优化失去依据。

5.4 控制流、数值与算子分解需要一起检查

常见接入问题包括：依赖张量值的 Python 分支、不可导出的自定义操作、旋转位置编码（Rotary Position Embedding，RoPE）的位置处理、掩码广播、GQA 中查询头与 KV 头的映射、归一化精度以及采样配置。GQA 的 KV 共享不一定需要把数据物理复制到每个查询头，应检查后端的实现方式。对每个问题，先定位是表达能力不足，还是后端没有覆盖对应操作。

算子分解可以把高层操作改写成通用原语，也可能破坏后端对专用融合算子的识别。因此，应先知道后端接受什么，再决定在哪一层分解。表达得更细，不一定更容易优化。

六、图优化与量化：变换必须保持哪些约定

6.1 优化先检查合法性，再估计收益

常量折叠（constant folding）、公共子表达式消除（Common Subexpression Elimination，CSE）、死代码消除（Dead Code Elimination，DCE）、算子分解与融合，都是常见图变换。但一次变换是否成立，取决于类型、形状、数值规则、副作用及结果的使用方式；合法之后，还需单独评估收益。

变换	可能收益	必须检查的条件
合并线性投影	减少读取和启动次数，获得较大矩阵	权重组织、输出切分、量化参数与后端支持
消除连续转置	减少布局转换	两次置换确实互逆；后续对步长/布局的要求仍满足
MatMul 与后处理融合	减少中间结果写回	广播、精度、舍入位置、额外使用者与片上容量
删除无用结果	减少计算和存储	操作没有需要保留的状态写入或其他副作用
公共子表达式复用	避免重复计算	输入、属性与依赖状态一致，副作用允许复用；再评估结果存活期变长的成本
调整计算顺序	改善数据复用和流水线	数据依赖、同步和数值误差符合约定

以“融合矩阵乘和残差相加”为例，数学表达可以合并，但融合实现可能改变中间舍入精度。另一个消费者若仍需要矩阵乘的原始结果，也会影响能否完全消除中间写回。优化收益需要针对完整子图测量。

6.2 模式重写与合法化各自解决什么

模式重写（pattern rewriting） 匹配一段程序并替换它；合法化（legalization） 将程序转换到目标允许的操作和类型集合。目标集合可以同时包含多个 dialect，合法也不等于已经生成硬件代码。

一个可维护的变换应记录四件事：匹配条件、拒绝条件、替换结果和验证方法。比如对连续转置，只在置换互逆、张量语义允许且相关属性一致时消除；对不满足条件的案例，应该保持原图或明确报错。

MLIR 的 Dialect Conversion组织转换目标、重写规则与类型转换。学习时要特别区分“规则没有匹配”“流水线仍有非法操作”和“转换后的程序数值错误”，这三种问题的排查入口不同。

以 Toy 教程的二维张量转置为例，下面的片段保留了显式类型，便于观察 SSA 使用关系：

1
2
3
4


// 变换前：同一二维张量连续转置两次。
%0 = "toy.transpose"(%input) : (tensor<2x3xf64>) -> tensor<3x2xf64>
%1 = "toy.transpose"(%0) : (tensor<3x2xf64>) -> tensor<2x3xf64>
func.return %1 : tensor<2x3xf64>

1
2


// 变换后：返回原输入，结果的类型与数值语义保持一致。
func.return %input : tensor<2x3xf64>

这里利用的是 Toy 操作的纯张量语义。若 %0 还有其他使用者，第一条转置仍需保留；若换成带任意排列属性的高维转置，则必须检查两次排列是否互逆。张量层的等价改写，接入有可变别名、布局或状态副作用的更低层表示时，也需要重新审视前提。Toy 的模式重写示例

6.3 数值格式怎样进入 IR 与执行约定

编译器需要区分数值含义、逻辑类型、物理存储与计算类型。FP16、BF16 都是 16 位浮点，分配给指数和尾数小数部分（fraction field）的位数不同；INT8、INT4 是整数表示，量化后还需由缩放因子（scale）、零点（zero-point）等参数说明它们代表什么数值。基础格式对比与误差算例见推理与部署篇第 6.2 节。本节继续追踪这些信息怎样变成可执行程序。

层面	一个量化权重的例子	编译器需要保持的约定
数值含义	整数 −4，在 scale=0.25、zero-point=0 时代表 −1.0	缩放、零点、量化整数范围、舍入、饱和与允许误差
逻辑表示	形状为 `[N, K]` 的量化张量，沿 K 分组	有符号性、量化轴、组大小、参数与元素对应关系
物理存储	两个 INT4 放进一个字节，再按目标分块重排	位顺序、字节偏移、对齐、填充与元数据位置
计算过程	直接走受支持的低比特路径，或按块反量化后计算	输入、乘法、累加与输出类型，以及转换发生的位置

均匀仿射量化的关系是：

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

其中 $q$ 是存储整数，$\hat{x}$ 是它表达的近似实数。round 表示按约定规则舍入，clip 表示将超出量化整数范围的值限制到边界；这里的范围裁剪（clipping）对应饱和处理（saturation），不同于向零截断（truncation）。

MLIR 的 i4 是不带有符号/无符号标记的 4 位整数类型（signless integer type），符号解释取决于操作或量化类型的约定，不能单独表达完整量化语义。MLIR 整数类型

MLIR 的量化类型区分存储类型（storage type）与表达类型（expressed type）：前者保存量化编码，后者表示这些编码对应的数值所采用的类型，通常为浮点。表达类型并不自动决定硬件累加类型。MLIR 量化设计

调试时可以先把约定打印成与具体 API 无关的清单：

1
2
3
4
5
6


storage_type: signed INT4 expressed_type: FP16
code_range: [-8, 7] group_axis: K
group_size: 128 scale_type: FP16
zero_point: 0 rounding: nearest, ties-to-even
packing/layout: 由产物和后端接口共同约定
compute/accumulator/output: 由已选择的执行路径明确记录

这是一份跨层核对清单，不是可以直接解析的 MLIR 类型声明，也不代表任意 NPU 都支持这些属性组合。FP16/BF16 转换同样要保持类型语义：二者位宽相同，位重解释（bitcast）通常会改变数值，不能替代数值转换；涉及累加或量化缩放时，更需要核对数值转换和存储重排的区别。

图 3 · 从量化数值约定到设备执行每一步都传递类型与参数；物理重排应保持同一元素与量化参数的对应关系。

flowchart TB
 A[模型数值与量化约定
scale · 零点 · 轴 · 分组] --> B[IR 类型与 Q/DQ
形状 · 转换 · 合法化]
 B --> C[物理打包与布局
INT4 字节 · 元数据 · 对齐]
 C --> D[内核与设备执行
读取 · 转换 · 乘法 · 累加]
 D --> E[输出与状态写回
输出类型 · 重量化 · KV]

6.4 INT4 怎样装进字节，怎样从内存中读回来

以有符号补码 INT4 为例，1100 表示 −4，0010 表示 2。ONNX 的紧凑存储规则是：连续两个元素中，第一个放在字节的低 4 位，第二个放在高 4 位；元素数为奇数时，最后补半个字节。厂商内部布局可能另外重排，不能把导出文件中的顺序直接当作设备格式。ONNX INT4 存储规范

假设权重 [-1.0, 0.0, 0.5, 1.5] 用 s=0.25, z=0 表示，得到整数 [-4, 0, 2, 6]：

1
2
3
4
5


逻辑顺序： -4 0 2 6
4 位补码： 1100 0000 0010 0110

第一个字节： 0000 1100 = 0x0C （低 4 位放 -4，高 4 位放 0）
第二个字节： 0110 0010 = 0x62 （低 4 位放 2，高 4 位放 6）

下面的小实验只依赖 Python，用于检查位序和符号恢复：

1
2
3
4
5
6
7
8
9


q = [-4, 0, 2, 6] # 本例固定为四个有效 INT4 值
packed = bytes((q[i] & 0xF) | ((q[i + 1] & 0xF) << 4)
 for i in range(0, len(q), 2))
codes = [(byte >> shift) & 0xF for byte in packed for shift in (0, 4)]
restored = [code - 16 if code >= 8 else code for code in codes]
dequantized = [0.25 * value for value in restored]
assert packed.hex() == "0c62"
assert restored == q
assert dequantized == [-1.0, 0.0, 0.5, 1.5]

若把取出的 1100 当无符号整数 12，再乘 0.25，就会得到 3.0，而非 −1.0。这个错误来自符号解释；若把高低半字节颠倒，则是元素顺序错误。两者都不是量化算法本身的误差。

逻辑张量形状与物理缓冲区大小需要分开记录。 连续打包的 N 个 INT4 只需 ceil(N/2) 字节保存编码，但仍要另外保存或约定 scale、零点、组大小和有效元素数。比如 128 个 INT4 加一个 FP16 scale，共为 64 + 2 = 66 字节；若某个假设布局要求每组独立按 16 字节对齐，则这组会占 80 字节。实际是否按组、按行或按整个张量对齐，由格式决定。

因此，布局变换必须同时处理权重编码和元数据。当原来沿 K 维的分组被转置、分块或交错存储时，scale 仍需对应原来的那组元素。把 4 位值装进 uint8/int32 容器，也不会自动改变它们的逻辑数值类型。

6.5 分组量化、累加类型与矩阵乘怎样配合

先明确计算路径。 W4A16 表示 4 位权重、16 位激活，还需说明具体编码及 FP16/BF16 的选择。一种实现是在内核中按块把权重反量化为浮点，再与浮点激活计算；另一类量化路径会让权重和激活都进入受支持的整数或低比特矩阵运算。不能只根据磁盘上的 INT4，推断乘法、累加或 KV 的类型。

下面以激活和权重都采用均匀整数量化为例。对一个分组点积，若组 g 的参数为 $s_{a,g},z_{a,g},s_{w,g},z_{w,g}$，则：

$$ y\approx\sum_g s_{a,g}s_{w,g} \left[\sum_{k\in g}(q_{a,k}-z_{a,g})(q_{w,k}-z_{w,g})\right]. $$

不同组的整数累加结果，需要按各自尺度组合。做一个简化算例：激活尺度为 1、零点全为 0，两组整数点积结果都为 4，权重尺度分别为 0.5、0.25；结果应是 4×0.5 + 4×0.25 = 3。若先合并成 8，再统一乘 0.5，就变成 4。这个差异说明分组边界是计算语义的一部分。

编译器需要确认：

分块的 K 维与量化分组是否对齐；跨组的 tile 怎样读取多个 scale。
零点修正怎样实现；若被折叠进其他项，是否仍保持同一数学关系。
整数部分和用什么类型累加，再在哪里缩放、转换或合并。
内核需要的权重布局与元数据布局是否相容，尾块怎样处理。

累加器需要单独选择。 例如 4096 项 127×127 的和为 66,064,384，超过 INT16 范围，因此 INT8 输入不能推出 INT8 或 INT16 累加。INT32、FP32 等较宽类型可服务相应路径，但仍需检查归约长度、数值范围和目标指令；浮点累加更宽也无法恢复输入量化时已经丢失的信息。

AWQ、GPTQ 等方法帮助选择权重量化参数与降低误差；要落到设备，仍须匹配分组、元数据、内核与图变换。AWQ、GPTQ

6.6 Cast、Q/DQ、重量化与融合的边界

Q/DQ 分别指量化与反量化（Quantize/Dequantize）。它们与普通类型转换、位重解释和内存重排有不同语义：

操作	对数值或存储做什么	必须检查什么
数值类型转换（cast）	用目标类型表示原来的数值，可能舍入或超范围	转换规则、范围、特殊值；不会自动应用量化 scale
量化 / 反量化（Q/DQ）	根据参数在原值与量化编码之间映射	scale、零点、轴、量化整数范围与舍入约定
重量化（requantization，也称重新量化）	将已有量化表示或整数累加结果转换到目标量化参数与类型	输入和输出参数、中间计算类型、舍入与饱和
位重解释（bitcast）	保持比特模式，用另一类型解释	源/目标类型规则；不保证数值相同，不应用量化 scale
位打包 / 解包（packing/unpacking）	组织或提取编码的比特	位序、符号恢复、有效长度与填充
布局变换	改变逻辑索引到物理位置的映射	参数与元素的对应关系，以及是否产生复制

对上一节的整数 −4，普通 INT4→FP16 数值转换得到 −4.0；使用 s=0.25, z=0 做反量化才得到 −1.0。编译器不能把这两种操作互换。MLIR 量化类型转换

再看最简单的逐张量整数乘加：忽略偏置（bias），设已完成零点修正的累加值为 acc，输出需要采用尺度 $s_y$、零点 $z_y$，则理想重量化关系为：

$$ q_y=\operatorname{clip}\left( \operatorname{round}\left(\frac{s_a s_w}{s_y}\operatorname{acc}\right)+z_y, q_{y,\min},q_{y,\max}\right). $$

目标实现可能用定点乘法与移位近似这一过程，因此需要检查乘法中间位宽、舍入和饱和。以整数量化为例，ONNX QuantizeLinear 采用舍入到最近值、中点取偶数（round to nearest, ties to even）；它与直接向零截断不是同一规则，例如 1.9 分别得到 2 和 1，2.5 的中点取偶结果为 2。超范围后饱和到边界，也与整数回绕（wraparound）不同。ONNX QuantizeLinear 的舍入与饱和约定

Q/DQ 可以作为图上的数值边界，后端再把解包、缩放、矩阵运算和输出转换融合在一个内核中。融合可以消除独立临时缓冲区，但应保留约定的数值行为；直接删除一个有损的 Q→DQ 往返，会改变程序。若后端缺少匹配实现，则可能拒绝、回退到其他执行路径（fallback），或先展开为浮点再执行。TensorRT 显式量化与 Q/DQ 融合

因此，检查转换后的 IR 还不够。还需确认实际执行类型、转换位置、是否生成全量展开副本，以及融合是否改善完整子图的时间与内存。

6.7 从量化数值验证到编译产物验证

先保存三组结果：原始参考计算、采用相同量化参数的数值参考、编译后执行。第二组与第一组的差异帮助评估量化本身；第三组与第二组的差异帮助定位编译或后端问题，还要考虑已声明的计算精度与归约顺序。

检查层次	最小案例	应确认的结果
编码与打包	−8/−1/0/7、奇数长度、跨字节取值	编码、符号、有效长度与解包一致
量化转换	零、中点、范围边界、超范围输入	参数、舍入和饱和与参考一致；非有限输入行为有约定
分组与布局	跨组 tile、尾块、转置前后	元数据仍对应正确元素，部分和使用正确尺度
计算与融合	不同归约长度、敏感后处理	累加与输出类型明确，误差符合约定
生成状态	prefill、decode、长历史和会话重置	KV 格式、状态更新与模型质量满足要求

只校准短输入，未必能代表长上下文、图像 token 或多轮历史下的分布。校准与质量评测集应分开，按阶段检查误差，再决定哪些层、哪些状态需要保留较高精度。KV 量化还需要独立确认量化粒度、静态或动态缩放、布局与读写约定，不能从权重量化配置直接推断。

这一部分的 P0 是格式语义、参数传递、打包/布局、转换与累加的区别，以及逐阶段验证；P1 是所选后端的具体实现；其他厂商编码和特殊低比特格式按需深入。第十三节第三周先用小实验建立这些约定，第五、六周再把它们接入布局与真实后端。

七、张量程序、布局与内存：把计算映射到硬件

7.1 从 MatMul 到分块执行

矩阵乘 $C_{M\times N}=A_{M\times K}B_{K\times N}$ 的计算量约为 $2MNK$ 次算术运算，一次乘加计作两次。硬件通常不能把完整矩阵都放进片上存储，因此需要计算分块（tiling），使读入的数据在被换出前获得足够复用。

一种分块策略至少决定：输出块大小、归约块大小、遍历顺序、数据进入哪级存储、多个执行单元怎样分工，以及何时同步。TensorIR 将块、迭代与张量计算原语组织成可变换的程序；MLIR 的 Linalg 等表示也可以保存结构化计算信息。TensorIR 论文

这里的**计算调度（schedule）**指张量程序的执行组织方式，包括循环顺序、分块、并行和数据搬运等安排，与推理服务的请求调度含义不同。张量化（tensorization） 通常指把一段匹配的计算映射到硬件提供的张量/矩阵计算原语，也不同于将 Python 列表转换为 Tensor。

7.2 一次片上容量计算

设一个输出分块为 $M_t=32,N_t=64$，归约分块 $K_t=128$，A/B 使用 2 字节元素，累加器使用 4 字节：

1
2
3
4
5
6


A 块：32 × 128 × 2 = 8 KiB
B 块：128 × 64 × 2 = 16 KiB
C 累加器：32 × 64 × 4 = 8 KiB
合计：32 KiB

A/B 都采用双缓冲：2 × (8 + 16) + 8 = 56 KiB

若假设 A/B 块与 C 累加缓冲区都占用同一个 48 KiB 的片上存储池，前一种组织在容量上可能可行，双缓冲（double buffering）则已经超限，尚未计入对齐、scale 和其他临时量。需要缩小分块、改变存储层级或调整流水线，不能只看“开启双缓冲可能隐藏搬运”这一收益。若累加器位于独立寄存器文件或专用存储中，应分别核算资源，不能机械地相加。

这个算例只说明资源预算，不指定某款 NPU 的原生精度或存储分配方式。实际分块还可能受矩阵单元形状、存储体（memory bank）、直接内存访问（Direct Memory Access，DMA）的传输与对齐要求，以及编译器约束影响。

7.3 布局是跨算子的约定

数据布局（data layout） 描述逻辑索引如何映射到物理存储。一个 MatMul 希望的权重块布局，可能与通用导出格式不同；注意力计算对 KV 的访问方向，又可能与追加写入最方便的方向不同。

局部布局优化要核算整条数据路径。若某个内核快了，但每一层都新增转置、打包或 CPU/NPU 往返，端到端可能退化。对低比特权重，还要确认“转置数据”之后 scale 的轴和分组语义是否同步改变。

有些 reshape/transpose 在某种表示里只是视图，在后端不接受相同步长或打包方式时却需要实际复制。分析时要查看执行后的访存和转换，不能仅凭高层算子名称估计成本。

7.4 Bufferization、内存规划与状态管理

这三个概念彼此关联，但负责不同的问题：

概念	主要决策	容易混淆之处
缓冲区化（bufferization，即将张量表示转换为缓冲区表示）	把张量值上的操作转换为内存缓冲区上的读写，并分析别名与原地复用	能否复用存储，需要确认不会覆盖仍被读取的旧值
内存规划（memory planning）	根据大小、对齐和存活期安排存储区域	临时量在图上最后一次使用，与异步任务实际完成可能不同
状态管理（state management）	维护跨调用持续存在的 KV、长度、会话与版本	前向结束后仍需保留；重置、切换和取消都要有约定

MLIR 的 One-Shot Bufferize围绕别名和读写冲突决定原地（in-place）或非原地（out-of-place）处理；ExecuTorch 的内存规划根据张量大小与存活期安排预分配内存区（arena）内的位置。嵌入的厂商子图仍可能管理自己的内部内存，外层规划不等于掌握了全部设备占用。

这里将“存活期”用于描述值仍可能被后续计算使用的范围；活跃性分析（liveness analysis）帮助判断各程序点哪些值仍然需要保留。“缓冲区生命周期（buffer lifetime）”则涉及分配、使用到释放的完整过程，异步设备的实际使用也必须计入。

例如，一份输入被两个并行任务借用，第二个任务尚未完成时，即使主机代码已提交了后续操作，也不能立即复用该区域。存储复用需要同时满足数据依赖和执行完成条件。

7.5 融合、层组和流水线需要共同优化

算子融合（operator fusion）可以减少中间结果写回和任务提交；TPU-MLIR 等工具中的层组（layer group）将一组操作组织起来，结合切片与局部存储规划复用数据，不一定意味着合成一个内核；流水线（pipelining）则尝试重叠搬运和计算。它们都会影响片上资源需求与并行程度，具体语义要按工具实现理解。

“融合越多越好”并不成立。更大的融合区域可能超过片上容量，迫使中间数据反复写回片外内存，或采用重计算（recomputation）；寄存器压力过高也可能引发寄存器溢出到内存（register spilling），这些都与数值溢出（numerical overflow）不同。某个小内核单独执行反而更灵活。TPU-MLIR 的官方仓库视频索引中，LayerGroup 教学适合观察计算组织与局部内存之间的关系。

自动调优也应围绕这一成本模型。搜索空间可以包含分块、顺序、布局和并行参数，代价由实机测量或预测模型给出；测量要控制频率、温度和输入条件。较早的 Ansor展示了程序生成与搜索的思路，学习概念后再对照所用版本的调优接口。

八、工具链地图：哪些需要深学，哪些先理解定位

8.1 先分清基础设施、执行栈和专用编译器

对象	所处位置与主要价值	建议投入
MLIR / LLVM	可扩展的表示、变换、分析和代码生成基础设施	编译器开发主线深学；先掌握 IR、重写、转换和测试
Apache TVM	图与张量程序协同优化、调度、代码生成及外部后端接入	选择 TVM 路线时深入；其他路线学习其分块与跨层思路
IREE	基于 MLIR 的编译与运行时系统，显式处理执行、资源与后端	适合研究编译—运行时协同，先验证所需后端是否可用
torch-mlir	将 PyTorch 程序桥接到 MLIR 生态	需要该前端路径时深入；理解输入约束和目标 dialect
ExecuTorch	PyTorch 模型导出、图处理、委托执行与端侧运行时	模型接入、后端集成主线优先
LiteRT	模型转换、运行时与 CPU/GPU/NPU 加速接口	Google AI Edge 和移动 NPU 路线重点了解
ONNX Runtime（ORT）	ONNX 图执行与执行提供程序（Execution Provider，EP，可理解为执行后端）	已采用 ONNX 的项目深入；研究分区与厂商 EP
TPU-MLIR	面向 Sophgo 芯片的图到目标编译、量化和部署工具	适合阅读实际 NPU 类编译器的变换与内存实现
Intel NPU Compiler	OpenVINO 体系中的 Intel NPU 编译器，有源码及开发指南	Intel 平台或专用编译器源码研究方向深入
MLIR-AIE / IRON	面向 AMD AI Engine 的编译基础与较低层编程接口	具备对应硬件、需要研究数据流和计算映射时深入

MLIR 提供构建编译器的基础，TVM、IREE 与专用编译器则选择自己的程序组织和执行方式。ExecuTorch、LiteRT、ORT 主要承担不同的模型与执行接入路径，可能调用厂商编译器。它们不能只用一张速度排行榜比较。

8.2 MLIR 与 TVM 怎样选

选择维度	MLIR 相关路线	TVM 相关路线
主要学习对象	dialect、类型、重写、转换、分析与目标后端	图/张量程序、调度、跨层变换与后端接入
实现风格	通常要阅读 C++、TableGen 和 pass 流水线；也有 Python 接口	Python/TVMScript 常用于表达与调度，底层仍有 C++
适合的问题	构建或扩展专用编译器，明确多层语义和执行约定	优化张量程序、组织图与内核、接入外部代码生成
共同难点	语义、形状、布局、内存、成本模型、目标硬件与验证	同左，具体 API 与工程组织不同

若目标是理解 NPU 编译器实现，本文建议以 MLIR 基础 + 一个可阅读的目标编译器为主线，再用 MLC 课程中的 TVM 示例建立张量程序直觉。若已有项目使用 TVM，则可以反过来，以项目栈为主，再学习 MLIR 中相同问题的表达方式。

当前 TVM 文档以 Relax 与张量 IR 的协作为重要路径，并出现 TIRx 等较新的接口；旧课程中的 Relay、tvm.tir 或早期 TVMScript 代码不能假定直接适配新版本。先固定课程环境，或明确进行版本迁移。TVM 架构、Relax

8.3 BYOC、delegate 与 EP 是可比较的接入思路

TVM 的 Bring Your Own Codegen（BYOC，外部代码生成后端接入）、ExecuTorch 的**后端委托执行（delegate）**和 ORT 的 EP 都允许外部后端承担一部分程序执行，但它们的 IR、生命周期和接口不同。

学习时可以用同一组问题比较：怎样声明能力，怎样选择子图，怎样序列化产物，谁分配输入输出，谁处理同步，失败后怎样恢复。共同的概念可以迁移，接口实现需要按项目重做。

一个细节很能说明验证的重要性：TVM 当前 BYOC 教程中的示例 NPU 后端是教学用桩实现（stub），只记录调度决策，不执行实际计算，输出缓冲区也未初始化，因此该部分只检查形状。跑通教学后端，证明的是接口链路；数值正确性和 NPU 性能需要另外验证。

8.4 ONNX、StableHLO 与 TOSA 要学到什么程度

它们首先是语义与接口边界。需要了解支持哪些算子、类型、形状与量化方式，以及生产者和消费者的版本约定；只有编写导入器、转换器或后端时，才需要深入更多算子规范。

StableHLO 的兼容保证针对其规定的可移植产物和语义范围，不能外推为设备二进制兼容。ONNX 的算子版本也不代表某个 EP 必然实现对应操作。TOSA 可以作为专用加速器的算子接口选择，最终仍依赖具体后端。StableHLO 兼容说明

8.5 同名与相邻技术的边界

MLC 可以指机器学习编译这一领域、MLC.ai 课程，或 MLC LLM 项目；阅读时明确上下文。
TPU-MLIR 在本文指 Sophgo 的开源项目，不是 Google TPU 编译器。
Triton language、TileLang 等 DSL 可以帮助理解计算分块和内核实现；是否能用于目标 NPU，要看具体后端支持。
CUDA/CUTLASS 的优化经验可以帮助建立 GPU 性能直觉，移植到 NPU 仍需重新理解指令、存储和同步。
运行时支持某芯片与开放该芯片的编译器或内核开发接口是不同能力，需要分别确认。

对同类框架，先深入一套，再比较另一套怎样表达同一个问题；这样才能识别设计取舍，而不只是累积 API 名称。

九、端侧 NPU 生态：厂商工具链怎样连接模型与设备

9.1 按设备与开放层次比较

下表列出可进一步验证的路线，表示项目定位与公开入口，不保证任意模型、量化格式和芯片组合都能运行。

生态	典型编译与执行路径	值得深入的工程问题
Qualcomm	ExecuTorch、LiteRT 或 ORT 的相应后端 → QNN 编译/图上下文 → 设备运行时	量化、图分区、上下文缓存、共享缓冲区与 HTP 执行证据
MediaTek	LiteRT NeuroPilot Accelerator 等接入层 → 厂商编译器与运行时	支持的模型/形状、AOT 与设备端编译、产物分发
Rockchip	RKLLM-Toolkit 转换/量化 → RKLLM 模型 → 板端 C/C++ Runtime	转换与运行版本配套、KV/上下文配置、模型覆盖与设备性能
Sophgo	TPU-MLIR 的图表示、量化、目标转换 → bmodel → 设备执行	dialect 变换、层组、存储规划、LLM 分阶段编译
Intel	OpenVINO/GenAI → Intel NPU 编译与插件 → NPU 驱动	形状策略、编译缓存、精度、编译器 pass 和运行时边界
AMD Ryzen AI	ONNX Runtime GenAI（OGA）等模型执行路径；底层研究另有 MLIR-AIE/IRON	NPU-only 与混合执行的区别，数据流、内存与目标映射
Apple	coremltools → Core ML 模型/编译产物 → 系统执行	状态模型、计算单元选择、实际设备分配与性能工具

对应资料入口：Qualcomm 后端、MediaTek 集成、RKLLM、TPU-MLIR、OpenVINO NPU、Ryzen AI OGA、Core ML 状态模型。

9.2 Qualcomm：接入层可以不同，厂商编译边界仍需理解

ExecuTorch、LiteRT 和 ORT 为 Qualcomm 设备提供了不同的接入方式。它们在模型表示、分区和运行时接口上不同，底层仍需配合目标 SDK 与设备能力。

ORT QNN EP 的公开文档给出了一条很有学习价值的路径：图经过处理和编译后，可以缓存 QNN 上下文二进制文件（context binary），以减少后续会话创建成本；还提供关闭 CPU EP 回退的配置，帮助验证图是否完整由指定 QNN 后端承接。QNN 还可选择不同执行后端，HTP（Hexagon Tensor Processor）路径与 CPU/GPU 路径应分开核对；关闭 ORT 层的 CPU 回退也不等于得到了设备内部逐指令执行轨迹。QNN EP 文档

这说明后端接入至少包含两类工作：把模型表达成可接受的图，以及管理编译后上下文的加载与生命周期。低层编译器未必全部可修改时，图改写、量化、分区、缓冲区和负载配置仍然是重要优化位置。

9.3 Rockchip 与 Sophgo：交付接口与编译源码的不同观察点

RKLLM 的公开工作流是 PC 侧转换/量化、板侧通过 Runtime 执行。其模型文件、转换选项和 C/C++ 接口适合研究实际部署约束；通用 RKNN 与 RKLLM 应按任务选择，不能因为都面向同一品牌芯片就互换流程。RKLLM 官方说明

TPU-MLIR 则提供面向目标芯片的编译源码和开发文档，可以继续追踪从高层图到目标表示的变换。做模型部署时关注转换与运行；研究编译实现时，可选一个操作沿导入、lowering、层组和代码生成路径阅读。具体底层组件的开放范围仍需逐项检查。TPU-MLIR 开发入口

两条路线对应不同的学习抓手。已有 Rockchip 设备，可以先把状态、精度与性能测清楚；希望修改实际编译 pass，又没有既定厂商约束时，可以从具有完整示例和测试入口的编译项目着手。

9.4 AI PC：上层部署与底层可编程能力分开看

Intel NPU Compiler 提供编译器源码、MLIR 入门、构建和调试指南，使学习者有机会从 OpenVINO 的模型使用进一步进入编译实现。驱动、固件、模型执行层与编译器仍有各自的版本和接口。Intel NPU Compiler

AMD Ryzen AI 的官方 OGA 文档区分 NPU-only 与 NPU/iGPU 混合模式；其可用模型与处理器组合需要查支持范围。底层的 MLIR-AIE/IRON则提供面向 AI Engine 的编程和编译入口。能够运行一个预优化模型，与能够自行编写该设备上的计算程序，应分别验证。Ryzen AI 执行模式

9.5 Apple：状态接口值得学习，执行位置需要证据

Core ML 的有状态模型（stateful model）能表达 KV 等跨调用状态，适合学习状态归属、模型接口和反复调用的成本。但其公开状态示例包含 CPU/GPU 配置，不能把该示例的收益直接解释为 Apple Neural Engine（ANE）收益。

配置允许的计算单元，也不是每个操作实际运行位置的证明。应使用模型分析与性能工具检查设备分配，并在同一模型、输入和精度下比较。Core ML 状态示例、WWDC24 的状态模型与性能工具讲解

9.6 当前发展值得关注的三件事

从上述公开资料中，可以提取三个方向：第一，导出与厂商后端的接口越来越完整；第二，KV 和生成阶段成为明确的编译/运行时对象；第三，部分专用 NPU 编译器提供了更深入的源码与开发入口。这是对这些项目的归纳，不意味着所有芯片的软件栈都已具备相同能力。

新的统一 API 会降低接入成本，但形状、布局、数值格式和设备内存的差异仍然存在。学习时应追踪这些约束怎样被表达和传递，而不是只跟踪 SDK 名称变化。

十、编译与运行时的结合点：状态、边界和产物

10.1 多个编译入口共享同一份逻辑状态

图 4 · 首次 prefill、带历史 KV 的 prefill 与 decode 的状态接口示意同一会话中的模型前向入口；物理缓冲区复用取决于布局、接口与运行时实现。

flowchart TB
 P[首次输入
Prefill 入口] --> K[会话 KV 状态
布局 · 容量 · 有效长度]
 K --> D[单步 Decode 入口]
 D --> K
 K --> H[带历史的 Prefill 入口
新一轮输入或后续输入块]
 H --> K
 P -- 提示词已处理完成 --> O[所需位置的 Logits
选择下一 token · 停止判断]
 H -- 提示词已处理完成 --> O
 D --> O
 O -- 继续生成：下一 token --> D
 O -- 停止或取消 --> R[等待执行完成
释放或保留会话状态]

常见自回归生成中，完整提示词的 prefill 结束后，利用最后一个有效位置的 logits 选择第一个输出 token。后续 decode 将上一步选出的 token 输入模型、更新 KV，再产生用于选择下一个 token 的 logits。因此，刚选出的 token 通常要到下一次前向计算才进入 KV。分块 prefill 在提示词处理完成前，只接续计算与状态，不开始生成回复。

这个接口有几个不能遗漏的条件：prefill 与 decode 使用相容的 KV 表示；有效长度与写入位置一致；容量超限行为明确；不同会话的写入互不污染；执行未结束时不能提前回收缓冲区。前缀缓存复用可以共享只读 KV 块，但共享后再写入时，需要独立缓冲区或写时复制（copy-on-write）等隔离机制，不能直接覆盖其他会话仍在使用的数据。PagedAttention 的 KV 共享与写时复制

固定容量的 KV 并不意味着注意力可以读取全部区域。尚未写入的位置需要通过正确的长度和掩码排除。同一模型跨形状桶切换时，要确认是继续复用、转换状态，还是重新计算；切换到不同模型或权重时，通常应重建 KV，不能仅凭形状相同复用。

10.2 原地更新、共享内存与零拷贝

“图中使用同一个 KV 参数”“主机与设备共享物理内存”“调用之间没有全量复制”是不同层面的事实。零拷贝（zero-copy）需要满足可访问性、对齐、地址注册、布局和生命周期等条件；即使共享物理内存，仍可能有缓存一致性维护（cache coherency maintenance）、同步和格式转换。

ExecuTorch 的 Qualcomm 示例提供了共享缓冲区接入说明，可以追踪缓冲区申请、注册、使用与释放的完整过程。Qualcomm 示例中的共享内存流程

函数返回不一定表示设备任务已完成。 异步执行时，状态和输入输出缓冲区必须保持有效，直到相应的设备任务完成；取消请求通常也需要处理已经提交的设备工作。编译器的存活期分析和运行时的完成条件，应在这一边界对齐。

10.3 子图覆盖率必须换算成边界成本

图 5 · 一个未覆盖操作怎样增加解码路径的边界开销示意允许回退时的路径；某些后端会直接拒绝该图，需要由调用方明确处理。

flowchart TB
 A[NPU 子图 A] --> B[等待设备完成
转换布局或准备缓冲区]
 B --> C[CPU 上的未覆盖操作]
 C --> D[准备设备输入
提交与同步]
 D --> E[NPU 子图 B]
 E --> F[后续模型层与解码步
边界可能反复出现]

一个只占少量计算的操作，可能切断较大的融合区域，或在每层每步引发切换。因此，按“支持算子个数”或“图节点覆盖率”衡量适配进度，可能低估最重要的问题。

可以用以下估算初步排序：

$$ T_{\mathrm{boundary/token}}\approx L n_b t_b. $$

假设 28 层，每层两次边界，每次平均 50 微秒，则每个 decode token 增加约 2.8 毫秒，128 个 decode 步约增加 358.4 毫秒。这是串行、均匀边界的分析算例；实际需要区分可重叠操作与关键路径，也要测量转换和同步的真实成本。

实际迁移收益应估为“原路径时间减去新设备计算、转换、搬运和额外同步时间”。有时候补一个小操作的覆盖，比把已有大算子再优化一点更有价值；有时候将一组操作整体留在 CPU/GPU 上更合理。

10.4 编译产物是有条件的执行程序

产物清单至少应记录：

1
2
3
4
5
6


源模型与权重校验、分词器与模板
导出器、IR/opset、编译器与优化流水线版本
目标芯片、精度、布局、输入范围和 KV 协议
运行时/驱动/SDK 依赖与已验证组合
权重、子图、外部常量、设备二进制及其对应关系
正确性结果、性能基线、冷启动和回退条件

AOT 产物可能减少首次启动工作，也可能增加按芯片、形状和精度维护的变体数。若针对 4 类目标、3 个形状桶、2 种精度生成独立变体，理论上就有 24 个组合；实际可通过共享权重、按需生成和减少支持范围控制规模，但要验证实现支持。

可移植图和目标二进制通常有不同的兼容边界。编译缓存的标识应包含会影响生成结果的输入，版本变化后根据兼容约定与回归结果决定复用，不能仅用“模型名称相同”作为依据。

10.5 Prefill/decode 分图与跨设备分工要分开决策

两个阶段有不同编译入口，仍可以在同一个 NPU 上执行；跨设备分工则额外涉及 KV 可访问性、布局转换、资源争用与同步。应先分别测清两个阶段，再判断迁移收益是否覆盖状态交换成本。

端侧的 CPU/GPU/NPU 协同还要考虑应用其他负载。例如视觉编码器、语音处理或 UI 可能正在使用 GPU。最短的独立模型延迟，并不一定对应完整应用最稳定的资源安排。

十一、架构选型：围绕目标、边界与长期成本

11.1 三类目标，对应不同起点

目标	起点	应优先投入
尽快交付固定设备上的模型	厂商已支持的模型与官方执行路径	数值、状态、内存、稳定性和版本配套
持续接入新模型与新形状	成熟导出/执行栈 + 可扩展后端接口	前端、分解/融合、量化、分区、支持矩阵
开发或改进编译器	有源码与测试入口的编译项目	IR、合法化、目标变换、布局、内存与代码生成

如果当前问题发生在导出和 KV 接口，先修改这一层；若热点在厂商编译结果内部，需要判断已有配置、图改写或算子扩展能否解决，再决定是否扩大自研范围。架构选择要和团队实际能维护的层次对应。

11.2 一个决策实例：模型可加载，但长输入慢

先把现象拆开：慢的是首次编译、prefill、KV 初始化、图切换，还是每步 decode？然后逐项比较：

增加一个更合适的输入形状桶，是否减少了填充计算。
使用分块 prefill，是否降低峰值内存，同时增加了调用与状态开销。
将一个小操作纳入后端，是否减少了反复切换。
改变 KV 格式或访问范围，是否改善访存且保持长上下文质量。

每次只改变一个主要因素，并保留失败样例。把所有开关一起调整，即使得到了更好的最终数字，也很难形成可迁移的判断。

11.3 用架构决策记录固定取舍

可以沿用上一篇的架构决策记录（Architecture Decision Record，ADR），增加编译特有的信息：

1
2
3
4
5
6
7
8


问题：哪个模型、输入范围或设备限制触发了决策？
基线：当前图、精度、布局、产物与设备结果。
候选：修改前端 / 修改 pass / 调整后端配置 / 改变设备分工。
正确性：语义约束、量化误差、状态与边界检查。
收益：编译成本、启动、prefill/decode、内存与持续性能。
代价：新增变体、源码维护、调试难度与模型升级成本。
决定：采用哪条路径，在哪些条件下生效？
退出条件：哪些模型/版本变化触发重编译、重测或回退？

一份能说明“为什么只给某组形状启用融合”的记录，往往比“某编译器更先进”的概括更有工程价值。

十二、怎样验证：逐阶段定位，最后回到完整模型

12.1 正确性检查要沿转换链展开

推荐保留以下参照：原始浮点实现、导出图、变换后图、量化数值模型、编译后的执行结果。逐层或逐模块比较，可以找出误差最早出现的位置。

检查对象	方法	能发现的问题
IR 结构	验证器、预期模式及反例	非法类型、遗漏属性、错误匹配
数值结果	绝对/相对误差、异常值检查、固定输入 logits	精度、布局、量化参数或算子实现错误
状态更新	对齐相同输入位置与解码步、多轮、重置、分块接续	KV 写错位置、跨会话污染、掩码与有效长度错误
输入边界	最小/最大长度、桶边缘、尾块、不合法输入	越界、错误特化、尾部处理和错误恢复缺失
任务质量	独立样本、分组评测、失败案例	多步生成放大误差、长上下文或多模态退化

浮点结果未必逐位一致（bitwise identical），应先按数据类型、操作和任务要求确定容差。只比较最终生成文本，很难区分编译错误与采样分歧；逐步比较 logits 时应固定输入 token 序列，避免生成路径分叉掩盖最初误差；只比较短序列的平均误差，也可能遗漏状态和尾块问题。

12.2 Pass 测试与数值测试互相补充

编写图重写时，需要正例证明该匹配被改写，反例证明不符合前提的图不会被误改。FileCheck 一类文本检查适合确认 IR 结构，但不能单独证明数值正确。

随后执行变换前后程序，使用多组输入验证；涉及状态时连续运行多步，涉及形状时覆盖分桶和上下界；最后再接回完整模型。测试应保护变换的语义条件，而不是只确认代码里出现过某个 pass 名称。MLIR Toy 教程中的变换与 lowering

12.3 性能报告分清四个时间窗口

窗口	记录什么	典型误判
编译期	导出/编译时间、主机峰值内存、产物大小	编译更慢的代价被完全忽略
初始化	权重加载、设备上下文、首次编译/预热	把热缓存启动当作首次启动
稳态执行	分阶段延迟、实际设备、搬运/同步、内存	未同步的主机计时只测到提交时间
持续运行	热稳定性能、内存趋势、错误与恢复	只测冷机短时峰值

比较前固定模型、数据、生成条件、硬件与版本，分别报告输入实际长度和编译形状。跨精度或跨后端比较时，应补同后端的参考精度基线，避免把引擎差异全部归因于量化。

如果某内核占总时间 20%，把它加速到 2 倍，在其他部分不变时，端到端加速上限约为 $1/(0.8+0.2/2)=1.11$ 倍。算例可以帮助设定预期，但最终仍要检查改动是否影响融合、搬运与状态。

12.4 一份可复查的编译实验记录

1
2
3
4
5
6
7
8


实验编号、源码提交、配置、设备与完整软件版本
模型/权重、导出图、pass 流水线、形状和精度
每阶段 IR 或可取得的诊断产物
量化元数据、KV 表示、分区与回退行为
正确性容差、输入边界、质量结果和失败样本
编译/初始化/prefill/decode 时间与重复测量
峰值内存、布局转换、实际设备轨迹、持续性能
相对基线的唯一变化、收益、退化条件与决定

公开工具有时无法展示固件或内部内核的全部细节。此时应明确可见范围，通过分阶段计时、输入扫描和受控对照缩小原因，不把猜测描述成已经定位的硬件瓶颈。

12.5 把稳定性放进最后一次验收

检查重复加载、会话重置、取消后资源释放、容量超限、设备错误、模型切换和版本回退。异步运行时尤其要覆盖“请求结束，但设备仍在使用缓冲区”的情况。

交付包应带上支持矩阵、编译与运行配置、模型/产物标识和复现说明。能够在已声明的条件下稳定重建和执行，才算完成这条编译工程链。

十三、8 周学习路线：用课程建立理解，用实验贯通编译链

13.1 学习前提与投入边界

这条路线面向已经能使用 Python、PyTorch，并理解矩阵乘、注意力和自回归生成的读者。修改 C++ 编译 pass 还需要基本的 C++ 阅读能力、CMake 构建与调试经验。若这些基础不足，应先补对应内容，或先选择模型接入方向。

安排采用每周 5 个主学习日，每天约 8 小时，共 8 周、约 320 小时。每天只规定任务与产物；第 6、7 天用于休息、补漏和处理构建问题，不叠加新的必修内容。已经完成上一篇推理路线的读者，可以直接复用模型、质量样本和性能脚本，把节省的时间投入 IR、pass 与内存分析。

两个月的目标是：读懂一条编译链，完成一次有条件的程序变换，接入一套目标工具链，并留下能解释正确性、性能与限制的实验。 独立实现完整 LLM 编译器、新芯片后端或全部设备内核，需要更长的积累。

建议采用“带着当天问题看指定章节 → 在固定版本上做小实验 → 对照 IR 与结果解释变化”的顺序。视频负责建立直觉，官方文档负责核对接口，源码和实验负责验证理解。每周至少一半投入留给代码、调试和复盘，避免把完整刷课作为完成标准。

13.2 课程与资料：编译主线优先，模型和 GPU 内容按需补齐

资源	本文中的角色	优先学习内容	使用方式
MLC 机器学习编译中文课程，2022	编译全景主课	第 1、2、3、4、6、9 课：编译层次、张量程序、TensorIR、框架整合、图与内存优化	视频、中文讲义与 notebook 配合；精选实验即可
MLIR 官方入门视频与 Toy 教程	IR 与 pass 实作主线	IR 结构、模式重写、接口、逐层 lowering	先跟 Toy 第 2、3 章，再借第 5、6 章已有实现贯通 CPU 路径
TPU-MLIR 官方资料与视频索引	NPU 编译案例	MLIR 语法、Pattern Rewriting、Dialect Conversion、LayerGroup	结合开发手册读源码；只精读选定链路
MIT 6.5940，2024 Fall	量化与高效模型补课	第 5、6 讲量化；按需补第 12 讲 Transformer、第 13 讲 LLM 部署	量化部分列为主修，其他内容按已有基础跳过
Stanford CS336，2026	模型与系统基础补课	第 2 讲资源核算，第 5、6 讲硬件与内核，第 10 讲推理	只补不熟悉的问题；训练、分布式作业不进入本路线必做项
CMU 15-442/15-642，2026	现代编译与硬件补充	Data Layouts、GEMM、ML Compilation	使用公开讲义补布局和性能直觉；这里不把它列为已核验的完整公开视频课
Apple WWDC24：部署大模型	状态与产物接口案例	约 8:30 起的状态模型、约 15:27 起的性能部分	配合 Core ML 状态模型示例，迁移接口设计思路
所选厂商的当前版本教程	设备落地材料	导出、编译、加载、设备诊断与限制	在第 1 周确认环境，第 6 周集中深入；具体入口见第 13.5 节

本篇建议的顺序是 MLC 精选 → MLIR 实作 → 一个真实 NPU 工具链。 MIT 量化课穿插在第三周；vLLM 服务短课和 NVIDIA 推理直播可以补部署视角，但在这条编译路线中排在 IR、变换与内存之后。

两条版本说明需要提前记住：MLC 2022 notebook 与当前 TVM API 存在差异，优先保留课程环境复现实验，再对照当前文档理解演进；MLIR 视频用于学习机制，构建教程和源码应取同一个版本。不要为了追上所有仓库的最新提交，把第一周耗在依赖迁移上。

上述视频入口来自课程或项目官方索引；TPU-MLIR 的 B 站入口可能受登录或访问限制，无法播放时使用同主题手册与源码。课程选择以公开教学内容和实验衔接为依据，不要求额外购买付费课程。

13.3 先固定一个实验仓库和一条设备路径

准备两类实验对象，并让它们共享形状、精度、状态和测量约定：

小模块：矩阵乘、MLP 或单层注意力。用来观察 IR、写重写规则、检查布局与缓冲区；尺寸小，错误容易定位。
小型完整 LLM：选目标后端明确支持、当前设备能容纳的模型。用来验证分阶段生成、量化质量和真实运行边界；模型、权重版本与 tokenizer 在第一周固定。

小模块可以从参考模型中提取；Toy 程序只承担编译机制练习。不要把 Toy 的 CPU lowering 直接描述成完整 LLM 到 NPU 的编译路径。

1
2
3
4
5
6
7
8


compiler-study/
 configs/ # 源码版本、模型、设备、形状、精度与环境
 models/ # 小模块与完整模型的导出入口
 ir/ # 关键阶段 IR、分区与诊断信息
 transforms/ # pass、重写规则或后端适配改动
 tests/ # 数值、形状、状态、重写反例
 runtime/ # 加载、执行、状态与测量脚本
 reports/ # 原始数据、每周结论与最终复现说明

可用条件	可执行的主线	结论边界
普通 Linux 主机、Mac 或 CPU 环境	模型导出、MLIR/Toy、图重写、量化数值、状态与内存实验；选兼容的 CPU 后端执行	可以验证程序变换和功能；不能给出 NPU 加速、功耗或热稳定结论
受支持的 Android 设备	选择 ExecuTorch + Qualcomm、ORT QNN 或 LiteRT 中的一条	提前核对 SoC、OS、SDK、ABI、开发主机与模型；同品牌手机不代表能力相同
Rockchip / Sophgo 开发板	RKLLM 模型工具链，或 TPU-MLIR + 对应设备运行时	板卡、驱动、模型支持和主机工具需配套；RKLLM 接口实验与编译器源码实验分别记录
受支持的 Intel / AMD AI PC	OpenVINO NPU / Intel NPU Compiler，或 Ryzen AI / MLIR-AIE 中的一条	先确认具体处理器与工具版本；上层模型部署成功不代表底层编译接口全部开放

第一周就完成目标 SDK 的可用性检查和最小示例准备。 如果工具包获取、主机环境或设备调试不可行，立即沿 CPU 路径完成共同基础，并把上板实验明确列为待补。模拟器可辅助功能检查，其耗时不能替代真实设备性能。

13.4 八周安排：每天有动作，每周有验收

图 6 · 8 周编译工程学习路线从语义与 IR 出发，逐步增加状态、硬件与交付约束；每周留下可复查的产物。

第 1—2 周
建立语义与 IR 基础
固定参考模型与环境，导出小模块，读懂形状约束，完成一个有反例保护的 IR 重写。
第 3—4 周
保持量化与状态约定
验证量化表示，建立 prefill/decode 的 KV 接口，覆盖带历史 KV 的输入追加、分桶边界与会话重置。
第 5—6 周
连接内存组织与目标后端
观察分块、布局和缓冲区，读通一条后端路径，明确实际执行位置与回退行为。
第 7—8 周
完成一次优化与可复现交付
验证一个性能假设，记录收益和退化条件，补稳定性与重建说明，形成完整工程报告。

第 1 周：固定模型语义，导出可检查的程序

本周问题：从 Python 模型到导出图，哪些输入、状态和形状约束必须保持？

本周材料：MLC 中文课程第 1、4 课的概览部分；torch.export 官方教程。注意力基础不足时选看 MIT 第 12 讲；资源核算不足时补 CS336 第 2 讲。回看本文第二、五节。

学习日	当天任务	完成标准与产物
第 1 天	固定参考模型、环境与仓库；按第 13.3 节选择一条设备路径，检查 SDK 获取、主机支持与最小示例条件	保存环境和模型标识；列出可运行设备、可用诊断工具及未满足条件
第 2 天	运行小模型的固定输入推理；画出单层注意力和生成流程，计算权重与 KV 容量	保存输入、关键张量形状和参考 logits；解释 prefill 与 decode 的维度差异
第 3 天	提取小型 MLP 或注意力模块，用 torch.export 导出；检查参数、输入输出、常量与图签名	导出结果能独立加载并与参考模块对照；保存可阅读的图
第 4 天	为同一模块定义静态或有界动态形状，运行合法输入、边界输入和违反约束的输入	每类至少一个案例；说明限制来自导出契约、操作语义还是后端
第 5 天	分开记录首次准备与重复执行；整理固定输入、数值容差和设备路径；复跑最小例子	提交 `w01-export-baseline`：代码、导出图、约束、参考结果与环境记录

本周验收：能解释每个输入与输出的含义，并从图中找到一个具体形状约束。性能数据只是后续对照的起点；目标 SDK 暂不可用时，第一周就注明采用 CPU 实验路径。

第 2 周：读懂 MLIR，写一个能证明条件的重写

本周问题：一个图变换为什么合法，编译器通过什么结构表达并检查它？

本周材料：MLIR 入门视频与 Toy 第 2、3、5、6 章。重点是 IR、模式与 lowering；语法解析器沿用教程实现。回看本文第三、六节。

学习日	当天任务	完成标准与产物
第 1 天	跟入门材料阅读一个短程序，标出 operation、SSA value、type、attribute、block 与 region	给一份 IR 添加自己的解释；区分张量值与可变缓冲区
第 2 天	按同一版本构建教程所需的最小工具目标，运行 Toy 第 2 章，查看打印与验证器错误	保存构建说明、正常 IR 和一个非法类型或属性案例
第 3 天	跟第 3 章完成模式重写，如消除语义上互逆的两次转置；写清张量阶数（rank，即轴的数量）、维度置换与副作用前提	保存变换前后 IR，指出匹配条件以及替换后的结果来源
第 4 天	增加正例、不可匹配反例和数值对照；覆盖多个形状，不直接套用未经检查的浮点代数恒等式	结构检查与数值检查均通过；失败时能定位到具体规则
第 5 天	使用第 5、6 章已有代码贯通逐层 lowering 与 CPU 执行，追踪本周规则处在什么阶段	提交 `w02-ir-rewrite`：规则、反例、数值结果与一张转换链图

本周验收：能够解释一个规则为什么不应匹配某个反例。构建资源有限时，限定目标和并行度，使用匹配版本的开发环境；本周无需编译 LLVM 的全部项目，也不要求从零实现所有 Toy 章节。

第 3 周：把图优化与量化约定接起来

本周问题：量化参数如何进入图，优化怎样保持轴、类型和误差约定？

本周材料：MLC 第 9 课图优化；MIT 第 5 讲：量化 I、第 6 讲：量化 II；MLIR 量化表示。论文从第十四节 AWQ 或 SmoothQuant 中选一篇，先读与本周实验对应的方法。回看本文第六节。

学习日	当天任务	完成标准与产物
第 1 天	读第 6.3 节及推理篇的格式基础；观察图中类型、Q/DQ 与融合候选，构造不能直接删除 Q/DQ 的反例	写出存储、表达、计算与输出类型；解释普通 cast 与反量化的区别
第 2 天	复现第 6.4 节 INT4 打包；补负数、边界值与奇数长度；在小矩阵上比较逐张量/分组参数	保存字节与解包结果；核对符号、位序、元数据大小及 scale 对应关系
第 3 天	按已选后端支持矩阵选一种精度方案；需要校准时固定校准集并隔离质量评测集；导出可检查的量化图	保存 Q/DQ 或相应 IR 表示、权重格式、参数与工具版本
第 4 天	用不同 scale 的两组点积复现第 6.5 节；对照浮点参考、量化数值参考与编译结果，再检查完整模型样本	记录误差最早出现的阶段；核对累加、输出转换和 Q/DQ 融合后的实际执行
第 5 天	只改变一个因素，如校准样本、分组设置或敏感操作精度，复测并解释结果	提交 `w03-quant-contract`：图、参数、误差、质量与采用条件

本周验收：换一个布局或分组方案时，知道哪些量化元数据也要变。设备尚不可用时完成图与数值验证；没有受支持的低比特内核时，性能项明确留待上板验证，不能用模拟量化的速度代表 NPU 低比特性能。

第 4 周：让 prefill、decode 与 KV 状态保持一致

本周问题：不同入口与形状变体怎样更新同一份逻辑会话状态？

本周材料：Core ML 状态模型指南、WWDC24 状态模型片段；按所选路径参考 ExecuTorch LLM 导出或 LLM-TPU 示例。示例用于理解接口，实验仍沿用本周可执行的后端。回看本文第五、十节。

学习日	当天任务	完成标准与产物
第 1 天	给小注意力模块补显式 KV 输入输出，用同一隐藏状态序列对照无缓存与有缓存计算；再接回完整小模型	先比较模块在相同位置的输出张量，再用固定 token 序列比较模型 logits；保存有效长度、位置索引（position）与掩码（mask）
第 2 天	实现固定容量状态缓冲区或后端支持的状态接口，明确读写范围与重置方式	写出状态协议；区分有效 KV、预留容量和本轮新增内容
第 3 天	选择少量容量可承受的形状桶，如 128/512/2048；测试桶边缘及超出容量的输入	保存实际长度与编译形状；解释填充、容量、产物数和错误行为
第 4 天	对照一次完整 prefill 与分块接续；再测试已有历史时追加新输入，然后进入 decode	在相同输入和生成条件下比较状态与输出；定位跨入口的不一致
第 5 天	增加多轮、状态重置、最大长度、不同会话交替执行的检查	提交 `w04-state-shape`：状态接口、边界用例、数值结果与内存估算

本周验收：至少能复现并修正一个刻意引入的状态错误，例如 KV 写入偏移或掩码错误。后端不支持某种状态机制时，用显式缓冲区验证语义，并记录真实设备接口还缺什么；不要为完成全部案例而更换多套引擎。

第 5 周：从张量程序走到布局与缓冲区

本周问题：同一个数学计算，为什么不同分块、布局与存储安排会产生不同成本？

本周材料：MLC 第 2、3 课，按需回看第 9 课；MLIR Bufferization；CMU Data Layouts讲义；TPU-MLIR 官方索引中的 LayerGroup 教学。回看本文第七节。

学习日	当天任务	完成标准与产物
第 1 天	用 MLC TensorIR 练习或已选工具表示一个 MatMul，标出迭代域、归约轴与读写区域	将数学式、张量程序和输入输出对应起来；固定正确性基线
第 2 天	比较三个合法分块方案，先估算工作集，再运行；包含不能整除分块的尾部形状	保存分块参数、理论容量、误差与重复计时，解释尾块处理
第 3 天	在最小 MLIR 程序上观察 bufferization，构造仍需读取旧值的别名冲突案例	对比原地与非原地处理，指出产生复制或新缓冲区的原因
第 4 天	只改变一次布局传播、融合范围或所选编译器支持的层组配置，检查中间张量的存活期与缓冲区复用	保存可取得的 IR、内存计划或诊断信息；未暴露的内部细节标为未知
第 5 天	对照小模块与较大子图的耗时、临时内存和搬运，选择继续使用的方案	提交 `w05-layout-memory`：容量推导、编译表示、测量与取舍说明

本周验收：能够解释“局部更快而子图更慢”的一种可能原因，并用受控实验验证。MLC notebook 作为独立小练习即可，不要求同时深改 TVM 和 MLIR 两套编译器；CPU 分块实验建立机制理解，实际 NPU tile 与 DMA 结论仍由对应后端和设备验证。

第 6 周：读通一条目标后端，确认真实执行边界

本周问题：一个模型操作在哪一层被接受、改写、拒绝或交给其他设备？

本周材料：从第 13.5 节 A/B/C 中选一条；沿用第一周选定的设备与 SDK。厂商指南用于完成运行，源码与诊断信息用于定位决策。

学习日	当天任务	完成标准与产物
第 1 天	重跑所选工具链的最小官方示例，固定编译与运行版本，保存目标产物	明确产物类型、目标设备、加载方式以及模型支持条件
第 2 天	沿小模块追踪一条路径：导入/分区、编译、产物加载到执行	保存带文件和函数名的调用链；指出能修改的代码与封闭接口
第 3 天	构造一个不受支持的操作、形状或精度案例，观察拒绝、回退或子图切分	保存实际诊断与执行位置；不能仅凭模型有输出判定全图在 NPU
第 4 天	修改一个小规则、能力判断、状态适配或受支持配置，覆盖符合与不符合条件的输入	改动有语义理由、正反例和执行证据；记录边界数量是否变化
第 5 天	在后端明确支持的完整小模型上接回生成流程，检查量化、状态与分阶段耗时	提交 `w06-backend-path`：产物、调用链、改动、数值与设备记录

本周验收：能根据证据说明哪些阶段在什么设备执行。没有真实 NPU 时，以可运行后端完成接入和编译机制实验，另附 NPU 适配差距清单；此时产出是可复现的编译学习项目，上板性能验收仍未完成。

第 7 周：围绕一个瓶颈做优化，而后决定是否保留

本周问题：哪一项编译决策值得改变，怎样证明收益来自这项变化？

本周材料：围绕已经观察到的瓶颈查对应 pass、内存、分区或厂商文档。自动调优有实际需求时再选看 MLC 第 5 课；新课程只用于解决当前问题。回看本文第十一、十二节。

学习日	当天任务	完成标准与产物
第 1 天	从轨迹或输入扫描中选择一个问题：形状桶、融合、布局、边界、KV 搬运或编译成本	写出可被推翻的假设、影响范围、正确性风险与预期代价
第 2 天	实现一个最小改动，复用前六周的结构、数值、状态和边界检查	保留独立配置或提交，能够恢复基线；先通过正确性检查
第 3 天	在同设备、同版本、同输入条件下比较基线与改动，分开统计编译、初始化与稳态	每组至少重复三次，保留原始结果、计时边界和诊断产物
第 4 天	做消融对照，测试预计受益的形状，也测可能退化的短输入、尾块或容量边缘	解释收益来自哪里，哪些条件下收益消失，以及内存或编译代价
第 5 天	写一份架构决策记录，决定采用、限定条件启用或恢复基线	提交 `w07-optimization`：改动、反例、对照数据与最终决定

本周验收：结果不要求达到某个加速倍数。能用证据推翻最初假设、解释编译器为何已经做过某项优化，或者发现一个明确的退化条件，都是合格的工程结论。

第 8 周：补稳定性，完成可复现交付

本周问题：另一位开发者能否在声明的条件下重建、运行并理解你的结果？

本周材料：所选工具链的产物兼容、运行时与测试说明；回看本文第十、十二节。停止新增大方向，把时间留给复现和解释。

学习日	当天任务	完成标准与产物
第 1 天	整理模型、配置、工具版本、形状、精度、状态协议与产物标识，固定最终基线	形成环境清单和支持矩阵；删除实验说明中的过期步骤
第 2 天	检查重复加载、多会话交替、重置、容量超限；接口支持时补取消与资源释放	保存通过与失败结果；不存在的接口写清边界，不虚构已验证能力
第 3 天	在已声明负载下持续运行至少两小时，记录内存趋势、错误与性能变化	真实设备记录可取得的温度/功耗信息；两小时作为起步验收，不代表覆盖长期可靠性
第 4 天	从干净工作目录按说明重建，使用固定 SDK 与依赖重新运行核心检查	记录实际操作和产物差异；要求功能可复现，字节级一致性按工具能力另外判断
第 5 天	完成技术报告和约十分钟演示：解释编译链、一次变换、一个错误和一个取舍	提交 `w08-compiler-delivery`：代码、配置、测试、数据、复现说明与限制

本周验收：读者可以按说明重现关键行为，并知道哪些结论来自真实 NPU、哪些来自 CPU 或数值模拟。最终报告应同时保留失败尝试、未解决问题和下一步最值得投入的技术点。

13.5 第六周的三个深入方向，只选一条

图 7 · 共同基础之后的三条深入方向围绕一个可修改的边界积累深度，再把产物接回同一套验证方法。

A · 模型与前端导出、分解、量化、分区
精读一个模型接入路径。交付：一项有条件的适配、数值对照，以及子图与设备执行记录。
B · 编译器内部IR、pass、布局、内存
精读一个可修改的编译器。交付：一个重写或配置改动，配套 IR、反例与执行结果。
C · 硬件映射与执行张量程序、数据流、状态接口
精读一个目标设备的小计算路径。交付：可运行的内核或缓冲区适配，以及局部与整体成本说明。

A：模型接入与图编译。 优先从 ExecuTorch Qualcomm LLM 示例、ORT QNN EP或 LiteRT Android中选一个。先运行已有模型，再研究一个分解、量化参数或能力判断；对照修改前后的分区和执行位置。RKLLM 用户可以采用同样的接口分析方法，但厂商工具未开放的内部 pass 不能作为可修改范围。

B：编译器与硬件映射。 希望阅读较完整的 NPU 编译流程，可以选择 TPU-MLIR，沿导入、Top/Tpu IR、局部内存与代码生成中的一小段深入；使用 Intel 平台可先读 NPU Compiler 的 MLIR 入门和项目结构。具体改动限于一个可执行、可测试的规则，不以读完仓库为目标。

C：张量程序与运行时。 有受支持 AMD 设备和底层编程兴趣时，可以从 MLIR-AIE / IRON官方小示例研究计算、数据流和缓冲区；选择集成方向时，则在既定运行时中追踪状态创建、注册、执行和释放。前者深入硬件映射，后者深入执行接口，二者选一个具体问题即可。完整 LLM 的效果需要接回模型流程验证，小 GEMM 成功只能证明这条计算路径。

13.6 AI 怎样参与，才能真正缩短学习周期

适合交给 AI 的工作包括：解释已提供的 IR、导航固定版本源码、生成重复性测试输入、整理实验配置、比较两份 pass 输出，以及根据现有日志提出排查顺序。把当前版本、实际代码、完整错误和硬件条件一起提供，通常比泛泛要求“写一个 NPU 编译器”更有效。

三个可复用的提问模板：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


阅读这份变换前后 IR：逐项说明形状、类型、量化参数和状态变化。
列出该重写保持语义的前提，并给出至少一个不应匹配的反例。
对材料中不能确认的内容，明确指出需要继续查看哪处定义。

这是固定提交的 pass 与测试入口：请追踪匹配、合法性检查和替换。
提出最小改动及对应测试；不要使用该版本不存在的 API。

这是基线与改动的原始数据、设备和计时方法：
检查比较条件是否一致，区分事实、推测和仍缺少的测量，
并提出一次能够区分主要原因的后续实验。

每周最后一天，关掉 AI 辅助，用自己的话解释一次 IR 变化、一个失败输入和一项取舍。AI 生成的规则必须经过正反例与数值检查；没有运行过的命令、没有采集过的设备数据，不写成实验结果。

13.7 进度落后时，保护核心顺序

检查点	必须留下的能力	可以暂缓的内容
第 2 周结束	能读 IR，解释并测试一个合法重写	自定义完整前端、读完全部 dialect
第 4 周结束	量化元数据清楚，状态与形状边界可验证	同时比较多种量化算法、复杂多模态模型
第 6 周结束	一条后端路径与执行边界清楚	同时接入第二厂商、实现完整新后端
第 8 周结束	一项受控实验和可复现交付	大规模自动调优、全部新论文复现

如果某周卡住，先缩小模型、图和形状集合，再减少选修内容；不要省略正确性、状态与真实执行位置检查来维持表面进度。学习路线的价值来自知识之间能互相解释，以及每一步都留下可检验的结果。

十四、进一步阅读：按工程问题选择论文和源码

14.1 核心材料与选读顺序

前面的课程负责搭起概念，下面的材料用于回答已经遇到的问题。每次阅读写下四件事：它解决什么约束、采用什么表示、依赖什么假设、怎样验证有效。

材料	适合深入的问题	建议顺序
MLIR: Scaling Compiler Infrastructure for Domain Specific Computation，2020	多层 IR 为什么存在，基础设施怎样容纳不同语义	第 2 周后核心阅读，对照一次实际 lowering
MLIR Dialect Conversion与 Bufferization	合法化怎样结束，别名与读写冲突怎样决定存储处理	第 2、5 周按实验查阅，比泛读所有 dialect 更优先
TensorIR，2022 预印本	张量程序怎样支持变换，计算语义与调度怎样结合	第 5 周核心阅读，配合小型分块实验
TVM，2018	图、算子优化与硬件后端怎样组成完整系统	第一轮建立全景；历史架构与当前 API 分开看
AWQ或 SmoothQuant	量化算法怎样重新分配误差，怎样约束后端实现	第 3 周按所用格式选一篇，另一篇先理解差别
TPU-MLIR，2022与面向 LLM 的编译方法，2026	一个具体 NPU 编译体系如何处理多层表示、有限存储和生成阶段	B 路线重点，结合当前源码核对；其他路线选读
IREE 开发者概览与 Stream IR	异步执行、资源与设备边界怎样进入编译表示	状态与运行时方向选读，不要求额外迁移全部实验
Ansor，2020	为什么搜索空间与代价模型比穷举更重要	第 7 周确实需要自动调优时再读
StableHLO 兼容性及目标 SDK 的产物说明	程序表示、序列化格式与设备产物分别承诺什么兼容性	第 8 周结合交付清单阅读

论文中的速度与模型范围依赖其设备、软件和评测条件。读过一种方法以后，先在自己的负载上找出对应约束，再决定是否复现；不要把发表年份或单项加速数字当作选型排序。

14.2 后续跟踪什么，暂时放下什么

建议持续跟踪四类变化：目标设备的模型/精度支持矩阵、所选编译器的 IR 与 pass 变化、状态和动态形状能力、编译产物与运行时兼容性。这些信息直接影响模型升级、性能和维护成本；遇到版本变化时，重跑已经建立的小模块、状态边界和完整模型检查。

当基础链路稳定后，再按真实需要扩展：长上下文和 KV 压缩、多模态前端、稀疏计算或混合专家（Mixture of Experts，MoE）的动态执行、自动调优和更高层的调度表达。它们各有价值，但进入学习主线的依据应是目标硬件与当前瓶颈，而非同时追逐所有新名词。

归纳起来，这张图谱的核心是：保留模型语义，表达硬件约束，验证程序变换，让编译产物与有状态执行正确衔接。 深入一套能修改、能观察、能验证的工具链，再用共同的问题比较其他实现，就能逐步形成面向端侧 NPU 的编译工程判断力。

大模型推理与部署工程图谱：技术栈、开源项目与学习路线

Sun, 20 Sep 2026 13:13:11 +0800

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 三种学习深度

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

优先级	应达到的程度	内容
P0：通用核心	能解释原理、建立基线、设计实验	模型推理与张量形状；prefill/decode；KV 缓存与其他持久状态；数值格式、量化与存储/计算精度；内存与带宽；质量、延迟、吞吐量和性能分析
P1：方向核心技术栈	能读关键源码、解决问题、交付系统	一个主推理引擎，加上方向需要的调度/分布式、端侧运行时，或编译器/算子/硬件后端
P2：备选与前沿	能说明问题、条件和替代关系	同层第二、第三个项目；尚未成为瓶颈的系统机制；暂时不适用的模型优化；新论文与新 DSL

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

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

路线	主要关注	值得深入的技术	可验证的结果
在线推理服务	交互延迟、容量、尾延迟、可用性	调度、KV、缓存、并行、路由与准入控制	满足 SLO 的容量与成本报告
离线批处理	总完成时间、资源利用与单位样本成本	批次组织、长度分组、吞吐量与失败恢复	固定任务集的完成时间与质量
端侧与本地推理	内存、功耗、温升、冷启动、平台集成	量化、轻量运行时、异构执行与状态管理	长时间可运行的端到端应用
编译与硬件优化	算子覆盖、布局、搬运、执行效率	IR、图分区、融合、计算内核、设备运行时	正确性与端到端优化证据

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

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

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

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

决策维度	至少需要知道什么	对架构的影响
请求分布	输入/输出长度的分位数、到达率、突发性、前缀重复程度	调度策略、KV 容量、缓存价值、扩缩容
模型结构	稠密模型（dense model）/MoE、MHA/GQA/MLA、滑动窗口、混合状态、VLM 输入	算子覆盖、状态布局、并行方式
质量约束	哪些任务不能退化；量化容许的误差	数值格式、校准集、是否需要 QAT
服务目标	首 token、后续 token、总时延的 p95/p99；可用性	批量大小、资源预留、排队与准入控制
设备条件	可用内存、实测带宽、片上存储、原生精度、互联、功耗	是否放得下、计算是否划算、能否多卡切分
交付条件	SDK 开放程度、模型更新频率、团队规模、离线要求	自研边界、编译成本、维护成本和升级策略

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

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

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

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

质量：业务任务完成率、准确率、长上下文能力、结构化输出正确率。
延迟：TTFT、ITL、端到端延迟，以及冷启动/首次编译时间。
容量：满足延迟目标时能承载多少并发、多少请求。
效率：每个合格请求的成本或能耗，而不只是峰值 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 约束内，降低单位有效请求的总成本。 对端侧设备，总成本还包括电池消耗、温升、安装包与常驻内存；对集群，还包括网络、空闲容量、故障冗余和运维投入。

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

图 1 · 大模型推理与部署的技术分层

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 指向更低层表示的转换，第八节会进一步说明。

层次	代表对象	最需要理解的边界
模型语义与参考实现	PyTorch、Transformers、模型官方实现	定义正确结果，未必提供最佳部署路径
推理引擎	vLLM、SGLang、TensorRT-LLM、llama.cpp、MLC LLM	管理生成过程、请求和模型执行；部分场景互为选项
分布式服务	Dynamo、llm-d、Kubernetes 相关组件	编排引擎与资源，通常不替代底层引擎
KV 数据管理	LMCache、Mooncake 的缓存/传输组件	管理复用、分层存储、搬运；与引擎集成
图表示与编译	torch.export、ONNX、TVM、MLIR、IREE	导出格式、编译基础设施和完整执行栈是不同对象
算子实现	CUDA、Triton language、CUTLASS/CuTe、FlashInfer、厂商算子库	编写或复用计算内核；不负责完整服务调度
硬件适配	驱动、CANN、QNN、OpenVINO、RKLLM 等	能力与开放边界随厂商、芯片和版本不同

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

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 则没有这种直接替代关系。

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

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

图 2 · 大模型推理与部署的发展时间线（2017—2026）从模型计算、请求调度到跨设备状态管理，各阶段的技术逐步积累。

2017.06
Transformer：形成后续推理优化的重要计算基础
Attention Is All You Need 首次公开。矩阵乘、注意力、归一化等成为需要理解的基本结构；现代纯解码器（decoder-only） LLM 在此基础上继续演化。
2018—2020
编译基础设施：把模型映射到多样化硬件
TVM 论文（2018.02）和 MLIR 论文（2020.02）提供两种重要观察入口：图与算子协同优化，以及多层中间表示。论文时间不等于项目诞生时间。
2022.05—07
从“算得快”走向“少搬数据、少等请求”
FlashAttention（5 月）关注注意力的访存开销；Orca（OSDI，7 月）展示迭代级调度。这是计算内核优化与推理服务（serving）两条互补路线。
2022.10—11
低比特与投机执行：减少成本的不同办法
GPTQ、SmoothQuant和投机解码论文陆续公开：前两者改变数值表示，后者改变生成执行方式。
2023.06—12
权重、KV 与重复前缀成为明确的优化对象
AWQ（6 月）、PagedAttention/vLLM 论文（9 月）、SGLang 论文（12 月）分别提供量化、KV 分页管理和结构化生成/缓存复用的代表性方案。
2023 · 端侧
另一条并行主线：让模型进入消费级设备
MLC LLM 的 5 月项目介绍展示通过编译面向多种消费级设备的路线；ExecuTorch 于 10 月公开介绍，强调轻量运行时与后端委托执行。部署的演进同时发生在数据中心和端侧。
2024
从单引擎优化扩展到阶段分离与模型—系统协同
DistServe（1 月）研究 prefill/decode 分离；DeepSeek-V2（5 月）体现 MLA 与 MoE 的模型侧改变；Mooncake（arXiv，6 月）讨论以 KV 为中心的分离式架构。
2025.03—05
分布式推理进入可组合的工程栈
Dynamo 于 3 月 18 日发布；llm-d 于 5 月 20 日发布。路由、资源编排、KV 传输与推理引擎之间的接口变得更加重要。
2026.02—09
基础设施继续演进，不能沿用固定的项目印象
DFlash（2 月）探索扩散式草稿生成；Dynamo 1.0（3 月）发布。9 月核对的 TensorRT-LLM v1.3.0rc27 预发布分支对应的 latest 迁移指南已说明旧 TensorRT 后端移除，新学习路径需要结合版本重新判断。

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

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

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

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

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）和采样语义。它们既决定性能，也经常是移植后“可以输出、但结果不对”的原因。几个高频术语与缩写应与具体含义对应起来：

术语	中文与英文名称	在推理中的含义
Q / K / V	查询 / 键 / 值（Query / Key / Value）	注意力（attention）计算中的三类表示
MHA	多头注意力（Multi-Head Attention）	标准结构中，每个查询头都有对应的 K/V 头
GQA	分组查询注意力（Grouped-Query Attention）	一组查询头共享 K/V 头，减少 KV 缓存需求
MLA	多头潜在注意力（Multi-head Latent Attention）	通过低秩联合压缩等设计减少需要缓存的状态
RoPE	旋转位置编码（Rotary Position Embedding）	将位置信息引入注意力表示，移植时要对齐位置与旋转约定
RMSNorm	均方根归一化（Root Mean Square Normalization）	基于均方根进行归一化，计算与数值行为不同于 LayerNorm（层归一化）
MLP	多层感知机（Multilayer Perceptron）	在此主要指 Transformer 中的前馈网络模块
logits	保留英文，可理解为未归一化的输出分数	通常经 softmax 转为概率，用于下一 token 的选择或采样

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 未必能解决问题。

优化应先按证据归类：

瓶颈	典型迹象	优先验证
计算	大 GEMM 占主导；计算单元忙	tile、矩阵指令、合适精度、批次形状
片外内存带宽	运算量不大，搬运量很高	权重/KV 压缩、融合、访问连续性、复用
片上容量/布局	大量切片、重复搬运、转置	tile 与 SRAM 预算、布局、双缓冲
主机端与启动	设备任务之间有空闲间隙，大量耗时很短的计算内核	CUDA Graph 等图执行机制、批量提交、融合、减少同步
跨设备通信	集合通信（collective communication）或数据传输占关键路径	并行策略、拓扑、通信与计算重叠
调度与排队	单请求快，服务 p99 延迟高	准入控制、每轮 token 预算、分块预填充、优先级

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

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

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

技术	主要解决什么	为什么有用	必须知道的代价或边界
FlashAttention	注意力计算中的数据搬运	分块计算，避免把完整中间注意力矩阵写回片外内存	标准稠密注意力的二次计算复杂度并未因此消失；适配依赖硬件
PagedAttention / KV 缓存分页管理	KV 分配、碎片和共享	按块管理逻辑序列，避免大块连续预留	需要页表/块表与配套计算内核；不是 KV 数值压缩
前缀缓存（prefix caching）	不同请求重复的 prefill	复用相同前缀对应的有效 KV 状态	不直接省去后续 decode；收益取决于命中长度与复用频率
连续批处理（continuous batching）	请求长短不一造成的空转	每轮调整活跃请求，让结束的请求及时退出	需要动态调整批次及其状态；与固定请求批次不同
分块预填充（chunked prefill）	长 prefill 干扰 decode	将输入处理拆成块，与 decode 共享每轮 token 预算（token budget）	预算限制每轮调度的 token 总量；块大小影响首 token 延迟、token 间延迟和计算效率
KV 量化/压缩	长上下文的状态容量与带宽	减少每 token 的状态存储	要验证长上下文质量、格式支持和转换开销
CUDA Graph 等图执行机制	重复提交与主机端提交开销	重放一组设备操作，减少逐次调度	形状、地址、状态更新有约束；占用额外资源；各 NPU 有不同机制

上述机制分别可以从 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） 规定有限比特怎样表示数值；模型质量描述任务效果。浮点格式用符号、指数和有效数的小数字段表达不同量级；整数格式先表示离散整数，量化方案再赋予这些整数对应的实数含义。

格式	每值原始存储	表示特点	应建立的直觉
FP32	32 bit = 4 字节	1 位符号、8 位指数、23 位小数字段	常用于数值参考或部分敏感计算；参考实现也需确认实际计算模式
FP16	16 bit = 2 字节	1 位符号、5 位指数、10 位小数字段；最大有限正数 65504	容量较小，但需要关注溢出和舍入
BF16	16 bit = 2 字节	1 位符号、8 位指数、7 位小数字段	指数范围接近 FP32；相较 FP16，范围更大、相对精度较低
INT8	8 bit = 1 字节	有符号整数通常为 −128～127	表示小数需要 scale 等量化信息；UINT8 的码域则为 0～255
INT4	4 bit；紧凑打包后平均半字节	有符号补码为 −8～7，UINT4 为 0～15	只有 16 个编码，误差更依赖量化范围与分组；还有元数据成本

浮点表中的小数字段不包含正规数隐含的最高有效位。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：

原值 x	量化整数 q	反量化值 x̂	发生了什么
−1.00	−4	−1.00	恰好可表示
−0.30	−1	−0.25	舍入引入误差
0.20	1	0.25	舍入引入误差
0.90	4	1.00	舍入引入误差
2.10	7	1.75	超出范围，被截断到上界

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

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

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

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

粒度	参数怎样共享	主要取舍
逐张量（per-tensor）	整个张量共用参数	元数据少；局部离群值可能影响其他部分
逐通道/逐轴（per-channel/per-axis）	指定轴的每个索引各有参数	可适应通道差异；必须明确量化轴
分组（per-group）	沿指定维度，每 G 个元素共享参数	可更细致地适应分布；增加元数据、访问和内核约束

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

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，再参与矩阵运算；转换可以融合在内核内部，避免先把全部权重展开成长驻浮点副本。其他路径可以利用目标硬件支持的低比特计算能力，前提是数值类型和缩放方式匹配。

图 3 · W4A16 的一种权重读取与计算路径示例采用 FP16 激活与 FP32 累加；实际支持依赖内核，解包与反量化可以融合执行。

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 是表示类型，下面这些方法则解决量化参数和误差分配问题：

方法	主要思路	学习深度建议
RTN（Round-to-Nearest）	给定量化范围与参数后舍入到最近可表示值	必须会做数值基线，检查截断和舍入
GPTQ	利用近似二阶信息降低权重量化误差	理解目标与校准流程，按项目需要深入实现
AWQ（Activation-aware Weight Quantization）	利用激活信息选择缩放，改善低比特权重表示	理解激活感知的动机及其与内核的衔接
SmoothQuant	通过等价缩放把激活量化难点迁移到权重侧	理解离群值，以及权重/激活协同量化

算法依据见 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 数

路线	代表思路	主要工程权衡
独立小模型	草稿模型 + 目标模型	多一份权重与状态；要匹配分词器和验证流程
模型内/附加预测模块	多 token 预测（Multi-Token Prediction，MTP）、EAGLE 系列等	依赖模型或训练好的预测模块；不是打开开关就普遍适用
输入/历史查找	基于 n-gram（连续 n 个 token 的片段）等的无额外神经草稿模型方案	重复内容可能受益；泛化能力与草稿质量不同
扩散式草稿	DFlash 等	新的草稿生成并行方式；仍需完整的成本与质量验证

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

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

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

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

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

项目	核心定位与适合场景	最值得学的部分	选择时重点验证
vLLM	通用 LLM 服务引擎；调度、KV 管理、模型与硬件适配生态	调度器（scheduler）、KV 缓存管理器（KV cache manager）、模型执行器（model runner）、后端（backend）接口	目标插件成熟度；模型与优化特性的组合支持
SGLang	从结构化生成与前缀复用出发，发展为覆盖稠密模型/MoE 等的高性能服务栈	RadixAttention、调度、结构化输出、分布式执行	具体模型/硬件路径；缓存与通信在自身负载下的收益
TensorRT-LLM	NVIDIA 平台的深度推理优化与硬件协同	专用计算内核、量化、并行执行和性能调优	GPU 代际、版本绑定、后端迁移和功能支持矩阵
llama.cpp	C/C++ 推理、低比特、本地和多种设备后端	模型执行、ggml 后端、GGUF、CPU/设备分工	目标后端的实际算子覆盖；端到端内存与延迟
MLC LLM	基于 TVM 的编译与部署路径，覆盖多种平台	模型表示 → 编译优化 → 模型库 → 运行时	新模型/新硬件的编译支持；不能假设任意 NPU 自动可用
MLX / MLX-LM	Apple Silicon 上的数组计算与 LLM 工具生态	统一内存、CPU/GPU 执行和本地实验	目标是否就是 Apple 平台；不要把它等同于苹果神经网络引擎（Apple Neural Engine，ANE）后端

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

在线服务路线：在 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 能力，适合移动/嵌入式路线考察模型转换、运行时与应用集成。二者都值得放入选型地图，但没有理由在尚未完成一条主线之前同时精读全部实现。

对象	初期投入建议	原因
第二个、第三个通用服务引擎	跑相同负载，比较关键路径即可	调度、KV、模型执行等基础知识高度复用
本地模型管理器、聊天 UI、API 包装层	会使用、知道底层依赖	对产品验证有价值，但不能替代芯片后端能力
多种模型导出格式与转换 CLI	围绕实际部署链掌握一种	核心是张量语义、形状和数值一致性
多套计算内核 DSL	先深学一种，再看差异	数据搬运、布局、tile 和同步知识更持久
所有分布式推理平台	有明确规模问题再深入	单设备实验通常还没有相同的调度和运维约束

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 先理解编译链中的动作

图 4 · 模型编译与设备执行流程

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 编译相关项目不是一组平行竞品

对象	所处层次与作用	与其他对象的关系	建议深度
`torch.compile`	在 PyTorch 执行中捕获并优化计算，接入编译后端	常与推理引擎一起使用；不是完整服务系统	掌握 graph break、guard、重编译和后端边界
`torch.export`	捕获可供后续转换的完整图及约束	是 ExecuTorch 等部署路径的入口之一	NPU/端侧方向重点掌握
ONNX + ONNX Runtime EP	图表示 + 执行提供程序（Execution Provider，EP）	EP 根据能力接管节点或子图；与厂商 SDK 对接	适合学习通用分区与后端接入
TVM	模型/算子编译、调度与运行时基础设施	MLC LLM 建立在相关编译能力上	适合需要较完整编译链的路线
MLIR	多层 IR、方言、编译 pass 与转换基础设施	可用于构建自研编译器；自身不是现成 LLM 服务	理解概念；工作需要时深入方言/pass
IREE	基于 MLIR 的编译器与运行时栈	提供具体编译、设备抽象与执行路径	目标栈使用它时深入，其余了解设计
ExecuTorch	PyTorch 模型面向端侧的导出、后端委托执行和轻量运行时	可连接不同硬件 delegate	移动端/嵌入式路线优先比较

依据：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 捕获的是待重放的设备操作及其依赖。二者处于不同层次，可以配合使用。

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

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

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

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

项目/技术	主要价值	适合在哪条路线深入
CUDA C++	NVIDIA 的设备编程、内存与同步基础	GPU 优化基础；很多性能思维可迁移，API 不可直接迁移到 NPU
Triton language	用块级张量表达计算内核，降低部分 GPU 内核开发门槛	适合做融合与算子实验；目标后端支持仍需检查
CUTLASS / CuTe DSL	高性能线性代数、布局与 NVIDIA 硬件映射	极致 GPU 计算内核路线再深入
FlashInfer	面向 LLM 推理的注意力等计算内核库	理解引擎如何调用专用算子库
TileLang	用 tile 表达高性能计算的 DSL	可作为另一种表达方式，初期不必与所有 DSL 同时学
DeepGEMM	特定低精度和形状下的 GEMM 实现	理解 MoE/稠密模型的计算部分
DeepEP	专家并行中的 token 分发（dispatch）与结果合并（combine）通信	解决的是 MoE 数据交换，与 GEMM 互补
厂商计算内核 API，例如 Ascend C	显式表达目标 NPU 的计算、片上内存与数据搬运	对应芯片的算子开发与性能优化

领域专用语言（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”数字比较。

硬件方向	应优先观察的约束	典型软件路线
CPU	内存带宽、向量指令、NUMA、线程开销	C/C++ 运行时、向量化算子；也常承担预处理与控制
GPU	显存、带宽、矩阵指令、计算内核启动、互联	通用引擎 + 专用计算内核 + 多卡通信
数据中心 NPU	编译器/算子覆盖、设备内存、互联、软件版本耦合	厂商运行时 + 引擎插件/图后端
移动/嵌入式 NPU、DSP	功耗、热约束、共享内存、静态编译边界、算子覆盖	delegate、预编译模型、厂商 SDK
FPGA	数据通路设计、片上资源、带宽、开发周期	可重构硬件与专用编译/运行时；通常是另一条深入路线

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

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

生态	值得观察的适配方式	需要确认的边界
vLLM 的 GPU 安装与后端路径	引擎连接 CUDA、ROCm 等 GPU 软件栈	GPU 架构、驱动、软件构建和各优化特性的支持条件
vLLM Ascend	通过硬件插件将引擎与昇腾执行能力连接	对齐 vLLM、插件、CANN、PyTorch/torch_npu 等版本；查看功能矩阵
ExecuTorch Qualcomm 后端	导出图、分区、委托给 Qualcomm AI Engine Direct/QNN	算子、形状、设备与 SDK 的支持条件
OpenVINO GenAI NPU 路径	从模型转换、编译到设备执行的完整样本	此处引用为 2025 文档；动态形状与配置能力要按安装版本核对
RKLLM	PC 侧转换/量化工具 + 板端 C/C++ 运行时 + 驱动	RKLLM 与通用 RKNN 路线有区别；检查芯片与模型列表
Core ML stateful models	将 KV 等持久状态纳入模型执行接口	可配置的计算单元（compute units）不保证所有节点实际运行在 ANE
LiteRT / LiteRT-LM	端侧模型运行时与 LLM 执行层协作	不同平台、加速后端与模型格式的具体支持

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

厂商在 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、注意力或量化解包等热点。以算子优化为例，过程应包括：

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

用 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 并行策略：先决定切什么，再讨论用几张卡

策略	切分对象	主要收益	主要代价
数据并行（Data Parallelism，DP）	将不同请求分配给模型副本	增加服务容量、隔离故障	每副本持有权重；路由和负载均衡
张量并行（Tensor Parallelism，TP）	层内矩阵/张量	跨设备容纳模型，增加层内并行	每层通信频繁，对互联敏感
流水线并行（Pipeline Parallelism，PP）	模型层	分摊权重内存	流水线气泡（pipeline bubble）、分阶段调度和尾延迟
专家并行（Expert Parallelism，EP）	MoE 专家	分摊专家权重与计算	token 分发/结果合并、负载不均、跨节点通信
上下文并行（Context Parallelism，CP）	序列/上下文及相关计算	支持长上下文、分摊部分状态与计算	注意力协调与通信；依具体实现而定

这里的 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 论文系统性提出并验证。

图 5 · 预填充/解码分离与 KV 状态流转

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

项目	更关注哪一部分	应怎样比较
NVIDIA Dynamo	分布式推理、路由、资源规划与 KV 数据流；可连接 vLLM、SGLang、TensorRT-LLM	与自身引擎、部署环境、硬件和扩缩容策略的适配；不是只有 NVIDIA 硬件一种路径
llm-d	Kubernetes 上的分布式推理与可部署方案	已有 K8s 平台时，观察路由、调度、运行方案和维护成本
LMCache	KV 复用、分层卸载、共享与管理	缓存命中收益、加载开销、存储层和引擎连接方式
Mooncake	以 KV 为中心的基础设施；传输引擎、存储等组件	网络/存储数据路径、拓扑与具体集成模块；范围不只是一篇早期论文

它们存在重叠，也存在集成关系；不能把四个项目作为四个完整推理引擎逐一替换测试。尤其是缓存复用，读取 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 当前值得跟踪的变化，而不是需要全部复现的论文

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

模型状态变得多样：GQA、MLA、滑动窗口与混合状态模型，使“所有层都是同一种 KV”越来越不够用。混合 KV 管理
低精度向整条数据路径延伸：不只权重，还包括激活、KV、通信；支持情况要与计算内核和硬件共同验证。LLM Compressor
推理资源围绕状态与阶段组织：长上下文、多轮对话和智能体负载使缓存、路由和阶段分离更有研究价值。Dynamo、Mooncake
草稿生成与内核表达继续演变：投机方法与 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 基准测试必须覆盖负载分布

至少分开测量：

负载	想回答的问题
短输入、短输出、低并发	系统的交互延迟与固定开销是多少？
长输入、短输出	prefill、注意力、视觉/文本预处理是否成为瓶颈？
短输入、长输出	decode 的带宽、权重读取与持续功耗如何？
长输入、长输出	KV 容量、长上下文质量与持续稳定性如何？
多请求、长短混合、突发到达	调度、公平性、准入控制与尾延迟如何？
重复前缀与冷缓存两组	缓存到底贡献了多少？
VLM 的分辨率/图片数分组	动态多模态输入怎样改变成本？

并发数与到达率不是同一个控制变量。 固定并发的闭环压测，会在请求变慢时自然减少新请求；固定到达率的开环压测更容易观察排队和过载。两种方式都可以使用，但要写清楚，并检查压测客户端自身是否先遇到 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 天留作休息、补缺或复盘，不再追加必修任务。每日安排只规定材料、任务与产物，具体时间由实验难度调整。

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

开始前做三项自测：

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

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

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

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

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

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

资源	在路线中的用途	精选内容与入口
MIT 6.5940	量化、部署与长上下文的主要理论来源；Song Han 主讲	EfficientML.ai（2024）：视频、讲义和实验。重点为第 5、6、12、13、15 讲；第 3、4 讲稀疏与剪枝按需补充
Stanford CS336	补模型计算、资源核算、硬件和系统直觉；Percy Liang、Tatsunori Hashimoto 主讲	Language Modeling from Scratch（2026）：课表与讲义、官方视频列表。主选第 2、5、6、10 讲的相关部分；模型基础不足补第 3 讲，多卡方向选第 7、8 讲，评测补第 12 讲
vLLM 短课	把模型压缩、服务和评测连起来；实践主线	DeepLearning.AI：Fast & Efficient LLM Inference with vLLM。Cedric Clyburn 主讲，页面标注 1 小时 38 分钟、9 节视频、3 个代码示例；学习时间还需加上调试和实验
CMU ML Systems	查清服务调度、投机解码、并行和编译机制	15-442/15-642 课表与讲义，Tianqi Chen、Zhihao Jia 授课。这里使用公开讲义，不将其当作已核实的完整公开视频课
NVIDIA 工程回放	学习从性能证据到优化方案的推理过程；后期选看	DeepSeek-R1 延迟优化，2025-06-04、MTP 实现与优化，2025-06-25，均来自 NVIDIA Developer；配合 TensorRT-LLM 官方文档
MLC 中文课程	编译方向的补充主课；需要中文讲解时尤其有用	2022 中文日程提供视频、中文笔记与练习。重点为第 1、3、9 课；旧版 TVM 示例应使用课程环境，或按当前文档迁移
SGLang 短课	补 KV 缓存实现，或在后期比较第二个引擎	DeepLearning.AI：Efficient Inference with SGLang: Text and Image Generation。重点看推理基础、KV 缓存和跨请求缓存；图像生成部分按方向选修

这份组合的分工是：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

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

条件	可以执行的路径	需要调整的任务
Linux + 受支持的 NVIDIA GPU	按下文 vLLM 示例主线完成；先使用小模型和短上下文	根据实际显存收缩批量与长度；量化格式、Triton 支持仍需核对
Mac 或仅 CPU	先做模型计算、容量估算、量化数值实验；服务实验可用 llama.cpp，Apple silicon 也可考察 MLX	第 4、6 周测本地后端实际支持的服务/缓存能力；第 2 周用 CPU/平台工具分析，Triton 实测留到有适用 GPU 时
可使用短时云 GPU	本地完成代码和正确性调试，集中做第 2—4 周及后半程的设备实验	下载、编译、排错也占用时间；记录实际机型和环境，不把云上结果当成本机结果
有目标 NPU/开发板	前半程用参考实现，后半程切入厂商支持的引擎或编译路径	第 6 周选择编译/硬件分支；算子覆盖、回退和真实设备测量成为主要验收项

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

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

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

图 6 · 课程与实践衔接的 8 周学习路线每周五个主要学习日；同一个模型、评测集与实验仓库贯穿全程。

第 1—2 周
看懂模型，建立基线
模型与 KV 状态 → 容量估算 → 性能分析。主资源：MIT 模型基础、CS336 资源核算与推理。产物：参考实现、正确性检查、性能基线。
第 3—4 周
完成量化、服务与负载测试
量化数值 → 模型压缩 → 推理服务 → 缓存与调度实验。主资源：MIT 量化、vLLM 短课。产物：可运行服务与质量、内存、性能对照报告。
第 5—6 周
理解编译接口，选择一个方向深入
图与形状约束 → 编译及运行时边界 → 一条关键调用路径。按方向使用 MLC、SGLang 或平台文档。产物：最小后端实验、源码记录与优化假设。
第 7—8 周
验证优化，完成稳定性与交付
一项改动 → 消融与退化分析 → 稳定性检查 → 环境复现与架构决策。产物：代码、配置、原始数据、ADR 与演示。

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

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

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

学习日	当天任务	完成标准与产物
第 1 天	完成先修自测，创建环境，运行小模型；固定权重、分词器、模板、精度与停止条件	保存环境清单与启动脚本；重启后能生成同一组测试输入的结果
第 2 天	看 MIT 第 12 讲，跟踪 Q/K/V、注意力、MLP 与 logits 的形状；整理约 30 个质量样本	画出一层 Transformer 的数据流，保存质量基线和判定规则
第 3 天	先用最小注意力模块，再用参考模型比较“每步重算完整前缀”与“使用 KV 缓存”；输入相同的 token 序列	按步检查 logits、缓存长度、位置索引与掩码；用明确的绝对/相对容差报告误差
第 4 天	看 CS336 第 2 讲，从配置读取层数、KV 头数与头维度，写权重/KV 容量估算器；改变上下文长度和批量	至少三个长度、两个批量的估算与实测表；解释额外内存来自哪里
第 5 天	检查单 token、不同前缀长度和掩码边界；刻意引入一次 KV 长度或位置错误，再定位修复	提交 `w01-reference`：代码、形状图、误差记录与容量表；独立解释 prefill/decode 的区别

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

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

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

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

学习日	当天任务	完成标准与产物
第 1 天	看 CS336 第 5、10 讲的相关部分，用算术强度与 Roofline 思路分析 prefill/decode；结合设备带宽、算力估计可能瓶颈	写下两条可被实验推翻的预测，并注明公式假设
第 2 天	给参考实现增加分阶段计时，区分加载、预热、prefill、decode；异步设备用适当同步或设备事件	得到可重复运行的基准脚本；解释测量边界与计时开销
第 3 天	扫描输入 128/512/2048 token、输出 32/128 token、批量 1/4 的组合；容量不足时缩小并记录	保存每组实际长度、延迟、吞吐量和内存；固定长度测试注明如何处理提前停止
第 4 天	选看 CS336 第 6 讲，使用 PyTorch Profiler 或平台工具捕获一个慢配置；沿主机、设备计算、搬运、同步寻找热点	保存执行轨迹，做一次只改变主要变量的对照，核对第 1 天预测
第 5 天	每组配置至少重复三次，汇总曲线、波动和异常；比较理论估算与实测	提交 `w02-baseline`：基准脚本、原始数据、执行轨迹与一页瓶颈报告

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

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

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

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

学习日	当天任务	完成标准与产物
第 1 天	读第 6.2.1—6.2.2 节，看 MIT 第 5 讲；比较 FP16/BF16 的表示，在小张量上实现 INT8/INT4 量化与反量化	复现正文 INT4 算例，增加中点舍入与超范围输入；解释数值范围、舍入和截断
第 2 天	看 MIT 第 6 讲，比较逐张量、逐通道和分组；计算权重与元数据容量，选读一篇算法论文的方法部分	保存包含权重、激活、KV、累加器、scale/zero-point 与 group size 的格式说明；复算 4.125 GB 示例
第 3 天	跟 vLLM 短课的压缩示例，依据目标引擎和硬件选择一种受支持的 PTQ 格式，需要校准时使用独立文本，导出模型产物	量化产物可在目标后端加载；保存算法、位宽、分组、校准集和版本配置
第 4 天	在同一后端、固定质量样本与第 2 周负载上比较参考精度模型和量化模型；确认反量化和实际计算发生在哪里	分别报告模型文件、加载后内存、生成峰值、质量与速度；记录实际内核及可确认的累加类型
第 5 天	分析失败样本，最多改一个主要因素，如校准数据或分组设置，再复测	提交 `w03-quant-report`：产物配置、失败样本、对照结果与采用/暂缓决定

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

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

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

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

学习日	当天任务	完成标准与产物
第 1 天	看 vLLM 短课的服务两节，先部署参考精度模型，再部署第 3 周的兼容量化产物；实现能记录流式响应的客户端	保存启动配置与客户端脚本，检查模板、停止条件及质量样本
第 2 天	跟课程跑通基准测试工具，再接入自己的固定请求集；在调优前写下实验用延迟目标	定义 TTFT、ITL、吞吐量、goodput 和错误的统计口径；流式响应的一个分块未必对应一个 token
第 3 天	读 CMU 服务调度讲义，分别测固定并发 1/4/8，以及逐步提高到达率的负载；检查客户端是否成为瓶颈	保存各负载的排队、延迟、吞吐量和错误；指出系统从何处开始过载
第 4 天	选看 MIT 第 15 讲，使用等长的共享/不同前缀请求，比较缓存关闭、冷缓存和命中；条件允许再单独测试分块预填充	记录实际缓存命中和配置，解释谁受益、谁可能退化；每次只改变一种机制
第 5 天	重启服务后复测，整理质量、容量、缓存与量化对照，选出后半程沿用的配置	提交 `w04-serving-report`：可复现服务、原始结果、负载曲线和基线配置

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

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

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

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

学习日	当天任务	完成标准与产物
第 1 天	看 MLC 第 1 课，沿已用引擎区分模型加载、图处理、运行时和设备内核；确认哪些步骤实际发生	画一张执行链，标明 eager、编译或委托执行的位置，不强行假设所有引擎都先导出整图
第 2 天	选一个小型 MLP 或无缓存的注意力模块，用 torch.export 导出并检查图与约束	保存导出代码，对照原模块验证输出；记录图中参数、算子与输入
第 3 天	为同一模块设置静态/动态形状，测试合法范围和越界输入	保存至少一个成功案例和一个约束失败案例，解释错误属于哪层
第 4 天	选看 MLC 第 9 课，用本机支持的 torch.compile 后端执行同一小模块，分开测首次编译与稳态；查看融合或回退信息	保存实际编译/执行证据；不能只凭“导出成功”判定已在目标设备执行
第 5 天	增加一个合法形状复测，解释输入输出和内存归属；结合已有瓶颈选择第 6 周分支	提交 `w05-backend-boundary`：最小代码、图、约束、误差与执行记录

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

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

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

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

学习日	当天任务	完成标准与产物
第 1 天	确定一个问题与比较对象：缓存策略、本地执行路径或小模块后端；列出固定条件	写出假设、预期收益、可能代价和最小验证范围
第 2 天	运行该方向的最小示例，复用前五周的模型、数据与测量方法	得到可重复的方向基线；跨格式或后端时先核对数值与模板差异
第 3 天	用断点、日志或性能轨迹跟踪一次请求/模块执行；找到状态创建、使用、释放的位置	保存带文件与函数名的调用链，标明调度、内存和设备边界
第 4 天	改一个可控参数，或在实验分支对一个小模块作最小改动；预测并观察行为	有正确性检查和实际执行证据，能解释改动怎样传到下游
第 5 天	在常规与边界负载下复测，判断最值得继续验证的瓶颈	提交 `w06-stack-study`：调用链、改动记录、对照结果和第 7 周优化假设

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

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

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

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

学习日	当天任务	完成标准与产物
第 1 天	选调度/缓存、加载/状态管理、算子/子图或投机解码之一；确定评价指标和停止条件	写下预期收益、额外内存/计算/维护成本，以及可能退化的负载
第 2 天	做最小正确性实验，再决定完整改动；涉及状态检查生命周期，涉及算子检查误差	保留可运行的正确性检查；投机解码另用小概率表验证接受、拒绝与修正分布
第 3 天	在选定项目中完成一处实现改动，或启用已有机制并补齐可观测性	保存补丁或配置差异、触发条件与执行证据
第 4 天	在一个预期受益负载和一个可能退化负载上做开关对照；计入额外开销	得到消融结果，解释质量、延迟、吞吐量与内存的共同变化
第 5 天	使用固定质量集复测，分析收益是否稳定，决定保留、缩小适用范围或回退	提交 `w07-optimization-report`：改动、原始结果、失败场景与技术决定

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

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

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

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

学习日	当天任务	完成标准与产物
第 1 天	整理依赖、模型与量化产物、编译/启动配置、质量集和基准脚本	形成一份固定版本的交付清单；说明设备、形状、精度与功能支持范围
第 2 天	服务路线检查取消、超时、过载和重启；本地路线检查内存压力与重复加载；编译路线检查形状边界和资源释放	保存失败与恢复记录，修复一项影响交付的问题，无法解决的列为限制
第 3 天	对代表负载做至少两小时连续运行，观察内存、延迟和错误趋势；端侧增加温升后的持续性能观察	提交稳定性曲线与异常记录；有条件再延长运行时间
第 4 天	在干净环境或新工作目录中按 README 重新安装、启动和运行评测，补齐遗漏步骤	一套可执行的复现流程，明确首次下载/编译与稳态成本
第 5 天	写一页 ADR，录制或现场做十分钟演示；脱离 AI 解释关键路径、瓶颈和取舍	提交 `final-adr.md`、工程包、演示与后续四周的一个深入主题

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

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

图 7 · 第 6 周的三条技术深入路线共享前五周的基础与评测方法；选择一条主线，将发现的瓶颈交给第七周验证。

路线 A · 推理服务请求 → 调度 → KV 管理
沿一次请求追踪队列、批次与缓存。比较一个调度或缓存行为，确定延迟与容量之间的取舍。
路线 B · 端侧与本地加载 → 内存 → 设备执行
沿模型加载和生成过程追踪权重、状态与设备分工。选择冷启动、内存或持续性能中的一个瓶颈。
路线 C · 编译与硬件图/IR → 计算内核 → 运行时
沿一个模块理解形状、布局、融合与搬运。选择一个编译变换、后端分区或内核展开实验。

路线	对应课程与实现入口	五天任务的具体落点
A：服务	SGLang 短课的推理优化与缓存部分；CMU 服务讲义；vLLM 架构说明	第 1—2 天在同一设备和可比配置上准备主引擎与一个对照；第 3 天追踪主引擎的调度/KV 路径；第 4 天改变批次预算或缓存条件；第 5 天解释长短请求下的差异。第二引擎难以安装时，改为主引擎两种策略的对照
B：本地	MIT Lab 5：笔记本上的 LLM 部署；llama.cpp 或 MLX LM 文档二选一	第 1—2 天固定模型来源与转换配置，测冷启动和生成；第 3 天追踪权重/KV 的创建与释放；第 4 天改变加载或设备执行配置；第 5 天比较内存与持续性能。有真实功耗测量能力时再报告能耗
C：编译	MLC 中文第 3 课 TensorIR 与第 9 课图优化；按需查 CMU 数据布局或 GPU GEMM；目标 SDK 的最小示例	第 1—2 天选一套 IR/内核工具运行小模块；第 3 天追踪布局、数据搬运和执行；第 4 天做一次融合、调度变换或分区调整；第 5 天验证误差与性能。有 NPU 时增加设备执行及回退检查，CPU 实验只报告 CPU 结果

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

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

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

场景	可以交给 AI 的具体请求	自己必须完成的检查
看课前后	“围绕今天的 KV 实验列出三个先修概念；根据这段讲义出三道检查题，先不要给答案。”	先独立画数据流或算容量，再对照讲义纠错
读源码	“基于这个提交，从请求入口追踪到状态释放，给出文件、函数与调用依据，标明不确定处。”	打开对应文件，用断点或日志验证一条实际路径
搭实验	“按这份负载与指标定义生成最小脚本，分离加载、预热和稳态，并保存原始结果。”	检查输入长度、同步、停止条件、统计分母和随机性；亲自运行
排错	“这是最小复现、环境与报错，请按可能性列出原因，每次给一个能区分原因的实验。”	一次改一个主要变量，记录哪些假设被证伪
分析结果	“只依据这份原始数据提出解释，再给出两个替代解释和区分实验；缺数据的地方列出来。”	回到日志和执行轨迹核对；无法归因时继续测量，不把推测写成结论
每周验收	“根据本周代码考我五个为什么，再给一个小改动或边界案例，暂不提供解答。”	关闭提示独立解释、修改并验证，找出仍依赖 AI 的薄弱环节

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

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

时间	应具备的能力	未通过时优先补什么
第 2 周末	能解释模型状态与主要内存，测出一个真实瓶颈	先修复正确性和计时；暂缓 Triton 选修
第 4 周末	能交付一个服务，比较量化、缓存与负载对质量和性能的影响	固定一种格式和一个后端，补齐基线与统计口径
第 6 周末	能读通一条关键路径，提出可验证的优化假设	缩小到一个状态对象、一个模块或一种策略；减少第二引擎比较范围
第 8 周末	能复现、解释优化取舍，并说明交付边界	优先补缺失的正确性、原始数据、失败恢复或复现步骤

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

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

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

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

阅读目的	建议时间	首选资料	第一遍需要回答的问题
注意力的访存开销	第 2 周选读	FlashAttention	哪些中间结果不再写回？分块如何保持计算语义？
调度与内存管理	第 4 周	Orca、PagedAttention	调度单位是什么？逻辑序列如何映射物理 KV？
缓存与结构化执行	第 6 周 A	SGLang 论文	缓存复用的条件是什么？前端需求怎样影响运行时？
量化	第 3 周，选一篇	GPTQ、AWQ、SmoothQuant	优化的误差对象不同在哪里？如何落到计算内核？
投机解码	第 7 周选做时	原始算法论文与所用引擎的实现文档	接受/拒绝规则怎样保持目标分布？草稿与验证成本何时能摊薄？
分阶段服务	八周后按需	DistServe、Mooncake	分离收益为什么可能超过传输成本？什么条件下不成立？
模型与系统协同	八周后按需	DeepSeek-V2	MLA 与 MoE 分别改变了哪些容量和计算假设？
一个引擎的源码	第 6 周	vLLM 架构或 llama.cpp	请求、状态、内存和设备执行在哪里交汇？
编译与部署接口	第 5 周	torch.export、ORT EP或 ExecuTorch	图的约束、分区与运行时之间有哪些接口约定？
编译器基础	第 5 周入门；第 6 周 C 深入	TVM、MLIR	同一个算子在不同层 IR 中保留了什么信息？
硬件与后端分支	第 6 周 C	目标平台的算子、编译、运行时、性能分析文档	能改哪一层？哪些问题需要硬件或 SDK 配合？

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

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

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

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

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

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