在大模型的工程落地里蒸馏是个绕不开的词。它用一个小模型去模仿大模型的行为在保留大部分能力的同时降低单位成本。但最近关于“防蒸馏机制被绕过”的讨论把这个原本偏工程优化的概念推到了安全研究的前台。多个头部模型被认为可以通过小模型的针对性提问“套出”隐藏思维链标题中的 Kimi-K3 就是这类概率异常现象的代称。本文会从蒸馏和防蒸馏的定义讲起拆解攻击链路给出用 Python 观察概率异常的脚本并整理可供企业参考的防御清单。理解这一整套问题不需要先成为安全专家但需要清楚一件事模型厂商防的从来不是“用户拿到了答案”而是“别人用一个更小的模型低成本复制出同样的能力甚至还原出内部推理过程”。隐藏思维链、输出扰动、API 限流都是围绕这个目标设计的。下面先把对抗双方争夺的对象讲清楚。1. 大模型蒸馏与防蒸馏先搞清楚对抗双方在争什么1.1 蒸馏的本质是让学生模型逼近教师模型的输出分布模型蒸馏最早是作为一种模型压缩技术出现。一个大模型在推理时需要大量显存和算力服务成本高响应速度也难以满足高并发场景。蒸馏的思路是不直接去训练一个小模型而是让这个小模型去模仿大模型在同样输入下的输出包括最终答案和每个 token 的概率分布。在标准蒸馏过程中教师模型会在某个输入上产出一个 logits 向量学生模型也产出同样的 logits。训练目标通常是让这两个分布尽量接近常见做法是计算 KL 散度或交叉熵损失。关键点在于学生模型学到的不仅是“正确 token 是什么”还包括“教师模型在每一个候选 token 上分配了多少概率”。这部分信息比单纯的正确答案丰富得多。# 伪代码蒸馏损失的核心思想 def distillation_loss(student_logits, teacher_logits, temperature): student_probs softmax(student_logits / temperature) teacher_probs softmax(teacher_logits / temperature) # 温度越高分布越平滑暴露的分布信息越多 return kl_divergence(teacher_probs, student_probs)这里的 temperature 是一个重要参数。温度升高会让概率分布变平使小概率 token 也参与学习温度降低会让分布更集中在高概率 token 上。攻击者如果希望从教师模型身上获取更多内部信息通常会优先采样低温度输出因为高概率 token 更接近模型“真正想说的内容”。1.2 防蒸馏机制保护的是答案背后的推理过程如果一个模型只能返回最终答案蒸馏的攻击效果会被削弱。真正有价值的信息藏在两处一是模型在生成过程中曾经产生过但没有展示出来的思维链二是模型在候选 token 上的概率分布它可能暴露模型内部对问题的“判断优先级”。防蒸馏机制通常沿着两条线设计。第一条线是训练侧让模型在输出前就把中间推理过程隐藏起来或者让推理链在多个语义等价的变体中随机切换使攻击者无法稳定提取规律。第二条线是服务侧通过 API 参数限制、日志监控、请求频率控制让攻击者无法拿到足够多的样本来逼近真实分布。隐藏思维链并不是为了阻止用户得到正确答案而是避免把“解题过程”也变成可抄袭的训练数据。但从最近的研究讨论来看这种隐藏并不是绝对可靠。即使模型不在文本里输出推理链它的概率分布仍可能保留推理痕迹。1.3 三个关键概念对照教师模型、学生模型、蒸馏攻击概念作用在攻击场景中的角色教师模型提供训练信号的大模型通常是闭源或高成本服务被攻击的目标攻击者希望从它的输出中提取能力学生模型通过模仿教师模型训练出来的小模型攻击者最终要得到的产物低成本复刻教师能力蒸馏攻击通过大量问答、采样、对比概率分布来复现教师行为绕过隐藏思维链和服务限制的整套方法这里要特别强调蒸馏攻击并不一定需要拿到模型权重。黑盒蒸馏攻击只需要调用 API收集输入输出对然后训练学生模型。正因为攻击成本集中在数据采集中厂商才会在 API 输出上做各种限制。2. 攻击链路拆解小模型如何把隐藏思维链“套”出来2.1 黑盒场景下提问设计与重复采样为什么有效闭源模型只开放 API攻击者拿不到 logits 或中间层信息只能在文本输入输出之间做统计。这让一些人误以为模型是“黑盒”内部信息不会泄露。但实际上黑盒只是拿不到内部状态并没有堵死所有信号通道。攻击者的第一个工具是提问设计。同样一个问题用不同的表述、不同的上下文、不同的前置约束去问模型可能产生不同的中间输出。比如要求“先解释思路再给答案”时部分模型会因为指令遵循而输出一定长度的推理过程但厂商在服务层可能对这类提示词做了关键词命中限制于是攻击者会换用更隐晦的方式例如让模型以“伪代码”“分步骤计划”“给朋友讲解”等形式输出。第二个工具是重复采样。即使模型每次只返回最终答案它内部使用的采样路径不同答案也可能在多个候选之间漂移。攻击者会固定一个问题调节 temperature 和 top_p重复请求几十次甚至几百次记录每次返回的 token 序列和概率上的倾向再从中估计模型内部最稳定的路径。这种“多次采样后求一致路径”的方法在思维链隐藏不彻底时可以明显提高提取概率。2.2 概率分布是比文本更敏感的泄露通道只观察最终文本能拿到的信息非常有限。但如果能够拿到每个生成 token 的 logits 或概率分布情况就不一样了。模型内部对题目的理解、对每一步推理的置信度都会体现在概率分布里。即使模型最终没有把“先算 A再算 B最后得到 C”这句话写出来它在生成“C”之前分配给“A”“B”相关 token 的概率也可能高于其他无关 token。这就像一个学生标准答案写得非常简练但他在做题时的草稿纸已经被统计学家看见了。草稿纸不一定被展示出来但痕迹会体现在他犹豫过哪些选项、对哪些步骤更确定。对大模型来说logits 就是这张草稿纸的浓缩版本。在很多 API 里厂商不会直接返回 logits但攻击者可以通过大量采样来估计概率。具体做法是固定输入多次调用生成接口记录每个候选 token 出现的频率用频率逼近真实概率分布。如果模型内部隐藏了某段推理链那么与这段推理链强相关的 token 会出现概率突增这种突增在正常回答里是不应该出现的。2.3 “Kimi-K3 概率异常”到底在描述什么标题里的 Kimi-K3 并不是一个所有研究机构都认同的正式命名。在公开讨论中它更像是一个被反复引用的案例名称用来指代一类可复现的概率异常现象某个小模型在模仿大模型时对特定问题输出的概率分布出现显著偏离正常水平的高置信尖峰而这个尖峰正好对应大模型内部思维链中的关键 token。下面用一个简化示意来理解这种现象。假设模型正常回答“答案是 42”时候选 token“42”的概率是 0.35其余候选分布比较平缓。但在某个疑似被攻击的异常样本里模型在输出“42”之前先把某个中间步骤 token 的概率推到 0.9 以上而这个中间步骤在最终答案里根本没有出现。这种“不该有却突然出现的确定性”就是一个典型概率异常。位置正常输出概率疑似泄露输出概率说明最终答案 token0.350.55仍然高但不异常无关普通 token0.02 到 0.050.01 到 0.03分布略变隐藏推理链关键 token0.030.91显著异常出现尖峰需要注意的是仅凭一次采样不能判断异常。Kimi-K3 类案例通常需要重复多轮才能看到稳定的尖峰。如果同一个中间 token 在多次采样中都表现出远超基线的高概率才能怀疑模型内部存在可被蒸馏信号捕捉到的推理步骤。2.4 论文所展示的“绕过”不等于防御体系彻底失效“全面告破”这个说法容易让人误以为防蒸馏机制从此没有价值。更准确的理解是在论文覆盖的实验条件里现有单一防御手段可以被绕过。攻击之所以能成功是因为防御措施往往是静态的。隐藏思维链能挡住文本提取却挡不住概率分布的统计推断API 限流能挡住高频调用却挡不住分布在不同账号、不同时间片上的低频采样。逐一突破不等于完全失效。一个模型如果同时使用了输出扰动、训练侧随机化、API 监控和模型水印攻击者要花费的成本会显著上升。所谓“全面告破”更像是在提醒防御方不能只依赖某一种机制必须把多层防御叠加起来。3. 用最小脚本观察概率异常从 logits 到熵这一部分的目标不是攻击模型而是帮助读者在自己的模型或实验环境里建立一套“概率异常观察工具”。只有先能稳定观察概率分布才能验证自己的模型有没有被蒸馏泄漏也才能评估防御策略是否有效。3.1 实验环境与依赖准备建议在 Python 3.9 以上环境中运行核心依赖是 Transformers、PyTorch 和 NumPy。如果只是观察 API 返回的候选概率也可以用 requests 加 pandas但完整查看 logits 还是本地模型更方便。依赖项作用版本建议transformers加载模型和 tokenizer4.30 以上越新越好torch前向计算与 softmax2.0 以上numpy统计计算任意较新版本scipy计算熵和 KL 散度可选安装命令pip install transformers torch numpy scipy本文示例使用本地开源小模型不针对任何真实闭源服务。落地到自己项目时需要把model_name换成实际模型路径并确认本地显存满足加载要求。3.2 计算 top token 概率分布和熵编写一个函数输入提示词输出每个位置的 top token 概率和整条序列的平均熵。熵越高说明模型在该位置越不确定熵越低说明模型越确定。当某个位置出现异常低熵并且低熵 token 与最终答案无关时就值得进一步检查。import torch import numpy as np from transformers import AutoTokenizer, AutoModelForCausalLM def load_model(model_nameQwen/Qwen2.5-0.5B-Instruct): tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto ) model.eval() return tokenizer, model def inspect_distribution(prompt, tokenizer, model, top_k10): inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.no_grad(): outputs model(**inputs) logits outputs.logits[0, -1, :] # 只看最后一个 token 的 logits probs torch.softmax(logits.float(), dim-1).cpu().numpy() top_indices np.argsort(probs)[::-1][:top_k] entropy -np.sum(probs * np.log(probs 1e-12)) print(fprompt 长度: {inputs[input_ids].shape[1]}) print(f位置熵: {entropy:.4f}) for idx in top_indices: token tokenizer.decode([idx]) print(f {token!r:20s} - {probs[idx]:.4f})这段代码只检查最后一个生成位置。实际排查时可以把输入拆成多段逐一检查每个位置的概率分布找出异常尖峰出现的位置。3.3 多次采样量化概率抖动单次 logits 只能说明模型在当前上下文里的倾向。要判断某个高概率 token 是稳定现象还是随机噪声需要多次采样。下面通过多次调用同一个生成函数统计目标 token 的出现频率和概率方差。import random def sample_token_probability(prompt, tokenizer, model, target_token, n30, temperature0.8): target_id tokenizer.convert_tokens_to_ids(target_token) freq 0 prob_list [] for _ in range(n): inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.no_grad(): logits model(**inputs).logits[0, -1, :] probs torch.softmax(logits.float() / temperature, dim-1).cpu().numpy() prob_list.append(probs[target_id]) if torch.argmax(logits) target_id: freq 1 prob_list np.array(prob_list) print(f目标 token: {target_token}) print(f平均概率: {prob_list.mean():.4f}) print(f概率标准差: {prob_list.std():.4f}) print(f最大概率: {prob_list.max():.4f}) print(f最小概率: {prob_list.min():.4f}) print(f成为最高频 token 的次数: {freq}/{n})如果目标 token 的平均概率明显高于同类 token且标准差很小说明它不是随机波动而是模型内部的稳定倾向。这个信号可以用来定位隐藏推理链中的关键 token。3.4 一个简化版异常判定流程在实际项目中建议按照下面的顺序判断一个概率尖峰是否属于异常。准备对照组选取多个结构相似但没有隐藏推理链的普通问题记录相同位置 token 的概率基线。目标组采样对疑似泄露问题重复采样 30 次以上记录每个候选 token 的概率。计算差距目标问题中关键 token 的平均概率是否高于对照组基线 3 个标准差以上。排除共现词如果该 token 是问题中已经出现过的词或者与最终答案强相关不能算异常。组合判断异常尖峰应该同时满足“高概率、低方差、与表层答案无关、多次重复稳定出现”四个条件。判定流程的伪代码如下def is_probability_anomaly(prob_list, baseline_mean, baseline_std, threshold3.0): mean np.mean(prob_list) if mean 0.5: return False if baseline_std 0: return mean 0.5 z_score (mean - baseline_mean) / baseline_std return z_score threshold这里的阈值不是固定值。对安全研究来说可以先用 3 倍标准差做粗筛再人工检查具体 token 是否会出现在隐藏推理链中。3.5 正常输出与疑似泄露输出的对比示例用 JSON 记录两种输出可以帮助团队快速对齐判断标准。正常输出里模型最终只给出答案候选 token 概率比较均匀疑似泄露输出里某个中间步骤 token 突然获得高置信度。{ question: 一个长方形周长是 24宽是 5求长, normal_output: { text: 答案是 7, last_token_probs: { 答案: 0.24, 是: 0.22, 7: 0.38, 长方形: 0.05 }, entropy: 1.21 }, suspicious_output: { text: 答案是 7, last_token_probs: { 答案: 0.23, 是: 0.21, 7: 0.38, 周长: 0.11, 宽: 0.88 }, entropy: 0.64 } }在这个示例中模型最终输出仍然是 7但宽这个 token 的概率异常升高。它并不是当前需要生成的 token却长期高于其他候选说明模型内部的推理路径可能把“宽”当作一个关键中间变量。防御方如果看到类似输出就应该检查提示词是否被人为设计来触发隐藏思维链。4. 从攻击视角反推防蒸馏策略四个层面的防御设计4.1 输出层扰动让概率分布不再成为稳定指纹攻击者能够在黑盒下还原概率分布依赖的是模型输出分布的稳定性。如果同一个问题每次返回的概率都略微不同并且这种不同无法被简单平均消除攻击者获取的信息质量就会下降。一种做法是在输出 logits 上加入可控噪声。对每个候选 token 的概率加一个满足拉普拉斯分布或高斯分布的随机扰动扰动幅度要控制在“不改变用户可感知的答案质量”和“显著破坏概率统计规律”之间。还有一种做法是提高输出温度让概率分布更加平滑减少极低概率 token 与高概率 token 之间的鸿沟。但温度过高会影响回答质量所以更推荐随机温度策略不同请求使用略有差异的温度而不是固定在同一值。输出层扰动不是万能药。如果攻击者采样次数足够多噪声会被平均掉。它的价值在于把攻击成本抬高到不可接受的水平而不是彻底阻断攻击。4.2 训练侧抑制减少可用于蒸馏的信息量训练侧防御的目标是让模型本身不具备容易被提取的隐藏思维链结构。常见思路包括推理链随机化同一个问题在不同采样温度下内部推理路径可以跳转到不同方案让攻击者难以从概率上锁定唯一关键 token。关键步骤退火在训练时削弱推理链中特定位点与输出 token 之间的统计依赖避免出现“中间 token 必高概率触发最终答案”的模式。指令遵循防套取在模型训练中加强“只输出最终答案不展开推理过程”的指令遵循能力同时降低模型对“换个说法就能绕过限制”的敏感性。需要注意训练侧防御往往会牺牲少量下游任务效果。在实验环境里可以先在敏感任务子集上做评估确认防御没有导致准确率大幅下降再逐步上线。4.3 API 侧治理通过调用特征识别蒸馏行为输出层和训练侧防御是在模型内部做文章API 治理则是在服务边界上拦截。蒸馏攻击通常有几个明显特征同一份问题模板被大量变体改写、请求间隔规律、temperature 和 top_p 频繁切换、单账号请求量远高于正常用户。API 侧可以记录以下字段{ request_id: 7f2c5d0a-1b4e-4b3a-8d6e-9b9c0a1d2e3f, user_id: u_100023, model: internal_teacher_v2, sampled_temperature: 0.62, sampled_top_p: 0.91, question_hash: a1b2c3d4e5f6, question_length: 128, response_entropy_mean: 0.83, response_entropy_std: 0.12, request_count_1h: 156, prompt_family_id: geometry_reasoning, risk_score: 0.87 }基于这些字段可以建立简单的蒸馏行为识别规则。例如单账号小时请求量超过阈值并且 response_entropy_std 明显低于正常用户同时 question_hash 集中在少数 prompt 模板就应该触发人工检查。4.4 模型侧水印与审计为模型打上可追踪标记模型水印是一种被动防御方法。它不是阻止攻击者蒸馏而是在被蒸馏后留下可追踪证据。常见做法是在训练数据里插入一些特定触发短语这些短语在正常业务中几乎不会出现但一旦攻击者把模型输出作为训练数据学生模型会继承这些触发行为。当厂商发现市面上出现一个高度疑似自家模型蒸馏出的模型时可以构造触发短语输入给该模型观察是否输出了水印特征。这个方案不能防止蒸馏但可以用于事后取证和维权。水印设计要避免污染正常业务输出一般选择生成概率极低的随机 token 组合并且只在特定 prompt 下触发。4.5 防御手段适用位置速查防御层面核心思路优点不足输出层扰动破坏概率分布稳定性实现简单可动态调整采样足够多时可被平均训练侧抑制减少隐藏思维链的结构性痕迹从根上降低泄露可能影响部分任务效果API 侧治理识别批量采样行为阻断数据采集阶段无法识别慢速分布式攻击模型水印追踪被蒸馏产物有利于事后追责不能阻止攻击发生企业防御的实际难度在于需要同时使用多个层面而不是任选其一。如果只做输出扰动攻击者可以增大采样量如果只做 API 限流攻击者可以换账号如果只做训练侧抑制模型在复杂推理任务上的能力可能下降。5. 复现与排查中最容易踩的坑5.1 把采样噪声当成思维链泄露大模型生成本身具有随机性。同一个问题在不同温度下概率分布天然会抖动。很多刚开始做检测的人看到一个低熵 token 就认为是隐藏思维链实际上只是采样波动。排查方法必须做多轮重复采样并设置对照组。对照组使用同样长度、同样主题但没有隐藏推理链的问题。如果异常 token 在对照问题里也频繁出现说明它只是普通高频词不是思维链泄露。5.2 忽略温度、top_p 与随机种子造成误判温度会改变概率分布的锐度。低温度下高概率 token 的概率会被放大低概率 token 被压缩容易出现“看起来高置信”的假信号。top_p 影响候选集合的大小也会干扰熵的计算。在复现实验时必须固定采样参数或者明确说明参数区间。比较好的做法是分别记录 temperature0.2、0.8、1.2 三档下的概率分布对比后再下结论。只用一个温度下的一次采样结果很容易得到错误结论。5.3 用准确率判断蒸馏是否成功忽略了分布信号在防御评估中很多团队只关注蒸馏出来的小模型在下游评测集上的准确率。准确率很高就认为防蒸馏失效准确率不高就认为防御成功。这种做法忽略了概率分布层面的泄露风险。即使小模型最终答案经常出错它仍然可能学会了教师模型的推理路径。等到攻击者调整提示词或者做跨任务迁移隐藏能力会被激活。评估防蒸馏效果时除了准确率还要比较学生模型与教师模型在 token 分布上的 KL 散度、在隐藏推理链关键 token 上的命中率。5.4 对真实闭源 API 做批量探测的合规与稳定性风险研究攻击方法时如果直接对真实闭源模型做大规模批量探测容易踩到服务协议和合规红线。高频调用可能导致账号封禁更严重的是未经授权对商业服务做逆向提取可能违反服务条款甚至相关法律。建议在任何批量化验证之前先确认研究对象是否允许这类测试。企业内部可以建立专用测试模型或者使用开源模型模拟一个“带隐藏思维链的教师模型”。把攻击链路和检测脚本跑通后再与合规团队确认是否可以对真实 API 做受限实验。5.5 常见异常速查表问题现象常见原因检查方式处理建议单个 token 概率突然很高采样噪声或模型偏好多次采样计算均值和方差增加采样次数看是否稳定不同请求间概率差异大temperature 或 top_p 不一致核对请求参数固定随机种子和采样参数正常回答质量下降输出扰动强度过大对比扰动前后的评测分数调小噪声幅度或改用随机温度API 请求被误杀蒸馏检测规则过严查看风险分和请求特征增加人工复核降低自动封禁比例小模型能复现教师推理链防蒸馏只做了一层检查四层防御是否都有落地补上训练侧抑制和水印6. 企业落地防蒸馏检测的实操清单6.1 发布环境前检查哪些内容防蒸馏不是模型上线后才考虑的问题。在发布前应该把下面这些点纳入检查流程是否确认模型输出中不包含超出产品设计意图的中间推理链。是否对 logits 或概率分布做过稳定性评估是否存在高置信的隐藏 token 尖峰。API 是否记录了足够的请求字段用于后续蒸馏行为分析。是否有临时关闭特定 prompt 模板或特定用户的熔断机制。是否制定了对真实 API 做批量测试的合规流程。是否在小规模请求上验证了输出层扰动不会影响关键业务指标。建议使用清单表逐项确认检查项是否完成负责人备注隐藏思维链风险排查是 / 否算法负责人至少覆盖常见推理类任务概率异常基线建立是 / 否安全负责人记录 30 个以上对照问题API 日志字段完整是 / 否平台负责人包含温度、top_p、熵合规审批流程是 / 否法务 / 安全明确禁止未授权批量采样6.2 监控告警指标与阈值设计生产环境不能只靠人工复现。建议针对下面的指标设置告警单用户小时请求量超过基线 3 倍时告警。同一 prompt 模板的请求数量超过 100 次/小时时告警。响应熵的标准差低于正常用户标准差的一半时告警。特定 prompt 家族的风险分超过 0.8 时进入人工审核。阈值需要根据业务情况调整。文本生成类业务和代码生成类业务的请求分布差异很大不能直接套用同一套阈值。更合理的方式是先运行两周基线采集再根据基线数据设置分位数阈值。6.3 从检测到处置的分级响应流程发现疑似蒸馏攻击后建议按下面流程处理确认不是采样噪声。先放大采样次数检查概率尖峰的是否稳定。查看用户请求模式。确认是否高频、是否使用多个账号、是否集中在同一类 prompt 模板。调整输出扰动强度。如果只是单点异常可以先对该用户提高温度和噪声观察概率分布是否被打散。限流或封禁。确认批量蒸馏行为后再限制该账号的并发和小时请求量。回溯水印。对已上线的小模型或外部疑似模型使用水印触发短语验证来源。复盘并更新规则。把本次发现的特征补充到蒸馏行为识别模型中。这套流程的意义在于不是发现异常就立刻封禁用户。对于正常开发者的高频调用误封会造成严重体验问题。分级响应既能降低蒸馏风险又能保留正常业务的可用性。回到最开始的讨论“小模型套出大模型隐藏思维链”和“Kimi-K3 概率异常”其实指向同一个核心问题即大模型的概率输出会在无意中暴露内部推理结构。无论是做模型服务的一方还是做安全研究的一方都应该意识到只隐藏文本答案是不够的概率分布同样是一条需要被保护的通道。本文给出的观察脚本和防御清单可以直接用在自己的模型监控环境中。下一步最值得做的练习是在一个开源模型上模拟“带隐藏思维链的教师 学生蒸馏”的小实验通过对比正常输出和疑似异常输出的熵、KL 散度和 token 命中率建立对这类问题的直观感受。这个实验跑通之后再回到自己负责的模型服务上设计防御策略会比只看论文结论可靠得多。