防蒸馏机制失效？黑盒条件下小模型如何“套出”大模型思维链

近年来，大模型行业一直在打两场仗：一场是明面上的性能军备竞赛，另一场是暗面上的模型攻防战。最近被社区反复讨论的一项研究工作，把第二场仗推到了新的高度——它绕过当前主流闭源模型的防蒸馏机制，让一个参数量小得多的模型，通过黑盒交互“套出”了大模型隐藏的思维链。换句话说，模型厂商辛辛苦苦藏起来的推理过程，被当成另一种形式的“数据”提取了出来。

这不是普通的技术新闻。它同时踩中了三个关键问题：大模型的知识产权怎么保护、思维链到底算不算核心资产、模型输出API还能不能放心开放。更让人警惕的是，研究里提到的某个观察对象在统计上出现了明显的异常信号——一个模型在特定生成概率上出现了可以被检测的偏移。从材料看，这个现象指向一个结论：蒸馏攻击不仅能好用，甚至已经留下了可被识别的“指纹”。

这篇文章不打算复述论文的每一张图。我会从蒸馏攻击的核心思路说起，分析防蒸馏机制为什么会失效，再结合Kimi-K3的概率异常现象，帮读者理解这场攻防的本质。读完你会得到三样东西：第一，知识蒸馏、思维链、防蒸馏机制之间的关系；第二，黑盒条件下小模型提取大模型推理过程的大致原理；第三，从模型提供方和应用方两个视角，如何评估风险并搭建基础防护策略。

1. 这篇文章真正要解决的问题

先回答一个现实问题：为什么我们要关心防蒸馏机制被攻破？

过去做模型蒸馏，大家默认的前提是白盒——你能拿到教师模型的权重或logits，才能把知识转移到学生模型里。开源模型蒸馏开源模型，这是社区常规操作。但现在攻击者把目标对准了闭源模型，而且只在黑盒条件下，通过API接口做输入输出采样，就能在目标任务上“复刻”出大模型的能力，甚至“套出”大模型的推理链路。

这件事的影响分三层：

第一层是资产层面。闭源模型公司投入巨资训练出来的模型，如果可以通过采样方式被“搬运”到小模型里，那模型本身作为商业资产的护城河就会变浅。第二层是安全层面。思维链一旦被提取，模型在推理过程中暴露的隐私信息、内部决策依据、甚至可能存在的偏见都会被放大。第三层是工程层面。如果API输出可以被用来做蒸馏训练，那么所有提供大模型服务的公司都必须重新审视自己的访问控制、频控策略和输出策略。

这篇文章最适合三类读者：

• 你在公司里负责大模型API接入或模型选型，需要理解开放接口的潜在风险。
• 你在做大模型应用开发，依赖闭源模型做推理，想知道自己的应用是否会被误判为“蒸馏攻击”。
• 你在做模型安全或算法治理，需要理解防蒸馏机制的基本原理和失效场景。

如果你只是好奇“小模型怎么偷大模型”，这篇文章也能给你一个体系化的答案，但更重要的是，我会告诉你这场攻防战的边界在哪里。

2. 基础概念：知识蒸馏、思维链与防蒸馏机制

在深入讨论攻击原理之前，先把三个容易混淆的概念讲清楚。

2.1 知识蒸馏：从教师模型到学生模型

知识蒸馏（Knowledge Distillation，KD）最早由Hinton等人在2015年提出。核心思路是让一个小模型（学生）去学习大模型（教师）的输出分布，而不仅仅学习硬标签。教师模型的软输出（soft logits）携带了类别之间的相似性信息，学生模型通过这些软标签，能用更少的参数逼近教师模型的性能。

传统蒸馏有几个必要条件：

• 能够拿到教师模型的logits输出。
• 教师和学生模型的任务空间一致。
• 蒸馏过程通常是离线批量进行的。

这些条件决定了传统蒸馏是白盒或半白盒的。当目标模型是闭源模型，只有API接口时，传统蒸馏思路就必须改变。

2.2 思维链：模型推理的“内部草稿”

思维链（Chain-of-Thought，CoT）是指大模型在给出最终答案之前，逐步生成的一系列中间推理步骤。比如让模型解一道数学题，它可能先写“设x为…，根据条件可得…”，然后一步步推导出答案。

思维链的价值在于：它不只是过程文本，更包含了模型的推理逻辑、信息检索路径、决策偏好。对一些复杂任务来说，思维链本身就是高价值的数据资产。这也是为什么很多闭源模型厂商在API层面对思维链展示做限制——他们担心用户通过大量采样，把模型的推理模式逆向出来，从而低成本复制模型能力。

2.3 防蒸馏机制：模型厂商的“护城河”设计

防蒸馏机制是模型厂商为了阻止别人通过API输出训练出可替代模型而设计的一系列策略。常见的防蒸馏手段包括：

从材料看，这次讨论的研究工作并没有依赖单一漏洞，而是组合利用了多个机制的有效性边界。这也提示我们：防蒸馏不是某一个开关能解决的问题，而是一个系统工程。

2.4 蒸馏攻击与传统蒸馏的本质区别

传统蒸馏是合作式蒸馏——教师模型的所有者主动提供知识。而蒸馏攻击是对抗式蒸馏——攻击者通过API黑盒采样，在没有任何白盒信息的情况下，尽可能恢复教师模型的决策边界和行为模式。这是两者最本质的区别。

用一句话总结：传统蒸馏是在“师傅愿意教”的前提下带徒弟，而蒸馏攻击是在“师傅拼命防”的前提下偷师，并且偷的还不只是招式，还有师傅心里默念的心法。

3. 攻击原理：小模型如何“套出”隐藏思维链

现在进入核心问题：黑盒条件下，小模型怎么把大模型的思维链“套”出来？

从公开讨论的研究思路看，攻击过程大致分为四个阶段。我这里只做原理性拆解，不展开具体提示词和实现细节，重点讲清楚“为什么能成功”。

3.1 阶段一：定向数据采集

攻击者首先需要构造大量高质量提示词，诱导大模型输出包含推理过程的长答案。这个过程的技术含量在于“诱导策略”——不是简单地问“请一步步思考”，而是通过多轮对话、角色设定、任务拆分等方式，让模型在解决复杂任务时自然输出中间推理。

有一个容易被忽视的点：大模型即使不显式输出思维链，它的最终答案也携带了推理信息。因为模型在生成每一个token时，都会根据上下文计算一个概率分布。答案的措辞、结构、冗余度，都隐含了它的“思考路径”。

3.2 阶段二：分布捕获与统计分析

这是最关键的一步。攻击者不只是收集文本，而是收集文本背后的概率信息。

假设大模型API返回了某个token序列，攻击者可以通过多次采样、温度调整、对数概率请求等手段，近似还原模型在该上下文下的输出分布。这些分布特征类似于模型的“行为指纹”。

更值得注意的是，即使模型不返回logprobs，攻击者也可以通过重复采样统计token出现的频率，估算出每个位置的概率分布。这个过程可以被看作：用大量样本逼近真实分布，从而在统计意义上恢复模型的部分内在状态。

从材料看，这次研究的一个重要贡献，就是证明了这种分布捕获在实际闭源模型中不仅可行，而且稳定。

3.3 阶段三：数据增强与伪标注

有了大量输入输出对之后，攻击者并不会直接拿去训练，而是会做一轮数据增强。常用手段包括：

• 对同一提示词做多次采样，保留一致性高的答案。
• 用更强的开源模型对输出做过滤和去噪。
• 对答案做标准化处理，统一格式。
• 用自举（self-bootstrapping）方式迭代扩充数据集。

这个阶段的目标是提升训练数据的质量和多样性。毕竟，从API采集的数据噪声很大，直接训练容易让模型学到错误模式。

3.4 阶段四：模仿训练

最后一步是用采集到的数据训练一个小模型。训练方式不限于传统蒸馏损失，更常用的是监督微调（Supervised Fine-Tuning，SFT）和偏好优化（Preference Optimization）。

这里有一个值得强调的点：攻击者并不需要完全复现大模型的能力，只需要在目标任务上达到接近的效果。换句话说，蒸馏攻击的目标是“够用”，而不是“100%复刻”。这就大大降低了攻击门槛。

回到思维链的话题。小模型通过训练学到的不仅是答案格式，还有隐含在答案中的推理模式。比如在数学任务上，小模型可能学到了“先写公式再代入数值”的解题风格；在代码任务上，可能学到了“先写注释再写实现”的结构。这些模式积累到一定程度，就等价于把大模型的思维链“套”了出来。

3.5 为什么黑盒条件下依然有效

很多人会困惑：既然只能看到输出，为什么能学到内部推理？

答案在于：大模型的思维链和最终输出是耦合的。最终输出不是独立于推理过程生成的，而是推理过程的“投影”。只要你能收集到足够多的投影，就有机会在统计上重构出投影背后的规律。

打个比方：你虽然看不到厨师在厨房里怎么切菜，但只要把这位厨师做的每一道菜都吃一遍，并且对照菜谱反推，一段时间后，你对这位厨师口味的判断会比只看一道菜准确得多。蒸馏攻击做的就是这件事——“吃菜”加“反推”。

4. Kimi-K3重现概率异常：一个值得警惕的信号

文章标题里提到了一个有意思的观察：Kimi-K3重现概率异常。这个概念很多读者可能第一次接触，我需要先解释清楚“重现概率”是什么。

4.1 什么是重现概率

在自回归语言模型中，模型生成token的过程可以看作是在每个位置根据上下文计算一个概率分布，然后从这个分布中采样。所谓重现概率，就是给定相同的上下文前缀，模型再次生成某个特定token或token序列的概率。

正常情况下，一个训练良好的模型，其重现概率应该遵循一个相对稳定的分布。如果某个模型在训练过程中吸收了另一个模型的大量输出，那么它在某些上下文下对特定token的选择概率，会发生可检测的偏移。这种偏移不是随机噪声，而是“学习痕迹”。

4.2 概率异常说明了什么

当一个小模型在特定任务上的重现概率出现系统性的异常偏移时，通常意味着三件事之一：

• 该模型确实在训练数据中包含了来源模型的大量输出。
• 该模型的训练过程中存在对特定先验分布的过度拟合。
• 该模型在某类任务上的学习目标与通用语言建模目标不一致。

从标题看，Kimi-K3是在某个观测实验中被发现出现了这种概率异常。更稳妥的判断是，这不是一个孤立的“翻车事件”，而是蒸馏攻击可被检测的一个重要证据。换句话说，被蒸馏的模型并不是完美的“克隆体”，它会在概率统计层面留下可被追踪的指纹。

4.3 概率指纹的检测思路

从研究角度，检测一个模型是否被蒸馏，可以通过以下统计指标：

这些指标单独使用都存在误判风险，但在组合使用时，可以形成一个有效的“蒸馏指纹识别”流程。

4.4 对Kimi-K3案例的谨慎解读

需要强调，我从材料中看到的是“Kimi-K3重现概率异常”这一现象，并不是说Kimi-K3一定是某个攻击的产物。这里的异常更可能是一个检测结果，说明在某个对比实验中，Kimi-K3的生成概率与常规模型存在显著差异。

对这个现象，业界有两种解读：

一种解读认为，这说明Kimi-K3在训练中大量借鉴了其他顶尖模型的输出，是蒸馏技术的一个实证。另一种解读认为，这只是模型在特定任务上经过定向优化后的正常表现，概率偏移不代表“被蒸馏”，也可能代表“被微调”。

从技术严谨性出发，我更倾向于这样的表述：Kimi-K3重现概率异常是一个信号，它提醒我们，模型的生成行为可以被量化分析，蒸馏行为不是无痕的。对于负责模型安全的人来说，这个信号本身就是价值。

5. 防蒸馏机制为何会失效

分析完攻击原理，我们回到一个更本质的问题：为什么现有防蒸馏机制会失效？

不是某一项防护设计得不好，而是攻击者利用了多层防护之间的空隙。

5.1 输出必须保留语义空间

防蒸馏机制有一个天然矛盾：模型厂商为了保证API可用，必须让输出足够自然、正确、稳定。如果对输出做大幅度的扰动或加密，用户体验就会急剧下降。

换句话说，防蒸馏机制只能在“不破坏模型正常输出”的约束下进行，而正常输出本身就是最大的信息泄漏通道。你想让模型帮你解题，它必须输出解题过程和答案；而这个过程无论怎么裁剪，都会携带推理痕迹。

5.2 推理过程与输出耦合不可消除

思维链的隐藏是有成本的。你可以限制模型不输出“逐步推理”，但你无法让模型在推理时完全改变内部状态。模型的最终答案、措辞选择、括号用法、数字精度，都是内部状态的“外溢信号”。

攻击者不需要理解这些信号，只需要用统计方法把它们收集起来。这也是为什么“隐藏思维链”机制失效的关键原因：你藏住了文字，藏不住概率分布。

5.3 检测规则的滞后性

防蒸馏机制依赖攻击检测，而攻击检测本身就是一个滞后过程。先有新的攻击方法，然后才有检测规则。从材料看，这次的研究显然利用了检测规则尚未覆盖的采样模式。

举个例子：某个模型厂商可能设置了“单用户每分钟最多请求100次”的频控规则。攻击者通过多账号、分布式代理、低速率长时间采样来绕过。更隐蔽的是，攻击者可以模仿正常用户的使用模式，把采样过程拉长到几天甚至几周，让频率检测完全失效。

5.4 防蒸馏和防滥用是两个目标

很多模型厂商把防蒸馏和防滥用混在一起设计。比如“检测到异常请求就拒绝服务”，这个策略既能防滥用，也能防部分蒸馏攻击。但两者的检测特征并不完全相同。

滥用检测关注的是请求量、内容违规、并发数。而蒸馏攻击的特征可能表现为：输出长文本比例高、重复请求模式明显、请求覆盖领域广泛、生成结果的多样性需求低。如果只按滥用规则检测，很容易漏掉真正的蒸馏行为。

5.5 攻击成本与防御成本的不对称

攻防不平衡是防蒸馏机制失效的底层原因。攻击者只需要成功一次，防蒸馏措施需要每次都对。攻击者可以在离线状态反复调整策略，防御方却必须在毫秒级响应中做出判断。

从经济角度看，蒸馏攻击的成本可能只有算力和API调用费，而防御方案需要持续投入研发、监控、误伤处理。这种不对称使得防蒸馏很难做到“万无一失”。

6. 对模型方与开发者的影响评估

防蒸馏机制被攻破，影响的不只是模型厂商，也包括所有基于大模型API做应用的开发者。我们用不同角色的视角来分析。

6.1 对闭源模型厂商的影响

最直接的影响是模型资产的贬值风险。如果一个下游团队可以通过数千次API调用，蒸馏出一个在特定任务上达到90%效果的替代模型，那么闭源模型在该任务上的商业壁垒就会被削弱。

更深层的影响是安全投入的加码。模型厂商需要重新评估API输出的粒度、日志策略、访问控制和数据签名机制。不是简单的加个频控就完事，而是要建立一套覆盖数据采集、分布监控、攻击识别的完整体系。

6.2 对应用开发者的影响

对应用开发者来说，最大的风险不是“被攻击”，而是“被误伤”。如果模型厂商为了防蒸馏而加大对API输出的限制，正常开发者可能会遇到：

• 输出被截断，长文本任务无法完成。
• 请求被限流，影响生产环境稳定性。
• API价格调整，因为厂商需要覆盖防蒸馏的成本。
• 输出格式改变，影响下游解析逻辑。

6.3 对安全研究者的影响

对安全研究者来说，这次攻防对抗提供了一个很好的研究方向。蒸馏攻击的检测与防御是一个完整的课题，包括概率指纹识别、数据投毒防御、输出扰动策略、模型水印技术等。

尤其是“概率异常检测”这个方向，它不只是一个研究工具，也可以成为生产环境中的监控手段。通过持续监控模型输出的概率分布，可以在早期发现潜在的蒸馏行为。

6.4 对开源模型社区的影响

对开源社区来说，蒸馏攻击的影响是双面的。一方面，社区可以利用蒸馏技术把开源大模型的能力迁移到小模型上，这是可行的应用方向。另一方面，如果开源模型被大量用于蒸馏闭源模型，可能引发更严格的API访问策略，最终反噬到所有开发者身上。

更稳妥的判断是：短期内，蒸馏攻击会让闭源模型厂商加强控制；长期看，平衡点应该是“防恶意复用，但不阻碍合理使用”。

7. 防护方案设计与代码示例

讲完原理和影响，下面给出一套基础的防护方案。这套方案不是我临时想出来的，而是从常见的API安全实践中归纳出来的，可以作为模型提供方和开发者的入门参考。需要说明的是，真实生产环境的防蒸馏远比这些示例复杂，本文提供一个可落地的起点。

7.1 防护思路总览

完整的防蒸馏方案应该覆盖四个层面：

7.2 示例一：行为模式异常检测脚本

下面的Python脚本演示了如何基于API日志，检测是否存在疑似蒸馏采样行为。核心逻辑是分析单个用户的请求密度、输出长度和请求模式。

# 文件路径：anomaly_detector.py import time from collections import defaultdict, deque class DistillDetector: def __init__(self, max_requests_per_minute=100, max_long_output_ratio=0.8): self.max_requests_per_minute = max_requests_per_minute self.max_long_output_ratio = max_long_output_ratio self.user_requests = defaultdict(lambda: deque()) self.user_long_output_count = defaultdict(int) def record_request(self, user_id: str, output_length: int, timestamp: float = None): timestamp = timestamp or time.time() window = self.user_requests[user_id] window.append(timestamp) # 只保留最近60秒的请求记录 while window and timestamp - window[0] > 60: window.popleft() if output_length > 5000: self.user_long_output_count[user_id] += 1 def is_abnormal(self, user_id: str) -> bool: window = self.user_requests[user_id] if len(window) > self.max_requests_per_minute: return True # 统计长输出占比 total_requests = len(window) if total_requests == 0: return False long_output_ratio = self.user_long_output_count[user_id] / total_requests if long_output_ratio > self.max_long_output_ratio and total_requests > 10: return True return False if __name__ == "__main__": detector = DistillDetector() # 模拟正常用户：短输出，低频率 for i in range(20): detector.record_request("user_normal", 300) # 模拟疑似攻击者：大量长输出请求 for i in range(80): detector.record_request("user_suspect", 6000) print("normal user abnormal:", detector.is_abnormal("user_normal")) print("suspect user abnormal:", detector.is_abnormal("user_suspect"))

这段脚本实现了一个简化的请求频率和输出长度联合检测逻辑。真实场景中，还需要考虑用户IP、设备指纹、请求时间分布等多个维度。

7.3 示例二：输出采样扰动策略

对于模型提供方，可以通过对输出概率分布做微小扰动，增大攻击者逆向恢复分布的难度。下面是一个简化示例，展示了如何在采样阶段加入噪声。

# 文件路径：sampling_perturbation.py import random import math def perturb_logits(logits, epsilon=0.1, seed=None): """ 对logits加入小幅度噪声，增加攻击者恢复原始分布的难度。 注意：epsilon过大会影响生成质量，实际使用建议在0.01~0.1之间。 """ if seed is not None: random.seed(seed) noise = [random.gauss(0, epsilon) for _ in range(len(logits))] perturbed = [logit + n for logit, n in zip(logits, noise)] # 重新计算softmax概率 max_logit = max(perturbed) exp_logits = [math.exp(logit - max_logit) for logit in perturbed] total = sum(exp_logits) probs = [e / total for e in exp_logits] return probs if __name__ == "__main__": # 模拟一个词汇表的logits original_logits = [2.0, 1.0, 0.5, 0.2, -0.5] perturbed_probs = perturb_logits(original_logits, epsilon=0.05) print("perturbed probabilities:", perturbed_probs)

这里的扰动不是为了让生成结果变差，而是为了让攻击者在有限样本下难以精确估计真实的token概率分布。这种策略的核心是：在“保护模型”和“维持输出质量”之间找平衡。

7.4 示例三：思维链输出控制配置

对大模型服务提供商，还可以从配置层限制思维链的暴露。下面是一个简化的服务端策略配置示例，以JSON为展示格式。

{ "model_protection": { "enabled": true, "chain_of_thought": { "hidden": true, "allowed_tasks": ["math", "coding"], "summary_only": true }, "output_limit": { "max_tokens": 4096 }, "sampling": { "temperature_range": [0.0, 1.2], "perturbation": 0.05 }, "rate_limit": { "per_user_per_minute": 60, "per_ip_per_hour": 1000 } } }

这份配置体现了几个关键策略：

• 思维链以“摘要形式”输出，而不是完整推理过程。
• 对输出长度做硬性限制，降低一次性采集的信息量。
• 对采样温度做范围控制，防止攻击者通过极端温度获取异常分布。

7.5 示例四：概率异常监控脚本

最后给一个面向模型提供方的概率异常检测脚本思路，用于在模型上线后持续监控生成概率是否存在明显偏移。

# 文件路径：prob_monitor.py import numpy as np from scipy.stats import entropy def monitor_distribution_shift(baseline_probs, observed_probs, threshold=0.1): """ baseline_probs: 模型上线初期的参考概率分布 observed_probs: 当前观察到的概率分布 threshold: KL散度阈值，超过则告警 """ kl = entropy(observed_probs, baseline_probs) print(f"KL divergence: {kl:.4f}") if kl > threshold: print("ALERT: significant distribution shift detected") return True return False # 模拟：上线初期token概率 vs 一段时间后的概率 baseline = np.array([0.4, 0.3, 0.2, 0.1]) observed_normal = np.array([0.39, 0.31, 0.2, 0.1]) observed_shifted = np.array([0.5, 0.25, 0.15, 0.1]) monitor_distribution_shift(baseline, observed_normal) monitor_distribution_shift(baseline, observed_shifted)

这个脚本使用KL散度比较两个概率分布，当偏移超过阈值时输出告警。在生产环境中，这个监控应该做成实时管道，与日志系统、告警系统联动。

8. 常见问题与应对策略

在讨论防蒸馏和思维链保护时，开发者和安全团队经常会遇到以下问题。这里整理成表格，方便排查。

这里特别提醒一个工程问题：如果你在正常的应用开发中需要稳定获取长文本输出（比如代码生成、文章生成），如果服务端增强了输出长度限制，一定要在应用层做好失败重试和降级策略。

9. 最佳实践与工程建议

聊完攻击和防护，最后落到工程实践。不管是模型提供方还是应用开发者，下面这些建议都值得纳入日常流程。

9.1 最小权限原则贯穿API设计

给用户的API能力，应该恰好满足他们的业务需求，而不是开放全部能力。比如，如果业务只需要摘要输出，就不要让对方能拿到逐token概率；如果业务不需要长文档生成，就应该对单次输出长度做限制。最小权限可以显著降低被恶意利用的风险。

9.2 建立输出行为基线

模型上线后，应该建立一套输出行为基线——包括token长度分布、生成速度、用户请求分布、常见输出风格。一旦某个指标出现明显偏移，告警系统应当及时发现。基线的价值不在于提前阻止攻击，而在于让“异常”变得可见。

9.3 日志留存与合规边界

防蒸馏和事后的审计离不开完整日志。但日志本身也包含敏感数据，必须在合规框架内处理。建议做到：

• 对prompt和输出中的隐私信息做脱敏。
• 日志保留周期要符合当地法规和企业安全策略。
• 对API调用者的身份标识做加密存储。
• 日志查询需要权限审批和操作审计。

9.4 模型更新与策略灰度发布

防蒸馏策略的变化不宜一次性全量下发，建议采用灰度发布。先在小流量用户上观察误伤率，再逐步扩大范围。类似的，模型版本更新带来的行为变化，也要提前准备对比测试，避免下游应用被静默影响。

9.5 从“防蒸馏”转向“防滥用”

更成熟的视角是把防蒸馏纳入防滥用体系，而不是单独设计规则。也就是说，与其花大量精力去识别“哪些请求是在做蒸馏”，不如构建一套综合考虑请求频率、输出特征、用户行为、资源消耗的异常检测系统。这样即使未来出现新的蒸馏攻击方式，已有的检测框架也能覆盖大部分风险。

9.6 对普通开发者的三点建议

如果你的业务依赖大模型API，但又担心受到模型厂商防蒸馏策略的影响，建议做三件事：

• 在应用层做模型版本适配层，不要硬编码特定API行为。
• 对关键输出做缓存，减少重复调用，降低对API频繁访问的依赖。
• 保持对模型厂商策略变更的监控，提前评估影响。

10. 总结与延伸方向

防蒸馏机制被攻破这件事，真正的技术含义不是“谁偷了谁”，而是大模型的能力边界和保护边界同时被重新定义。思维链作为模型推理的“内部草稿”，正在变成一种可被量化、提取、复用的高价值数据资产。这一轮攻防战告诉我们：只要模型仍然通过文本输出能力，就必然存在可被观测和学习的统计影子。

如果你在关注这个方向，下一步值得深入研究三块内容：一是蒸馏行为的概率指纹检测方法，二是输出层面的扰动与保护算法，三是在合规框架下对模型复用边界的界定。尤其是第三点，它已经从技术问题变成了商业问题和治理问题。

对大多数开发者来说，不需要急着给所有方案打补丁，但应该保持两件事：对外部模型输出的依赖保持警惕，对模型行为的变化保持监控。这两点做到了，即使防蒸馏机制继续演进，你的系统也不会措手不及。