--- title: "同一个权重、同一张卡，答案却不一样：本地部署大模型的精度风险与银行验证清单" date: 2026-10-01 description: "Level1Techs 论坛上一篇实测帖给出了本地部署大模型最反直觉的结论：同一份权重、同一张 GPU、同一个驱动与 vLLM，仅切换 attention backend 这一个配置项，就能让模型在工具调用中把 Cisco 接口号从 GigabitEthernet0/0/1.201 写成 GigabitEthernet0/1/4，并重复执行错误命令；且该偏移可 bit-identical 复现。本文解读该帖的三组实验（attention backend、KV cache 量化、五种权重量化对比）、拓扑与硬件差异、以及作者对 KLD 方法论的重要纠偏，并逐条分析对中国银行业本地部署大模型的启示：配置漂移即静默的行为变更、量化选型是正确性问题而非成本问题、长上下文与精度直接冲突、工具调用必须前置确定性校验、扩缩容即模型变更。文中给出一份可落地的三层验证清单，并明确标注本文哪些是原帖事实、哪些是机制推论。" tags: ["本地部署", "大模型", "推理精度", "量化", "vLLM", "工具调用", "模型治理", "Agent", "中国银行业", "技术风险"] schema_type: "Article" references: - title: "Why your local LLM feels dumber than it is（Level1Techs 论坛主帖，Part 1 三组实验 + Part 2 工具调用分叉追踪 + Part 3 去审查微调对比）" url: "https://forum.level1techs.com/t/why-your-local-llm-feels-dumber-than-it-is/253917" source: "Level1Techs Forums" - title: "Part 2 楼层（工具调用区的 token flip 实例，含 Cisco 接口号错误与 TP1/TP2/TP4 对比）" url: "https://forum.level1techs.com/t/why-your-local-llm-feels-dumber-than-it-is/253917/4" source: "Level1Techs Forums" - title: "作者对 KL 散度与 Top-1 指标的方法论澄清（第 10 楼）" url: "https://forum.level1techs.com/t/why-your-local-llm-feels-dumber-than-it-is/253917/10" source: "Level1Techs Forums" - title: "社区对 KL 散度用法的三点纠正（第 8 楼，Burhan）" url: "https://forum.level1techs.com/t/why-your-local-llm-feels-dumber-than-it-is/253917/8" source: "Level1Techs Forums" - title: "Qwen/Qwen3.6-27B（官方 BF16 参考 checkpoint）" url: "https://huggingface.co/Qwen/Qwen3.6-27B" source: "Hugging Face" - title: "nvidia/Qwen3.6-27B-NVFP4（官方 NVFP4 权重，本文五路量化对比中唯一失败工具调用者）" url: "https://huggingface.co/nvidia/Qwen3.6-27B-NVFP4" source: "Hugging Face" --- ## 一个反直觉的实验结论 先说结论，因为它决定了后面所有的推论。 原帖作者 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"。 ### 实验三：五种权重/激活精度对比 这是对银行选型最有参考价值的一组实验。五个候选： | 候选 | 权重/激活 | 线性层 GEMM | 定性 | |---|---|---|---| | **BF16 参考** | BF16 权重 + BF16 激活 | `torch.nn.functional.linear` | 参考 checkpoint | | **官方 FP8** | E4M3 FP8 权重（128×128 块）+ 动态 FP8 激活量化 | `CutlassFp8BlockScaledMMKernel` | DeepGemm 被自动禁用 | | **社区 INT8** | 静态对称、通道级 INT8 权重 + BF16 激活（W8A16） | `MarlinLinearKernel` | 一次性量化，**明确无校准数据集** | | **官方 NVFP4** | 混合：208 个 FP8 W8A8 + 193 个 NVFP4 W4A16 | `FlashInferFP8ScaledMM` / `MarlinNvFp4LinearKernel` | **非原生 FP4 算术** | | **社区 AWQ** | 静态非对称 INT4（组大小 32，MSE observer）+ BF16 激活 | `MarlinLinearKernel` | 校准集标注为 "STEM and Agentic" | 结果： - **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/代码、多工具调用、恢复动作和架构建议**。 | 微调 | SP04 Top-1 翻转 | SP06 Top-1 翻转 | SP06 最差区间 p95 KLD | 无效分叉未来（SP04 / SP06） | |---|---|---|---|---| | Heretic-ARA（可复现的 ARA ablation） | 0.717% | 1.337% | 0.03661 | 0/11 · 0/58 | | Huihui Abliterated（"粗略 PoC" ablation） | 0.912% | 1.406% | 0.04477 | 0/14 · 0/61 | | Blackfrost Abliterated（拒答方向权重编辑） | 3.844% | 4.978% | 0.31235 | 0/59 · 1/216 | | AEON Ultimate（SSM repair + Abliterix + MTP graft） | 2.997% | **5.831%** | **0.68507** | **8/46 · 36/253** | **关键结论不是"它们不安全"，而是"它们在工具调用上更不可靠"。** 前两个基本可用，后两个作者建议列入 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 上自行实测。 *作者毕超，金融行业风险管理从业者。本文仅代表作者个人观点，不构成任何机构立场。* ## 常见问题 Q: 银行做本地部署，是不是应该直接用 BF16、避免一切量化？ A: **原帖的结论恰恰相反：五个量化候选里，唯一失败工具调用的是官方 NVFP4，而明确标注"无校准数据集"的社区 W8A16、官方 FP8、以及 AWQ W4A16 都正确完成了调用。** BF16 是数值保真参考，不是正确性标签——**一个量化模型完全可能偏离 BF16 而给出语义更好的答案。** 关键不是"是否量化"，而是"哪些层被量化"（W8A16 保留 BF16 激活、GDN 投影与 lm_head 不量化，这是它表现好的原因）、以及"在什么硬件上以什么 kernel 执行"（官方 NVFP4 在 SM120 上退化为 Marlin 权重-only 路径）。**建议做法是按"卡 + 引擎 + 精度格式"实测，并对精度敏感的链路保留非量化基线，而不是一刀切地全 BF16 或全 4bit。** Q: KV cache 量化只是为了塞进更多上下文，这个取舍值得吗？ A: **银行场景下通常不值得，因为长上下文恰好是精度最敏感的地方。** 原帖实验显示 KV cache INT8 出错但最终能恢复，INT4 则没能恢复，表现为 40k token 后的 IQ 断崖。银行最看重的能力就是长上下文（制度文档、尽调报告、监管报送），也是 KV cache 最吃紧的位置——**为容量牺牲精度，等于在最需要精确的地方引入最高风险。** 而且原帖的分歧是**成簇出现、随内容变化**，不存在"控制长度就安全"的临界点。**优先用检索、分块、上下文压缩解决容量；精度让步是最后手段，且必须实测。** Q: 我们已经有回归评测了，还需要关注 token 翻转吗？ A: **需要先确认你的回归评测测的是正确性，还是只是可复现性。** 作者的原话很直接："Repeating the identical deterministic run tests reproducibility, but does not make BF16 correct."（重复确定性运行测的是可复现性，不是正确性。）银行上线前常见做法是"同一输入多次跑结果一致就放行"——这只能证明没有随机性，不能证明结果是对的，因为原帖里的偏移是**确定性、可 bit-identical 复现**的。**正确的验收需要带标注答案、可执行工具调用检查，或跨多样工作负载的语义评分**；并且评测负载要用自己的真实长上下文与工具 schema，而不是通用基准——zero-shot 测试不是 agentic 任务的类比。 Q: 用 KLD 散度衡量量化模型和原模型的差距，这个做法在业界很常见，问题出在哪？ A: **出在三个层面。** 第一，KL 散度只度量"离基线多远"，完全不度量"对不对"——**更低 KL 不等于更聪明**，量化模型完全可能偏离 BF16 而给出语义更好的答案。**第二，BF16 不是 oracle，只是数值保真参考**，把"与 BF16 的距离最小"当验收标准，方向本身可能就是错的。**第三，Top-1 和 KL 度量的是不同的东西**——KL 度量整个分布的移动（含不改变赢家的变化），Top-1 是不连续的赢家测试，一个极小 KL 就能翻转 50.1/49.9 的决策，而大 KL 可能让压倒性赢家纹丝不动。另外算 KL 前必须先 softmax，否则 logits 不是有效分布。**结论：KL 与 Top-1 可以作为诊断指标，但不能作为验收指标；验收必须有带标注的正确性检查。** Q: 我们想做"去审查"的开源模型微调以降低成本，这个思路技术上可行吗？ A: **从原帖 Part 3 的证据看，代价不止是合规，技术上更差。** 四个热门去审查微调对比官方 BF16：Heretic-ARA 和 Huihui 的 SP06 Top-1 翻转率在 1.3%–1.4%（基本可用），但 Blackfrost 达 4.978%，AEON Ultimate 达 5.831% 且 253 个分叉未来中 36 个无效（约 14%）。而 SP06 的评测区间恰好包含**精确 CLI/SQL/代码、多工具调用、恢复动作、架构建议**——正是银行场景的核心。**结论是：abliteration 破坏了工具调用能力，不只是移除了安全对齐。合规风险与技术风险在这里同向，不能互相抵消。** Q: 推理指纹要记录哪些字段？ A: **至少十项：权重 hash、量化方案（含哪些层被排除量化）、attention backend、TP/PP 拓扑、NCCL 配置、vLLM 与引擎版本、驱动版本、采样参数（含 chat template）。** 判断标准很简单——**任何一项变化都要重新验证模型行为，就属于模型变更。** 原帖的实证是：仅 attention backend 一项变化就能让工具调用写错接口号。另外提醒两点：**拓扑变更（扩缩容、故障转移、换卡）也是模型变更**，因为 TP1/TP2/TP4 的行为是非单调的；**采样参数也是故障源**，原帖提到温度设得过低会让模型陷在 THINK 输出里绕不出来。