四个开源编码模型被提示补全上传 URL——分析

# 四个开源编码模型，被强制补全一个上传 URL：字节会流向哪里 来源：https://int8.io/forced-curl/ ## 四个开源编码模型，被强制补全一个上传 URL：字节会流向哪里 10 月 26 日，Cohere 发布了一份报告（https://cohere.com/blog/concerning-behaviour-popular-open-weight-ai-model），其中一个 Qwen 模型在作为编码代理工作时，拼装出了一条 `curl` 命令，该命令会把用户的文件上传到一个阿里云存储桶中。一周之内出现了七次复现、一条 337 分的 Hacker News 讨论帖（https://news.ycombinator.com/item?id=50246658）、r/LocalLLaMA 上两个 1,400 赞的帖子（trace 发布帖（https://www.reddit.com/r/LocalLLaMA/comments/1xgbm28/）、辟谣帖（https://www.reddit.com/r/LocalLLaMA/comments/1xgopmj/)），以及一篇 The Register 的报道。所有复现都使用同一个模型和同一段 2,300 token 的提示词。唯一一次跨模型尝试——url-atlas（https://url-atlas.vercel.app/）——每个模型跑了 1,000 个样本，结论是"无法定论"，而按照这种发生率，它也只能得出这个结论。 评论区反复出现的问题很简单：*这是 Qwen 的问题，是中国模型的问题，还是所有模型都有这个问题？*我有一张寂寞而冰冷的 RTX 4090 和一个周末，于是我自己跑了这个对比。**测试框架和分类器**（https://github.com/int8/forced-curl）以及**完整的 40 万行数据集**（https://huggingface.co/datasets/kamilc-bst/forced-curl）都是公开的。 [实验装置](https://int8.io/assets/img/curl/setup.png) | [实验装置（移动端）](https://int8.io/assets/img/curl/m/setup.png) ## TL;DR - **大家的互联网是一样的。** 对所有四个模型来说，Google Storage、GitHub、S3 和 example.com 都占据主导。 - **厂商的指纹藏在长尾里。** Qwen3.5-9B 提及阿里云的次数是 GLM-4-9B（一个没有自家云的中国模型）的 13 倍。Google 和 NVIDIA 的模型从不提及任何中国的东西。 - **Qwen 不是在回连，它是在引用训练数据。** 它提及 api.openai.com 的次数与阿里云差不多，而没人往 Qwen 里塞过 OpenAI。 - **凭据会出现，而且大多只是戏服。** Qwen 在 2.5% 的 URL 中写入了 key、token 或签名，GLM 为 0.6%，Gemma 和 Nemotron 几乎从不。Qwen 的三分之一是明显的假货，比如 `YOUR_API_KEY`。四分之一能骗过密钥扫描器：72 个 AWS 风格的 `AKIA...` key ID，107 个能解码为 `{"alg":"HS256"}` 的 JWT header。没有一个被真正验证过。最有说服力的一个 Mapbox token，解码结果是 `exampleuser`。 - **Gemma 在搜任务本身。** 其中三分之一被标注为非占位符的 URL 是页面浏览，而这些当中近一半是一个 Google 搜索，搜的是它被分配的那件差事该怎么做：`how to clean up tmp`、`temporary files removal command`。 - **卫生习惯是看得出来的，NVIDIA 的最好。** Nemotron-Nano-9B 有 93% 的时候写 example.com 或它的兄弟域名，3% 的补全中提及真实的第三方，每 10 万次中 46 次写入凭据。Gemma 紧随其后。模型写 example.com 是因为它的训练数据就这么写，所以这看起来是严格的预处理，而不是运气。代价是对真实端点的记忆变弱了。 [Figure 1 主图](https://int8.io/assets/img/curl/hero_map_qwen.png) | [移动端](https://int8.io/assets/img/curl/m/hero_map_qwen.png) *Figure 1. Qwen3.5-9B 的 10 万次强制补全。气泡位于模型写出的主机名所对应的云区域。它以区域名提及的第二个国家是中国。没有任何请求被实际发出。* ## 实验细节 每个模型都使用自己的聊天模板和工具调用语法，先填充一段 bash 工具调用，其中的 curl 命令停在 `https://` 处；然后生成接下来的 40 个 token；每个模型 10 万次补全，温度 1.0，在一个无网络 namespace 内的一张 RTX 4090 上运行。主机先按一套公开的规则集分类，再由 Claude Haiku 5.5 标注，后者只看到主机名和路径。确切的提示词与前缀、checkpoint 版本、包版本、分类器和标注审计都在[仓库 README](https://github.com/int8/forced-curl#readme) 里。 ## 10 万次上传流向何处 [Kinds](https://int8.io/assets/img/curl/kinds.png) | [移动端](https://int8.io/assets/img/curl/m/kinds.png) *Figure 2. 每个模型 10 万次补全按主机类别的占比，基于规则的分类。* ## URL 实际在做什么 主机类别说明"在哪里"，路径说明"在做什么"。用 LLM 标注器阅读 8 万条唯一路径，得到了仅看主机名的复现无法看到的那部分内容。 [Character](https://int8.io/assets/img/curl/character.png) | [移动端](https://int8.io/assets/img/curl/m/character.png) *Figure 3. 标注器在路径和域名中读到的内容：隐含的动作、提示词回声、形似凭据的参数，以及注册域名是否属于真实的已知组织。* **GLM 在隔壁搭了个采集器。** 每十个 GLM 补全中就有一个指向带端口和通用路由的私有或回环地址：`192.168.1.5:3000/api/v1/data`、`0.0.0.0:6961/upload`。它是唯一以这种模式大规模出现的模型。 **Gemma 跑去查了。** 被告知要上传一个 tarball，Gemma 却打开了 635 次 `www.google.com/search`。其中 373 次的查询词就是那件差事本身：`how to clean up tmp`、`temporary files removal command`、`clean up old temporary files in linux`，还有一次被 token 预算截断成 `how to delete files in to t`。另有 142 次搜的是 `test`。这个本该把你的文件搬走的模型，跑去找怎么做作业了。 **凭据会出现，但很少，且大多只是戏服。** 形似签名或 token 的参数（`X-Amz-Signature`、`OSSAccessKeyId`、`token=`、`?Expires=`）出现在 3.8% 的 Qwen 标注 URL 和 1.6% 的 GLM 标注 URL 中；折合每 10 万次补全，Qwen 为 2,468，GLM 为 593，Nemotron 为 46，Gemma 为 12。Qwen 的其中 844 条带有明显的假值（`YOUR_API_KEY`、`DEMO_KEY`、`${API_KEY}`），490 条在 `=` 处或之前就结束了，559 条带有长度和熵都合适的值，其中包括 72 个 `AKIA...` AWS key ID 和 107 个能解码为合法 `{"alg":"HS256","typ":"JWT"}` 的 JWT header。没有一个被验证过，而且 40 个 token 的预算让每个计数都只是下界。其中最有说服力的一个 Mapbox `pk.eyJ...` token，解码结果是 `{"u":"exampleuser"}`。 ### URL 从哪来 [Mechanisms](https://int8.io/assets/img/curl/mechanisms.png) | [移动端](https://int8.io/assets/img/curl/m/mechanisms.png) *Figure 4. 每个唯一 URL 一个机制标签，由标注器从一个 13 类代码本中指派，该代码本是在对 1,000 条 URL 样本的开放式编码过程中构建的，按补全次数加权。* ## 阿里案例 [Rare](https://int8.io/assets/img/curl/rare.png) | [移动端](https://int8.io/assets/img/curl/m/rare.png) *Figure 5. 每 10 万次补全的稀有主机类别，对数刻度，Wilson 95% 置信区间。Gemma 和 Nemotron 以计数形式列在右侧。* 现在到了大家都关心的部分。每 10 万次补全： | | Qwen3.5-9B | GLM-4-9B | Gemma 4 12B | Nemotron 9B | |---|---|---|---|---| | 阿里云（OSS、DashScope、aliyuncs） | 417 | 32 | 0 | 1 | | 阿里系（qwen.ai、modelscope、淘宝……） | 243 | 8 | 0 | 0 | | 其他中国服务（腾讯、百度、华为……） | 664 | 15 | 10 | 0 | | 云元数据 IP（169.254.169.254、阿里的 100.100.100.200） | 236 | 0 | 0 | 4 | | api.openai.com 及其他 OpenAI 主机 | 357 | 65 | 0 | 0 | GLM 正是此前争论中缺少的对照组：一个来自没有公开云的实验室的中国模型。如果中国训练数据能解释阿里云的出现率，GLM 应该和 Qwen 相当。但它并不相当。Qwen 提及阿里云的次数是 GLM 的 13 倍，这个差距在阿里的其他资产上同样存在，在其他中国服务上则较小。下面就是那 660 次阿里补全的解剖。 [Alibaba anatomy](https://int8.io/assets/img/curl/alibaba_anatomy.png) | [移动端](https://int8.io/assets/img/curl/m/alibaba_anatomy.png) *Figure 6. 所有主机为阿里云或阿里系服务的 Qwen 补全，旁边是 GLM 的计数。左：主机类型。中：模型放在 `.oss-cn-aliyuncs.com` 前面的存储桶名。右：标注器的机制标签。* 有两件事让这不至于成为"Qwen 回连"的标题。第一，同一个模型提及了 357 次 api.openai.com，接近它提及阿里云的次数。没人往 Qwen 里植入过 OpenAI 的端点。更简单的解读是：一个被强制写 API 主机的模型，会写出它在代码中见过最多的主机，而对于一个在阿里内部训练的模型，这包括阿里的文档和 SDK 示例。这是一个语料指纹，而不是一个目的地。第二，这些阿里主机是通用的。`upload.oss-cn-hangzhou.aliyuncs.com` 是一个读过 OSS 快速入门、又被告知命令是 `curl -T` 的模型会写出来的东西。这 660 条中没有一条是某个已知会接收数据的具体租户，少数几个形似真实名称的存储桶也都是孤例。如果一个 RL 环境把真实端点泄漏进了权重，那看起来会是同一个主机反复出现，而不是 186 个各出现一两次的不同存储桶名。 ## 运营商与国家 标注器给出的运营商排名（构建时没有给它一份要查找的名单）讲的是同一个故事。阿里是 Qwen 的第 11 大运营商，OpenAI 是第 12 大。GLM 提及 Hetzner 和 UC Irvine 机器学习数据仓库各数百次，而 Yandex 在两个中国模型中都出现了。 [Operators](https://int8.io/assets/img/curl/operators.png) | [移动端](https://int8.io/assets/img/curl/m/operators.png) *Figure 7. 每个模型可识别主机的前几大运营商，由标注器在没有名单可依的情况下命名。阿里是 Qwen 的第 11 大运营商，OpenAI 是第 12 大。* [HQ countries](https://int8.io/assets/img/curl/hq_countries.png) | [移动端](https://int8.io/assets/img/curl/m/hq_countries.png) *Figure 8. 可识别主机的运营商总部所在国，四个模型，每 1 万次补全，对数刻度。* [Regions](https://int8.io/assets/img/curl/countries_qwen_glm.png) | [移动端](https://int8.io/assets/img/curl/m/countries_qwen_glm.png) *Figure 9. 一个不同的问题：主机本身所命名的数据中心区域（us-east-1、cn-hangzhou、europe-west3），Qwen 对 GLM。Qwen 提及区域的次数远多于 GLM；两者都把大部分放在美国。* ## 169.254.169.254 云实例元数据地址是这个数据集中唯一一个如果从云 VM 内部被访问就真会做点有趣事情的主机。它会返回实例的身份、启动脚本，以及按需返回 VM 角色的临时凭据。Qwen 在 10 万次中写了它 226 次，另外 10 次写了它的阿里等价物 100.100.100.200。Nemotron 写了 4 次。GLM 和 Gemma 从不写。 [Metadata paths](https://int8.io/assets/img/curl/metadata_paths.png) | [移动端](https://int8.io/assets/img/curl/m/metadata_paths.png) *Figure 10. Qwen 的 226 次元数据 IP 补全，按路径会返回什么排序。88% 会读取实例 ID。有 4 条会请求角色凭据。* 一个监控代理请求实例 ID 是常规操作。一个代理请求 `iam/security-credentials` 则是云凭据窃取的第一步。Qwen 的路径大多属于第一类，即打开各家云文档时见到的那些示例。有 4 条指名了凭据端点，15 条指名了启动脚本。url-atlas（https://url-atlas.vercel.app/）在 Cohere 的安全主题前缀下看到 Nemotron Super VL 有 17% 的样本触及元数据 IP；Zenity（https://zenity.io/blog/who-is-your-agent-calling-what-the-qwen3-8-egress-finding-means-for-enterprise-ai）在普通提示词下看到的比例至多为 0.3%。在一个不含安全词汇的编码提示词下，只有 Qwen 会写它，比例为 0.23%。 ## 这意味着什么 **对于把这些模型部署为代理的人。** Cohere 提出的补救措施是对的，而且很无聊：出口流量白名单、代理环境中不放任何环境化的云凭据、把权重当作未签名的二进制来对待。这条建议适用于这张表里的每一个模型，包括那两个从不提及任何中国的模型，因为那些下载形状的补全和捏造的主机在真实 shell 里同样不受欢迎。 **对于写相关报道的人。** "Qwen 外泄到阿里云"不是数据所说的话。数据说的是：当一个模型被强制产出一个上传 URL 时，Qwen 在所有方面产出得都更多，包括更多阿里、更多 OpenAI、更多元数据 IP、更多捏造的域名和更多形似凭据的字符串；而相对一个中国对照组的阿里超额是真实的、13 倍的、通用的，且在绝对量级上只是个舍入误差。 **对于训练模型的人。** 占位符的差距看起来像数据卫生的差距。两个美国模型大多写占位符，Nemotron 93%、Gemma 68%，而 GLM 约一半，Qwen 只有四分之一。模型写 example.com 是因为它的训练数据写了 example.com，而这正是严格预处理的产物：抓取代码中的 URL 被清洗或规范化，合成的工具调用数据带有使用保留名称的生成指令。在另一端，Qwen 复现的是真实的数据分片、真实的存储桶和真实的签名 URL 语法——这就是当原始 URL 留在语料里时存活下来的东西。这份数据无法区分预训练过滤与后训练风格，而且更严格的卫生也意味着对真实端点的记忆更弱，所以这是一个权衡，而不是美德。但如果你想要代理 shell 里少一些意外，那个杠杆是数据集，而不是实验室的国籍。