第17周：推理系统与加速

先说人话

先说人话：一张卡装不下或算不完时，把参数、样本和流水阶段分给多张卡。

学习大模型并行训练先明确它解决的瓶颈，再判断是否值得引入；名称相似不代表机制相同。

机制拆开

一张卡装不下或算不完时，把参数、样本和流水阶段分给多张卡。数据并行复制模型分样本，张量并行拆一次矩阵运算，流水线并行拆网络层，专家并行只把被路由到的专家分散出去。

分析大模型并行训练时沿输入、状态、计算或检索、输出四步画数据流，并把成本落到时间、显存、带宽或质量指标。

边界与取舍

并行度越高不等于越快；通信、气泡、负载不均和故障恢复会吞掉收益。先用显存、计算量和互联带宽定位瓶颈，再选择组合。

评价大模型并行训练必须附工作负载、硬件或模型、版本和测量口径；没有这些条件的“更快”“更准”不能直接用于选型。

落地检查

把大模型并行训练放进真实系统前，先保存未改动方案的原始数据，再按单一变量引入改动。评估大模型并行训练不能只看平均值，还要记录尾延迟、资源峰值、异常输入和失败恢复。

复盘大模型并行训练实验时，要能回答三个问题：改善来自哪一步，代价转移到了哪里，指标不达标时如何停止并回滚。这样得到的大模型并行训练结论不是一张漂亮截图，而是一份别人可以复核的工程证据。最后还要把大模型并行训练的配置、版本、样本和原始输出一起保存，确保换一个人也能重复同样的检查。

上线前再为大模型并行训练安排一次反向评审：让没有参与实现的人只看记录复现实验，并主动寻找会推翻结论的输入。如果大模型并行训练复现失败，就先补证据而不是扩大部署范围。

先说人话

先说人话：模型代码最终会变成加法、矩阵乘法、归一化等算子组成的计算图。

学习算子与计算图先明确它解决的瓶颈，再判断是否值得引入；名称相似不代表机制相同。

机制拆开

模型代码最终会变成加法、矩阵乘法、归一化等算子组成的计算图。框架根据依赖安排执行，编译器通过融合、常量折叠和内存规划减少调度与搬运成本。

分析算子与计算图时沿输入、状态、计算或检索、输出四步画数据流，并把成本落到时间、显存、带宽或质量指标。

边界与取舍

图优化必须保持数值语义；动态形状、数据相关控制流和自定义算子会限制编译。融合也可能增加寄存器压力，不能只看算子数量。

评价算子与计算图必须附工作负载、硬件或模型、版本和测量口径；没有这些条件的“更快”“更准”不能直接用于选型。

落地检查

把算子与计算图放进真实系统前，先保存未改动方案的原始数据，再按单一变量引入改动。评估算子与计算图不能只看平均值，还要记录尾延迟、资源峰值、异常输入和失败恢复。

复盘算子与计算图实验时，要能回答三个问题：改善来自哪一步，代价转移到了哪里，指标不达标时如何停止并回滚。这样得到的算子与计算图结论不是一张漂亮截图，而是一份别人可以复核的工程证据。最后还要把算子与计算图的配置、版本、样本和原始输出一起保存，确保换一个人也能重复同样的检查。

上线前再为算子与计算图安排一次反向评审：让没有参与实现的人只看记录复现实验，并主动寻找会推翻结论的输入。如果算子与计算图复现失败，就先补证据而不是扩大部署范围。

先说人话

先说人话：自回归生成每次只新增一个 Token，但旧 Token 的注意力键和值不会改变。

学习KV Cache先明确它解决的瓶颈，再判断是否值得引入；名称相似不代表机制相同。

机制拆开

自回归生成每次只新增一个 Token，但旧 Token 的注意力键和值不会改变。KV Cache 保存这些中间结果，避免每一步重算整段上下文，用显存换取解码速度。

分析KV Cache时沿输入、状态、计算或检索、输出四步画数据流，并把成本落到时间、显存、带宽或质量指标。

边界与取舍

缓存大小随层数、序列长度、批量和 KV 头数增长；长上下文可能先把显存吃满。它减少重复计算，却不消除新 Token 对历史 KV 的读取。

评价KV Cache必须附工作负载、硬件或模型、版本和测量口径；没有这些条件的“更快”“更准”不能直接用于选型。

落地检查

把KV Cache放进真实系统前，先保存未改动方案的原始数据，再按单一变量引入改动。评估KV Cache不能只看平均值，还要记录尾延迟、资源峰值、异常输入和失败恢复。

复盘KV Cache实验时，要能回答三个问题：改善来自哪一步，代价转移到了哪里，指标不达标时如何停止并回滚。这样得到的KV Cache结论不是一张漂亮截图，而是一份别人可以复核的工程证据。最后还要把KV Cache的配置、版本、样本和原始输出一起保存，确保换一个人也能重复同样的检查。

上线前再为KV Cache安排一次反向评审：让没有参与实现的人只看记录复现实验，并主动寻找会推翻结论的输入。如果KV Cache复现失败，就先补证据而不是扩大部署范围。

先说人话

先说人话：多次请求共享完全相同的前缀时，可以复用前缀已经算好的 KV 块。

学习Prefix Cache先明确它解决的瓶颈，再判断是否值得引入；名称相似不代表机制相同。

机制拆开

多次请求共享完全相同的前缀时，可以复用前缀已经算好的 KV 块。它适合固定系统提示、公共文档或多轮会话开头，命中后缩短首 Token 等待。

分析Prefix Cache时沿输入、状态、计算或检索、输出四步画数据流，并把成本落到时间、显存、带宽或质量指标。

边界与取舍

只有 Token 序列与影响计算的模型配置一致才可复用；看起来相同的文本可能因模板、空格或特殊 Token 不同而失配。缓存淘汰与租户隔离同样重要。

评价Prefix Cache必须附工作负载、硬件或模型、版本和测量口径；没有这些条件的“更快”“更准”不能直接用于选型。

落地检查

把Prefix Cache放进真实系统前，先保存未改动方案的原始数据，再按单一变量引入改动。评估Prefix Cache不能只看平均值，还要记录尾延迟、资源峰值、异常输入和失败恢复。

复盘Prefix Cache实验时，要能回答三个问题：改善来自哪一步，代价转移到了哪里，指标不达标时如何停止并回滚。这样得到的Prefix Cache结论不是一张漂亮截图，而是一份别人可以复核的工程证据。最后还要把Prefix Cache的配置、版本、样本和原始输出一起保存，确保换一个人也能重复同样的检查。

上线前再为Prefix Cache安排一次反向评审：让没有参与实现的人只看记录复现实验，并主动寻找会推翻结论的输入。如果Prefix Cache复现失败，就先补证据而不是扩大部署范围。

先说人话

先说人话：模型输出的是下一个 Token 的概率分布。

学习采样与解码策略先明确它解决的瓶颈，再判断是否值得引入；名称相似不代表机制相同。

机制拆开

模型输出的是下一个 Token 的概率分布。贪心每次拿最大值，temperature 调整分布尖锐程度，top-k 与 top-p 截断候选；这些开关共同决定稳定性、多样性和可复现性。

分析采样与解码策略时沿输入、状态、计算或检索、输出四步画数据流，并把成本落到时间、显存、带宽或质量指标。

边界与取舍

参数没有跨任务的万能值。把 temperature 设为零也不保证整个服务绝对确定，批处理、数值精度和后端实现仍可能带来差异。

评价采样与解码策略必须附工作负载、硬件或模型、版本和测量口径；没有这些条件的“更快”“更准”不能直接用于选型。

落地检查

把采样与解码策略放进真实系统前，先保存未改动方案的原始数据，再按单一变量引入改动。评估采样与解码策略不能只看平均值，还要记录尾延迟、资源峰值、异常输入和失败恢复。

复盘采样与解码策略实验时，要能回答三个问题：改善来自哪一步，代价转移到了哪里，指标不达标时如何停止并回滚。这样得到的采样与解码策略结论不是一张漂亮截图，而是一份别人可以复核的工程证据。最后还要把采样与解码策略的配置、版本、样本和原始输出一起保存，确保换一个人也能重复同样的检查。

上线前再为采样与解码策略安排一次反向评审：让没有参与实现的人只看记录复现实验，并主动寻找会推翻结论的输入。如果采样与解码策略复现失败，就先补证据而不是扩大部署范围。

先说人话

先说人话：先让便宜的草稿模型连续提出几个 Token，再由目标模型一次并行核验。

学习投机解码先明确它解决的瓶颈，再判断是否值得引入；名称相似不代表机制相同。

机制拆开

先让便宜的草稿模型连续提出几个 Token，再由目标模型一次并行核验。被接受的草稿直接使用，被拒位置按目标分布纠正，因此在正确算法和采样条件下不改变目标分布。

分析投机解码时沿输入、状态、计算或检索、输出四步画数据流，并把成本落到时间、显存、带宽或质量指标。

边界与取舍

加速取决于草稿接受率和两模型成本差；草稿不准或目标模型已很小，核验开销可能得不偿失。不能把直接采用草稿结果冒充投机解码。

评价投机解码必须附工作负载、硬件或模型、版本和测量口径；没有这些条件的“更快”“更准”不能直接用于选型。

落地检查

把投机解码放进真实系统前，先保存未改动方案的原始数据，再按单一变量引入改动。评估投机解码不能只看平均值，还要记录尾延迟、资源峰值、异常输入和失败恢复。

复盘投机解码实验时，要能回答三个问题：改善来自哪一步，代价转移到了哪里，指标不达标时如何停止并回滚。这样得到的投机解码结论不是一张漂亮截图，而是一份别人可以复核的工程证据。最后还要把投机解码的配置、版本、样本和原始输出一起保存，确保换一个人也能重复同样的检查。

上线前再为投机解码安排一次反向评审：让没有参与实现的人只看记录复现实验，并主动寻找会推翻结论的输入。如果投机解码复现失败，就先补证据而不是扩大部署范围。

先说人话

先说人话：Prefill 一次处理整段输入，计算密集并决定首 Token 延迟；Decode 每步生成一个 Token，频繁读取 KV，往往受内存带宽影响。

学习Prefill/Decode 分离先明确它解决的瓶颈，再判断是否值得引入；名称相似不代表机制相同。

机制拆开

Prefill 一次处理整段输入，计算密集并决定首 Token 延迟；Decode 每步生成一个 Token，频繁读取 KV，往往受内存带宽影响。分开调度可给两阶段配置不同实例与批处理策略。

分析Prefill/Decode 分离时沿输入、状态、计算或检索、输出四步画数据流，并把成本落到时间、显存、带宽或质量指标。

边界与取舍

分离会引入 KV 传输、排队和容量匹配问题。吞吐提高不代表首 Token 与逐 Token 延迟同时改善，必须分别测 TTFT、TPOT 和端到端延迟。

评价Prefill/Decode 分离必须附工作负载、硬件或模型、版本和测量口径；没有这些条件的“更快”“更准”不能直接用于选型。

落地检查

把Prefill/Decode 分离放进真实系统前，先保存未改动方案的原始数据，再按单一变量引入改动。评估Prefill/Decode 分离不能只看平均值，还要记录尾延迟、资源峰值、异常输入和失败恢复。

复盘Prefill/Decode 分离实验时，要能回答三个问题：改善来自哪一步，代价转移到了哪里，指标不达标时如何停止并回滚。这样得到的Prefill/Decode 分离结论不是一张漂亮截图，而是一份别人可以复核的工程证据。最后还要把Prefill/Decode 分离的配置、版本、样本和原始输出一起保存，确保换一个人也能重复同样的检查。

上线前再为Prefill/Decode 分离安排一次反向评审：让没有参与实现的人只看记录复现实验，并主动寻找会推翻结论的输入。如果Prefill/Decode 分离复现失败，就先补证据而不是扩大部署范围。