压缩

上下文窗口：模型的"工作台" 上下文窗口是模型的工作台——它能在一次推理中处理的所有信息。窗口越大，模型能"看到"的信息越多，但也意味着更高的计算成本和更慢的推理速度。如何在有限的窗口中放入最有价值的信息，是一个核心工程问题。 窗口大小的演进 GPT-3 (2020): 2K tokens GPT-3.5 (2022): 4K-16K tokens GPT-4 (2023): 8K-128K tokens Gemini 1.5 (2024): 1M-2M tokens Llama 4 (2026): 256K-10M tokens 窗口在持续增长，但"能用"和"用好"是两回事。研究表明，即使支持百万token的窗口，模型在长上下文中的表现也远不如短上下文——这就是"Lost in the Middle"问题。 Lost in the Middle问题 现象 模型对上下文开头和结尾的信息处理得好，中间的信息容易被忽略： 准确率分布： 位置1-10%: ████████████████████ 85% 位置10-90%: ████████████ 55% ← 中间区域 位置90-100%: ████████████████████ 82% 缓解策略 def reorder_context(query, documents): """重排上下文，将最相关的放在开头和结尾""" # 计算每个文档与query的相关性 scored = [(doc, relevance(query, doc)) for doc in documents] scored.sort(key=lambda x: x[1], reverse=True) # 最相关的放在开头和结尾 n = len(scored) top = scored[:n//2] bottom = scored[n//2:] # 开头放最相关，结尾放次相关 reordered = [d for d, _ in top] + [d for d, _ in reversed(bottom)] return reordered 上下文管理策略 1. 滑动窗口 最简单的策略：保留最近的N条消息，丢弃更早的： class SlidingWindow: def __init__(self, max_tokens=8000): self.max_tokens = max_tokens self.messages = [] def add(self, message): self.messages.append(message) self._truncate() def _truncate(self): while self._total_tokens() > self.max_tokens: self.messages.pop(0) # 移除最早的消息 问题：完全丢失早期上下文，可能遗忘关键信息。 ...

LLM 知识蒸馏：从大模型到小模型的能力迁移 引言 大模型能力强大但部署成本高昂：70B 模型推理需要多张 A100，延迟数百毫秒。知识蒸馏（Knowledge Distillation）通过让小模型（Student）学习大模型（Teacher）的行为，在保持核心能力的同时大幅压缩模型体积和推理成本。 本文系统梳理 LLM 时代知识蒸馏的方法论，从经典 KD 到最新进展，附完整代码实现。 1. 知识蒸馏的分类体系 1.1 按信息来源分类 知识蒸馏 ├── 白盒蒸馏（White-box） │ ├── Logit 蒸馏（软标签） │ ├── 中间层蒸馏（特征/注意力） │ └── 注意力蒸馏 └── 黑盒蒸馏（Black-box） ├── 响应蒸馏（Response-based） │ ├── 指令跟随蒸馏 │ ├── CoT 蒸馏 │ └── 多轮对话蒸馏 └── 行为蒸馏（Behavior-based） ├── 排序蒸馏 └── 反馈蒸馏（RLAIF） 1.2 按训练方式分类 类型 Teacher 是否参与训练 典型场景 离线蒸馏 ❌ 预先生成数据 大部分场景（最常见） 在线蒸馏 ✅ 同步推理 多模型协同训练 自蒸馏 自身作为 Teacher 同构模型不同层 2. 白盒蒸馏：Logit 级别 2.1 经典 KD Loss Hinton 等人提出的经典知识蒸馏使用 KL 散度对齐 Teacher 和 Student 的输出分布： ...