--- layout: post.njk source: https://yage.ai/share/reasoning-theft-20260812.html speaker: yage.ai title: 模型蒸馏攻防的秘诀：厂商藏不住的推理，和你删不掉的密钥 date: '2026-08-12' summary: 文章探讨了模型蒸馏攻防中的安全漏洞。研究发现，厂商试图通过加密推理过程来保护技术资产，但这种机制在跨模型调用中存在兼容性漏洞，使得弱模型可以解密出前沿模型的推理轨迹。此外，这种不透明的数据块也给AI应用开发带来了安全隐患，如API密钥和敏感信息的泄露风险，凸显了厂商保护IP与开发者数据安全之间的矛盾。 area: tech-engineering category: ai-application tags: - model-distillation - inference-security - key-sharing-vulnerabilities - agent-security people: [] companies_orgs: - Anthropic - OpenAI - Google products_models: - Opus 4.8 - Haiku 4.5 - GPT-5.6 - Gemini media_books: [] draft: true status: evergreen --- 前段时间有厂商在媒体上公开指控竞品大规模蒸馏，大家这才注意到大模型背后的数据攻防已经打得这么频繁。拿强模型的输出来训练小模型，小模型的能力就能往前跨一大截，这件事在工程上早就有大量验证。模型厂商为了保护技术资产，纷纷开始把模型答复前产生的推理过程藏起来，试图切断这条蒸馏路径。 刚读完 arXiv 上的两篇论文，里面的测试结果让人清醒不少。原本大家以为加密推理轨迹就能挡住能力蒸馏，事实上这条路没有起到预期的防护效果。更让人意外的是，厂商为了隐藏推理所设计的机制，顺带把风险带给了所有使用 API 的 AI builder，甚至影响到了你平时调试日志里的数据安全。 ## 跨模型密钥共享引发的解密漏洞 到 2026 年年中，Anthropic、OpenAI 与 Google 均已关闭明文推理过程的展示。模型在给出最终答复前，后台会运行一段复杂的思考过程，里面包含中间推理，还可能带有历史记忆中的隐私信息。为了避免在服务端留存大量用户状态，厂商把这段推理过程打包成一个加密数据块发给客户端，等下一次请求时再由客户端原样传回。这好比厂商塞给你一个带锁的钥匙盒，你每次调用 API 都得带着它，钥匙留在厂商手里，你无法读取里面的文本。 问题在于，同一家厂商生态内的加密推理块可以跨模型互换。这种兼容性给跨模型调用留下了通道。Anthropic 的 Opus 4.8 生成的加密数据块，Haiku 4.5 能够直接接收并处理。GPT-5.6 系列可以回放所有更早 GPT 代的推理轨迹，Gemini 全系列也能互通。 这就引出了一个安全上的不对称。前沿大模型 Opus 4.8 经过了严格的拒绝训练，不会轻易按提示泄露推理。但为成本和速度优化的 Haiku 4.5 缺少同等防护。攻击者不需要正面攻破 Opus 4.8，只要把它生成的加密块塞进给 Haiku 4.5 的请求里，就能借 Haiku 4.5 的手把加密推理解出来。 具体怎么操作？这项研究描述了两种注入方式。第一种是把加密推理块放在当前这一轮回复的开头，让弱模型直接从这段推理往下续写，它会以为自己之前确实想过这些。第二种是塞进之前的对话历史里，弱模型更不会起疑。注入之后，攻击者给弱模型一个简单的指令，让它用特殊标记把自己之前的思考逐字誊写一遍。Anthropic 的 Haiku 4.5 非常配合，研究者只用了同一个固定的提取指令，就让它把这些攻击中的加密推理都老老实实念了出来。每家厂商选的解码器弱模型不同：Anthropic 用 Haiku 4.5，OpenAI 用 GPT-5.6 Luna，Google 用 Gemini Robotics 1.6。 怎么确认提取出来的确实是模型的真实推理，而不是弱模型自己编的？研究者拿了 120 道编程竞赛题做测试，把提取出来的推理重新编码，跟 API 报告的 thinking token 数做对比。两者高度吻合，说明提取出来的内容就是模型在加密块里真正想过的事情。 整个攻击花不了多少钱。用 Haiku 4.5 解码 1 万条推理轨迹，每条大约 1.2 万 token 的输入输出窗口，按标准 API 定价算下来大约 720 美元。花这点钱就能批量拿到 Opus 4.8 的真实推理轨迹，用来蒸馏自己的模型。厂商花了大力气把推理藏起来，结果等于没藏。 ## 依赖公开输出逆向推理轨迹的突破 可能有人会想，这种漏洞只要修好密钥隔离、给小模型加固访问权限就能解决。2026 年 3 月发出来的另一篇研究提出了更严峻的问题：就算把加密块做得再严密，同样阻止不了竞争对手蒸馏模型能力。 这篇论文换了一个完全不同的角度。攻击者压根不需要拿到真实的推理过程，光看模型公开输出的最终答案，就能反向推导出高质量的推理链条；有简短摘要时也可以利用，但摘要不是必要条件。 方法是分三步走的。第一步，攻击者找一个公开的弱推理模型当替身，用它在公开数据集上生成大量输入、推理和答案的样本，再用压缩模型把推理压成摘要，拿这些样本训练一个反演模型。这个反演模型学会的核心技能是：给定输入、答案和可选摘要，反推出推理过程。第二步，把目标模型（比如 GPT-5.4 mini）公开给的答案和可选摘要喂给训练好的反演模型，合成出目标模型的推理轨迹。第三步，拿这些合成推理去训练一个学生模型。研究者同时开源了实现代码。 从简单输出重建完整推理的反演过程 这里有个关键细节：训练反演模型用的替身模型，比目标模型弱得多。研究者在实验里用的是 R1-Distill-Qwen-1.5B（R1-Weak），参数量只有 15 亿，而目标模型 GPT-5.4 mini 是黑盒商业模型。但反演模型从弱替身那里学到的反推能力，能迁移到强目标模型上。 实验结果很扎实。研究者把反演推理拿来训练学生模型，并在多项基准上做了测试。MATH500 数学测试上，一个 70 亿参数的开源模型在用了反演推理训练后，准确率从 68.4% 涨到了 76.0%。换成更大的学生模型，从 13.0% 提高到 52.4%。反演推理也明显优于直接把摘要加答案用于训练的做法。其中，1 万次 GPT-5.4 mini 查询的 API 账单约 173 美元，后续反演和微调不再查询目标模型。 还有一个发现：如果替身模型和目标模型碰巧是同一个，反演出来的推理在部分测试中甚至比真实推理效果更好。真实推理里经常有走弯路、推翻重来的片段，反演出来的推理是干净的前向推导，反而成了更好的训练信号。 代码上的加密缺陷还能通过补丁解决，但答案自带的信息量没法屏蔽。只要大模型输出了逻辑严密的正确解答，外部就能从结果倒推思考步骤。试图用加密来防蒸馏，在信息反演面前效果有限，这条防线在原理上就难以封堵蒸馏需求。 ## 不透明数据块给应用开发带来的安全隐患 提取加密块的影响远不止模型蒸馏。对于做应用的 AI builder 来说，哪怕你完全不碰模型蒸馏，这套加密机制也已经撞上了日常的开发流程。 日常排查 Agent 问题时，大家习惯把排查好的 session log 分享到 GitHub 或论坛上。就算你在发帖前仔细清理了网页明文里的 API 密钥和个人密码，随 API 响应返回的加密数据块里依然可能藏着这些敏感信息。在论文披露的攻击条件下，其他人下载这份轨迹日志后，就能用前面提到的方法恢复里面的文字。 这不是理论上的担忧。这项研究的作者做过统计，他们从 GitHub 和 Hugging Face 搜集了 6,708 条公开的 Agent 运行轨迹，从里面提取出 315,320 个加密推理块。解密后发现，里面包含了 62 个 API 密钥、33 个登录密码、24 个访问令牌、7 个私钥和 30 个个人邮箱地址。更棘手的是，有 64 个敏感数据在前面的明文对话里从来没露过面。模型可能从记忆里把敏感数据写入隐藏推理，也可能在处理匿名化或清理指令时重述这些数据；可见文本删掉后，加密块里的内容仍会保留。 看似干净的日志里藏着开发者删不掉的敏感数据 另一个隐患出在运行轨迹的复用上。大家在搭建长流程 Agent 时，往往会复用优秀的对话上下文来节省调用成本。一旦有人在分享的轨迹里植入恶意加密块，比如写入一条偷偷向外传输文件的隐蔽指令，系统加载这份上下文时可能执行这些动作。实验表明，这种注入方式能让 Agent 在处理正常任务的同时把敏感文件发送出去，明文日志检查也看不到加密块里的指令。 这两个场景展示了一个明确的工程代价：开发者手里拿着一个既无法审查、也无法清理的黑盒数据块。厂商靠加密把推理藏起来保护自身 IP，但在实际应用中，这份安全成本和运维不确定性全落在了开发者头上。 ## 商业保护策略与用户数据控制权的失衡 把推理过程藏起来的思路，实际效果并不理想。在守方这边，靠输出反演就能推导出等效的推理轨迹，小模型也能把加密块里的内容还原出来。防蒸馏的目标没有达成，思考过程也没有保住。 在应用方这边，不透明的加密机制带来了不必要的麻烦。你在 GitHub 上发一份包含 session log 的排查记录，里面可能带着删不掉的 API 密钥；你借用别人分享的 Agent 轨迹，里面可能夹杂着恶意调用的指令。防蒸馏是厂商之间的商业较量，但由此产生的数据安全问题却留给了每一个写代码的开发者。 对用户隐藏数据、却对容易诱导的小模型开放解密权限，这种机制在逻辑上存在内在冲突。厂商保护商业资产的需求可以理解，但把防护成本变成开发者的负担，在架构设计上缺乏合理性。大模型在处理下文时必须解密上下文，只要攻击者能通过提示词控制 Haiku 这类轻量模型，数据块里的信息就随时面临暴露风险。 模型可能从记忆中调取敏感密钥并写入加密块，开发者既看不到内容也无法擦除，数据控制权在这个过程中不自觉地旁落了。随着 Agent 承接越来越复杂的业务流程，每一个调用 API 的开发者都有必要重新评估这种架构带来的潜在风险。