九、模型微调与推理优化

这一章考查从"会用模型"到"会改模型、会部署模型"的跨越。面试重点不是调参细节，而是决策判断：什么时候值得微调、微调怎么不学坏、推理怎么把成本和延迟压下来。

91. 什么情况该微调、什么情况用 RAG、什么情况改 Prompt 就够了？给一个决策框架。

必刷 · 中等

参考答案

结论先行：按"问题的类型"决策，不按技术热度决策。Prompt 解决"怎么做"，RAG 解决"知道什么"，微调解决"能力内化"。三者成本和迭代周期差一个量级以上，选错方向浪费的是几周时间。

决策三问（按顺序）：

1. 改 Prompt 能不能解决？ 指令遵循、格式约束、风格调整、few-shot 引导，绝大多数行为问题先在这一层试。迭代分钟级、零基建、随时可回滚。上限：模型本身能力不够时无效；示例和规则会占上下文、增加每次请求的 Token 成本。
2. 缺的是知识还是能力？ 缺知识——私有领域知识、高频更新的事实、需要溯源引用——必须 RAG，微调记不住也改不动（改一次知识要重训一次，且易幻觉）。缺能力——输出格式死活不稳定、领域话术风格学不像、希望小模型达到大模型的特定任务水平——考虑微调。
3. 训练数据拿得够吗？ 微调至少要几百到几千条高质量标注样本。拿不到，退回前两层；拿得到，还要评估迭代周期（天/周级）是否匹配业务节奏。

对比速查：

维度	Prompt	RAG	微调
解决什么	行为引导	知识注入	能力/风格内化
迭代周期	分钟	小时	天~周
数据需求	几个示例	文档库	数百~数万条标注
知识时效	差	好（随时更新索引）	差（需重训）
可溯源	否	是	否
单次成本	低（但 Prompt 冗长时增加）	中（检索开销）	低（Prompt 变短，可用小模型）

三者可以组合：微调一个领域模型 + RAG 提供最新事实，是生产系统常见形态——微调负责"像一个领域专家"，RAG 负责"知道今天的事实"。典型错误是把频繁变化的知识（价格、库存、政策条文）硬灌进微调数据，上线一周就过期。

面试官可能追问

• 你们业务里有没有微调和 RAG 都不上、纯 Prompt 就跑起来的例子？（分类、抽取、格式化任务占业务大头，多数不需要训练）
• 想把线上大模型 API 换成自部署小模型降成本，中间要做什么？（先收集线上真实请求构造评测集，用微调让小模型在目标任务对齐大模型效果，再灰度切流）
• 微调后效果反而变差，可能是什么原因？（数据质量差、分布与线上不符、过拟合导致灾难性遗忘，见第 96 题）

92. LoRA 的原理是什么？秩 r 和 alpha 怎么选？QLoRA 又优化了什么？

必刷 · 中等

参考答案

LoRA（Low-Rank Adaptation） 的核心假设：微调引起的权重变化量 ΔW 是低秩的。做法是冻结预训练权重 W，在旁边加一条低秩支路，用两个小矩阵乘积近似 ΔW：

• 前向计算：h = Wx + (α/r) · B·A，其中 A 用高斯随机初始化，B 初始化为全零（保证训练起点 ΔW = 0，不破坏原模型）；
• 可训练参数量：每层 r × (d_in + d_out)，远小于 d_in × d_out。7B 模型全参微调要训 70 亿参数，LoRA 只训几百万到几千万，不到 1%；
• 收益：梯度和优化器状态只针对少量参数，训练显存大幅下降；基座冻结，部署时可只发几十 MB 的适配器文件，同一基座挂不同 LoRA 即多任务热切换。

参数选择（经验值）：

• 秩 r：常用 8~64。格式对齐、简单风格迁移用 8~16 就够；复杂领域能力、大数据量用 32~64；再往上收益递减、过拟合风险上升；
• alpha：缩放系数，实际作用是 α/r。惯例设为 r 的 1~2 倍（如 r=16、alpha=32），调 r 时保持 alpha 不变是常见做法；
• 挂载位置：默认只挂 attention 的 q/v 投影即可，任务复杂时可扩展到全部线性层（q/k/v/o + MLP），通常比单纯加大 r 更有效。

QLoRA 优化的是显存：把冻结的基座权重量化成 4-bit NF4（NormalFloat，对正态分布的权重更友好）存放，反向传播时反量化到 BF16 算梯度、只更新 LoRA 部分；配合双重量化（量化常数本身也量化）和分页优化器（防峰值 OOM）。效果：65B 模型微调从多卡 A100 压到单卡 48GB，7B/14B 单张消费级卡可训；论文结论是对齐效果接近 BF16 全参微调，损失很小。

面试官可能追问

• LoRA 为什么推理时几乎零开销？（训练完可以把 B·A 合并进 W，变成普通权重，无额外计算）
• LoRA 的秩是不是越大越好？（不是：任务本身低秩时大 r 徒增过拟合风险，建议从小往上调，用评测集选）
• QLoRA 训出来的适配器能直接用在未量化的基座上吗？（能，LoRA 权重与基座精度解耦，量化只是训练期的存放方式）

93. 全参微调、LoRA、Prompt Tuning 在成本、效果、部署上的差异？

高频 · 中等

参考答案

维度	全参微调	LoRA	Prompt Tuning / P-Tuning
可训练参数	100%	<1%（低秩矩阵）	0.01% 级（软提示向量）
训练显存（7B 参考）	AdamW 下每参数约 16 字节，约 110GB+，需多卡	单卡 24GB 可训，QLoRA 下更低	与 LoRA 相近或更低
效果上限	最高，能改深层行为	大多数任务接近全参，极复杂能力迁移略弱	小模型（10B 以下）明显偏弱，规模上来后才追平
灾难性遗忘	风险最高	低（基座冻结，卸载即还原）	低
部署	整个模型副本，每任务一份全量权重	只发几十 MB 适配器，可热切换、单基座多任务	需推理框架支持注入软提示
工程复杂度	高（分布式训练、合并发布流程）	低，消费级硬件可做	低，但生态支持不如 LoRA 通用

经验结论：

• 默认从 LoRA 起步——成本低、可回退、效果在多数业务任务（风格、格式、领域 SFT）上够用；
• 只有当 LoRA 反复调参仍达不到目标（如需注入大量复杂领域知识、改变推理行为），或本来就是基座团队做通用能力提升，才上全参；
• Prompt Tuning 在业务侧已较少作为首选：小模型上效果差距明显，大模型上与 LoRA 拉不开差距，且部署生态不如 LoRA 顺滑。它更多作为研究基线和极多任务共享一个基座的场景方案。

面试官可能追问

• 全参微调显存里都装了什么？（权重 + 梯度 + AdamW 的一阶/二阶动量，混合精度下还有 fp32 主权重，合计每参数约 16 字节，还没算激活值）
• 多个业务各要一个专属模型，怎么部署最省？（共享一份基座权重，按请求路由加载不同 LoRA 适配器，vLLM 等框架支持多 LoRA 并发服务）
• 什么信号说明该从 LoRA 升级到全参？（数据量上到十万级、LoRA 在评测集上明显低于全参基线、任务需要改变模型深层推理模式）

94. SFT 训练数据怎么构造？需要多少条？数据质量和数量哪个更重要？

高频 · 中等

参考答案

构造方法（按优先级）：

1. 业务日志回流：线上真实请求 + 人工修正的理想答案，分布最贴近实际，是性价比最高的来源；
2. 人工编写：按任务规格说明（指令 + 输入 + 标准输出）生产，质量高但贵，适合种子集和难例；
3. 强模型蒸馏：用 GPT-4 级模型按多样化指令生成答案再人工抽检（细节见第 98 题）。

构造原则：

• 分布对齐：任务类型配比要贴近线上真实流量，不要训练集里 80% 是 A 任务、线上 80% 是 B 任务；
• 指令多样性：同一能力用不同问法、不同长度、不同口语化程度表达，防止模型只认固定句式；
• 答案规范统一：格式、语气、拒答策略要有一致标准，互相矛盾的样本会互相抵消；
• 覆盖边界行为：该拒答的、知识不足的、需要澄清的样本要专门构造，否则模型学不会说"不知道"。

数量级（经验值）：

• 格式对齐、简单风格迁移：几百~几千条即可起效；
• 领域能力（客服话术、行业术语理解）：数千~数万条；
• 更大规模（数十万以上）属于继续预训练/大规模指令学习的范畴，多数业务用不到。

质量优先于数量：LIMA 的结论"约 1000 条精挑细选的数据就能对齐出不错的效果"已被广泛印证；反过来，混入 5%~10% 脏数据（答案错误、格式混乱、互相矛盾）就会显著拉低整体效果，且坏样本教出来的错误行为在线上很难归因。实操上：先造 1~2 千条高质量核心集跑通闭环，验证有效后再放量，同时建立人工抽检和淘汰机制。

面试官可能追问

• 怎么判断训练数据"够了"？（画出数据量—评测分数曲线，进入平台期即边际收益耗尽，继续堆不如回去提质量）
• 答案只有一条"标准写法"吗？（开放任务允许多样性，可以用评分点代替唯一答案；但风格和格式类任务要求强一致）
• 用户日志里的隐私数据怎么处理进训练集？（脱敏/去标识化后再用，必要时签署数据使用授权，训练数据也要过安全合规审查）

95. SFT、RLHF、DPO 的关系和区别？分别解决什么问题？业务侧一般用到哪一层？

中频 · 较难

参考答案

三者是递进关系：SFT 教模型"会做"，RLHF/DPO 教模型"做得更好"。

SFT（监督微调）：行为克隆。给"指令—标准答案"对，做极大似然，模型模仿示范。解决任务格式、基础能力、风格。局限：只能学到示范里的"平均水平"——一个问题只有一个好答案时够用，但开放性任务（同样问题有多个回答，有的更好）无法表达"这个回答比那个好"。

RLHF（基于人类反馈的强化学习）：三段式——SFT 起步 → 训练奖励模型 RM（学习人类对回答对的偏好排序）→ 用 PPO 等强化学习算法最大化 RM 打分（同时加 KL 惩罚防止偏离 SFT 模型太远）。解决"超越模仿、优化整体偏好"（有用性、无害性、语气）。代价：训练链路要同时持有 policy、reference、reward、value 四个模型，显存和工程复杂度高，超参敏感、训练不稳定。

DPO（直接偏好优化）：观察到 RLHF 的 reward 可以由 policy 与 reference 的对数比隐式表示，于是绕过 RM 和 RL，直接拿偏好对（同一 prompt 的 chosen / rejected 两个回答）加参考模型构造损失做分类式训练。数学上等价于优化同目标的 RLHF。优点：只要 policy + reference 两个模型，损失函数稳定、类监督学习式训练，工程门槛大幅下降；效果经验上与 PPO-RLHF 各有胜负、总体接近。

维度	SFT	RLHF (PPO)	DPO
数据	指令—答案对	指令 + 偏好排序	指令 + 偏好对
优化目标	模仿	RM 打分 + KL 约束	隐式 reward
工程复杂度	低	高	中
稳定性	好	差，调参敏感	较好

业务侧一般用到哪层：绝大多数团队止步于 SFT（+ 强模型蒸馏数据）；对回复风格、安全性、用户满意度有产品级要求时上 DPO（用线上偏好数据或强模型构造偏好对）；完整 PPO-RLHF 基本是基座大厂和研究团队的配置，业务团队很少碰。中间还有轻量方案：拒绝采样微调（用 RM 或 judge 选 best-of-n 再 SFT）、迭代式 DPO。

面试官可能追问

• 偏好数据从哪来？（人工标注 A/B 对比、线上隐式反馈如点赞点踩/重新生成、强模型当裁判生成偏好对）
• DPO 有什么坑？（依赖偏好对质量和 SFT 起点分布，chosen/rejected 都离线分布太远会训歪；容易过拟合偏好集，需要控制 epoch 和学习率）
• RLHF 里的 KL 惩罚是防什么的？（防 policy 为刷分跑出离谱分布、奖励黑客，本质是拴在 SFT 模型上的缰绳）

96. 微调后模型通用能力下降（灾难性遗忘）怎么办？训练侧和配比上有什么手段？

高频 · 较难

参考答案

先说现象与成因：微调后目标任务涨点，但通用指令遵循、常识问答、其他任务明显退化——领域数据把参数"带离"了预训练分布，原有的通用表征被覆盖。这是全参微调最常见的事故，LoRA 因为基座冻结天然轻得多，但也不等于零风险。

数据配比手段（首选，最有效）：

• 混入通用指令数据做 replay：用开源通用指令集（如 OpenAssistant、Tulu 系开源指令集）与领域数据混训，经验配比 领域 : 通用 ≈ 1:1 到 3:1，领域数据越少、通用占比要越高；
• 难度与多样性分层：通用数据不是随便凑数，要覆盖指令遵循、常识、多轮对话等维度，并按难度分层采样；
• 加入预训练风格数据：遗忘严重时掺少量通用预训练语料做"复习"。

训练侧手段：

• 降低学习率：从全参常用的 1e-5 量级再降半档到 5e-6 左右，少踩出深坑；
• 控制 epoch：领域数据 1~2 个 epoch 通常就够，多训只会加剧过拟合和遗忘，配合早停（以"领域分 + 通用分"联合曲线选 checkpoint）；
• 正则化与模型合并：L2-SP（把参数拴在初始值附近）、训练后做权重插值（如 WiSE-FT：θ = α·θ_ft + (1-α)·θ_base，α 经验在 0.5~0.8 之间扫）拉回部分通用能力；
• KL 对齐：训练中加与基座输出分布的 KL 约束，思路同 RLHF 的缰绳。

方法侧手段：

• 优先 LoRA：基座冻结，卸载适配器即完全恢复原模型；不同任务各挂各的 LoRA，天然隔离；
• 控制可训练范围（只放开部分层），代价是上限也受限。

评估守底线（不可省）：微调期间必须并行跑一个通用能力回归集——可以是 MMLU / GSM8K / IFEval 等公开基准的精简子集（几百条即可），加自建通用指令回归集。发布门禁：领域指标达标 且 通用指标跌幅在阈值内（如 <2%）才放行。

面试官可能追问

• LoRA 就完全不会遗忘吗？（也会：适配器学到的行为会在基座上"劫持"部分通用输入模式，只是程度轻、且可随时卸载，同样要跑回归集）
• 领域数据和通用数据冲突怎么办（通用答案和领域答案矛盾）？（以领域为准但要显式标注边界场景，让模型学会"在领域语境下用领域答案"，而不是全局覆盖）
• 线上已经发现遗忘了，最快的止血方案？（LoRA 直接摘掉回滚；全参则回滚到上一个 checkpoint，再带通用数据重训）

97. 微调效果怎么评估？只看训练 loss 下降有意义吗？怎么搭评测集？

中频 · 中等

参考答案

结论：训练 loss 基本没意义，eval loss 意义也有限。 loss 下降只说明模型在拟合训练集，既不代表泛化（loss 可以在过拟合状态下继续走低，线上反而更差），也无法反映业务关心的维度（格式合法率、风格符合度、拒答时机）。微调评估必须用独立的评测集 + 业务指标说话。

评测集怎么搭（三层结构）：

1. 目标任务评测集（held-out）：训练数据切分时严格隔离，几百条起步，覆盖任务的主要场景 + 边界场景（该拒答的、超范围的）。指标按任务类型选：
   • 有标准答案：准确率 / F1 / 精确匹配；
   • 格式类：Schema 校验通过率（可全自动化，最有价值的第一道指标）；
   • 开放生成：LLM as Judge 多维打分（正确性、风格、安全性）+ 人工抽检校准；
2. 通用能力回归集：公开基准精简子集 + 自建通用指令集，守灾难性遗忘的底线（见第 96 题）；
3. 线上灰度：最终以业务指标收口——采纳率、转人工率、投诉率、点踩率，离线分数只是代理。

流程要点：

• 训练过程中每 N 步在评测集上评估，画"领域分 / 通用分"双曲线选 checkpoint，而不是取最后一个；
• 多 seed 或多 checkpoint 评估取均值，差方差大的配置直接弃（不稳定）；
• 与微调前的基线模型、以及"Prompt 优化版"基线做三方对比——微调必须同时打赢这两个对手才值得上线，很多所谓微调收益其实 Prompt 就能拿到；
• 评测集版本化管理，每次增删留痕，分数才能跨时间可比。

面试官可能追问

• 评测集要多少条才有统计意义？（看指标方差：二分类式的格式通过率 200~300 条可用；开放任务 judge 打分建议 300 条以上并报告置信区间）
• 训练和评测数据怎么保证不泄漏？（构造阶段统一编号去重，切分后物理隔离存储；上线前跑一遍精确匹配和 n-gram 重叠检查）
• 离线分数涨了但线上没效果，怎么排查？（分布偏移——评测集与线上真实流量不一致；或指标本身与业务目标不对齐，需要用线上日志重新构造评测集）

98. 数据蒸馏是什么？怎么用强模型构造小模型可用的训练数据？怎么控质量？

中频 · 较难

参考答案

定义：用强模型（teacher，如 GPT-4 级闭源模型或更大的开源模型）的输出，去训练小模型（student），让小模型在特定任务上逼近甚至超过 teacher 的性价比。业务里最常见的形态：用闭源旗舰构造数据，微调一个可私有部署的小模型，兼得效果、成本与数据安全。

构造流程（可直接落地）：

1. 定分布：从线上日志或任务规格导出真实 prompt 分布，按场景、难度、问法风格分层，生成 prompt 种子集（也可用强模型扩写指令做增强，思路同 self-instruct）；
2. 生成：用强模型按统一输出规范生成答案；开放任务开 CoT、temperature 适中（0.7 左右）；重要 prompt 做 best-of-n 多路生成；
3. 过滤（质量控制核心，见下）；
4. 格式化：整理成训练格式（指令 / 输入 / 输出，或偏好对），去重（精确 + MinHash / embedding 相似度），按训练配比混合。

质量控制手段：

• 一致性校验：同一 prompt 采样多次，答案互相矛盾（事实类）的丢弃或降权；self-consistency 投票取多数答案；
• Judge 打分：用另一个强模型按 rubric 给蒸馏样本打分，阈值以下剔除（经验上能剔掉一成到三成的问题样本）；
• 规则硬校验：格式合法性、引用是否存在、日期数值是否落在合理区间；
• 事实抽检：涉及事实的样本按比例人工核对，量级 5%~10%；
• 去污染：与评测集做重叠检查，蒸馏数据里混进评测题会造成虚高，这是最常见的自欺；
• 难度对齐：小模型学不会的过长推理链要截断或简化，teacher 的 CoT 直接照搬常超出 student 的容量。

合规注意：用闭源模型输出训练竞品模型可能违反其服务条款，商用前确认 ToS 与数据条款；开源 teacher 则确认 license 允许蒸馏用途。

面试官可能追问

• 蒸馏和直接用强模型推理比，收益在哪？（推理成本降一个量级、可私有化、延迟低；代价是一次性训练成本和效果天花板——student 通常到 teacher 的九成上下）
• 偏好数据也能蒸馏吗？（能：让强模型对多个候选答案排序构造 chosen/rejected 对，喂 DPO，即 RLAIF / judge 蒸馏路线）
• 怎么防止小模型学到 teacher 的幻觉？（事实类任务给 teacher 提供参考文档做接地生成，再按文档做忠实度校验，无据可依的样本直接丢弃）

99. 量化（INT8 / INT4、GPTQ、AWQ）对效果和推理性能分别有什么影响？

高频 · 基础

参考答案

量化是把权重（和激活）从 FP16 压到更低比特，本质是用精度换显存和带宽。

对性能的影响：

• 显存：与位宽成正比。7B 模型 FP16 约 14GB，INT8 约 7GB，INT4 约 3.5GB——直接决定什么卡能跑、单卡能塞多大并发；
• 吞吐/延迟：Decode 阶段是访存瓶颈，权重变小后单次读取的数据量下降，吞吐相应提升（经验上 INT4 相比 FP16 有几十个百分点量级的提升，取决于实现和算子优化）；
• Prefill（算力密集）阶段收益相对小。

对效果的影响（经验量级）：

• INT8：精度损失很小，多数任务几乎无感（1% 以内），接近"免费午餐"；
• INT4：损失更明显，常规对话/抽取可接受，但知识密集问答、复杂推理、长尾代码等任务敏感，可能有几个点的退化，上量前必须过评测集；
• 通用规律：模型越大对量化越鲁棒，同样的 INT4 在 70B 上损失比 7B 小。

GPTQ 与 AWQ 的区别（都是训练后量化 PTQ，只需几百条校准数据，不用重训）：

• GPTQ：逐层量化，利用二阶信息（基于 OBS 思想）最小化每层输出的重建误差，把权重压到 3/4-bit；生态广、速度快；
• AWQ：激活感知——观察到少数"重要权重"（对应激活幅度大的通道）对精度影响大，通过 per-channel 缩放保护它们，等效保持这些权重的更高精度。INT4 下效果保持通常更好，且对推理 kernel 友好，部署侧（vLLM 等）支持成熟。

落地建议：优先 INT4（AWQ/GPTQ）+ 过评测集验证退化在阈值内；知识密集型业务对精度敏感时退到 INT8 或 W8A8；边缘设备另有一套 GGUF/K-quants 生态（llama.cpp）。

面试官可能追问

• 为什么权重能压而激活难压？（权重分布稳定且近似正态，适合离线量化；激活有离群值， outliers 集中在少数通道，故常见"权重 INT4 + 激活 FP16"的 W4A16 方案）
• KV Cache 也能量化吗？（能，INT8 KV Cache 可再省一半 KV 显存、支持更长上下文，需框架支持，注意对长对话质量的影响）
• 量化后的模型还能微调吗？（QLoRA 正是"量化基座 + LoRA"的组合；GPTQ/AWQ 结果本身面向部署，一般不再训练）

100. vLLM 的 PagedAttention 是什么？为什么能大幅提升吞吐？Continuous Batching 呢？

中频 · 中等

参考答案

两者分别管"显存"和"调度"，是 vLLM 吞吐优势的两根支柱。

PagedAttention——KV Cache 的分页管理：借鉴操作系统虚拟内存。传统实现给每个序列按其最大可能长度连续预留 KV Cache，序列长度参差不齐时产生大量内部碎片和预留浪费，实测能浪费掉六成上下的 KV 显存。PagedAttention 把每个序列的 KV Cache 切成固定大小的 block（如 16 个 Token 一块），逻辑上连续、物理上离散，按需分配：

• 浪费只剩最后一个 block 的局部碎片（<4% 量级），同等显存能容纳的并发序列数翻倍级增长；
• 额外收益：Prefix Caching——不同请求共享的 system prompt / few-shot 前缀指向同一批物理块，命中即免算免存；并行采样、beam search 的多个候选也能共享前缀块；
• 整体吞吐提升常见 2~4 倍（相对 HF Transformers 基线更高，具体取决于负载）。

Continuous Batching（迭代级调度）：传统 static batching 要等一批里最长的序列生成完才能整批返回，短序列陪着空转，GPU 利用率被"木桶短板"拖垮。Continuous Batching 把调度粒度降到每一步 decode 迭代：某序列一结束立刻踢出、释放的槽位立刻让排队中的新请求加入（新请求做 prefill 后无缝融入），批次持续保持满载。对用户侧体感是排队延迟下降，对系统侧是吞吐上限抬升。

一句话分工：Continuous Batching 让 GPU 永远有活干，PagedAttention 让显存永远塞得下更多序列——前者解决时间维度的空泡，后者解决空间维度的浪费，配合起来才有高并发下的线性扩容能力。

面试官可能追问

• Prefix Caching 适合什么负载？（system prompt 长且固定、few-shot 模板统一的企业场景收益最大，命中率越高首 Token 延迟越低）
• 有没有 PagedAttention 管不了的开销？（注意力计算本身不变，块寻址有少量额外开销；超长上下文下 KV 总量依然巨大，还需 GQA / KV 量化配合）
• Continuous Batching 和 chunked prefill 什么关系？（把长 prefill 切成小块分步执行，避免长输入请求阻塞其他请求的 decode，是对混合负载的进一步优化）

101. 7B 模型推理需要多少显存？给一个估算方法（权重 + KV Cache + 激活值）。

低频 · 较难

参考答案

总公式：推理显存 ≈ 权重 + KV Cache + 激活与框架开销。以 7B（Llama-2-7B 类，32 层 / 32 头 / 头维 128，MHA）为例逐项算：

① 权重：参数量 × 每参数字节数。

• FP16/BF16：7B × 2B = 14GB；
• INT8：约 7GB；INT4：约 3.5GB。

② KV Cache：2 × 层数 × KV头数 × 头维 × 序列长 × batch × 每元素字节数。

• 代入（FP16）：2 × 32 × 32 × 128 × 2B = 512KB / Token / 序列；
• batch=1、上下文 4K → 约 2GB；batch=32、4K → 约 64GB——并发和上下文一上来，KV Cache 反超权重成为大头；
• 若是 GQA 模型（如 Llama-3-8B，8 个 KV 头）：每 Token 降到约 128KB，等长上下文下 KV 显存省 4 倍，这就是 GQA 成为标配的原因。

③ 激活值：推理时与 batch、序列长度、实现相关，通常占比不大，预留 1~2GB 或总量的 10%~20% 即可；再加上 CUDA context、内存碎片等框架固定开销，同样要留余量。

结论（量级）：

配置	权重	典型可用余量（24GB 卡）
7B FP16	14GB	剩约 8GB 给 KV → 单序列 4K 多路并发可行，长上下文/高并发吃紧
7B INT8	7GB	KV 空间宽裕
7B INT4	3.5GB	12~16GB 级消费卡可跑

实操建议：先按目标场景算出权重 + 峰值 KV（峰值 batch × 最长上下文），再上浮 20% 做安全余量；显存不够时优先顺序是——量化权重 → GQA/KV 量化 → 限制并发或上下文 → 换更大卡。训练态是另一套账（梯度 + 优化器状态，每参数约 16 字节），不能拿推理公式套。

面试官可能追问

• 为什么 Decode 阶段 batch 越大越"划算"？（权重只需读一次就服务整个 batch，访存被摊薄，这就是不断提高并发提升吞吐的原理，直到 KV 显存或算力打满）
• 128K 上下文的 KV Cache 有多大？（MHA 的 7B 按 512KB/Token 算，单序列 128K 就要约 64GB——所以长上下文模型必须用 GQA/MQA、滑动窗口或 KV 量化）
• 框架的开销怎么估？（用 vLLM 的 gpu_memory_utilization 参数反推：框架先 profiling 实测可用 KV 空间，比手算更准，压测时以实测为准）

102. 投机解码（Speculative Decoding）的原理和适用条件？

低频 · 较难

参考答案

要解决的问题：自回归 Decode 是串行的——每生成一个 Token 都要完整读一遍模型权重（访存瓶颈），算力大量闲置。

原理（draft + verify 两阶段）：

1. 起草：用一个小而快的 draft 模型（参数量 1/10 到 1/50 量级）自回归连猜 k 个候选 Token（如 k=4~8）；
2. 验证：目标大模型一次前向并行验证这 k 个位置——因为权重只需读一遍，验证 k 个 Token 的成本远低于串行生成 k 步；
3. 接受/拒绝：用拒绝采样逐个校验 draft Token 与目标模型的分布，一致则接受并前进；遇到第一个不匹配的 Token，从修正后的分布重新采样并停止本轮。数学上可证明最终输出分布与目标模型独立生成完全一致——是无损加速，不是近似加速。

加速条件与适用边界：

• draft 与 target 分布要接近：接受率 0.7~0.8 以上收益才明显（每轮期望前进 token 数 ≈ (1−a^(k+1))/(1−a) 量级，a 为接受率），实测常见 2~3 倍加速；
• 任务输出可预测时收益大：代码补全、模板化文本、RAG 中的引用拼接；
• 收益小的场景：高温创意生成、分布差异大的领域（draft 老是猜错，退化为纯增加验证开销）；
• 工程前提：draft 与 target 通常需共享 tokenizer；部署要同时加载两个模型，显存有额外开销（小模型量级不大）。

变体：不需要独立 draft 模型的 self-speculative 方案——Medusa（在目标模型上加多个预测头一次出多个未来 Token）、EAGLE（在特征层面自回归起草）；以及针对 RAG/代码场景几乎零成本的 Prompt Lookup Decoding（直接从上下文里 n-gram 匹配拷贝候选，赌输出与检索内容高度重合）。

面试官可能追问

• 为什么验证 k 个 Token 的成本远小于 k 步串行？（Decode 每步的瓶颈是把权重从显存搬进计算单元，一次前向只搬一次；验证阶段算力并行度也高）
• 投机解码会改变输出质量吗？（不会，拒绝采样保证分布等价；但随机种子下的具体输出序列会不同）
• 什么情况下负优化？（接受率低（draft 太弱或任务发散）、序列很短、或 draft 推理开销占比过高时，总时间反而增加，上线前必须分场景压测）