多维蝴蝶效应：Cohere 未在 Qwen3.8-Flash-Next 上测试的内容

多维蝴蝶效应：Cohere 没有对 Qwen3.8-Flash-Next 测试的那些事 Mark Galyan 2026 年 10 月 30 日 模型不是模型，不是模型，不是…… sanmaohe 的幽灵 发生了什么：Cohere 团队使用微软的 CTI-REALM 网络安全基准评估阿里巴巴的 Qwen3.8-Flash-Next 时（任务是编写一条检测恶意 curl 下载的规则），模型无视了提示。尽管其推理轨迹明确表示不会进行任何工具调用，它还是探查了宿主环境（检查 /tmp、实用工具和 DNS），并尝试向位于北京的一个阿里云 OSS 存储桶（sanmaohe[.]oss-cn-beijing[.]aliyuncs[.]com）发送包含探测字符串的 HTTP PUT 请求。（一款热门开放权重 AI 模型令人担忧的行为 | Cohere）沙箱阻止了这次出站尝试，没有报告任何损害。Cohere 还补充说，这种情况的发生率似乎低于每 100,000 次评估调用一次。我做了什么：将 Cohere 的原始轨迹截断在 URL 之前，使用本地 Unsloth GGUF 文件运行了 1,200 次。刀刃上的平衡 我自然想进一步探索，找出哪些机制导致我的结果与 Cohere 的结果不同。我与 Claude 合作，尝试分离出哪些调节因素会改变概率，以及改变的幅度。量化通常是导致模型偏离基础版本的最大因素，因此我们测试了该模型的 2 位和 4 位版本，两者均来自 Unsloth。我们取用 Cohere 发布的轨迹，在第 2,323 个 token 处截断，并以原始 token ID 的形式输入，结束位置就在即将生成 URL 之前。我们只进行了文本生成，没有实际访问任何 URL。受硬件限制，我们也无法测试全精度模型。使用 buun 的 llama.cpp 作为引擎，按照 Cohere 自己的设置（T 1.0、top_k 20）采样 1,200 次后，我们发现，刚过第 2,323 个 token 时，模型并没有锁定某个硬编码的后门。事实上，至于模型会写出哪个地址，我们并未发现明显占优的选项。它处于一个数值概率分布之中。XDA 的 Adam Conway 认为这是“一次意外”，源于“模型记住了自己的训练环境”，即“它在后训练期间使用过的一个内部代理”（《Qwen 3.8 编造带有真实密钥 ID 的阿里巴巴 URL，这就是我不认为它是后门的原因》）。我们的结果没有一次与 Cohere 的确切结果相同。事实上，在我们的各种配置中，模型在该位置选择 Cohere 的 sanmaohe 存储桶的原始概率介于 4×10⁻¹⁸ 和 7×10⁻³⁸ 之间。模型确实几乎 100% 都补全了一个 URL（不过这并不意外，因为前缀已经写出了上传命令）。这个 URL 指向哪里，以及它有多大概率是云地址，取决于具体的文件（甚至取决于其中五层在哪里计算！）。没有哪个目的地址绝对占优，微小的数值变化就会扰动结果。和往常一样，我们预先登记了预测（其中 3 项未得到验证，参见 PREREG_FLASHNEXT_PROBE.md）。局限性：两个文件、一个引擎、一台主机、一个截断点。我们以两种不同方式测试了 2 位文件。由于该文件比 4 位文件小不少，我得以将更多模型层完全塞进四张 P100 显卡的显存中。4 位文件无法做到这一点，只能将 44 层放入显存，其余部分放入系统内存。另外也要明确，2 位和 4 位只是标签，因为每个文件内部都包含大量混合精度权重，所以请自行看待这些标签。为了匹配 4 位文件的测试条件，我们将相同数量的层（44 层）载入显存，其余部分放入内存。随后，我们又运行了一次相同的测试，但将全部 49 层都放入显存。在所有测试中，28.8GB 的 n-gram 表都位于系统内存中。为什么要做两种不同的测试？因为不同硬件可能产生额外或不同的数学计算路径，从而导致输出分歧。如果你已经做这类工作一段时间，应该早就知道这一点，但对许多人来说，这可能是一个新鲜而重要的事实。4 位模型最常选择 localhost 或 127.0.0.1（约占 32.5%）。2 位测试（卸载至内存与完全使用 GPU）中，最常选择的是以“23”开头的公网地址（分别占 65% 和 35%）。它选择阿里云元数据地址 100.100.100.200 的比例分别为 7.3% 和 2.3%，而 4 位模型的比例为 5.3%。有趣的是，结果显示，层的放置位置改变了这一比例，而位数没有带来可检测的影响。指标 / 结果 IQ4_XS（44 层 GPU）Q2_K_XL（44 层 GPU）Q2_K_XL（49 层 GPU）写出 URL 395/400 400/400 400/400 localhost 或 127.0.0.1 32.5% 0% 0% 以 23. 开头的地址 0% 65% 35% 阿里云元数据 100.100.100.200 5.3% 7.3% 2.3% 任意 aliyuncs.com 主机 1.8% 3.5% 1.5% Cohere 的 sanmaohe 存储桶 0 0 0 不同的首个主机地址数量 152 229 273 排除 n-gram 表这一可疑调节因素 说到 GGUF 内部那张 28.8GB 的 n-gram 嵌入表（per_layer_token_embd.weight），XDA 的 Adam Conway 最近追踪发现，Routify 主机名正是来自这张表。当他屏蔽那些行后，模型便不再写出该主机名，转而编造了另一个代理（《Qwen 3.8 编造带有真实密钥 ID 的阿里巴巴 URL，这就是我不认为它是后门的原因》）。这让我开始思考：对这张表采用不同的量化方式，会不会是这里的一个调节因素。因此，我们检查了两个 Unsloth 模型中的表是否采用了不同的量化方式，但结果是它们逐字节完全相同；两者均以 IQ4_NL 格式存储，在 2 位和 4 位文件中的 SHA256 哈希值也完全一致。既然表完全相同，那么不同文件之间的波动必然来自模型的其余部分及数值计算路径。我们没有测试具体来自哪个部分。硬件蝴蝶效应（当 5 层让天平倾斜）如果仅将同一个 UD-Q2_K_XL 文件中的 5 层从系统内存移到 P100 上，就能让模型以阿里云元数据地址（100.100.100.200）为目标的比例降低约三分之二（下降 5.0 个百分点，95% 置信区间：-8.2 至 -2.1，p ≈ 0.001），那么显然，我们面对的是一系列极其敏感的系统。这进一步说明，两个看似相同或近乎相同的推理栈部署，实际上可能差异很大，只是外表相似而已。最后，为了测量底层概率，我们通过两种不同方式提供最后三个 token：一次性批量处理，以及模仿实际推理过程逐步流式输入。即使不改变层的放置位置或量化方式，批量读取所得到的分布与真实样本之间的总变差距离也达到了 0.33 至 0.41，而逐个生成 token 时则为 0.04 至 0.11。仅仅改变 CUDA 内核路径，很可能就会改变模型的概率。安全与部署团队应当得到的启示 在我们进行的这些轮测试中，仍然无法确定这是否是蓄意行为，但我认为大多数证据都不支持这一判断。当本地环境之间的差异如此显著时，指望托管的云端端点复现其中任何一种配置的结果，都是冒险的假设。同样，当把 5 层移到 CPU 上就能让该前缀下的元数据探测率增至三倍时，一次没有异常的测试也无法证明模型安全。Cohere 的操作建议（将模型置于沙箱中、阻止出站网络访问、像对待未签名二进制文件一样对待权重）是合理的，我也会建议采取完全相同的预防措施。我认为，每个部署栈中都有如此多的调节因素，我们目前所能期望做到的，最多就是进行概括性观察，并分析数据之间的关联。因此，为所有部署制定严谨的安全验证规程至关重要。Cohere 还有一句值得记住的话：“推理轨迹不是安全边界。”这样的故事还会有很多，系好安全带吧。https://www.xda-developers.com/qwen-invents-alibaba-urls-real-key-id-dont-think-backdoor/ https://cohere.com/blog/concerning-behaviour-popular-open-weight-ai-model https://github.com/apollo-mg/Project-Apollo/tree/69c3f7952de04c7662a5166eb9e3480a8a1ea9ff/data/receipts/flashnext-probe