知识蒸馏的根本动因是：大模型的能力不应被其参数规模所垄断——如何让小模型"继承"大模型的行为分布，是深度学习工程化的核心命题。
Bucilua 等人在 KDD 2006 发表"Model Compression"，首次系统性地提出用大模型的软输出（soft label）训练小模型，核心洞察是：大模型的输出概率分布比 one-hot 标签携带更多结构信息（"dark knowledge"）。这是蒸馏思想的原始形态，但彼时深度学习尚未崛起，影响有限。
Geoffrey Hinton、Oriol Vinyals 和 Jeff Dean 在 NeurIPS 2015 Workshop 发表"Distilling the Knowledge in a Neural Network"，引入温度参数 $T$ 软化 softmax 输出，使小模型能学习类间相似度结构。这篇论文定义了蒸馏的标准范式：教师产生软标签，学生最小化 KL 散度。此后工业界大规模采用，Google 将其用于搜索排序模型压缩。
随着 BERT 的爆发，DistilBERT（Sanh et al., 2019）、TinyBERT（Jiao et al., 2020）、PKD（Sun et al., 2019）相继提出对注意力图、隐层表示进行逐层对齐的"特征蒸馏"。这一阶段的关键突破是：不仅蒸馏最终输出，还蒸馏中间计算过程，使小模型的内部表示空间向教师靠拢。但这些方法的前提是师生架构同构（都是 Transformer encoder）。
GPT 系列崛起后，蒸馏面临新挑战：自回归模型的输出是逐 token 的条件分布序列，序列级蒸馏需要对齐指数级的路径空间。SeqKD（Kim & Rush, 2016）用教师生成的序列作为伪标签，规避了分布匹配问题，但丢失了软标签的结构信息。MiniLLM（Gu et al., ICLR 2024）则提出用反向 KL 散度替代正向 KL，避免学生在教师低概率区域浪费容量。
扩散语言模型（Diffusion LM）的兴起带来了根本性的架构异质性问题：教师是自回归模型（单向因果注意力，逐 token 生成），学生是扩散模型（双向注意力，并行去噪）。两者的生成机制、概率分解方式、时间步语义完全不同，传统 token 级 KL 对齐失效。MDLM、SEDD 等工作建立了扩散 LM 的理论基础，而 TIDE（2025）等工作开始系统探索如何将自回归教师的知识"翻译"到扩散学生的去噪轨迹上，标志着蒸馏研究进入跨范式时代。
设自回归教师对序列 $\mathbf{x} = (x_1, \ldots, x_L)$ 的联合概率为： $$p_{\text{AR}}(\mathbf{x}) = \prod_{t=1}^{L} p_\theta(x_t \mid x_{
跨架构蒸馏的整体逻辑是：先将异构教师的知识"投影"到与学生生成机制兼容的监督信号空间，再在扩散时间步上分层对齐，使学生在并行解码时复现教师的语言分布。
对训练集中每条序列 $\mathbf{x}$，用自回归教师对每个位置的候选词汇打分，生成 token 级软分布 $\tilde{p}(x^i)$。关键设计选择：不直接用教师的条件概率 $p_{\text{AR}}(x_t \mid x_{
对每条序列按均匀分布采样时间步 $s \sim \mathcal{U}(0,1)$，按 absorbing 或 Gaussian 噪声机制生成 $\mathbf{x}_s$。为什么不固定单一时间步？扩散模型的去噪能力需要在整个噪声谱上均匀训练：低噪声时步（$s$ 小）考验细粒度词汇选择，高噪声时步（$s$ 大）考验全局语义结构，两者对应教师知识的不同层次。关键参数：噪声调度（线性 vs. cosine）显著影响各时间步的学习难度分配。
学生模型（双向 Transformer）接收 $(\mathbf{x}_s, s)$，对所有被掩码位置输出预测分布 $p_\phi(x^i \mid \mathbf{x}_s, s)$。蒸馏损失为该预测与教师软标签的 KL 散度，与标准扩散去噪损失加权求和：
python loss = alpha * kl_divergence(teacher_soft_label, student_logits) \ + (1 - alpha) * cross_entropy(true_label, student_logits)权重 $\alpha$ 控制蒸馏强度，通常随训练进行退火（早期依赖教师，后期依赖真实标签）。为什么保留真实标签损失？防止学生过拟合教师的错误，特别是教师在低频词上的不确定性可能被放大。
训练完成后，学生在推理时执行多步并行去噪（通常 10~50 步，远少于序列长度 L）。每步对所有位置同时预测，再按置信度选择性 unmask。关键工程细节：去噪步数是质量与速度的核心旋钮——步数越少越快但质量下降，需要通过 confidence-based masking（优先 unmask 高置信位置）缓解误差累积。与自回归教师相比，推理 FLOPs 可降低 $O(L)$ 倍（并行 vs. 串行），但每步的注意力复杂度为 $O(L^2)$，实际加速比取决于序列长度和硬件并行度。
若师生模型层数可对应，可额外对齐隐层表示：将教师自回归层的 key-value 表示通过线性投影映射到学生双向层的表示空间，最小化余弦距离。这一步在实践中效果不稳定，因为单向/双向注意力的表示几何结构存在系统性差异，强制对齐可能损害学生的双向建模能力。
跨架构蒸馏是大模型时代"能力民主化"的关键技术路径。自回归 LLM（GPT-4、LLaMA-3）积累了海量预训练知识，而扩散 LM 因并行解码在实时生成场景（TTS、代码补全、对话）具有天然优势。将前者的知识迁移到后者，可在不牺牲生成质量的前提下大幅降低延迟。工业界已有实践：字节跳动的 PLANNER、Meta 的 MDLM 系列均在探索此路径。未来 3~5 年，随着扩散 LM 架构成熟，跨架构蒸馏将成为模型部署的标准工具链之一。
当前核心开放问题：①如何在不枚举全词表的前提下高效构造教师软标签（计算瓶颈）；②扩散步数极少时（1~3步）的质量崩溃机制尚不清楚；③多模态场景下（语音/图像 token 混合序列）跨架构蒸馏的对齐策略几乎空白；④教师与学生的"知识容量不匹配"问题——当学生参数量远小于教师时，蒸馏是否会引入系统性偏差？
AI评估基础设施从"附属工具"演变为独立计算瓶颈，根本动因是：模型能力的增长速度已超过人类评估者和传统自动化指标的判别上限，评估本身成为了制约研究迭代速度的新瓶颈。
ImageNet（Deng et al., 2009）开创了"固定测试集+单一指标"的评估范式，GLUE（Wang et al., 2018）将其移植到 NLP。这一时期评估的计算成本可忽略不计：跑一次 GLUE 只需几分钟，结果确定性强，社区围绕排行榜形成了高效的竞争机制。评估基础设施几乎不需要专门设计，一个 Python 脚本足矣。
BERT 在 GLUE 上超越人类基线（2019），GPT-3 在 SuperGLUE 上接近饱和（2021）。研究者发现模型在基准上的高分并不等价于真实能力——模型学会了利用数据集偏差（Annotation Artifacts，Gururangan et al., 2018）。这一时期出现了两个应对方向：①持续推出更难的基准（BIG-Bench, 2022；MMLU, 2021），②引入人类评估（Chatbot Arena 的前身）。但人类评估的成本是自动化的 100~1000 倍，无法支撑高频迭代。
Zheng et al. 在 NeurIPS 2023 发表"Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena"，系统验证了用强 LLM（GPT-4）评估弱 LLM 输出的可行性。这一范式迅速成为主流：AlpacaEval、Arena-Hard、WildBench 等基准全部采用 LLM judge。但随之而来的问题是：每次评估需要调用 judge 模型数千~数万次，评估成本从"可忽略"跃升为"与训练成本同量级"。一个 7B 模型在 AlpacaEval 上的完整评估需要约 800 次 GPT-4 调用，成本约 $50~$200。
随着强化学习后训练（RLHF、DPO、GRPO）的普及，模型迭代频率从"每季度一个版本"加速到"每天数十次实验"。每次实验都需要评估，评估成本开始在总研究预算中占据显著比例。Anthropic、OpenAI 内部报告（部分通过博客和论文泄露）显示：在大规模后训练实验中，评估基础设施的 GPU 小时消耗已达到训练本身的 30%~50%。社区开始讨论"eval compute"作为独立资源维度的必要性，HuggingFace、Scale AI 等机构开始将评估服务作为独立产品提供。
DeepInfra 登陆 HuggingFace 推理提供商（本日新闻[13]）、OpenAI Stargate 扩容（[11]）等事件的背后，有一条隐线：大规模评估对推理基础设施提出了与生产推理不同的需求——高并发、短序列、低延迟、结果可复现。专门针对评估场景优化的推理栈开始出现，标志着评估基础设施工程化进入成熟期。
评估瓶颈的工程解法是一个多层次的系统设计问题：从单次评估的效率优化，到评估任务的并发调度，再到跨实验的结果复用，形成完整的评估基础设施栈。
首先区分三类评估场景，它们对基础设施的需求截然不同： - 开发时快速反馈（每次 commit 触发）：需要极低延迟（<5分钟），允许使用小型代理基准（Mini-benchmark），牺牲覆盖度换速度。 - 实验对比评估（每次训练 run 结束后）：需要统计显著性，要求足够样本量，延迟可接受 30~60 分钟。 - 发布前全量评估：覆盖所有基准，需要完整的可复现性保证，延迟可接受数小时。 关键工程决策：不要用同一套基础设施服务三类需求。混用会导致快速反馈被慢评估阻塞，或全量评估因资源竞争而结果不稳定。
LLM-as-Judge 是当前评估成本的主要来源。工程优化方向： 批处理（Batching）：Judge 模型的输入通常是独立的 prompt-response 对，天然支持大 batch。将 batch size 从 1 提升到 64，吞吐量可提升 10~20 倍（受 KV cache 内存限制）。 Judge 模型蒸馏：用 GPT-4 judge 的结果训练一个小型本地 judge（如 7B 模型），在大多数评估维度上与 GPT-4 judge 的一致性可达 85%~90%，成本降低 100 倍。Prometheus（Kim et al., 2024）、JudgeLM 是代表性工作。 缓存与去重：相同的 (prompt, response) 对在不同实验中重复出现（尤其是基准 prompt 固定时），建立内容哈希缓存可避免重复调用 judge，命中率通常在 30%~60%。
python cache_key = sha256(f"{prompt}|{response}|{judge_model_version}") if cache_key in eval_cache: return eval_cache[cache_key] else: result = judge_model.evaluate(prompt, response) eval_cache[cache_key] = result return result全量评估（如 MMLU 的 14000 题）在早期实验阶段是浪费。自适应采样策略： 分层采样：按能力维度（数学、代码、常识等）分层，每层抽取固定比例，保证覆盖度的同时减少总量。 序贯检验（Sequential Testing）：在评估过程中持续计算当前模型与基线的差异显著性，一旦达到预设置信度（如 p<0.05）即停止，无需跑完全部样本。平均可节省 40%~60% 的评估计算量。 难度自适应：优先评估模型在"边界题"（历史上不同模型分歧最大的题目）上的表现，这些题目的信息量最高。
评估任务的计算特征与训练任务截然不同： - 训练：大 batch，长时间占用 GPU，通信密集（all-reduce） - 评估：小 batch，短时间，完全独立（embarrassingly parallel） 工程实践：将评估任务调度到训练间隙的碎片化 GPU 时间（spot instance），或使用专门的推理集群（高并发、小显存实例）。Kubernetes + Ray Serve 是常见组合：Ray 负责评估任务的分布式调度，每个 judge 调用作为独立 task，自动处理失败重试和负载均衡。 关键指标：评估吞吐量（evaluations/hour）、评估延迟（P99 latency）、评估成本（$/1000 evaluations）。目标是使评估吞吐量 ≥ 训练实验产出速率，避免评估队列积压。
评估结果的可复现性是工程上最容易被忽视但最重要的属性： 评估快照：锁定 judge 模型版本、采样温度（通常设为 0）、prompt 模板版本。任何一个变量的改变都会导致历史结果不可比。 结果数据库：将所有评估结果（含原始 judge 输出、元数据）存入结构化数据库，支持跨实验的统计分析和趋势追踪。 评估即代码（Eval-as-Code）：评估配置用代码定义并纳入版本控制，与模型 checkpoint 一一对应，确保任何历史实验可完整复现。
评估基础设施工程已成为 AI 研究效率的隐性杠杆。OpenAI、Anthropic、Google DeepMind 的内部评估平台（Evals、Model Card Evaluations）直接决定了这些机构的模型迭代速度。HuggingFace 的 Open LLM Leaderboard、Chatbot Arena 作为社区评估基础设施，已成为整个开源社区的"公共计量标准"。对于中小型 AI 团队，评估基础设施的投入回报率极高：花 1 周建设评估栈，可节省后续数月的无效实验。
当前核心开放问题：①LLM judge 的位置偏差（position bias）和自我偏好（self-preference）尚无完美解决方案；②多模态评估（视频、音频生成质量）的自动化 judge 可靠性远低于文本；③评估基准的"污染检测"（训练数据是否包含测试题）仍是系统性难题；④如何设计"永不饱和"的动态基准，使其随模型能力自动调整难度，是下一代评估基础设施的核心挑战。