大模型工程面试题

这一篇补的是“模型工程”部分：结构、训练后方法、推理优化、部署和选型。它和 Agent 不冲突，而是 Agent 的底层能力来源。

答题主线

部署模型时可以想成开一家只在午休高峰营业的餐馆：权重是厨房设备，KV Cache 是每桌正在用的餐具，并发一多，光把设备搬进店里远远不够。真正的容量要看长短请求混合时的 P95 和故障余量。

回答这类题时，建议按下面这条线展开：

模型结构 -> 训练方式 -> 对齐方法 -> 推理优化 -> 部署限流 -> 成本和效果权衡

面试官通常想确认你是否理解这些事情：

• 模型为什么能工作。
• 不同注意力和位置编码有什么差别。
• 预训练、SFT、RLHF、DPO 分别解决什么问题。
• LoRA / QLoRA 为什么常用。
• 量化、并发、缓存、批处理、限流怎么影响成本和延迟。

一、模型结构基础

Q1：Transformer 解决了什么问题？

考察点

考察你是否理解 Transformer 相对 RNN/CNN 的计算特征，以及 self-attention 的工程代价。

回答脉络

先讲它替代了什么，再讲为什么它适合语言任务。

参考答案

Transformer 用 attention 机制建模序列中不同位置之间的关系，替代了传统 RNN 在长距离依赖和并行计算上的劣势。它的好处包括：

• 支持并行训练。
• 能建模长距离依赖。
• 结构适合大规模预训练。

在面试里我会补一句注意力的核心形式：

Attention(Q, K, V) = softmax(QK^T / sqrt(d_k))V

训练时同一序列的 token 可以并行计算；自注意力能直接建立远距离依赖，代价是标准 attention 对序列长度 n 的计算和显存大致为 O(n^2)。因此长上下文会显著增加 prefill 压力，工程上才会关注 FlashAttention、稀疏注意力、GQA 和 KV cache。Transformer 让大模型能高效处理大规模文本数据，但“能并行训练”不等于“推理可以一次生成完整答案”。

常见追问及答案

• 问：Transformer 为什么比 RNN 更适合预训练？ RNN 按时间步依赖，训练难以充分并行，长距离信息还要经过很多步传递；Transformer 在训练时可对整段序列并行做矩阵计算，更适合 GPU/TPU 和大规模数据。
• 问：Transformer 有没有代价？ 有。标准 self-attention 的序列长度复杂度近似二次增长，显存和长上下文延迟都很高；推理阶段还要逐 token decode。

容易扣分

• 只说“attention 解决长依赖”，不提 O(n^2) 代价。
• 把训练并行误说成生成过程也能完全并行。

Q2：自注意力、交叉注意力和多头注意力有什么区别？

考察点

考察你能否从 Q、K、V 的来源解释三种注意力，并联系编码器-解码器、多模态和检索场景。

回答脉络

把“关注谁”讲清楚。

参考答案

• 自注意力：序列内部各位置之间相互关注。
• 交叉注意力：一个序列去关注另一个序列，比如 decoder 看 encoder 输出。
• 多头注意力：并行使用多个注意力头，从不同子空间捕捉信息。

更具体地说，自注意力中 Q、K、V 来自同一个序列；交叉注意力中 Q 来自当前解码序列，K、V 来自另一个序列，例如翻译任务里的 encoder 输出，或多模态模型里的图像特征；多头注意力则把隐藏维度拆成多个头并行计算，再拼接投影。多头不是简单复制模型，而是让不同头学习不同关系，例如局部语法、指代和长距离依赖。

常见追问及答案

• 问：decoder-only LLM 还有交叉注意力吗？ 典型纯文本 decoder-only 架构主要使用带因果 mask 的 self-attention；多模态或带外部编码器的架构可以额外加入 cross-attention。
• 问：causal mask 的作用是什么？ 生成位置只能看到当前位置及之前的 token，不能偷看未来答案，保证训练目标与自回归推理一致。

容易扣分

• 把 cross-attention 说成“不同 head 之间注意”。
• 忘记 decoder self-attention 的因果 mask。

Q3：MHA、MQA、GQA 有什么区别？

考察点

考察你是否能用 head 数和 KV 共享解释三者的显存/吞吐取舍。

回答脉络

重点讲 KV 共享和推理效率。

参考答案

• MHA（Multi-Head Attention）：每个头都有自己的 Q/K/V，表达力强，但推理开销大。
• MQA（Multi-Query Attention）：多个头共享 K/V，减少推理时 KV cache 占用，速度更快。
• GQA（Grouped-Query Attention）：介于两者之间，一组 query 头共享一组 K/V，兼顾效果和效率。

工程上常见的选择逻辑是：如果更关注推理效率和显存占用，MQA/GQA 往往更有吸引力；如果更关注表达能力和历史兼容性，MHA 很常见。

以 query head 数为 h_q、KV head 数为 h_kv、每头维度为 d、层数为 L、序列长度为 S、每元素 b 字节粗略估算：

KV cache bytes ≈ 2 × L × S × h_kv × d × b × batch

MHA 中 h_kv = h_q，MQA 中通常 h_kv = 1，GQA 则取中间值。例如 32 个 query heads、8 个 KV heads 时，KV cache 的主体大小约为 MHA 的 8/32 = 25%，但实际吞吐还受 kernel、带宽和 batch 影响。

常见追问及答案

• 问：MQA 一定比 MHA 好吗？ 不一定。共享 KV 会减少缓存和访存，但可能损失一部分表达能力；GQA 是常见折中，最终要看模型质量和目标硬件压测。
• 问：为什么 KV cache 只存 K/V，不存 Q？ 当前新 token 的 Q 只使用一次，而历史 K/V 会在后续每一步反复参与注意力，因此缓存 K/V 的收益最大。

容易扣分

• 只说 MQA/GQA 更快，不会解释 KV cache 为什么变小。
• 把 GQA 说成减少 query head 数。

Q4：RoPE、绝对位置编码和相对位置编码有什么区别？

考察点

考察你是否理解位置编码如何注入顺序信息，以及长上下文扩展存在外推风险。

回答脉络

位置编码解决“顺序感”。

参考答案

位置编码的作用是给模型序列顺序信息。常见思路有：

• 绝对位置编码：给每个位置固定位置向量。
• 相对位置编码：关注 token 之间的相对距离。
• RoPE：通过旋转位置编码把位置信息融入注意力，很多现代大模型常用。

RoPE 会根据位置对 Q、K 的二维子空间做旋转，使点积中自然包含相对位置信息。它不是“无限长上下文方案”：模型训练长度、旋转频率和扩展方法会影响超出训练长度后的质量，实际部署要验证长文档检索、位置敏感任务和不同长度的回归指标。

常见追问及答案

• 问：为什么位置编码不能只给 token 加一个位置编号？ 模型需要把位置关系编码进可学习的表示和注意力计算；单独的整数没有合适的连续几何结构。
• 问：扩展上下文长度为什么可能失效？ 训练分布没有覆盖更长位置，位置频率和注意力分布可能外推异常；需要采用经过验证的 scaling/微调方案并重新评估。

容易扣分

• 说 RoPE 可以无损支持任意长度。
• 混淆绝对位置、相对位置和 RoPE 的实现方式。

Q5：Tokenizer 为什么重要？

考察点

考察你是否能把 tokenizer 与 token 效率、上下文容量、成本和模型兼容性联系起来。

回答脉络

tokenizer 直接影响 token 数、成本和语义切分。

参考答案

Tokenizer 把文本切成模型可处理的 token。它的重要性体现在：

• 直接影响 token 计费。
• 影响上下文窗口能放多少内容。
• 影响中文、英文、代码的切分方式。
• 影响 embedding 和检索结果的一致性。

所以在工程上，不能只看字符长度估算成本，要用目标模型的 tokenizer 实际计算。比如同样 1000 个中文字符，在不同词表中可能切成不同数量的 token；代码、数字和混合中英文通常更容易膨胀。上下文预算、分块大小、截断位置和计费预估都应该使用与线上一致的 tokenizer。

常见追问及答案

• 问：tokenizer 可以和模型随意替换吗？ 通常不可以，模型 embedding 层和输出词表是按特定词表训练的；换 tokenizer 会改变 token id 和输入分布，必须配套模型或重新训练。
• 问：RAG 分块为什么也要按 token 而不是字符？ 模型上下文和注意力成本按 token 计算，按字符切块可能导致中文、代码和英文块的实际长度差异很大。实际还要保留语义边界和适当 overlap。

容易扣分

• 把 tokenizer 当成普通字符串 split。
• 用字符数直接代替 token 数做窗口和成本规划。

二、训练后方法与对齐

Q6：预训练、SFT、RLHF、DPO 分别是什么？

考察点

考察你是否能按训练数据、优化目标和解决的问题区分不同阶段，而不是把它们都称作“微调”。

回答脉络

按“学语言”“学任务”“学偏好”讲。

参考答案

• 预训练：在大规模语料上学语言和世界知识的基本分布。
• SFT（监督微调）：用高质量指令数据让模型学会某种任务格式和回答风格。
• RLHF：用人类偏好反馈优化模型输出，更偏对齐和安全。
• DPO：直接基于偏好对比优化模型，不需要传统强化学习那套复杂流程。

面试里可以总结成：预训练学基础能力，SFT 学任务行为，偏好优化调整“什么回答更好”。继续预训练通常使用领域无标注文本改变知识分布；SFT 使用 prompt/response 监督信号学习格式和任务；RLHF 通过 reward model 和强化学习优化偏好；DPO 直接使用 chosen/rejected 偏好对进行相对优化。

常见追问及答案

• 问：公司有一批业务文档，先做预训练还是 SFT？ 如果目标是让模型回答最新业务知识，优先做 RAG；若确实要让模型吸收领域语言分布，可做继续预训练；若目标是固定输出格式和流程行为，准备高质量指令数据做 SFT。
• 问：DPO 为什么不等于 SFT？ SFT 只告诉模型一个示范答案，DPO 同时提供 preferred 和 rejected 的相对偏好，优化目标是让 chosen 的相对概率更高。

容易扣分

• 混淆无标注语料、指令数据和偏好对。
• 认为做完对齐就能替代 RAG 或事实校验。

Q7：LoRA 和 QLoRA 为什么这么常见？

考察点

考察你是否理解参数高效微调节省的是可训练参数、梯度和优化器状态，而不是凭空减少全部计算。

回答脉络

它们都是参数高效微调，目标是降低训练成本。

参考答案

LoRA 通过给原模型参数旁路加低秩适配矩阵，只训练很少的一部分参数，从而降低显存和训练成本。QLoRA 则进一步结合量化，把底座模型压成更低精度，再做 LoRA 微调，进一步省资源。

常见适用场景：

• 想对大模型做领域微调。
• 预算有限。
• 不想全量训练。

如果面试官问“为什么不用全量微调”，我会说：全量微调需要保存和更新每个参数的梯度、优化器状态，成本高、版本体积大、回滚复杂；LoRA/QLoRA 更适合数据量有限、需要多任务 adapter 或资源有限的场景。但当任务与底座差异很大、需要改变大量知识或追求极致指标时，仍可能评估全量或继续预训练。

常见追问及答案

• 问：LoRA 省显存是否代表训练一定更快？ 不一定。可训练参数和优化器状态变少，但前向仍要经过底座，长序列的激活和数据吞吐仍可能是瓶颈。
• 问：LoRA adapter 能跨底座复用吗？ 通常不能随意复用，必须绑定底座架构、层名、隐藏维度和 tokenizer；即使架构相同，也要验证版本和效果。

容易扣分

• 把 LoRA 说成只训练最后一层。
• 说量化后所有计算和参数都变成 4-bit。

Q8：量化是什么？为什么能加速或省显存？

考察点

考察你是否能区分精度格式、权重量化、激活量化和实际硬件 kernel 的关系。

回答脉络

讲精度和资源的权衡。

参考答案

量化是把模型参数从高精度表示压缩到更低精度，比如 FP16、INT8、INT4 等。这样做能减少显存占用、提升吞吐或降低部署成本。

代价是：

• 可能损失一点精度。
• 对某些任务和模型更敏感。
• 不同层和不同量化方法效果差异很大。

以权重量化为例，若模型有 7B 参数，FP16 权重仅粗略估算就是 7e9 × 2 bytes ≈ 14 GB，还不包括运行时开销；INT4 理论上约为 7e9 × 0.5 bytes ≈ 3.5 GB，实际还要加 scale、zero point、未量化层和框架开销。因此“能装进显存”不等于“能高吞吐服务”。

量化不一定自动加速：如果硬件和 kernel 原生支持低比特矩阵计算，可能提升吞吐；如果运行时频繁反量化，瓶颈在带宽或算子不支持，速度甚至可能变慢。工程上要用目标任务集比较质量、显存、TTFT、TPOT、吞吐和长上下文稳定性。

常见追问及答案

• 问：FP16 和 INT4 是一回事吗？ 不是。FP16 是浮点精度格式，INT4 是低比特整数表示，通常还需要缩放参数和特定量化算法。
• 问：哪些层对量化更敏感？ 不同模型不同，通常要关注 attention、输出头、激活异常值和少数 outlier 通道；不能只凭参数量判断，应做逐层或分组实验。

容易扣分

• 用“参数量乘字节数”当成完整显存结论。
• 认为 INT4 必然比 FP16 快且无质量损失。

Q9：MoE 是什么？适合什么场景？

考察点

考察你是否理解 MoE 的总参数量、激活参数量、路由和负载均衡之间的关系。

回答脉络

专家混合让不同 token 激活不同子网络，降低计算成本。

参考答案

MoE（Mixture of Experts）是一种只激活部分专家网络的架构。它的好处是可以在参数量很大的情况下，保持相对可控的计算成本。

适合场景：

• 大规模模型扩展。
• 希望提升容量但不想线性增加每次计算量。

但 MoE 的路由和训练复杂度更高，部署和负载均衡也更难。

假设有 8 个专家、每个 token 只路由到 top-2 专家，那么每个 token 的主干 FFN 计算大致只激活 2 个专家，但显存通常仍要容纳多个专家权重，总参数量和通信压力不能按“只存两个专家”估算。路由过于集中会导致热点专家溢出、token 丢弃或负载不均，需要 auxiliary loss、容量因子和跨卡通信策略。

常见追问及答案

• 问：MoE 参数量大但为什么可能更省算力？ 因为每个 token 只激活少数专家，激活参数量小于总参数量；但实际收益取决于路由、通信、kernel 和 batch。
• 问：MoE 部署比 dense 模型难在哪里？ 专家权重分布、路由通信、热点专家、显存容量和动态负载都更复杂，单机 benchmark 不能代表多卡线上表现。

容易扣分

• 把 MoE 说成多个模型投票。
• 只看总参数量或只看激活参数量，忽略权重存储和通信。

想把 Router、Top-K、专家负载和部署差异串起来，可以继续读 MoE 混合专家：大模型为什么要学会分工。

三、推理、解码与性能

Q10：greedy、beam search、sampling 各适合什么场景？

考察点

考察你是否能把解码策略和任务目标、计算开销、稳定性联系起来。

回答脉络

说清“确定性 vs 多样性”。

参考答案

• Greedy：每步选概率最高 token，稳定但可能保守。
• Beam search：保留多个候选路径，适合某些序列生成任务，但成本更高。
• Sampling：随机采样，适合开放式生成、对话和创意任务。

beam search 在机器翻译、摘要等候选序列评分场景更常见，但在开放式 LLM 对话中 beam 数增大可能重复、变得保守，且 decode 成本更高。工具参数、分类和结构化输出通常采用低 temperature、较窄候选或受 schema 约束的解码；创作任务才更强调多样性。

常见追问及答案

• 问：beam search 一定比 greedy 好吗？ 不一定。它只是在有限候选路径中优化模型概率，模型概率不等于事实质量；beam 数越大也会增加延迟和显存。
• 问：top_k 和 top_p 的区别是什么？ top_k 固定保留概率最高的 k 个 token；top_p 按累计概率动态决定候选集合大小。二者通常选一个主控，避免参数叠加后难以解释。

容易扣分

• 把 beam search 说成随机采样。
• 认为 greedy 结果一定准确、beam 越大一定更好。

Q11：为什么流式输出很重要？

考察点

考察你是否理解流式输出改善的是 TTFT 体验，同时会引入连接、取消、重试和一致性问题。

回答脉络

讲用户体验和交互控制。

参考答案

流式输出的价值在于：

• 用户能更快看到首字。
• 长回答体验更好。
• Agent 可以边生成边让前端展示。

对于交互型应用，首 token 延迟和流式体验非常关键。

常见追问及答案

• 问：流式输出是不是降低了总耗时？ 不一定，它主要降低用户等待首字的感知延迟；总生成时间仍取决于输入、输出、模型和服务负载。
• 问：流式返回如何保证最终结果完整？ 发送增量事件并维护 request id、序号和 finish reason；服务端保存最终状态，客户端断线后不能把半截文本误当成成功结果。

容易扣分

• 只从“打字机效果”回答，不谈 TTFT 和取消回收。
• 把首字更快等同于总延迟更低。

Q12：batching、并发和限流怎么影响 LLM 服务？

考察点

考察你是否能在吞吐、尾延迟、GPU 利用率和租户公平性之间做服务设计。

回答脉络

讲吞吐、延迟和稳定性。

参考答案

• Batching：把多个请求合并处理，提高吞吐，但可能增加单个请求等待时间。
• 并发控制：防止同时太多请求把模型服务打爆。
• 限流：保护系统和成本，避免某个用户或任务占满资源。

工程上经常要在吞吐和延迟之间平衡，尤其是推理服务高峰期。

一个简单的容量直觉是：若单实例在目标 SLA 下能稳定处理 1200 output tokens/s，而业务峰值需要 3000 output tokens/s，至少需要 ceil(3000 / 1200) = 3 个等价实例，还要留故障、发布和突发余量。实际不能只按平均值计算，要按输入输出长度分布和 P95/P99 压测。

常见追问及答案

• 问：为什么 batch 越大吞吐越高但延迟也可能升高？ 合并请求能提高矩阵计算效率，但请求可能等待凑 batch，且长请求会拖住短请求，导致排队和尾延迟增加。
• 问：限流应该按 QPS 还是 token？ 两者都需要。QPS 保护连接和调度资源，token/并发限制更贴近模型计算和 KV cache 消耗。

容易扣分

• 把并发、QPS、吞吐混为一谈。
• 只看 GPU 利用率，不看排队时间和 P95/P99。

Q13：模型服务为什么需要缓存？

考察点

考察你能否区分 prompt、检索、业务结果和 KV 缓存，并说明缓存一致性与隐私风险。

回答脉络

缓存能减少重复 prefill、重复检索和重复生成。

参考答案

缓存的作用主要有：

• prompt 前缀复用。
• 重复 query 复用检索结果。
• 热门答案复用。
• 中间步骤结果复用。

缓存不是越多越好，关键是要让稳定内容和变化内容分开。否则命中率低，缓存管理成本反而上升。

常见追问及答案

• 问：什么结果适合缓存？ 稳定的公共 prompt 前缀、版本化知识检索结果、幂等的热门只读查询适合缓存；用户权限、库存、余额等实时或强隔离数据必须短 TTL、带租户键或不缓存。
• 问：缓存 key 应包含哪些信息？ 至少包含模型/版本、标准化输入、关键参数、知识库版本、租户或权限范围；否则容易串租户、读到旧知识或混淆不同解码策略。

容易扣分

• 只说“用 Redis 缓存答案”。
• 不考虑 TTL、版本、权限和数据泄露。

四、模型选型与部署

Q14：怎么选一个适合业务的模型？

考察点

考察你是否能用业务约束建立可验证的模型选型流程，而不是按榜单或参数量拍板。

回答脉络

看任务类型、成本、延迟、上下文、工具能力和安全能力。

参考答案

我会看这些维度：

• 任务是分类、抽取、写作还是复杂推理。
• 是否需要长上下文。
• 是否需要工具调用。
• 延迟和成本预算。
• 语言和领域匹配度。
• 结构化输出稳定性。
• 安全和合规要求。

不是“越大越好”，而是“够用、稳定、可控、可承担”。我会先建立覆盖真实输入的评测集，例如 500 条问答、工具调用和拒答样本，定义任务成功率、结构化合法率、事实性、P95 延迟和单成功任务成本，再比较候选模型。还要验证上下文长度、tokenizer、工具协议、数据合规、可用区和供应商稳定性。

常见追问及答案

• 问：如果大模型质量只高 3%，但成本高 5 倍，怎么选？ 先按业务风险分层：高风险或复杂任务可用大模型，低风险任务用小模型；用单成功任务成本和用户/业务价值判断，不用参数量做结论。
• 问：怎么做模型上线前评估？ 离线固定集、对抗集和历史失败集先筛选，再做 shadow/灰度流量，监控质量、延迟、错误率、成本和降级比例，设置回滚阈值。

容易扣分

• 只看公开 benchmark 或模型参数量。
• 不定义业务成功标准，也不考虑合规、灰度和回滚。

Q15：什么时候该用小模型，什么时候该用大模型？

考察点

考察你是否具备任务分解和模型路由意识，能把模型能力映射到成本与风险。

回答脉络

小模型负责简单稳定任务，大模型负责复杂开放任务。

参考答案

一般来说：

• 小模型适合路由、分类、抽取、简单改写、局部判断。
• 大模型适合复杂推理、多步工具调用、长文总结、开放式写作。

真实系统里经常是组合：先用小模型做路由或预筛，再把复杂任务交给大模型，以控制成本。

例如一个客服 Agent 可以让规则或小模型识别意图和敏感风险，检索/字段抽取使用专门模型，只有需要多步推理或复杂解释的请求升级到大模型。路由不能只看关键词，还要结合输入长度、工具数量、历史失败率、用户等级和预算；高风险任务宁可拒答或人工审核，也不能为了省钱盲目降级。

常见追问及答案

• 问：小模型什么时候反而更好？ 任务边界窄、格式固定、延迟敏感且有足够标注数据时，小模型更容易稳定、便宜和可控。
• 问：怎么防止小模型路由错？ 对高风险类别设置保守阈值和升级路径，记录路由理由，按路由后的任务成功率、升级率和单成功成本持续评估。

容易扣分

• 只按输入长度或关键词路由。
• 没有 fallback、人工兜底和路由质量指标。

Q16：模型部署时为什么要关注上下文长度和显存？

考察点

考察你是否能把上下文长度转换成 KV cache、并发、吞吐和成本约束。

回答脉络

上下文越长，KV cache 越大，显存压力越高。

参考答案

模型部署时，长上下文不仅影响 token 成本，也影响推理显存和吞吐。上下文越长，KV cache 占用通常越大，服务端可并发处理的请求就越少。

所以如果一个业务大量使用长上下文、长对话、多轮 Agent，就必须在模型选型、量化、缓存和并发策略上一起考虑。

粗略地，KV cache 可按 2 × 层数 × 序列长度 × KV head 数 × head_dim × 每元素字节数 × batch 估算。序列从 4K 增至 32K，若其他条件不变，单请求 KV cache 大约增至 8 倍，能够容纳的并发通常会显著下降。因此“模型支持 128K”不等于“可以让所有用户都用满 128K”。

常见追问及答案

• 问：显存不够先量化还是先缩短上下文？ 取决于质量和业务：若输入有大量冗余，先做摘要、检索和截断通常更稳；若上下文不可缩短，再评估量化、GQA、分页 KV 和降低并发。
• 问：权重显存够了为什么还是 OOM？ 还要算 KV cache、激活、临时 workspace、CUDA 上下文、碎片和 batch；长序列并发常是运行时峰值来源。

容易扣分

• 只用参数量乘精度估算显存。
• 把最大上下文窗口当成线上推荐上下文。

Q17：什么叫模型路由？

考察点

考察你是否能把模型路由设计成带能力、健康、预算和回退策略的工程系统。

回答脉络

把不同任务分配给不同模型。

参考答案

模型路由就是根据任务类型、复杂度、成本和延迟，把请求分给不同模型处理。常见策略包括：

• 低成本任务走小模型。
• 高复杂度任务走大模型。
• 敏感任务走受控模型。
• 某些步骤走专门模型，比如 embedding、rerank、分类器。

模型路由是控制成本和质量的常见手段，尤其适合 Agent 平台和多租户系统。

常见追问及答案

• 问：路由器至少要维护什么信息？ 模型能力矩阵、价格、上下文限制、工具/结构化输出支持、健康状态、实时延迟、租户合规范围和 fallback 顺序。
• 问：路由策略如何验证？ 用历史流量回放和标注集比较路由准确率、任务成功率、升级率、P95 延迟和每次成功任务成本，并保留按版本回滚的配置。

容易扣分

• 只说“简单问题小模型、复杂问题大模型”。
• 不谈模型健康、合规、预算、fallback 和可观测性。

五、基础概念追问

Q18：为什么有些模型推理特别贵？

考察点

考察你是否能从 token、架构、内部推理和系统调用链拆解成本。

参考答案

因为它可能有更长上下文、更高输出 token、更复杂的内部推理、更多轮工具调用或更高规格的服务端资源。可以粗略拆成：

总成本 = 输入 token 成本 + 输出/推理 token 成本
        + embedding/rerank/工具成本 + 重试与失败成本

同一个模型若输入从 2K 增到 20K、Agent 轮数从 2 增到 8，成本和首 token 延迟都可能显著上升，所以需要记录每一步 usage，而不是只看最终回答长度。

常见追问及答案

• 问：如何降低贵模型成本？ 先减少无效上下文和重复调用，再做 prompt/检索缓存、任务路由、输出上限、批处理和失败重试治理；每一步都用质量和单成功成本验证。

容易扣分

• 只把贵归因于参数量。
• 忽略多轮 Agent、缓存、重试和工具链路。

Q19：为什么有些任务不用大模型也能做得很好？

考察点

考察你是否理解任务复杂度、数据分布和可验证性比模型大小更重要。

参考答案

因为分类、抽取、模板化写作、规则路由这类任务对模型“世界知识”要求不高，小模型甚至传统算法就够用。若输出空间有限、标签稳定、规则清晰，传统分类器或 schema 校验更便宜、更可解释；模型只负责规则难以覆盖的语言理解部分。

常见追问及答案

• 问：为什么不全用规则？ 规则适合稳定边界，但面对同义表达、上下文依赖和频繁变化的语言会迅速膨胀；可以用规则做硬约束，用小模型做语义判断，再用大模型处理少量复杂例外。

容易扣分

• 把“不需要大模型”理解成“不需要任何模型评估”。
• 不会说明规则、分类器和大模型的组合边界。

Q20：模型越大就一定更适合 Agent 吗？

考察点

考察你是否能从工具调用稳定性、成本、延迟、可控性和风险，而不只是推理能力判断 Agent 模型。

参考答案

不一定。Agent 需要的不只是能力，还要稳定地产生合法工具参数、理解工具返回、遵守权限边界、在失败后恢复，并且成本和延迟可接受。一个答案更聪明但经常误调用工具的模型，线上可能不如能力稍弱但结构化输出稳定的模型。

很多场景里小模型负责路由、分类和简单步骤，大模型只负责关键决策；工具执行、权限校验和最终写入由确定性服务完成。选型要用真实任务链路评估端到端成功率、错误副作用、平均/P95 延迟和每次成功任务成本。

常见追问及答案

• 问：Agent 评估只看最终文本对不对吗？ 不够。还要看工具选择准确率、参数合法率、调用次数、恢复成功率、权限违规率和副作用错误。
• 问：如何让大模型的 Agent 行为可控？ 工具 schema、参数校验、权限和预算由服务端执行，模型只提出意图；对高风险动作增加确认、幂等键和审计。

容易扣分

• 只用通用 benchmark 判断 Agent 能力。
• 让模型直接决定权限和执行结果，不设置确定性校验。

前 20 题常见扣分点

• 只会说 Transformer 很强，但说不出它解决了什么问题。
• 不知道 MHA、MQA、GQA 的区别。
• 把 SFT、RLHF、DPO 混在一起。
• 只会说 LoRA 很省显存，但说不出为什么。
• 不懂量化、batching、限流和缓存对部署的影响。
• 只会一味上大模型，不会做路由和组合。

六、训练、微调与对齐的工程决策

Q21：预训练到底学到了什么？为什么不能把业务文档直接当成预训练数据喂进去？

考察点

考察你是否理解预训练目标、数据治理和业务知识更新之间的关系。

回答脉络

先解释 next-token prediction，再区分预训练、领域继续预训练和 SFT，最后说明数据风险。

详细参考答案

自回归语言模型的预训练通常以 next-token prediction 为目标：给定前面的 token，预测下一个 token，通过海量文本学习语言结构、事实关联、代码模式和一定的推理规律。预训练数据决定模型的基础分布，但“见过文本”不等于“记住并能可靠复述其中的每个事实”。

业务文档不能未经治理直接加入训练，原因包括：

• 文档可能包含个人信息、商业秘密、过期版本和互相矛盾的内容。
• 训练后知识进入参数，更新、删除和审计都比外部知识库困难。
• 文档质量不高时，模型可能学到错误格式、模板噪声和不应公开的信息。
• 训练集和评估集如果重复，会造成数据泄漏，离线指标虚高。

如果目的是让模型掌握某个领域的语言和术语，可以考虑领域继续预训练；如果目的是学会固定输入输出格式和任务行为，通常优先 SFT；如果知识需要实时更新、按租户隔离或必须给出处，优先 RAG 和工具。

工程落地

训练前要做数据分级、脱敏、去重、质量过滤、版本记录和 train/validation/test 隔离。对可删除数据要保留来源和样本映射，至少知道某个能力来自哪批数据。上线前还要做成员推断、敏感信息回显和旧知识残留测试。

常见追问及答案

• 问：继续预训练和 SFT 的差别是什么？ 继续预训练通常仍学习语言建模分布，适合领域语料和术语；SFT 用有输入输出关系的标注样本学习任务行为和回答格式。
• 问：把公司知识微调进模型后，用户问什么都能答吗？ 不能保证。参数记忆可能不完整、难更新，也不能替代权限过滤和实时状态查询。

容易扣分

• 认为预训练就是把文档逐条存进模型。
• 不谈数据泄露、版本和遗忘问题。
• 看到知识库问题就直接推荐训练。

Q22：SFT 数据集应该怎么设计？为什么数据质量通常比数据量更重要？

考察点

考察你是否有从业务样本构造训练数据、避免把错误示范放大到模型里的能力。

回答脉络

从任务定义、样本格式、覆盖边界、质量控制和评估切分五步回答。

详细参考答案

SFT 的目标是让模型模仿高质量的输入输出行为，因此数据不能只是把大量原始文本拼在一起。一个合格的 SFT 样本至少要明确用户输入、必要的系统约束、理想答案，以及需要时的工具调用或拒答行为。

设计数据时我会覆盖：

• 正常任务、边界输入、缺少信息和歧义问题。
• 需要调用工具、不应该调用工具、工具失败后的行为。
• 正确答案、无答案时的诚实拒答和安全拒绝。
• 多种表达方式，避免模型只记住固定句式。
• 长短输入、中文英文、代码和结构化输出。
• 真实业务中高频且高价值的错误案例。

质量比数量重要，是因为 SFT 会强化示范中的模式。少量准确、边界清楚、风格一致的数据，常常比大量重复、互相矛盾或包含幻觉的答案更有效。重复样本还会改变数据分布，让模型过度偏向某种短答案或模板。

工程落地

我会建立数据标注规范和双人抽检流程，记录每条样本的任务类型、难度、来源、版本和质量标签。训练集、验证集和测试集按用户问题或文档来源去重切分，不能只随机切行。测试集保留一部分“未见过的表达”和对抗边界，检查模型是否学到能力而不是背答案。

常见追问及答案

• 问：SFT 样本越长越好吗？ 不一定。长样本可能提供更多上下文，但也增加成本和噪声，应保留对任务有用的信息。
• 问：能不能直接用模型生成训练数据？ 可以作为候选数据，但必须人工或规则审核，避免把教师模型的幻觉、格式错误和偏见放大。
• 问：为什么验证集不能和训练集随机混合？ 相似问题、同一文档和模板重复会造成泄漏，导致验证指标不能代表泛化。

容易扣分

• 只说“准备很多问答对”，不谈负样本、拒答和边界。
• 不区分训练集、验证集和测试集。
• 把模型生成数据当成天然正确。

Q23：LoRA 的低秩适配到底做了什么？rank、alpha、dropout 和 target modules 怎么选？

考察点

考察你是否真正理解 LoRA 的参数高效微调，而不是只记住“省显存”。

回答脉络

先讲冻结底座和低秩增量，再讲关键超参数，最后讲模块选择和合并部署。

详细参考答案

LoRA 冻结原模型权重 W，只学习一个低秩增量矩阵，常见形式是：

W' = W + scaling * B * A

其中 A、B 的中间维度 rank 远小于原始维度。训练时梯度主要更新 A 和 B，优化器状态也只需要为适配器保存，因此显存、训练时间和磁盘占用都显著下降。推理时可以把增量合并到底座权重，也可以保留成独立 adapter，按租户或任务动态加载。

几个常见参数的含义：

• rank：低秩空间大小。rank 越大，适配容量通常越强，但参数、显存和过拟合风险也会增加。
• alpha：控制增量缩放，实际比例常与 alpha/rank 有关，不能脱离实现孤立比较。
• dropout：对适配分支做正则，数据少或噪声大时有助于泛化。
• target modules：把 LoRA 注入哪些线性层。只注入 attention 的 query/value 参数更省资源；覆盖 query/key/value/output 或 MLP 可能提升任务适配能力，但成本更高。

选择不能靠固定经验值。我会用小规模网格实验比较 rank、学习率、训练步数和 target modules，并按任务类型评估能力保持、格式遵循、领域效果和通用能力退化。

工程落地

每个 adapter 要绑定底座模型版本、tokenizer、训练数据版本和超参数。部署时要防止用错底座或加载多个不兼容 adapter。上线可以先保持 adapter 独立，便于回滚；确认稳定后再合并权重，减少运行时加载开销。

常见追问及答案

• 问：LoRA 一定不损伤原模型能力吗？ 不一定。训练过度、数据分布太窄或 target modules 选择不当都可能导致灾难性遗忘。
• 问：rank 越大效果越好吗？ 不一定。任务复杂度、数据量和训练质量更重要，rank 增大也可能带来过拟合和部署成本。
• 问：LoRA 和 prompt tuning 一样吗？ 不一样。LoRA 修改部分权重的增量，prompt tuning 主要学习输入侧的连续提示向量，参数位置和适用特点不同。

容易扣分

• 只说“LoRA 训练少量参数”，讲不出低秩增量。
• 不知道 target modules 会影响效果和成本。
• 忽略底座、tokenizer 和 adapter 版本绑定。

Q24：QLoRA 比 LoRA 多做了什么？4-bit 量化会不会让训练结果不可信？

考察点

考察你对 QLoRA 的组成、显存节省来源和精度风险的理解。

回答脉络

先说量化底座、LoRA 可训练分支，再说 NF4、双重量化和 paged optimizer，最后讲验证。

详细参考答案

QLoRA 的核心是：底座模型以低比特形式加载并冻结，训练时通过量化权重参与前向计算，同时只更新 LoRA adapter。它并不是把所有训练参数都改成 4-bit，而是用量化底座节省显存，把可训练的增量保持在更适合优化的精度。

常见实现会结合以下思想：

• NF4：针对近似正态分布权重设计的 4-bit 表示。
• 双重量化：进一步压缩量化所需的 scale 等状态。
• paged optimizer：在显存紧张时更灵活地管理优化器状态，降低峰值显存。

QLoRA 的优势是能在有限 GPU 资源上适配更大的底座模型，但量化误差仍可能影响小数据任务、精确代码、数学和长上下文任务。不同底座、量化格式、硬件和 kernel 的结果也不完全一样。

工程落地

我会先用全精度或 LoRA 版本建立基线，再比较 QLoRA 的任务指标、困惑度、工具调用成功率、结构化输出合法率和推理速度。训练结束后不仅测试 adapter，还要测试合并权重、目标推理框架和真实 batch 配置，避免训练环境和线上环境出现精度差异。

常见追问及答案

• 问：QLoRA 训练完是不是得到一个 4-bit 全量新模型？ 通常得到量化底座加 LoRA adapter；是否合并、以什么精度导出，取决于部署流程。
• 问：QLoRA 一定比 LoRA 好吗？ 不一定。它更省显存，但增加量化误差和实现复杂度，资源充足且追求极致质量时未必需要。
• 问：为什么 QLoRA 仍可能需要很多显存？ 激活值、梯度、LoRA 参数、优化器状态、序列长度和 batch 仍会占显存，底座量化并不会把所有内存都消掉。

容易扣分

• 说成“把训练过程全部变成 4-bit”。
• 只讲省显存，不讲量化误差和线上复测。

Q25：DPO 和 RLHF 有什么区别？什么时候会选 DPO？

考察点

考察你是否能区分监督示范、偏好数据和强化学习优化，而不是把所有对齐都叫 RLHF。

回答脉络

先定义偏好数据，再对比 RLHF 流程和 DPO 的优化方式，最后讲数据与风险。

详细参考答案

经典 RLHF 通常包括 SFT、收集人类偏好、训练 reward model，再用 PPO 等强化学习方法优化策略模型。它能够直接优化偏好奖励，但流程复杂，训练稳定性、奖励模型偏差和调参成本都较高。

DPO 直接使用同一个 prompt 下的 chosen/rejected 回答对，通过偏好对比目标更新策略模型，通常不需要单独在线训练 reward model，也不需要完整的 PPO 环节。它的工程门槛更低，适合已有较高质量偏好对、希望调整回答风格、拒答边界或任务偏好的场景。

但 DPO 不是自动产生偏好，也不等于安全保证。偏好对的标注质量、chosen 与 rejected 的差距、数据覆盖和 reference model 选择都会影响结果。偏好数据如果只偏爱“听起来专业”的答案，模型可能学会冗长或过度自信，而不是真正正确。

工程落地

训练前我会检查偏好对是否真的可比较，区分事实正确、格式合规、帮助性、安全性和风格偏好。训练后用独立测试集比较胜率、事实性、拒答准确率、长度变化、通用能力和安全回归，并保留未微调模型作为回退版本。

常见追问及答案

• 问：DPO 不需要 reward model 就没有奖励模型偏差了吗？ 没有。偏好标签和 reference model 仍然会引入偏差，只是训练链路更直接。
• 问：SFT 后一定要 DPO 吗？ 不一定。SFT 已经满足行为要求时不需要额外对齐；DPO 适合存在稳定偏好差异且有可靠成对数据的情况。
• 问：DPO 能解决事实幻觉吗？ 不能单独保证。事实性仍需要 RAG、工具、数据验证和独立评估。

容易扣分

• 把 DPO 说成“没有人工偏好数据的自动强化学习”。
• 混淆 chosen/rejected 和普通问答标签。
• 认为做完 DPO 就自动安全、准确。

Q26：如何判断一次微调真的有效，而不是训练集记忆或评估泄漏？

考察点

考察你是否具备完整的微调评估意识，包括基线、泛化、回归和成本。

回答脉络

按基线、数据切分、分层指标、人工分析和线上验证回答。

详细参考答案

微调是否有效不能只看训练 loss 下降，也不能只看一组公开 benchmark。至少要比较四类结果：

• 任务效果：目标分类、抽取、工具选择、格式遵循或领域问答是否提升。
• 泛化能力：未见过的表达、时间范围、用户类型、文档版本和长短输入是否仍然有效。
• 能力保持：通用问答、代码、语言能力、拒答和安全边界是否退化。
• 工程指标：推理 token、延迟、显存、吞吐和单成功任务成本是否可接受。

评估集要按用户问题或来源去重，保留时间切分和难例集。对于生成任务，自动指标只能作为一部分，还要做人工抽样或模型辅助评估，并检查具体错误类型。若训练和测试共享模板、文档段落或近重复问题，指标很可能是泄漏。

工程落地

我会保存 base、prompt-only、RAG-only、LoRA 和 QLoRA 的同一套结果，设置上线门槛和不可回退指标。先做离线 replay，再做 shadow traffic，最后小比例灰度。每个模型版本关联数据版本、代码版本、prompt 版本和评估报告，出现回退可定位原因。

常见追问及答案

• 问：loss 越低越好吗？ 不一定。训练 loss 低可能意味着过拟合，和真实任务成功率不完全一致。
• 问：如何检测数据泄漏？ 检查样本 hash、文档来源、近似重复、模板变量和时间切分，并用未公开的新数据验证。

容易扣分

• 只报一个准确率或 loss。
• 没有基线和回归指标。
• 不检查微调对原有能力和安全边界的影响。

七、推理性能与服务原理

Q27：LLM 推理为什么要区分 prefill 和 decode？

考察点

考察你是否理解一次生成请求的两种计算阶段，以及它们对首 token 延迟和持续生成速度的不同影响。

回答脉络

先讲两阶段做什么，再讲瓶颈不同，最后给出优化方法。

详细参考答案

LLM 推理通常可以分成 prefill 和 decode：

• Prefill：一次性处理用户输入、历史、工具定义和检索上下文，计算整段输入的隐藏状态，并建立 KV cache。它通常计算密集度高，输入越长，首 token 延迟越明显。
• Decode：在已有 KV cache 的基础上逐 token 生成，每次只处理新 token，但要读取历史 K/V。它通常更受显存带宽、KV cache 读写和逐步串行特性影响。

因此两个常见指标分别对应不同阶段：TTFT 主要受排队和 prefill 影响，TPOT 或 inter-token latency 主要反映 decode 阶段。一个服务可能首字很快但后续输出慢，也可能首字很慢但生成速度快，不能只用总耗时描述体验。

工程落地

我会分别记录排队时间、prefill 时间、首 token 时间、每 token 生成时间和总完成时间。长输入场景优先控制上下文、使用前缀缓存和更快的 prefill；长输出场景优先控制最大输出、优化 KV cache、使用更适合 decode 的 batching 和量化配置。

常见追问及答案

• 问：为什么输入变长，首字延迟会明显增加？ 因为 prefill 需要处理更多输入 token，并为后续生成建立更大的 KV cache。
• 问：为什么输出变长，首字可能不变但总时间增加？ 首字前主要是输入处理，后续每生成一个 token 都要执行一次 decode，所以输出长度直接拉长总耗时。
• 问：prompt cache 主要优化哪个阶段？ 通常主要减少重复前缀的 prefill 计算，但不会自动消除新输出 token 的 decode 成本。

容易扣分

• 把 prefill 说成“生成前的网络请求时间”。
• 只谈端到端延迟，不区分输入长和输出长的影响。

Q28：KV Cache 是什么？怎么粗略估算它的显存占用？

考察点

考察你能否解释长上下文和高并发为什么会吃显存，以及 MHA、MQA、GQA 的实际价值。

回答脉络

先说明缓存内容，再给估算公式，最后讲压缩和淘汰手段。

详细参考答案

在自回归生成中，已经处理过的 token 会产生 attention 所需的 key 和 value。如果每生成一个新 token 都重新计算全部历史，成本会很高，因此推理服务会把历史 K/V 缓存在 GPU 或分页显存中。后续 decode 只需要为新 token 计算 Q、K、V，并读取历史 K/V。

一个简化的 KV cache 显存估算是：

KV bytes ≈ batch_size * sequence_length
          * num_layers
          * 2
          * num_kv_heads
          * head_dim
          * bytes_per_element

其中 2 表示 K 和 V 两份。实际实现还会有 block 对齐、元数据、分配碎片和框架开销。MHA 的 num_kv_heads 通常等于 query heads；MQA 让多个 query head 共享一组 K/V；GQA 让一组 query head 共享一组 K/V，因此后两者能显著减少 KV cache 占用。

当上下文长度、并发数或输出上限增加时，KV cache 线性增长，往往比模型权重更快成为服务瓶颈。量化模型权重可以腾出显存，但如果 KV cache 仍使用 FP16，长上下文高并发时依然可能 OOM。

工程落地

容量规划时我会分别计算权重、激活、KV cache、临时 workspace 和运行时开销，预留安全余量。服务端使用 paged attention 或 block-based cache，按请求动态分配和回收；超过容量时根据租户优先级排队、拒绝、缩短上下文或降级，而不是让整个进程崩溃。

常见追问及答案

• 问：KV Cache 能跨用户任意共享吗？ 不能。只有完全相同且具备隔离保障的前缀才可能复用，用户私有上下文不能因为相似就混用。
• 问：KV cache 量化有什么代价？ 可以降低显存和带宽压力，但会引入近似误差，可能影响长上下文和生成质量，需要针对模型和任务验证。
• 问：为什么 batch 增大后显存突然不够？ 每个活跃序列都需要自己的 KV cache，batch 和序列长度共同决定缓存规模，且不同请求的长度还会造成分配碎片。

容易扣分

• 只知道 KV cache“能加速”，不会解释缓存的是 K/V。
• 估算时漏掉层数、K/V 两份或并发序列数。
• 认为只要把权重量化就不存在显存问题。

Q29：什么是 static batching、dynamic batching 和 continuous batching？为什么大模型服务常用 continuous batching？

考察点

考察你是否理解请求长度不一时的 GPU 调度问题，以及吞吐和延迟之间的取舍。

回答脉络

先对比三种 batching，再说明 continuous batching 解决的空转问题。

详细参考答案

• Static batching：等待一批请求凑齐后一起处理，批内请求通常同步推进。实现简单，但短请求要等待长请求，长度差异大时浪费明显。
• Dynamic batching：在一个短时间窗口内收集到达的请求，动态组成 batch。比静态 batching 灵活，但仍可能受到批内最长请求拖累。
• Continuous batching：把生成过程按迭代调度，每一轮可以让新请求加入、已完成请求退出，活跃序列不必等待整批最长请求结束。

大模型 decode 是逐步进行的，continuous batching 能把不同请求的 decode token 交错放进同一批次，减少 GPU 空转，提高整体吞吐。它也带来调度复杂度：要管理 KV cache、请求优先级、最大 batch token、长请求饥饿、取消和流式输出。

工程落地

我会设置最大等待窗口、最大 batch token、最大并发序列和每租户配额。交互请求和离线批处理使用不同队列，交互请求以 TTFT/P95 为约束，离线请求以 tokens/sec 和 GPU 利用率为约束。监控队列等待、活跃序列数、KV cache 使用率和每轮 batch 的 token 数。

常见追问及答案

• 问：batch 越大吞吐越高吗？ 到达显存、带宽或计算饱和点后不一定，过大还会增加排队和尾延迟。
• 问：continuous batching 会不会破坏用户之间的上下文？ 正确实现下不会。batch 只是计算调度，KV cache 和请求状态必须按 sequence 隔离。
• 问：怎么保证短请求不被长请求饿死？ 使用优先级、年龄提升、最大等待时间和租户公平调度，不能只追求 GPU 利用率。

容易扣分

• 把 continuous batching 说成“把所有请求拼成一个大 prompt”。
• 不知道生成阶段可以让请求动态加入和退出。

Q30：LLM 服务常见的延迟和吞吐指标分别是什么？如何定位性能瓶颈？

考察点

考察你是否能够用可测量指标讨论性能，而不是只说“模型很慢”。

回答脉络

先定义指标，再按排队、输入处理、输出生成、网络和下游依赖拆分。

详细参考答案

常见指标包括：

• TTFT（Time To First Token）：从请求进入到收到第一个输出 token 的时间，影响用户感知的“开始响应速度”。
• TPOT 或 ITL（Time Per Output Token / Inter-Token Latency）：输出 token 之间的平均或分位间隔，反映持续生成速度。
• E2E latency：从请求开始到完整响应结束的时间。
• Throughput：单位时间生成的 token 数、完成请求数或成功任务数。
• P50/P95/P99：中位数和尾延迟，生产服务不能只报平均值。
• GPU utilization、显存使用率和 KV cache 使用率：帮助判断硬件是否饱和或缓存是否成为瓶颈。

定位时我会先把端到端时间拆成排队、路由、网络、prefill、decode、工具和后处理。TTFT 高可能是队列太长、输入太长、prefill 慢或模型路由错误；TPOT 高可能是 decode 带宽不足、batch 调度不合理、量化 kernel 不匹配或 KV cache 压力大；E2E 高还可能来自输出太长和下游工具慢。

工程落地

每次请求记录 request_id、模型、输入输出 token、排队时间、首 token 时间、完成时间、批次大小、GPU、缓存命中和错误。压测时按真实长度分布、并发分布和流式比例测试，至少给出低并发和高并发两组结果，避免用单请求 benchmark 代表线上性能。

常见追问及答案

• 问：平均延迟很好，用户仍然觉得慢，为什么？ 尾延迟可能很差，或者 TTFT 很高；用户感知通常更受首字和 P95 影响。
• 问：吞吐和延迟能同时无限优化吗？ 通常存在取舍。增大 batch 提高吞吐可能增加等待和尾延迟，需要按接口类型设置目标。
• 问：tokens/sec 越高任务体验就一定越好？ 不一定。首字、完整答案长度、正确率和工具等待也影响体验，应看成功任务的综合指标。

容易扣分

• 把 QPS、tokens/sec、TTFT 和总延迟混为一个指标。
• 只看 GPU 利用率，不看尾延迟和任务成功率。

Q31：为什么推理服务需要 paged attention、prefix cache 或 KV cache 管理器？

考察点

考察你是否理解高并发推理中的显存碎片、前缀复用和动态请求生命周期。

回答脉络

从连续显存分配的问题出发，再说明分页和前缀复用的收益与边界。

详细参考答案

如果每条请求都为最大上下文预留一段连续 KV cache，短请求会浪费空间，长短请求交替完成还会产生碎片，导致“总剩余显存足够但找不到连续空间”。paged attention 把 KV cache 切成固定大小的 block，逻辑序列通过 block table 映射到物理块，便于动态分配、回收和复用。

prefix cache 则利用多个请求共享的稳定前缀，只保存一次对应的 KV 状态，后续请求从公共前缀之后开始计算。它适合稳定 system prompt、工具 schema、固定文档前缀等场景，但必须验证前缀完全一致、模型和参数兼容，并做好租户隔离、TTL 和淘汰。

工程落地

服务端要监控 block 使用率、碎片率、缓存命中率、缓存淘汰和 OOM。请求取消、超时、断连和异常退出都必须释放对应 block；不能只在正常完成时回收，否则长时间运行会出现隐性泄漏。

常见追问及答案

• 问：prefix cache 和结果缓存有什么区别？ prefix cache 复用模型对输入前缀的中间计算，仍需继续生成；结果缓存直接复用完整答案，必须严格考虑时效、用户权限和随机参数。
• 问：前缀只差一个字符能复用后面的 KV 吗？ 一般只能复用相同的 token 前缀，变化位置之后的缓存不能直接复用。

容易扣分

• 把 paged attention 说成数据库分页。
• 忽略取消请求后的 KV cache 回收。

Q32：PTQ、QAT、GPTQ、AWQ 和 bitsandbytes 量化有什么区别？

考察点

考察你是否能区分量化发生的时间、优化目标和部署实现，而不是把所有低比特格式混成一个概念。

回答脉络

先按训练前后区分，再介绍常见方法，最后讲如何选择和验证。

详细参考答案

• PTQ（Post-Training Quantization）：模型训练完成后再量化，不修改或只少量校准参数，成本低、部署快，但可能有精度损失。
• QAT（Quantization-Aware Training）：训练或微调时模拟量化误差，让模型适应低精度表示，通常效果更好，但训练成本更高。
• GPTQ：常见的后训练权重量化方法，通常逐层或按组优化量化误差，适合生成式模型权重压缩。
• AWQ：根据激活的重要性保护部分权重，尽量减少对输出质量敏感的权重损失，常用于高效推理。
• bitsandbytes 8-bit/4-bit：常见的低比特加载与训练配套实现，适合快速试验和 QLoRA，但实际速度要看硬件和 kernel。

还要区分量化对象：只量化权重、同时量化激活，或者量化 KV cache，影响不同。权重量化主要降低模型常驻显存；激活量化可能进一步提升吞吐，但更容易带来精度和算子兼容问题。低比特并不自动等于更快，若硬件没有匹配 kernel，反而可能增加反量化开销。

工程落地

我会对目标模型、真实业务样本和目标 GPU 做矩阵测试：FP16/BF16 基线、INT8、INT4 不同方法分别测准确率、困惑度、工具成功率、TTFT、TPOT、吞吐、显存和功耗。最终选择“业务质量门槛内最便宜”的方案，而不是盲目选择最低 bit 数。

常见追问及答案

• 问：4-bit 一定比 8-bit 快吗？ 不一定。显存变小不等于 kernel 更高效，速度取决于硬件、算子、batch、序列长度和反量化实现。
• 问：量化只影响推理吗？ 主要用于推理，也可以用于 QLoRA 训练的底座加载；训练中的可训练参数和优化器通常仍保留更高精度。
• 问：校准数据应该怎么选？ 应覆盖真实语言、长度、领域、代码和关键任务分布，不能只用几条简单句子。

容易扣分

• 把 PTQ 和 QAT 混为一谈。
• 认为 bit 数越低速度一定越快。
• 只测语言流畅度，不测业务任务和结构化输出。

Q33：模型并行、数据并行、流水线并行和张量并行分别解决什么问题？

考察点

考察你是否理解大模型训练与推理如何跨 GPU 拆分，以及通信成本为什么重要。

回答脉络

先说“复制数据”与“切模型”的差别，再分别解释 DP、TP、PP，最后讲组合并行。

详细参考答案

• 数据并行（DP）：每张 GPU 放一份模型副本，不同 GPU 处理不同数据分片，再同步梯度。适合模型单卡能放下、希望增加训练吞吐的情况。
• 张量并行（TP）：把一个层中的矩阵或 attention 头拆到多张 GPU，单个请求的前向需要设备间通信。适合单卡放不下或希望分摊单层计算的场景。
• 流水线并行（PP）：把不同层放到不同 GPU，micro-batch 依次经过各阶段。可以容纳更大模型，但会有 pipeline bubble 和阶段负载不均。
• 模型并行：广义上指把模型参数或计算拆到多张设备，TP、PP 都属于常见模型并行方式。

训练常把 DP、TP、PP 和 ZeRO/FSDP 组合。推理时更关注权重、KV cache 和通信拓扑：TP 可能降低单卡显存压力，但跨卡 all-reduce 或 all-gather 会影响延迟；PP 对单请求延迟和调度更复杂，多用于超大模型。

工程落地

选择并行策略前先做显存和算力估算，再结合 GPU 互联带宽、网络拓扑、batch 和目标延迟测试。多卡机器内高速互联适合 TP；跨机器通信慢时要谨慎扩大 TP。训练要监控 step time、通信占比、GPU 空转和负载不均，不能只看显存是否放得下。

常见追问及答案

• 问：数据并行能解决模型单卡放不下吗？ 传统数据并行不能，它会复制完整模型；需要模型并行或参数分片方案。
• 问：为什么 GPU 利用率高但训练/推理仍慢？ 可能大量时间花在通信、同步、内存带宽或不均衡等待上，利用率不是唯一指标。
• 问：ZeRO 和数据并行有什么关系？ ZeRO 通过分片优化器状态、梯度和参数，减少每卡冗余，可和数据并行结合，具体阶段的分片范围不同。

容易扣分

• 只按“把模型拆开”解释所有并行。
• 不提跨卡通信和 pipeline bubble。

Q34：什么是 speculative decoding？什么时候值得使用？

考察点

考察你是否理解推测解码如何用小模型辅助大模型，以及它为什么不是所有请求都能加速。

回答脉络

先描述 draft/target 两个模型，再讲接受与回退，最后讲适用条件。

详细参考答案

Speculative decoding 使用一个更快的小模型先预测一段 draft tokens，再由目标大模型并行验证这些 token。目标模型接受其中符合自身分布的前缀，遇到不接受的位置就从目标模型继续生成。这样可以减少目标模型逐 token decode 的串行次数，在两个模型输出分布相近、目标模型 decode 成为瓶颈时获得加速。

它的收益取决于 draft token 的接受率、验证批量效率、目标模型规模和服务负载。若小模型预测质量差，接受率低，额外的 draft 推理和验证开销可能抵消收益。对强约束 JSON、短答案、频繁工具调用或高并发场景，也要单独测试。

工程落地

压测时记录 draft 接受率、目标模型调用次数、TPOT、端到端延迟、GPU 利用率和质量回归。小模型和大模型应使用兼容 tokenizer 或明确处理 token 映射；模型更新后接受率可能改变，不能只复制旧配置。

常见追问及答案

• 问：speculative decoding 会改变答案正确性吗？ 正确验证算法应尽量保持目标模型分布，但实现细节、随机采样和停止规则仍需做一致性测试。
• 问：它主要解决 prefill 还是 decode？ 主要减少目标模型 decode 的串行步数，通常对长输出更有价值。

容易扣分

• 说成“小模型生成答案，大模型只做最后润色”。
• 忽略接受率和额外推理开销。

八、模型路由、部署与可靠性

Q35：如何设计一个真正可用的模型路由器？

考察点

考察你能否把路由从“按任务选模型”扩展到能力、成本、延迟、配额和故障切换。

回答脉络

先定义路由输入，再讲候选筛选、策略决策、降级和反馈闭环。

详细参考答案

模型路由器的输入可以包括任务类型、语言、上下文长度、是否需要视觉或工具调用、复杂度、租户等级、预算、数据合规区域和当前模型健康状态。路由流程通常是：

1. 根据能力和合规要求筛掉不可用模型。
2. 根据上下文长度、工具协议和结构化输出能力筛选候选。
3. 用规则、分类器或轻量模型估计任务难度。
4. 在质量、价格、延迟和剩余配额之间选择模型。
5. 对超时、限流和质量校验失败执行有限重试或升级。

路由不能只按“简单问题小模型、复杂问题大模型”硬编码，因为真实复杂度可能来自长输入、领域术语、工具依赖或高风险要求。路由决策要可解释、可配置、可回放，不能让一个黑盒分类器决定所有高风险动作。

工程落地

统一模型适配层，把不同供应商的消息格式、工具调用、usage、错误码和流式事件转换为内部协议。路由配置版本化，保留 fallback 顺序、超时、重试和预算上限。以任务成功率、升级率、单成功任务成本、P95 延迟和各模型错误率做路由反馈。

常见追问及答案

• 问：模型超时直接换另一个模型可以吗？ 要区分请求是否已在上游执行，避免重复写操作；对只读任务可有限重试，对写操作必须依赖幂等键和状态查询。
• 问：路由器如何知道任务难度？ 可以用规则、历史特征或小模型分类，但必须用标注集评估误判成本，尤其关注把高难任务错误路由到小模型。
• 问：路由是不是越动态越好？ 不是。过度动态会降低缓存命中、增加调试困难和版本不确定性，应在稳定策略和自适应策略之间取平衡。

容易扣分

• 只说按关键词路由。
• 不谈合规、预算、熔断、重试和观测。

Q36：LLM 推理 API 的重试、超时、幂等和降级应该怎么设计？

考察点

考察你是否知道模型服务也会遇到分布式系统问题，尤其是“请求可能已经执行但客户端没收到响应”。

回答脉络

按错误分类，再讲重试边界、幂等控制和用户可见降级。

详细参考答案

我会先把错误分成：参数错误、认证/权限错误、限流、服务暂时不可用、网络超时、上游已接受但响应丢失，以及模型内容不符合业务校验。只有暂时性错误才适合重试；参数和权限错误重试没有意义；高风险写操作不能因为超时就盲目重发。

重试策略需要指数退避、随机抖动、最大次数和总 deadline。每次请求使用 request_id；涉及外部副作用的 tool call 使用业务幂等键。客户端超时后，服务端应提供状态查询或任务队列，而不是让客户端猜测是否成功。

降级可以包括：换同能力备用模型、关闭非必要工具、减少检索 top-k、返回已验证的缓存结果、转异步任务、请求用户稍后重试或转人工。降级必须显式记录，不能悄悄返回看似正常但质量未知的内容。

工程落地

为每个模型和下游设置独立连接池、并发上限、超时和熔断器，避免一个供应商故障拖垮整个网关。监控重试率、超时率、fallback rate、重复副作用、队列堆积和每次成功任务的总耗时。

常见追问及答案

• 问：HTTP 500 都可以重试吗？ 不一定。要结合上游是否可能已经执行、请求是否幂等和错误语义判断。
• 问：流式响应中断怎么办？ 保存已发送片段和请求状态，判断是否能安全续写；结构化或写操作不能简单把半截内容拼成成功结果。
• 问：备用模型一定要和主模型完全一样吗？ 不需要完全一样，但要明确能力差异、协议差异和质量降级边界，提前做兼容评估。

容易扣分

• 只说“失败就重试三次”。
• 不区分读请求和写请求。
• 不设计幂等和状态查询。

Q37：如何设计 LLM 网关的限流、配额和成本预算？

考察点

考察你是否能把 token 资源管理和传统 QPS 限流结合起来。

回答脉络

先讲为什么单看请求数不够，再讲多维配额、预估和结算。

详细参考答案

LLM 请求的资源消耗与输入输出长度差异很大，单纯按 QPS 限流不够。一个短分类请求和一个长上下文、长输出的 Agent 任务可能消耗完全不同的 GPU 时间和费用，因此网关通常同时控制：

• 请求数、并发数和每秒请求数。
• 输入 token、输出 token 和每分钟 token。
• 单租户、用户、API key、接口和模型配额。
• 单任务最大轮数、工具调用次数、总 deadline 和预算。

网关可以在请求前用 tokenizer 估算输入，并为输出预留预算；请求完成后以服务端 usage 结算，修正估算误差。遇到额度不足时，可以拒绝、排队、切换低成本模型、缩短上下文或转异步，但要把原因和降级状态记录下来。

工程落地

采用分层限流：全局保护、模型级容量、租户级配额和用户级公平性。预算按日或月结算，预留突发额度，避免多个并发请求同时穿透预算。看板展示 token 用量、缓存比例、模型分布、重试成本、成功任务成本和预算消耗预测。

常见追问及答案

• 问：为什么 token 限流还要做并发限流？ token 只描述工作量，不能完全保护连接数、KV cache、线程和下游资源，两者需要同时控制。
• 问：预估 token 不准怎么办？ 预估用于准入和预算预留，最终以服务端 usage 对账；长输出或推理模型要设置更保守的上限。
• 问：限流会不会伤害体验？ 会有影响，所以应按优先级和任务类型排队，交互请求和离线批处理不能使用同一套策略。

容易扣分

• 只实现 QPS，不考虑 token 和上下文长度。
• 没有租户隔离和预算耗尽策略。

Q38：如何做模型服务的容量规划？为什么“单卡能跑起来”不代表可以上线？

考察点

考察你是否能把模型加载、并发、峰值流量、尾延迟和高可用放在一起估算。

回答脉络

先列资源项，再按业务流量换算，最后做压测和冗余。

详细参考答案

容量规划至少要考虑：模型权重、KV cache、激活和 workspace、GPU 显存余量、输入输出长度分布、并发数、目标 TTFT/TPOT、峰值 QPS、流式连接数、工具等待和故障冗余。简单的“模型参数量乘每参数字节数”只能估算权重，不能代表推理峰值。

我会先从业务侧得到平均和 P95 输入输出长度、峰值并发、读写比例、SLA 和可接受降级，再用目标硬件和推理框架压测。测试应覆盖冷启动、热启动、短请求、长请求、混合长度、continuous batching、取消和上游限流。根据单实例在 SLA 下的有效吞吐计算实例数，并额外保留故障和发布余量。

工程落地

生产至少区分模型加载池、交互推理池和离线批处理池，避免离线大任务抢占在线流量。设置健康检查、优雅退出、请求排空、自动扩缩容和版本灰度。扩容指标不能只看 CPU，至少还要看 GPU 显存、KV cache、队列等待、TTFT P95 和有效 tokens/sec。

常见追问及答案

• 问：GPU 利用率 80% 就还能接 20% 流量吗？ 不能直接这样推断，瓶颈可能是显存、KV cache、带宽或尾延迟，需按 SLA 压测。
• 问：模型加载需要多久有什么影响？ 影响扩容、故障恢复和发布窗口；大模型可采用预热、镜像缓存和备用热实例降低冷启动风险。
• 问：为什么线上压测结果比离线 benchmark 差？ 线上有排队、网络、流式连接、混合长度、工具等待、日志和多租户竞争，单请求 benchmark 不能代表真实场景。

容易扣分

• 只估权重显存，不算 KV cache 和运行时开销。
• 只测平均延迟，不测高并发和 P95/P99。
• 没有冗余、灰度和优雅退出方案。

Q39：FP32、FP16、BF16 和混合精度训练有什么区别？

考察点

考察你是否理解浮点格式、数值稳定性和训练/推理资源之间的关系。

回答脉络

先比较位宽和表示范围，再讲 BF16/FP16 的训练差异，最后说明为什么仍需要 master weights 和 loss scaling 等机制。

详细参考答案

FP32 使用 32 位表示，精度和数值范围相对充足，但显存和带宽成本高。FP16 使用 16 位，能减少显存、提高部分 GPU 上的计算吞吐，但指数范围较小，训练中更容易出现 overflow 或 underflow。BF16 也是 16 位，但指数范围接近 FP32、尾数精度较低，通常更适合现代硬件上的大模型训练，因为数值范围更稳，很多场景不需要复杂的 loss scaling。

混合精度不是“所有东西都改成半精度”，而是根据算子和稳定性选择精度：矩阵乘等高吞吐计算使用 FP16/BF16，部分归约、归一化、损失计算或优化器状态保留更高精度。训练时可能保留 FP32 master weights、梯度累积或优化器状态，以降低数值误差。

推理时 FP16/BF16 常用于质量和速度折中；再往下的 INT8/INT4 属于量化，机制和风险不完全相同。不同 GPU 对 BF16、FP16、Tensor Core 和量化 kernel 的支持也不同，不能只看数据类型名称。

工程落地

我会在目标硬件上比较显存、吞吐、loss 曲线、NaN/Inf 计数和最终任务指标。训练出现不稳定时检查学习率、梯度范围、归一化算子、loss scaling、数据异常和 kernel，而不是直接归因于“模型太大”。

常见追问及答案

• 问：BF16 精度比 FP16 高吗？ 不能简单这样说。BF16 尾数精度通常低于 FP16，但指数范围更大，训练中的数值稳定性往往更好。
• 问：推理一定用 FP16 吗？ 不一定，要根据硬件、模型支持、延迟、显存和质量选择 BF16、FP16 或更低比特。
• 问：混合精度会不会改变模型结果？ 可能带来微小数值差异，因此需要固定环境和回归评估；通常可以在质量门槛内获得更好的资源效率。

容易扣分

• 把 FP16、BF16 和 INT4 都叫“半精度”。
• 认为混合精度就是所有张量都使用同一种低精度。

Q40：微调时学习率、batch size、epoch 和 gradient accumulation 怎么一起考虑？

考察点

考察你是否能从有效 batch、训练步数和过拟合角度解释微调参数，而不是背一组固定数值。

回答脉络

先定义有效 batch，再讲学习率和训练轮数的相互影响，最后说监控和调参顺序。

详细参考答案

有效 batch size 可以近似理解为：

effective_batch
  = per_device_batch
  * gradient_accumulation_steps
  * data_parallel_world_size

单卡放不下大 batch 时，可以用 gradient accumulation 多个 micro-batch 累积梯度后再更新一次。batch 变大通常会改变梯度噪声和每个 epoch 的更新步数，学习率不能完全照搬小 batch 配置。epoch 太少可能学不到任务模式，太多则可能过拟合、格式僵化或遗忘通用能力。

LoRA 微调虽然可训练参数少，也不代表可以无限提高学习率。关键要看数据量、任务差异、rank、序列长度、目标模块和底座模型。调参时我会先固定数据和评估集，优先观察训练/验证 loss 分叉、目标指标、通用能力和输出长度变化，再调整学习率、训练步数、warmup、batch 和正则。

工程落地

记录每次实验的有效 batch、学习率、warmup、epoch、总 token、梯度范数、训练 loss、验证 loss 和 checkpoint。使用 early stopping 或选择最佳验证 checkpoint，不把最后一个 checkpoint 默认当成最优版本。显存不足时优先降低 micro-batch 并使用梯度累积，同时评估训练吞吐是否变差。

常见追问及答案

• 问：epoch 越多效果越好吗？ 不一定。小数据集上很容易过拟合，尤其是格式和风格任务。
• 问：gradient accumulation 等于真正增大 batch 吗？ 在梯度平均近似和实现正确时效果接近，但它不能完全替代大 batch 的并行计算，训练时间和某些算子行为不同。
• 问：怎么知道学习率太大？ 观察 loss 爆炸、NaN、验证集突然恶化、输出异常和梯度范数异常；需要结合实验对比，不能只看单个 step。

容易扣分

• 只给一个固定学习率和 epoch，完全不看数据规模。
• 不理解 gradient accumulation 对有效 batch 的影响。

Q41：Base 模型、Instruction 模型和 Chat 模型有什么区别？部署选型时怎么判断？

考察点

考察你是否理解模型训练阶段和对话模板，避免模型本身没选对却一直修改 prompt。

回答脉络

先区分预训练模型和指令对齐模型，再讲 chat template、工具调用和适用场景。

详细参考答案

Base 模型主要完成预训练，擅长根据上下文延续文本，但未必理解“请完成任务”的指令，也未必遵循对话 role 和 JSON 协议。Instruction 模型经过 SFT 等训练，更擅长遵循任务指令、回答问题和执行固定格式。Chat 模型通常进一步针对多轮对话、拒答、安全和角色消息做了对齐，常配套特定 chat template。

选型要看任务：继续训练领域语言可能从 base 开始；直接做问答和 Agent 通常优先 instruction/chat 模型；需要工具调用时要验证模型是否见过工具 schema、是否支持并行调用、是否能在失败后修正。即使模型能力相同，错误的 chat template、role 顺序或特殊 token 也可能让输出明显变差。

工程落地

部署时固定 tokenizer 和 chat template，不要手工拼接一个“看起来差不多”的 prompt。模型注册信息中保存 base/instruction 类型、上下文长度、停止 token、工具协议、量化格式和已知限制。迁移模型时做同一批消息的 template 对比和任务回归。

常见追问及答案

• 问：Base 模型一定不能做对话吗？ 可以通过额外 prompt 或微调实现，但指令遵循和安全行为通常需要额外验证。
• 问：换模型只替换 model name 就行吗？ 不一定。tokenizer、模板、停止条件、工具协议、输出格式和安全行为都可能不同。
• 问：Chat template 为什么会影响结果？ 它决定 role、边界和特殊 token 的编码，模型训练时学习了相应格式，格式不匹配会改变输入分布。

容易扣分

• 把 Base、Instruction、Chat 当成参数量不同的三个版本。
• 不检查 chat template 和停止 token。

Q42：流式推理接口如何处理客户端断开、取消和背压？

考察点

考察你是否能把流式输出从“逐字显示”讲到连接生命周期、GPU 资源和系统稳定性。

回答脉络

先讲事件流，再讲取消传播与资源回收，最后讲背压和一致性。

详细参考答案

流式接口通常通过 SSE、WebSocket 或类似协议持续发送 token/event。服务端需要维护 request_id、sequence 状态、已发送 token、finish reason 和错误状态。客户端断开后，取消信号要传到网关、调度器和推理引擎，及时停止后续 decode 并释放 KV cache；否则用户看不到结果，但 GPU 仍在消耗。

背压是指客户端读取速度跟不上模型输出速度。如果服务端无界缓冲，慢客户端会积压内存和连接；如果直接丢事件，又可能让结构化结果不可恢复。常见策略是有界队列、写超时、取消慢连接、区分可重放事件和不可重放 token，并在结束时发送明确的完成或错误事件。

对 Agent 流式输出，还要区分模型文本、tool call delta、工具执行状态和最终结果，不能只把所有事件拼成字符串。工具写操作应在服务端确认成功后再发送“已完成”，避免把模型意图误显示成真实执行结果。

工程落地

测试正常完成、客户端主动取消、网络断开、代理超时、慢客户端、工具执行中取消和服务进程重启。监控活跃流连接、取消率、断连后残留任务、发送缓冲区、KV cache 回收时间和未完成请求数。

常见追问及答案

• 问：用户关闭页面后，模型一定会停止吗？ 不一定。需要实现从连接到推理任务的取消传播，并设置服务端 deadline 兜底。
• 问：流式输出中途不能重试吗？ 可以尝试续写，但必须判断已发送内容、随机性和任务是否幂等；结构化结果和副作用操作不能简单拼接。
• 问：为什么不能无限缓存输出事件？ 慢客户端会让内存和连接数无限增长，最终拖垮整个服务。

容易扣分

• 只讲前端打字机效果，不谈后端取消和资源释放。
• 不区分文本事件、工具事件和最终状态。

Q43：如何做多模型、多供应商的统一适配层？

考察点

考察你是否能处理不同模型 API 的协议、能力、错误和计费差异，避免业务代码到处写供应商分支。

回答脉络

先定义内部协议，再讲能力矩阵、适配差异、观测和版本治理。

详细参考答案

统一适配层应该抽象业务真正需要的能力，而不是假设所有供应商字段完全一致。内部协议至少覆盖 messages、模型参数、工具 schema、流式事件、结构化输出、usage、finish reason、错误分类和 request metadata。供应商差异通过 adapter 转换，业务层只依赖内部协议。

同时维护模型能力矩阵：上下文窗口、输入/输出模态、工具调用、并行 tool calls、JSON Schema、缓存、reasoning usage、速率限制、区域和数据保留策略。能力不支持时要在路由前拒绝或降级，不能等到线上返回模糊错误。

统一层还要保留原始响应和规范化响应的关联，便于对账和问题定位。不同供应商的 token 统计、缓存字段和价格不一致，成本计算模块要使用“模型版本 + 价格版本 + usage schema”进行适配。

工程落地

为每个 adapter 写协议一致性测试：普通文本、空输出、工具调用、并行工具、结构化失败、流式中断、限流、超时和 usage 解析。新供应商先通过回放测试，再进入 shadow 或小比例路由，保留快速回退开关。

常见追问及答案

• 问：统一成 OpenAI 风格接口够不够？ 只能解决部分消息格式问题，不足以抹平缓存、推理用量、工具协议、错误语义和上下文差异。
• 问：多供应商切换会影响 prompt cache 吗？ 会。缓存通常与模型、服务端和前缀规则绑定，切换供应商后命中率可能重新开始。
• 问：如何避免供应商 SDK 升级造成线上回归？ 锁定版本、保留适配器契约测试、回放真实请求，并用灰度和可回退配置发布。

容易扣分

• 只做字段转发，不处理能力矩阵和错误语义。
• 把不同供应商的 token/缓存字段当成完全同名同义。

新增题目常见扣分点

• 把继续预训练、SFT、LoRA、QLoRA 和 DPO 都泛化成“微调”，讲不清数据形式、优化对象和适用问题。
• 只用训练 loss、公开榜单或单一准确率判断模型，不看泛化、能力保持、安全和单成功任务成本。
• 只估算模型权重显存，不考虑激活、KV cache、workspace、碎片和并发序列。
• 把“显存占用下降”直接等同于“推理速度一定提升”，忽略硬件、kernel、带宽和通信。
• 只报平均延迟或 QPS，不区分 TTFT、TPOT、E2E、P95/P99 和有效吞吐。
• 把 continuous batching 说成普通 batch 拼接，不会解释请求动态加入、退出和公平调度。
• 遇到超时就无脑重试，不区分只读请求、写操作、上游已执行和幂等键。
• 只做 QPS 限流，不控制 token、KV cache、并发、租户配额和单任务预算。
• 把模型路由理解成按关键词切换，忽略能力矩阵、合规、健康状态和可回放性。
• 多供应商接入只转发字段，不处理 chat template、工具协议、usage、价格和错误语义差异。