LLM 推理的训练-推理一致性工程 2026：从算子融合、激活回收到位元保真的生产闭环

一、问题的提出：当「同一个模型」变成「两个分布」

在 2024 至 2025 这一轮大模型推理工程的浪潮里，几乎所有讨论都被一个共同的问题牵着走：训练算力与推理算力之间的不对称。这一不对称的具体表现是，相同的权重文件在离线评测时 PPL 漂亮得无可挑剔，可是一旦搬到生产推理集群，长 context 推理就出现偶发性的 top-1 token 翻转、量化模型悄悄漂移、跨 GPU 厂商迁移时 Loss 表面看起来稳定但下游任务指标全面回退。这些现象背后有一个共同的工程命名，它不是「模型 bug」也不是「框架问题」，而是一类被统称为 training-serving skew（训练-推理 skew） 的数值层不一致。

本文想讨论的是这一不一致的工程闭环。Skew 不是某种可被一刀切消除的误差，而是一种由算子融合路径、activation 数值布局、kernel 选型三类底层因素共同决定的「位元保真」问题。当一篇论文声称某个 LLM 在 MMLU 上达到 78.4%，但生产上同时部署的 vLLM 与 TensorRT-LLM Engine 两条路径在某些条 prompt 上给出截然不同的生成时，问题并非模型的不确定性，而往往是两条推理路径在 transformer block 内部的某一层产生了足以改变 softmax 输出的数值差异。

我们的目标不是消除所有 skew——这一点在生产环境里既不可能也无必要。我们的目标是把这套不一致可量化、可观测、可在工程闭环上治理。本文将沿着「skew 是什么 → skew 的三类来源 → skew 沿什么维度放大 → 信息论视角下的位元保真上限 → 生产上能落地的五条具体措施 → SRE 侧的对齐仪表盘」这条线索，把训练-推理一致性的工程闭环彻底拆开。

二、形式化：把 skew 变成可度量的算子级量

对一个 transformer block 而言，训练路径与推理路径在算子图（operator graph）层面永远不是同一张图。训练图的每个 attention 层之后紧跟一个 dropout，而推理图把这个 dropout 当作恒等映射处理。这种结构性差异对最终 logits 的影响可以用下面的形式化定义来刻画。

设 $x$ 为某个算子的输入张量，$f_{\text{train}}(\cdot)$ 为训练图中对应算子的浮点实现，$f_{\text{infer}}(\cdot)$ 为推理图中对应算子的浮点实现，则该算子层的 skew 范数（skew norm）定义为：

这是一个无量纲的相对误差。当 $\rho(x) > 10^{-3}$ 时，说明单层算子的浮点实现已经在百分之一量级发生偏离；超过 $10^{-2}$ 时，相邻层的累积 skew 会在 30 层后放大至影响 top-2 token 的相对得分。

把整张网络的所有 skew 范数串起来，便得到一个 skew profile。对一个 LLaMA-3 类架构，skew profile 通常呈现「中段陡、两端平」的特征：embedding 层与最终 lm_head 层的 skew 较小（因为它们只是矩阵乘），但中间 transformer block 的 FFN gate 投影层与 attention QKV 投影层上 skew 最大，因为这些层通常被选作 fused kernel 的「融合边界」，不同的 fusion boundary 会改变 reduction 顺序从而改变 round-off 累积方向。

skew profile 的工程意义在于，它把抽象的「训练-推理不一致」转成了一张可在每个 release commit 上追踪的曲线。CI 流水线若能在每次模型权重导出时自动跑一次双路径推理的 skew profile，便能在权重进入生产前就发现某些层是不是悄悄换了 fusion 策略。

三、算子融合路径：Inductor、TorchCompile、TensorRT-LLM Engine 的三种偏差

同一组 PyTorch 算子被不同的编译器后端编译后，生成的 CUDA kernel 在 reduction 顺序、register pressure、tensor core 调度顺序上都会有微小差异，从而累积成可测的 skew。这是训练-推理 skew 的最大单一来源。

第一类路径是 PyTorch Eager，即不经过任何图编译直接 dispatch 到 ATen kernel。这种路径下每个 matmul 都对应一个独立的 cuBLAS 调用，每个 elementwise op 都对应一个独立的 elementwise CUDA kernel。Reduction 顺序由 cuBLAS 内部决定，与训练时的实现路径（一般是 DeepSpeed、FSDP、Megatron-LM 自带的 apex fused op）不一致。

第二类路径是 TorchInductor / TorchCompile，其代码生成器会把连续的 matmul + bias + activation 融合成一个 Triton kernel。具体到一个典型的 FFN gate 投影 y = gelu(x @ W^T + b)，Inductor 会把它编译成：

@triton.jit
def fused_gate_gelu(X, W, B, Y, M, N, K, stride_xm, stride_xk, ...):
    pid = tl.program_id(0)
    offs_m = pid * BLOCK_M + tl.arange(0, BLOCK_M)
    offs_n = tl.arange(0, BLOCK_N)
    a = tl.load(X + offs_m[:, None] * stride_xm + tl.arange(0, K)[None, :])
    b = tl.load(W + offs_n[None, :] * stride_wn + tl.arange(0, K)[:, None] * stride_wk)
    acc = tl.dot(a, b)               # FP32 accumulator
    acc = acc + tl.load(B + offs_n)
    acc = gelu(acc)                   # fused gelu
    tl.store(Y + offs_m[:, None] * stride_ym + offs_n[None, :], acc.to(tl.float16))

这个融合把本来三次独立的 kernel launch（matmul、bias add、gelu）变成一次 launch，整体上把 GPU kernel launch overhead 摊薄掉，但代价是 reduction 顺序被锁死在 Triton 编译器选择的策略上。Inductor 的 reduction 通常是 tl.dot 内部基于 TF32 tensor core 路径，按 K 维分块的树形 reduction。

第三类路径是 TensorRT-LLM Engine，它的 fusion 策略更激进。会进一步把 matmul + bias + gelu + quantize 融合到 cublasLt 的 epilogue 接口：

# TRT-LLM builder (简化)
config = trt.BuilderConfig()
config.set_flag(trt.BuilderFlag.FP16)
config.set_flag(trt.BuilderFlag.GELU_APPROX)
# 内部把 matmul + bias + gelu + INT8 quantize 链成一次 cuBLAS epilogue call
layer = network.add_matmul(x, w)
layer.bias = b
epilogue = trt.MatmulNode.Epilogue.GELU_BIAS

这种 epilogue 内部用的是 warp-level shuffle reduction，与 Triton 的 block-level reduction 在 round-off 累积顺序上有结构差异。Block-level reduction 一般是按 block 内的 32 线程分组合并，最后再做一次跨 block 的合并；warp-level shuffle 跳过中间步骤直接做跨 lane 的 butterfly。两者的累加顺序不一样，最终 fp16 输出末尾的 3-4 个 ulp（unit of least precision）会被打到不同的位元。

这就是 skew 的根部来源：不同 fusion 策略的 reduction 顺序不同，最后 fp16 输出末尾的几 bit 不可预测。这一不可预测性沿着 30-80 个 transformer block 累积，到最后一层 logits 时已经可能翻转 top-1 token（尤其在 top-2 logits 差距小于 0.1 的困难样本上）。

四、激活数值漂移：从 BF16 到 FP16 的 reduction 顺序

第二条 skew 通道是 activation 数值路径的不一致。激活值的中间表示（fp16 / bf16 / fp8 / int8）在不同推理后端的 cast 顺序不同，由此产生的 round-off 误差与符号误差是另一类主导来源。

第一组不一致是 fp16 vs bf16 的 reduction order。fp16 的尾数是 10 bit，bf16 是 7 bit，二者的可表达精度差距在 1024 倍以上。但更重要的是 bf16 的指数范围与 fp32 相同（8 bit），所以 bf16 在跨尺度数值稳定的场景下远优于 fp16。然而某些推理引擎在 tensor core 计算中默认按 fp16 + fp32 accumulator 的路径走，accumulator 内部做 fp32 累加，最后 cast 回 fp16 时引入一次截断。如果训练图走的是 bf16 路径而推理图走 fp16 路径，同样的 matmul 输出的 bf16 与 fp16 最后 1-2 个 ulp 不可预测地翻转。

第二组不一致是 chunked prefill 时序放大。vLLM 的 chunked prefill 把一个长 prompt 的 prefill 切成多个 chunk，逐个推入 transformer。这意味着每个 chunk 结束时其 KV cache 已经被写入，下一个 chunk 的 attention 输出会读到上一个 chunk 已经写入的 KV，而训练时则是把整个 prompt 一次性处理。这种时序差异会让 chunked prefill 在长 context 上累积一个「KV 时序 skew」，表现为 PPL 随着 chunk 数线性增长，到 4K-8K token 时已经比一次性 prefill 差 0.05-0.1 PPL 单位。

第三组不一致是 activation layout 的物理差异。训练时 activation 是「行主序 + contiguous」，推理时为了高效融合 kernel 可能被重新排成「块主序 + padded」。这种 layout 差异在 matmul 内部不会造成数值差异（因为它是 GEMM 输入排列而不是数值差异），但在 elementwise op 上会把 round-off 引入不同的 lane 顺序。一个最常见的现象是 RMSNorm 的 reduction：训练时按 row sum 实现，推理时按 block sum 实现，二者的浮点累加顺序不同，输出的最后 1 个 ulp 不可预测。

把这三条通道耦合在一起，「skew」就开始显现出生产可观测的特征：长 context 推理的 PPL 漂移 0.05-0.1 个单位、短 context 推理不受影响、跨 GPU 厂商迁移时漂移加剧、跨 quantization 方案（FP8 / INT8 / INT4）漂移非线性放大。这些特征在 vLLM、TensorRT-LLM、SGLang、llama.cpp 上都能复现，且量化版本越激进漂移越大——这是因为每一层量化都会引入额外的 round-off 误差，skew 通道在最后一层被 multiplier 放大。

五、KV cache 与 attention impl 的跨厂商 skew

第三条 skew 通道发生在 KV cache layout 与 attention kernel 选型上。这是被讨论得最少的一类，但对长 context 推理的实际影响可能比前两类更大。

KV cache 在 GPU 上的物理布局有至少四种主流形态：

1. [batch, head, seq, dim] 连续张量（HuggingFace 训练态默认布局）
2. [batch, seq, head, dim] 重组布局（vLLM PagedAttention 早期版本）
3. paged KV block 列表（vLLM 0.4+ 默认 PagedAttention，KV block size 16）
4. fp8 / int4 量化 KV block（TensorRT-LLM Engine 的 KV cache quantization）

不同布局在 attention kernel 上对应不同 memory access pattern。layout 1 + 2 对应标准 FlashAttention（按 (Q, K, V) 三元组一并读入 on-chip SRAM），layout 3 对应 PagedAttention（按 paged table 索引跳着读 K/V），layout 4 对应 quantized FlashAttention（先反量化再算 attention）。三种 attention impl 在数值上有结构差异：

• 标准 FlashAttention v2 使用 tl.dot 的 standard precision 路径（fp16 inputs / fp32 accumulator / fp16 output）
• FlashAttention v3 支持 FP8 GEMM + warp-specialization，accumulator 可选 fp32 或 fp16
• xformers 的 memory_efficient_attention 在 cutlass 3.x 上用 FMA 替代 fp32 accumulator，直接 fp16 累加
• cuDNN SDPA 在 A100/H100 上的 accumulator 策略是 fp32 强制，H800 之后允许 fp16

这些 accumulator 策略的差异让一段相同的 prompt 在四种 attention impl 下，前 8 个 token 的 hidden state 输出最后一 bit 都可能翻转——而 top-2 logits 的差距恰好就在这一 bit 上。

更隐蔽的一点是 causality mask 的实现差异。训练图里 causality mask 是按 q_idx >= kv_idx 的 broadcast 比较做的，推理图里 PagedAttention 的 causality 是通过 block-level 偏移 + remaining mask 联合做的。当 prompt 长度恰好落在 PagedAttention block 边界（默认 16）附近时，mask 的浮点比较结果可能在两种 impl 之间翻转 1 个 token。这一翻转会让模型在前几个生成 token 上产生偶发性的「跳变」，生产上表现为用户报告的「同一个问题不同时候答得不一样」。

最后一个相关来源是 rope / rotary embedding 的实现差异。LongRoPE、NTK-aware、YaRN 这些长 context 位置编码方案在不同推理后端里复现精度有差异。一个常见的 bug 模式是 rotary 的 sin/cos 在算 cos(2π * pos / θ) 时用 fp32 算而 inv_freq 在 bf16 下离散化。训练时一律 fp32 没有问题，但推理后端如果做了一致性优化把这部分强行 bf16，那么 64K context 的 PPL 会比训练态高 0.3-0.5 个单位。

六、统一视角：把 skew 当作「位元保真」问题

如果把训练-推理的关系提炼成一个信息论通道，训练图相当于编码器（encoder），推理图相当于解码器（decoder），skew profile 给出该通道在不同频率分量上的加性噪声谱。这一框架把零散的几类 skew 来源统一成同一个视角：在有限 bit 宽（fp16 / bf16 / fp8 / int8）下，没有办法同时实现「与训练图 bit-exact」与「足够吞吐」这两个目标。所以训练-推理 skew 是一个信道容量问题，不是某种可被消除的 bug。

设训练态算子的浮点实现为 $f_t$，推理态算子的浮点实现为 $f_i$，两者在概率意义上被同一个输入 $x$ 采样时，输出差异的方差是：

要保证推理 logits 与训练 logits 的 top-1 翻转概率低于 $\epsilon$，等价于要求最后一层 logits 上的 skew 累积方差低于 $(\delta/2)^2$，其中 $\delta$ 是训练时 top-1 与 top-2 的差距中位数。一个粗略上界是，80 层 transformer 的累积方差可以被建模为独立同分布的累加，方差上界为 $80 \cdot \sigma^2$。所以要满足 top-1 翻转概率低于 0.01，需要 $\sigma^2 < \delta^2/(4 \cdot 80 \cdot z_{0.99}^2)$。$\delta$ 一般在困难 prompt 上是 0.05，对应要求 $\sigma < 0.001$。

把这一数值代入实际推理引擎，可以看到为什么在生产上没有「零 skew」这件事：当某一层 fusion 路径变化会引入 fp16 上的 1 ulp（约 $10^{-3}$ 相对误差）时，单层就接近极限。真正的工程问题是把 skew 累积方向控制在不放大 top-1 翻转概率的位置——具体的方法就是下面这五条具体的工程推论。

七、工程推论：从算子到生产管线的可执行清单

推论一：建立 dtype/layout 一致性审计管道。CI 流水线在每次模型权重导出后，自动用同一条 prompt 在三条推理路径（PyTorch Eager、TorchCompile、TRT-LLM Engine）上跑推理，记录每层的 skew 范数与最后一层 logits 的 top-1/2 翻转率，超过阈值（如 $\rho > 10^{-3}$ 超过 3 层）则拦截发布。每个 release 都跟踪这一 profile，绘图成 release delta。审计管道用 Python + 自家 dump 的 activation tensors 实现，初期成本低，长期回报远超一次性投入。

推论二：长 context 推理的 chunked prefill + KV 时序 skew 监控。把 chunk 数量与 PPL 漂移做成 metric（chunk_count, ppl_drift），实时追踪。当 8K context 推理的 ppl_drift 超过 0.1，应触发自动 prefill 时序调整（如回退到一次性 prefill 或调小 chunk size）。这一项可作为 vLLM / SGLang 的内置 metric，长期在生产中复现。

推论三：量化感知训练与推理 dtype 路径绑定。INT8 / FP8 量化必须在训练期间做 fake-quantize 模拟推理后端的算子融合路径，让训练时的 skew profile 与推理时一致。这意味着训练侧的 quantization-aware training 必须明确指定目标推理后端的 fusion 边界（Inductor / TRT-LLM / llama.cpp / MLC-LLM），并使用同一套 reduction order。如果融合边界不匹配，量化模型的 PPL 漂移会比 BF16 推理大 5-10 倍。

推论四：跨 GPU 厂商的 bias 漂移治理。NVIDIA H100 / H800 / A100 / L40S 之间的 tensor core accumulator 策略有微妙差异，AMD MI300X 在 fp16 GEMM 上与 NVIDIA 的 reduction order 也不同。从 H100 迁移到 H800 或 MI300X 会引入 fp16 路径上的 1-2 ulp 偏差，这一偏差会在某些层累积到不可忽略。对跨厂商迁移，每次必须重新跑一次双路径 skew audit，并在 bias 校准表里加入「厂商 + 推理后端 + dtype」的标注，否则下游任务指标的回退无法定位原因。

推论五：算子替换的灰度对照体系。当生产上需要替换某个 transformer block 的算子（如升级 attention impl）时，不应一次性全量替换。建议在 5% 流量上双路径并行推理（dual-path），实时对比两条路径的 top-1/2 翻转率与下游任务指标。一周稳定后再放量至 100%。这条推论也是规避「算子替换-量化漂移-skew 放大」三连环的可靠工程方法。

推论六：长 context 推理的 prefill 时序侧通道观测。除了主路径的 top-1 翻转率监控，生产上还可以从 prompt 提示词的最后一个 token 起，反向构造「逆序重写 prompt」对照：对同一个 prompt 的若干 token 做随机 mask 让模型补全，再构造一个「先 mask 后补全」的反序版本，让模型自行校对补全是否一致。这一对照在长 context 推理上对 chunked prefill 时序 skew 的响应极其敏感——当 chunked prefill 时序累积了显著 skew，逆序版本上的补全方差会比正常版本高出 1 个数量级。这一方法的好处是无需访问训练态 ground truth，便可在生产流量里建立稳定的 skew proxy 监控。

推论七：tokenizer 与 lm_head 的字面一致性审计。除了算子路径，还有一类容易被忽略的 skew 来源是词表层面：训练态 tokenizer 与推理端分词器在 Unicode normalization、byte-level BPE 处理、特殊 token 注入上的微小差异会让模型接收到与训练时不一致的 token 序列。这类 skew 通常表现为 top-1 token 翻转但是 logits 差距很小（小于 0.02）。生产上应当把 tokenizer 版本、Unicode 规范化策略、特殊 token 序列作为元数据纳入每一次推理请求的 trace 头，便于出现「同模型不同响应」时快速归因。

推论八：skew 与下游任务指标的因果归因。当生产上遇到下游任务指标（如 RAG 召回率、Code 编译通过率）回退时，第一反应不应是「换模型」。应当先调出 trace 中该请求的推理后端版本、量化 dtype、上下文长度、batch 大小四元组，对照过去 30 天同一四元组的基线分布。如果分布显著偏移（如某后端占比从 20% 上升到 60%），大概率是 skew 问题，不是模型问题。这条推论尤其适用于多推理后端混部（vLLM + TRT-LLM + SGLang 混合）的生产环境。

推论九：推理 ops 的 skew-aware autoscaling。常规 autoscaling 只看 QPS 与延迟。skew-aware autoscaling 把「不同推理后端的覆盖比例」也作为一个指标维度，防止长尾推理路径的覆盖比例突然下跌而又被上层 QPS 平均掩盖。当某条推理后端（如 TensorRT-LLM Engine for INT8 路径）的覆盖比例从 30% 跌到 5% 而被自动忽略，则该路径积累的 skew 可能在某次 GPU 升级后被一次性放大。生产上应把后端覆盖比例做成 SLO，让它保持稳定。

八、讨论与局限

训练-推理一致性的工程治理不是「修一处补一片」的零散修补，而是一个跨图编译、算子融合、KV cache 布局、量化路径、GPU 厂商差异的多维耦合问题。在工程现实里我们能做的，是把不可控的因素可观测化。

必须承认几点局限。第一，数值方法与硬件决定的不可压缩性——例如 fp16 GEMM 在不同 reduction order 下的 round-off 累积方向不可预测地翻转最后 1-2 ulp，这部分是浮点数学本身的性质，没有工程方案能完全消除。第二，硬件 GPU / NPU 的 accumulator 策略是厂商内部细节，不一定公开文档，未来跨硬件推理一致性很难事先知道。第三，超大规模推理服务（如 100K context 或更长）下的 skew 累积仍未被充分研究，已知经验大多停留在 8K-32K context。64K-128K 的长 context 工程闭环需要持续追踪。

第二个局限是 skew 治理与吞吐优化的目标张力。融合 kernel 越激进（更多 epilogue、更少 launch overhead）数值路径越偏离训练图，skew 越大。在某些吞吐关键的场景（如 7B / 13B 模型在线服务），这一权衡迫使工程团队必须选「更激进融合 + 接受更大 skew」或「保守融合 + 训练-推理更一致」中的一个。生产上没有 free lunch。

最后一个限制是 「零 skew 推理」不存在的工程现实。即便把本文列出的所有工程措施都贯彻到位，跨 GPU 厂商 / 推理后端 / 量化路径的最后 1 bit 翻转依然是不可避免的。生产团队需要把这一不可消除的不确定性纳入 SLO 设计——例如下游任务指标的回退容忍度应以 1-3 sigma 区间覆盖，而非要求「完全一致」。

九、给 SRE / 推理平台工程师的可观测性清单

第一条：双路径推理对照面板。生产环境长存一个 5% 流量的小流量金丝雀集群，强制跑与主集群不同的推理后端（如主集群 vLLM，金丝雀 TensorRT-LLM Engine）。两条路径的 top-1 翻转率、生成任务下游指标的 delta，作为实时 dashboard 的核心指标，1 分钟级刷新。

第二条：per-layer skew 监控。CI 流水线内的 skew profile，跑成每次 release 必出的报告。当任意一层 $\rho > 5 \times 10^{-3}$ 出现次数 > 5 层时，自动告警，要求推理平台工程师 review 是否引入了非预期的算子替换。

第三条：长 context PPL 漂移矩阵。对 1K / 2K / 4K / 8K / 16K / 32K / 64K / 128K 八个 context 档位做推理 PPL 漂移监控。在线推理不能跑 PPL，但可以跑 top-1 entropy / top-1 vs top-2 margin 分布作为代理指标。漂移显著时回滚到上一次稳定 release。

第四条：跨 GPU 厂商 skew audit。任意从 NVIDIA H 系列迁移到 H800 / B100 / B200 / MI300X 之前，必须跑一次完整 skew profile。当迁移后某些层的 $\rho$ 显著高于 baseline（如 > 2 倍），要在生产灰度阶段加入「厂商 + dtype」标注的 bias 漂移监控。

第五条：chunked prefill 时序监控。vLLM / SGLang 的 chunked prefill 调度参数 (chunk_size, max_num_seqs) 变化必须在 SLO 仪表盘追踪 PPL 漂移。chunk size 减小会降低长 context 推理吞吐，但会降低时序 skew。生产上有一个 sweet spot，需要结合 SLO 找到。

把这五条置于每月一次的 release review 与每周一次的 oncall 复盘里，训练-推理一致性治理就从「模型团队的偶发性事故」转成「推理平台团队的常态化能力」。

参考文献

1. PyTorch Team, "torch.compile: A compiler to speed up PyTorch models," 2023, https://pytorch.org/blog/introducing-torchcompile/
2. Tri Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness," NeurIPS 2022.
3. Tri Dao, "FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision," 2024.
4. Woosuk Kwon et al., "vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention," SOSP 2023.
5. NVIDIA, "TensorRT-LLM: A TensorRT Toolbox for Large Language Models," GitHub repository, 2023-2024.
6. B. Lefaudeux et al., "xformers: A modular and hackable transformer modelling library," GitHub repository, 2021.
7. J. Rasley et al., "DeepSpeed: System Optimizations Enable Training Deep Learning Models with over 100 Billion Parameters," KDD 2020.
8. M. Shoeybi et al., "Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism," 2019.
9. PyTorch Team, "Automatic Mixed Precision documentation," 2024.
10. NVIDIA, "cublasLt documentation: Matmul epilogue fusion," 2023.
11. Y. Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration," 2023.
12. T. Dettmers et al., "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale," NeurIPS 2022.
13. B. Spector et al., "PagedAttention v2: KV cache paging for long-context inference," 2024.
14. S. Rajbhandari et al., "ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning," SC 2021.
15. OpenAI, "Scaling Laws for Neural Language Models," 2020.
16. Y. Leviathan et al., "Fast Inference from Transformers via Speculative Decoding," ICML 2023.
17. X. Miao et al., "SpecInfer: Accelerating Generative LLM Serving with Speculative Inference and Verified Trie," NSDI 2024.
18. NVIDIA, "FP8 Formats for Deep Learning," Hopper Architecture Whitepaper, 2023.
19. PyTorch Team, "torch.compile with Inductor backend," Documentation, 2024.
20. Y. Sheng et al., "FlexFlow: A Flexible Dataflow Accelerator Architecture for Sparse Deep Learning," 2020.
21. L. Zheng et al., "Alpa: Automating Inter- and Intra-Operator Parallelism for Distributed Deep Learning," OSDI 2022.
22. D. Narayanan et al., "Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM," SC 2021.

一句话摘要：训练-推理 skew 不是 bug，是一种由算子融合、activation 数值与 KV 布局三类路径决定的位元保真问题；生产上把双路径对照、per-layer skew 监控、长 context PPL 矩阵、跨 GPU 厂商审计、chunked prefill 时序追踪这五条可观测措施落到 CI 与 SRE 仪表盘上，才能把它从偶发事故变成常态化的工程治理能力。