同一个权重、同一张卡，答案却不一样：本地部署大模型的精度风险与银行验证清单

一个反直觉的实验结论

先说结论，因为它决定了后面所有的推论。

原帖作者 thr3e 在 RTX PRO 6000 Blackwell 上跑 Qwen3.6-27B，把 attention backend 从 Triton 换成 FlashAttention 2——这一个配置项，同一张卡、同一套驱动、同一个 vLLM 构建、同一份权重、同一段提示词、同样的 KV cache 设置——模型在一个真实的 Cisco 工具调用场景里，把目标接口从 GigabitEthernet0/0/1.201 写成了 GigabitEthernet0/1/4。

然后它执行了那条错误命令，而且在两个已经分叉的分支里又执行了一遍。正确答案是 show mac address table（按 MAC 地址查归属），FlashAttention 2 试图用 show run 把自己从那个 token 翻转造成的麻烦里捞出来。

作者在原话里把后果说得很直接：

"If a simple runtime difference in cuda kernels caused this to happen in production, it could result in a critical network outage."

更重要的是：这个偏移不是随机噪声。他做了同 backend 重复运行的对照实验，结果是每一个隐状态位置的 logits 逐 bit 相同。也就是说，差异完全来自 prefill 阶段矩阵乘法和加法的执行路径，而非采样随机性。

这一点必须记清楚：你的本地大模型"变笨了"，很可能不是模型的问题，也不是温度的问题，而是你换了配置。

为什么同一份权重会给出不同的答案

这不是玄学，是浮点运算的基本性质。

原帖 Part 1 花了很多篇幅铺垫这件事的技术背景。"logits" 是模型给每个候选 token 的打分，归一化成概率后经过采样器，再由 detokenizer 转成文本。问题在于：不同的 CUDA kernel 在做同一个矩阵乘法时，归约（reduction）的顺序不同。浮点加法不满足结合律，先加后加再相加，与先加两个再加第三个，结果可以不同。这个差异极小——通常在 1e-7 量级——但当两个候选 token 的 logit 接近时，这个微小差异足以翻转 argmax。

作者用 Qwen3.6-27B 做了一个值得注意的实验设计。这个模型是 dense 的，但它是混合架构：64 层按"Gated DeltaNet / 线性注意力三层 + 一层全注意力"重复排列。也就是说，只有 16 层全注意力层会走可切换的 attention backend，GDN 路径保持固定。这让实验变量更干净——差异确实只来自那 16 层。

他的工作量负载用的是 "Prompt 2"：一段约 100k token 的真实工作流上下文，包含多个工具调用和真实产出。这个负载刻意避开了所有公开基准和训练数据集——他的原话是："Nobody could have benchmaxed for this, or calibrated their quant to accommodate it."（没人能针对它刷榜，也没人能为它校准量化参数。）

这个设计对银行有直接借鉴意义，后面第五节会展开。

Part 1：三组实验的发现

实验一：切换 attention backend

在 100k token 上下文中，每 32 个 prompt token 采集一次全词表 logits（BF16 存储，事后在 FP64 下计算分布距离）。测试三个可用的全注意力 backend：FlashAttention 2、Flash Inference、Triton Attention。

结果有三个形态：

1. 前几千 token 三者完全一致——分歧不是从一开始就有的。
2. 分歧成簇出现，并且随提示词内容变化，而不是随上下文长度平滑增长。
3. 这一点尤其重要：它不存在一个"模型在多少 token 后崩溃"的临界点。不能指望"控制上下文长度就避开了这个风险"。

原帖只报告了 logits 层面 3% 抽样采样的结果——作者在第 10 楼主动承认这个方法不正确，只用于看大图，因此 Part 2 改为在工具调用区采集 100% logits。

实验二：只量化 KV cache

权重和激活保持 BF16 不变，只把 KV cache 量化。

• BF16：正常。
• INT8 KV cache：出错，但最终能自我恢复。
• INT4 KV cache：没能恢复。

原帖这一节的标题直接叫 "why your LLM's IQ drops like a rock after 40k tokens"。

实验三：五种权重/激活精度对比

这是对银行选型最有参考价值的一组实验。五个候选：

结果：

• BF16、FP8、INT8 W8A16、AWQ W4A16 都正确完成了工具调用。
• 只有 NVFP4 失败，到 88k 上下文时约 50% 的 token 翻转率，在五个候选里垫底。
• NVFP4 和 AWQ 这两个 W4A16 都无法正确闭合工具调用，并且把 Cisco 命令行语法搞错了——正确命令是 show arp，它们执行的是 show run。

这里有两个反直觉的细节，恰恰是银行选型时最容易踩的坑。

第一，"官方"不等于"在你的卡上原生执行"。 NVFP4 名字里的 "NV" 和 "FP4" 暗示原生 FP4 算术，但作者明确写道：在他的 SM120 上游 nightly 运行中，vLLM 判定该 GPU 路径缺乏原生 FP4 支持，显式选择了通过 Marlin 的纯权重 FP4 压缩。也就是说，你拿到的是一个"FP4 格式的权重"，但它在你的硬件上跑的是权重-only 的模拟路径。

同样地，官方 FP8 checkpoint 在同一张卡上，DeepGemm 被自动禁用——vLLM 把它的 E8M0 scale 格式标记为对该架构（SM120）降精度，改选了 CUTLASS。而且官方 FP8 的公开文件里没有可识别的校准数据集。

结论：同一个"FP8 模型"在不同 GPU 上会走完全不同的代码路径，精度特性不同。 按模型名做选型验证，方法上就是错的。

第二，社区量化打败了官方量化。 那个明确标注"无校准数据集"的社区 W8A16 版本，表现优于官方 FP8 和官方 NVFP4。作者给了解释：W8A16 保留 BF16 激活，并且 GDN/linear_attn 投影与 lm_head 不参与量化。在混合架构模型里，"哪些层被排除"比"整体多少 bit"更能决定最终表现。

Part 2：工具调用区的真实故障

Part 1 只证明了"token 会翻转"。Part 2 回答了一个更要紧的问题：翻转之后会发生什么？

作者建了一个可视化工具，把 2–5 个可比较运行时并排显示，在它们出现分歧时分叉并同时追踪两条路径。他不把出错的模型拉回"正确答案"，而是让它继续跑下去，看它如何发散。

这个方法论选择很关键，因为一个 token 翻转的后果取决于后续生成能否收敛。结果是不会收敛。

三个实例：

1. 接口号翻转 + 重复错误命令：如前所述，GigabitEthernet0/0/1.201 变成 GigabitEthernet0/1/4，然后在两个分叉分支里重复执行错误命令。
2. 命令替换：正确是 show mac address table，FA2 试图 show run——不是失败，是"用一个相关但错误的命令继续"。
3. 任务完全未执行：模型试图给接口配置 description，token 翻转导致该任务根本没有被执行。

三个实例的可重复性都是 bit-identical 的 logits 采集。作者的结论是："this is simply changing one configuration option in vLLM to select TRT/FA2/FI. Same gpu, same os/drivers/software/vllm/prompt/cache/weights/activations."

拓扑也会改变行为

作者随后对比了张量并行：TP1 得到可接受的工具调用，TP2 失败，TP4 又成功了。

他说进一步抓 NCCL graph 通常能定位到是 NCCL 的问题。这个非单调性本身就值得警惕——它意味着"多卡比单卡更准"或"卡越多越好"这类直觉都不成立。

硬件差异

他在 SM120 家族内部对比了 RTX PRO 6000 和 RTX 5090，不同卡种之间的 token 翻转同样被记录在案。

到 Part 2 结束时，他已经完成 100% logits 采集并分叉追踪的维度包括：不同权重、不同模型、不同 KV cache 量化、不同张量并行、不同 NCCL 设置、不同 attention backend、不同显卡（6k vs 5090）。

作者对方法论的重要纠偏

这一节是整篇帖子里对比特实务价值最高的部分。原帖第 10 楼，作者主动澄清了几个被广泛误用的指标。银行的技术评审如果只记住"要测 KL 散度"，会踩到每个坑。

第一，必须先 softmax。 社区回复（Burhan，第 8 楼）指出：logits 本身不是有效分布，算 KL 之前必须先 softmax 成概率分布。作者回复确认：他们的 harness 会把采集的 logits 转成 float64、施加 log_softmax，然后计算方向性 KL（D_KL(P_BF16 | P_candidate)）、反向 KL 和 Jensen–Shannon 散度。

第二，KL 散度只度量"离基线多远"，完全不度量"对不对"。 这是最容易被误用的一点，原帖摘要里那句 "Lower KLD means closer to that baseline, not automatically 'smarter'" 就是在强调这件事。

第三，BF16 是数值保真参考，不是 oracle，更不是正确性标签。 作者原话：

"BF16 is a numerical-fidelity reference, not an oracle or correctness label. A quantized model can absolutely diverge from BF16 and produce a semantically better answer."

这条直接否定了"以 BF16 距离最小为验收标准"的思路。

第四，Top-1 和 KL 度量的是完全不同的东西。

• Top-1 disagreement = 改变的胜者位置数 / 评估位置数。 它不是 logits 的百分比差异。
• KL 度量整个概率分布的移动，包含那些根本不会改变赢家的变化。
• Top-1 是不连续的赢家测试：一个极小的 KL 变化就能翻转 50.1/49.9 的决策；而一个大得多的 KL 变化可能让压倒性的赢家纹丝不动。

作者还给了方向性建议：Top-1 与贪心解码直接相关，但对贪心解码来说，教师强制下的 Top-1 翻转仍只是一个反事实的根，不自动等于一个不同的完整答案——这正是他要分叉追踪的原因。

第五，重复确定性运行测的是可复现性，不是正确性。 原话：

"Repeating the identical deterministic run tests reproducibility, but does not make BF16 correct; correctness requires labelled answers, executable tool-call checks, or semantic grading across varied workloads."

第六，不要相信没有方法论披露的极低 KLD 声明。 作者提醒模型卡上的 KLD 数字若不披露参考 checkpoint、完整运行环境、评测文本、校准数据、上下文长度、采样位置、KL 方向、任何词表截断、以及如何聚合，这个数字无法解读。他还专门点名了 Homebrew 量化模型卡上的低 KLD 声明。

第七，采样参数本身就是故障源。 作者顺带提了一句：HF 模型卡通常明确指定了采样器和 chat template 参数（temp 1.0、top-p 0.95 等），温度设得太低会让 Qwen 陷在 THINK 输出里绕不出来。

第八，三个提示词测不出东西。 原帖 Part 1 就写了：不要把温度归零、粘三条提示词就宣布结论。zero-shot 测试不是大多数 agentic 任务的类比——你需要长上下文工具调用评测和领域特定知识评测。

Part 3：去审查微调在技术上更差

Part 3 测了四个 Qwen3.8-27B 的热门"去审查"（abliterated / heretic / uncensored）全 BF16 微调，对比官方 BF16 参考。评测负载 SP06 覆盖 4,339 个 token、七个输出区间，包括散文、精确 CLI/SQL/代码、多工具调用、恢复动作和架构建议。

关键结论不是"它们不安全"，而是"它们在工具调用上更不可靠"。

前两个基本可用，后两个作者建议列入 do-not-use。AEON Ultimate 的 253 个分叉未来里有 36 个无效（约 14%）。

SP06 的区间设计——精确 CLI/SQL、多工具调用、恢复动作——正好是银行场景的核心。而"恢复动作"这一项的失效尤其值得注意：它在 Part 2 里已经被证明是模型的弱项（两个分叉分支重复执行错误命令、任务完全未执行）。

如果银行内部有人提议"我们找一个开源的去审查模型微调，成本低、无审查问题"，这篇实验提供的证据是：在结构化输出和命令生成上，它比官方权重更不可靠。合规风险与技术风险在这里同向，而不是互相抵消。

对中国银行业的五条启示

以下分析是把原帖的机制结论映射到银行本地部署场景。原帖的实验对象是网络自动化，不是金融业务，所以这里做的是机制类比，不是等价映射。

启示一：配置漂移就是静默的行为变更，需要"推理指纹"

银行的模型治理隐含一个假设：模型版本 + 参数 + 权重 = 可复现的输出。传统 IT 有配置基线，这个假设在自建推理栈上其实不成立。

原帖证明了：仅切换一个 vLLM 配置项，就能改变工具调用里的关键 token，而且这个偏移是确定性的、可 bit-identical 复现的。这意味着它不会以"偶发异常"的形式出现在你的告警里——它会表现为"上周还对的接口号，这周开始错了"。

而运维现实是：为了性能把 FA2 换成 Triton、为省显存开 KV cache INT8、为扩容把 TP1 调到 TP2——每一次都是一次未经评测的模型变更，而所有精度评测报告都基于旧配置。

可操作动作：建立推理指纹（inference fingerprint）。 至少记录：权重 hash + 量化方案 + attention backend + TP/PP 拓扑 + NCCL 配置 + vLLM 版本 + 驱动版本 + 采样参数 + chat template。指纹变化即视为模型变更，走变更管理流程并触发回归。

启示二：量化选型是正确性问题，不是成本问题；且必须按三元组验证

把 NVFP4 从"官方发布的最新格式"降级理解：它在作者的硬件上不是原生 FP4 算术，而是退回到 Marlin 的权重-only 路径，并且是五个候选里唯一无法闭合工具调用的，到 88k 上下文约 50% token 翻转。

对银行的直接含义：任何量化方案都不能按"模型名称 + bit 数"来验收，必须在目标硬件上实测。 更关键的是，同一个 FP8 模型在不同 GPU 上可能走完全不同的 kernel 路径，精度特性不同——验证单元是"卡 + 引擎 + 精度格式"三元组，不是模型名。

反直觉的附带结论：那个明确标注"无校准数据集"的社区 W8A16 版本打败了官方 FP8 和官方 NVFP4，因为它保留了 BF16 激活、并且把 GDN 投影与 lm_head 排除在量化之外。在混合架构模型上，"哪些层不量化"比"整体多少 bit"更决定结果——这意味着银行的模型清单也应该记录"哪些层被量化"。

启示三：长上下文与精度是直接冲突的两个目标

KV cache INT8 最终能恢复，INT4 不能。原帖那一节的标题是 40k token 后 IQ 断崖。

银行最看重的能力恰恰是长上下文——制度文档检索、客户尽调报告、监管报送、合同与征信材料审阅。而这也是 KV cache 最吃紧、最容易被量化的位置。为了塞进更多上下文而量化 KV cache，等于在最需要精确的地方引入最高风险。

另一个容易被忽略的点：原帖发现分歧不是随上下文长度平滑增长，而是成簇出现、随内容变化。这意味着"控制上下文长度"不是一个有效的规避手段——你不能通过限制输入长度来证明"我们的场景在安全区"。

可操作动作：不要把 KV cache 量化当作默认容量手段。 优先用检索、分块、上下文压缩解决容量问题；精度让步应当是最后手段，且必须按第三节的方式验证。

启示四：从"能答"到"能改"是质变，工具调用必须有执行前确定性校验

这是五条启示里最重要的一条，因为它涉及的不是服务质量，而是操作事故。

原帖的三个实例——接口号写错、在两个分支里重复执行错误命令、用相关但错误的命令替换正确命令、任务完全未执行——全部发生在工具调用区。作者的 Part 2 之所以要用 100% logits 而不是抽样，正是因为"翻转之后会不会收敛、会不会造成操作失败"才是有实际后果的问题。

银行场景的等价物很清楚：模型调用核心系统接口——账户查询、限额调整、报文发送、批量任务调度。一个 token 翻转对应的是查错账户、重复提交、参数错位。

质变点在于：QA 场景答错是服务质量问题，Agent 场景答错是操作事故。 而"重复执行错误命令"这个细节尤其重要——它说明模型不会从自己的错误里自愈，一次微小偏差会被后续生成放大并固化。

可操作动作：模型输出必须经过确定性校验层才能进入执行。 至少包括：schema 强校验 + 业务规则校验（接口号合法性、账户存在性、限额范围）+ 幂等/去重机制 + 高风险操作二次确认。绝不能把模型生成的工具调用参数直接下发到生产系统。

启示五：扩缩容即模型变更，推理拓扑必须纳入变更管理

TP1 可接受、TP2 失败、TP4 又成功。这个非单调性意味着容量调整本身就是一次模型变更——而它的触发原因是运维事件，不是代码变更，所以很容易绕过变更管理流程。

会改变拓扑的场景包括：HPA 弹性伸缩、节点故障转移、换卡代际、跨可用区迁移、显存水位触发的重新编排。

可操作动作：把拓扑变更显式列为模型变更的触发条件，故障转移后必须重跑回归。 如果做不到这一点，那么"已验证的模型"这个状态会随着基础设施的日常波动而静默失效。

一份可落地的三层验证清单

把前面的结论压缩成可执行的三层。

第一层 · 指纹层：变更可控

• 记录完整推理配置指纹（权重 hash、量化方案、attention backend、TP/PP 拓扑、NCCL 配置、引擎与驱动版本、采样参数、chat template）
• 指纹变化 = 模型变更，进入变更管理并触发回归
• 拓扑变更（扩缩容、故障转移、换卡）显式纳入触发条件

第二层 · 行为层：验收可信

• 在自己的真实长上下文 + 自己的工具 schema 上做 A/B，而不是通用基准或三条提示词
• 至少覆盖：精确的结构化输出、多工具调用、失败恢复动作（Part 3 的 SP06 区间设计可直接借用）
• 关注工具调用能否正确闭合，而不只是文本质量
• 验收标准用"带标注答案 / 可执行工具调用检查 / 语义评分"，不用 BF16 距离最小
• 出现 token 翻转时做分叉追踪，看后续是否收敛，而不是只看翻转率这个数字
• 量化选型按"卡 + 引擎 + 精度格式"实测，同时记录"哪些层被排除在量化之外"

第三层 · 执行层：风险可控

• schema 强校验 + 业务规则校验，模型输出不可直接下发
• 幂等 / 去重机制，防止错误动作被重复执行
• 高风险操作二次确认
• 对精度敏感的路径保留非量化（至少 BF16）基线，不为容量牺牲关键链路的精度

本文结论的边界

为免误用，明确标注本文的证据强度。

原帖事实（可直接引用）： 三组实验的设置与结果、Cisco 接口号翻转实例、TP1/TP2/TP4 非单调、五个量化候选的 GEMM 与量化细节、去审查微调的四组对比数据、以及第 10 楼的方法论澄清。这些都在原帖中有完整记录。

本文分析（推论）： 全部五条银行启示、三层验证清单、以及"配置漂移即模型变更"的核心论断，都是把原帖的机制结论映射到银行本地部署场景。原帖实验对象是网络自动化，不是金融业务；Cisco 接口名与账户号、接口号之间的对应关系是机制类比，不是等价映射。

需要谨慎的三点：

其一，这是单一研究者在特定硬件上的实验，不是同行评审。 硬件是 RTX PRO 6000 Blackwell 与 RTX 5090（均 SM120 家族），模型是 Qwen3.x 家族，上下文约 96–100k，样本量有限。作者自己也说明部分方法是刻意简化的。

其二，但核心机制是硬件无关的。 浮点加法不满足结合律、不同 kernel 的归约顺序不同——这是数值计算的基本性质。社区回复（vad，第 7 楼）也指向这一点：交换律、浮点、定义顺序这些基本原理会在神经网络身上反咬一口，而问题的识别被延迟了，因为所有人都假设输出是随机的、输入也在变。换卡、换引擎、换拓扑不会消除这个机制。

其三，作者的重型运行结果尚未发布。 H200 的运行"昨晚基本跑完"，B200"今早某个时候跑完"，原帖明确说"just wait for what's coming next"。因此本文不能用来推断 H200/B200 上的表现。

最后一条实务提醒：本文给出的所有数字都不是银行生产环境的验证结果。 本文提供的是"必须验证"的方法论，不是"选哪个方案"的结论。银行的具体选型必须在目标硬件、目标上下文长度、目标工具 schema 上自行实测。

作者毕超，金融行业风险管理从业者。本文仅代表作者个人观点，不构成任何机构立场。