这两年我前前后后参加过几十场 LLM 相关的技术面试，也帮团队面过不少候选人。说句实在话，面试官问来问去，真正能拉开差距的也就那么几个问题。标题里提到的这 8 个问题，几乎是我见过淘汰率最高的追问组合。你要是准备去面 LLM 岗，不管是大模型算法岗、AI 应用开发还是 Agent 工程岗，这几个问题答不好，前面聊得再热乎也白搭。这篇文章我把它们掰开揉碎了讲清楚，每个问题都拆解背后的考察点、答题思路、常见误区和加分项，争取让你看完之后能直接拿去用。

1. 这 8 个问题到底在考什么

1.1 面试官不是考你会背，是看你怎么思考

很多候选人以为面试就是背书，把 Transformer 架构、Self-Attention 公式、LoRA 原理背得滚瓜烂熟就稳了。但实际上 LLM 面试的核心从来不是考察记忆，而是考察两件事：第一，你是否真正理解大模型这套技术栈的工作原理，理解到什么层级；第二，面对一个真实问题，你能不能把知识转化成工程解决方案。

我举个特别常见的例子。问 "Transformer 为什么用 Layer Norm 而不是 Batch Norm"，如果你只回答 "Layer Norm 不受 batch size 影响"，那只是及格线。面试官真正想听的是你对训练动态的理解——RNN 和 Transformer 里序列长度可变，Batch Norm 的统计量会抖动，而 Layer Norm 对每个 token 独立做归一化，保证梯度流稳定。更进一步，你还能说出 Pre-Norm 和 Post-Norm 的区别，Recovery 和调节学习率的联动关系，这才是高手。

1.2 8 个问题背后的三条主线

我把这 8 个问题归纳成三条主线：基础理论、工程落地、实战排查。基础理论线主要考你对 Transformer、Tokenizer、Scaling Law 这些底层原理的理解；工程落地线考的是 RAG、Agent、微调和数据标注，这些直接决定你能不能把模型真正用起来；实战排查线是压轴题，考的是幻觉评估、容错控制和调优经验，这部分最容易暴露候选人是不是真的动手做过。

这三条主线不是孤立存在的。记住面试官心里有一条隐藏链条：你的模型在真实场景跑起来之后会遇到什么问题，你怎么发现，怎么定位，怎么解决。任何一个环节答得虚，都会被追问出来。

1.3 高分答案的共同特征

我观察过很多高分候选人的回答，他们都有几个共同点：会用"因为我实际跑过，所以我知道……"这类真实经验开头；会把问题和更大的系统联系起来；会主动说"这个方案在什么场景下不适用"。这三点其实是同一件事——你不仅知道答案，还知道这个答案的边界。

所以这篇博文我不打算给你标准答案，而是给你一条"答题链"：考察点 → 核心原理 → 现场回答示范 → 易错点 → 加分项。你把这个链条吃透，面试的时候就能从容应对各种变形追问。

2. 理论根基题：Transformer 架构与 Tokenizer

2.1 为什么第一题必问 Transformer

Transformer 是 LLM 的底座，这个问题不搞清楚，后面全是空中楼阁。面试官问 Transformer 通常不从"请介绍一下 Transformer"这种开放式问题切入，而是从一个细节切入，然后不断深挖。

最常见的深挖路径是 Self-Attention 的复杂度。你要能说出标准 Softmax Attention 的时间复杂度是 O(n²d)，空间复杂度也是 O(n²)——这里 n 是序列长度，d 是维度。当序列长度到 8K、16K 的时候，平方级复杂度会让训练和推理都变得不可接受。这时候面试官会追问："那你有什么优化思路？"你应该自然引出 FlashAttention——它通过分块计算、重计算等方式避免一次性把完整的注意力矩阵加载到 HBM 里，把显存占用从 O(n²) 降到 O(n) 级别，训练速度提升明显。

再往下深挖，面试官可能会让你现场推一下 Q、K、V 的计算过程。这里要特别注意，很多人把公式写出来就停了，但真正的得分点是解释清楚"为什么要把 QK^T 除以 √d_k"。答案是除以 √d_k 是为了防止维度增大时点积数值过大，导致 Softmax 进入饱和区，梯度变得极小。我面试的时候会特意追问这一点，能答上来的候选人不到三分之一，你把这个细节搞懂，就已经超过大多数人。

2.2 Tokenizer 是很多人栽跟头的隐藏考点

Tokenizer 看起来简单，其实是最容易暴露基本功底的问题。面试官会问三类问题：分词原理、词表大小的影响、Tokenizer 对模型能力的限制。

分词原理要能说清楚 BPE（Byte Pair Encoding）的核心逻辑——从字符级开始，反复统计最高频的相邻字符对并合并，直到达到目标词表大小。注意 BPE 不是简单切词，它是在字节和字符之间找到一个平衡，让常见词变成单一 Token，生僻词可以用子词组合出来。比如 "unhappiness" 可能被拆成 "un"、"happi"、"ness"，这样既能压缩序列长度，又能处理没见过的新词。

词表大小的影响是个高频追问点。词表太大，Embedding 层参数爆炸，训练和存储成本都上去；词表太小，每个词要拆成很多子词，序列变长，计算量增大，表达能力也下降。常见的 32K、50K、100K 词表都有自己的适用场景，没有绝对最优。这里我建议你用具体数据说明：比如 50K 词表，Embedding 维度 4096，那么仅 Embedding 层参数就有 50K × 4096 ≈ 2亿参数，相对一个 7B 模型占比不算大，但如果词表扩到 200K，Embedding 参数就接近 10 亿，这时候就必须考虑词表压缩或者共享 Embedding 方案。

Tokenizer 对模型能力的限制这个问题，答好了特别加分。你要能提到 "Tokenizer 崩坏" 现象——例如当输入包含大量代码、数学公式、特殊符号时，Tokenizer 会把本来连续的语义切成碎片，导致模型理解困难。我实际测试过，对一些代码密集的输入，token 数可能比正常文本多出 30%-50%，而且模型回答质量明显下降。这就解释了为什么很多大厂要花大力气做代码专用的 Tokenizer 或扩充词表。

2.3 手撕细节：经典"8 选 2"之一怎么答

Transformer 相关的问题里，最常被要求"手撕"的是两段：一段是 Attention 计算的伪代码，另一段是 Pre-Norm 和 Post-Norm 的残差连接结构。面试官让你手撕，不是为了看你默写，而是看你在没有文档辅助的情况下，是否真的理解数据流的形状变化。

以 Attention 为例，你要能写出数据形状的变化过程：输入 X 形状是 (batch_size, seq_len, hidden_dim)，经过三个不同的线性层得到 Q、K、V，形状不变。然后 Q 乘以 K 的转置（K 要转置成 (batch_size, seq_len_head, seq_len)，这里 head 是注意力头数），注意力分数经过 Softmax 后乘以 V，最后经过输出投影。写代码的时候要注意两点：第一，mask 怎么处理？padding mask 要在 Softmax 之前把无效位置设为负无穷，这样才能让 Softmax 概率趋近于零，而不是在 Softmax 之后硬性 zero；第二，多头注意力时 Q、K、V 要拆成多头并行计算，最后再 concat 回来，面试官会追问为什么要并行——因为每个 head 可以关注不同的语义子空间，类似多个"频道"同时工作。

Pre-Norm 和 Post-Norm 的区别，我提供一个记忆方法：Post-Norm 是在残差相加之后做归一化，所以归一化的是"模块输出 + 残差输入"，早期 Transformer 都用这种结构，但梯度在反向传播时要经过多层叠加，容易梯度消失；Pre-Norm 是先归一化再进模块，残差加的是一个"已经标准化的分支"，梯度通道更干净，所以现在的主流 LLM 基本都用 Pre-Norm。面试时顺嘴提一句 "GPT 系列和 LLaMA 系列都用 Pre-Norm，配合残差连接的初始化技巧，可以让训练更稳定"，这个加分效果很直接。

3. Scaling Law 与数据标注：决定模型智商的两个暗门

3.1 Scaling Law 不是背公式，是要理解曲线拐点

Scaling Law 是 LLM 面试里"看起来简单、实际淘汰率极高"的问题。很多候选人能背出"模型性能随参数量、数据量、计算量幂律增长"，但被问到"给一个 10B 模型继续训练，数据和算力都有限，你怎么分配资源"就卡住了。

核心公式你要掌握：$P = A \cdot N^{-α} + B \cdot D^{-β} + E$，这里的 P 是 loss，N 是参数量，D 是数据量，α、β 是缩放指数。实际工程里，我们要关注的是损失函数的下降逐渐变慢的拐点。比如训练一个模型时，在 100B token 时 loss 下降很快，到 500B token 时每增加 100B token 只下降 0.01，这时候再堆数据性价比就很低了，应该转去调优化器、调学习率，或者提升数据质量。

另外一个高频变形是 "Chinchilla 法则"。这篇论文核心结论是：在计算量预算固定时，最优参数量和 token 数应该等比放大。具体来说，参数量和训练 token 数大约都是原始模型的 1.6 倍左右，模型规模和数据量要一起涨，不能只加参数不加数据。面试官经常会追问："既然这样，为什么很多大模型还是参数很大、数据相对偏少？"正确的回答是：因为推理成本也是约束，一个模型参数量翻倍，推理延迟和显存占用都会涨，所以在算力受限时，很多团队宁可在数据上多砸几个 epoch，也不把模型搞得太大。这个回答体现出的工程权衡思维，比单纯背结论高级得多。

3.2 数据标注：面试官想听的"脏活经验"

LLM 的数据标注是个又脏又累但面试必问的环节。热词里有"llm怎么数据标注"，说明很多人就有这个困惑。面试官不会问抽象的数据标注理论，他只会问你实际做过的数据处理流程。

你要能说清楚一条完整的标注链路：原始数据收集 → 清洗去重 → 质量分级 → 格式转换 → 多轮校验。这里面的坑非常多。举个例子，只是"去重"这一步就大有文章——用 MinHash 做内容去重，你在实际中会遇到一个棘手问题：很多文本只是长得像，但内容完全不一样，比如产品描述里带价格变动和日期信息，简单哈希去重会把它们误判为重复。正确的做法是先做模板归一化，把数字、日期、人名替换成特殊占位符再做去重，召回率会好很多。

还有一个高频问题是 "如何设计偏好数据"。现在主流训练流程里，SFT 之后要用 RLHF/DPO 做对齐，偏好数据就是用来打分排序的。面试官会问：偏好标注有哪些陷阱？你要能答出这几点：第一，不同标注员对"好回答"的标准差异极大，所以必须写详细的标注规范，最好带正反例；第二，标注员容易受长度和语气影响——更长的回答、更正式的语气不一定更好，要设计"对比式"评估而不是"绝对式"评估；第三，要做交叉标注和一致性检测，比如同一对回答让三个标注员打分，用 Cohen's Kappa 算一致性系数，低于 0.6 就要讨论、培训、重标。

第三个必问的数据题是"数据配比"。训练集里不同来源的数据比例怎么定？我的经验是代码类数据可以占到 20%-30%，数学类 10%-15%，百科、书籍这些长文本大概 40%，对话数据 15%-20%。代码数据比例高，模型推理能力会明显提升，但代码数据太多会让模型在自然语言任务上变得有点"生硬"，所以要用下游任务指标来反推配比。你需要举一个具体例子：我在一次 SFT 中用 20% 代码 + 80% 文本，模型在 HumanEval 上提升了 8 个点，但日常写作的连贯性略有下降，后来把代码比例降到 15%，两个指标都恢复到了一个不错的平衡点。这种回答才是真正的干货，面试官一听就知道你动手调过数据。

4. 工程落地题：RAG、Agent 与幻觉评估

4.1 RAG 面试的核心不是"是什么"，而是"什么时候用"

RAG（Retrieval-Augmented Generation）已经成了 LLM 应用开发的标配，面试官基本必问。但大多数候选人只会说"RAG 就是检索 + 生成"，然后被追问两句就露馅。

我建议你从问题出发回答：RAG 要解决的是什么问题？在什么场景下值得上 RAG，什么场景下上了反而拖后腿。要解决的核心问题是"模型知识截止日期之后的新知识"和"私有领域知识"。比如给一个 2024 年以前的模型接入 2025 年的产品文档，如果不做检索增强，模型要么胡说，要么说"我不知道"，所以你需要把文档先切片、向量化、存储，然后在生成前检索相关片段，喂给模型。

面试官会问："那 RAG 和长期微调有什么区别？"你要答出三个关键维度：第一，RAG 是即插即用的知识更新，不需要重新训练模型，成本低；第二，RAG 的可追溯性好——引用来源能定位到具体文档，这在金融、医疗场景非常关键，你做微调就说不清楚模型为什么会突然答出某个答案；第三，RAG 对知识冲突的处理更灵活。但是 RAG 在复杂推理和多跳问题上比较弱，比如"帮我对比这三份文档里的合同条款差异"，普通的 Top-K 检索很难把三份文档的相关片段都捞出来，这时候要上 GraphRAG 或者 Multi-hop RAG 才能缓解。

RAG 的实战细节里，三个问题必定被追问：切分策略、检索融合、重排。切分策略方面，你会刻意强调"固定长度切分是偷懒方案"，更好的做法是按文档结构切，比如 Markdown 标题、PDF 段落边界、代码函数边界。你要是能说出 "Recursive Character Text Splitter" 和 "Semantic Chunking" 的差别——前者按字符数递归切，后者用 Embedding 相似度判断语义边界——面试官的眼睛就亮了。检索部分，让你现场算 BM25 和向量检索的打分融合公式也不要慌，简单的加权公式 Score = α · S_vector + (1-α) · S_bm25 就能说清楚，再加一句 "α 一般从 0.3-0.7 之间网格搜索" 就非常落地。重排环节，你要说到 "学术上叫 cross encoder，工业界直接跑一个小的 rerank 模型，一般把 Top 50 压缩到 Top 5，效果提升明显，但注意 Reranker 的时延，如果放在在线链路会拖慢响应，要合理缓存"。

4.2 Agent 与自主容错控制：热词背后的隐藏考点

最近"识的 llm 智能体自主容错控制"这类热词挺火的，面试里 Agent 方向的考题也越来越多。面试官会问你：如果 Agent 在执行任务的过程中出错，你怎么办？这个问题本质是考"容错控制"。

Agent 出错的方式五花八门：工具调用格式错误、工具返回结果异常、模型幻觉导致决策错误、陷入死循环。有工程经验的人会指出，90% 的 Agent 错误发生在"模式匹配"上——模型生成了 JSON，但 JSON 里有一个字段名拼错了，或者少了一个逗号，工具调用直接失败。

回答这个问题，你要先讲三层防线。第一层是输出校验——工具调用结果要做 Schema 校验，不符合就要求模型重新生成，或者用规则修复。注意这里不要只说"重试"，要补充"带错误信息的重试"：把校验失败的报错原封不动返回给模型，让模型看错误信息后自我修正，成功率会提升一大截。第二层是状态机回退——Agent 需要一个状态管理机制，比如定义 NORMAL、RETRY、FALLBACK、TERMINATED 四个状态，当重试次数超过阈值就自动切换到 FALLBACK 策略，比如从自动调用切换为询问人工确认。第三层是异常兜底——当一个 planner 的决策链太长导致失败，最简单的方案是回退到单步 ReAct 模式，先执行一步工具、看一眼结果、再决定下一步，牺牲效率换稳定性。

我实际踩过的一个大坑是 Agent 的循环检测。LLM 在长时间任务里很容易陷入两个动作之间反复切换，比如反复调用同一个搜索引擎 API 改关键词，返回结果却一直不变。我当时的解决方案是加一个"动作哈希记忆"——把每次的输入和工具调用做 hash，当出现重复的 (state, action) 对时就强制打断，输出"任务陷入循环，建议人工干预"。这个方案不算高大上，但非常有效，面试时讲出来，能体现你了解 Agent 在真实环境中的脆弱性，而不是只会背 ReAct 的步骤。

另一个加分点是把 Agent 的解析从 JSON 改成 Function Calling/结构化输出。常见框架里，工具调用格式混乱是个老大难，但如果你用模型的 function calling 能力而不是让模型自己编 JSON，加上一套输出校验器，容错率能提升很多。你在回答中主动提这个，面试官会觉得你真的在推理阶段摸爬滚打过。

4.3 LLM 幻觉：评价体系与治理手段

幻觉是 LLM 应用场景里几乎必然被问到的问题。任何做 LLM 落地的团队都要面对用户提问模型不知道答案，模型一本正经地编造事实。

面对这个问题，面试官会从两个角度深挖：你怎么评估幻觉，你怎么减少幻觉。评估方面，你要能区分两个核心指标：事实一致性（Factual Consistency）和忠实度（Faithfulness）。事实一致性是查看生成内容是否和外部事实匹配，常用方法有 ROUGE、BLEU、BERTScore 之类，但更工程化的是用另一个 LLM 做"元评论"打分——热词里提到"llm 元评论残留"，其实指的就是这种用 LLM 去评测 LLM 的思路。你要能说清楚：用 GPT-4 或者 Qwen 做 evaluator，把生成内容和检索到的证据同时丢给 evaluator，让它打分"1-5 分，5 分是完全一致"，然后拿这个分数做回归测试。不过这里要提一个坑：元评论和模型自身可能共享相同的偏见，所以要在评测集里加人工抽检。

减少幻觉的手段也要分层：第一层是 Source Augmentation，给模型提供高相关性的上下文，并显式要求"当无法从上下文中找到答案时，请回答不知道"，这种指令级别的约束能压掉一部分幻觉；第二层是解码阶段优化，比如用 DoLa 或者 contrastive decoding 方法降低模型对已知信息的过度自信；第三层是训练阶段优化，SFT 时故意加入"无法回答"的正样例，让模型学习抑制幻觉。面试回答时，把这些手段串成一个"测-治-防"闭环，比零散罗列更有说服力。

5. 安全对齐与最优实践：从 RLHF 到 DPO 的进阶话题

5.1 对齐面试中的高频三连问

对齐问题是 LLM 工程岗和算法岗面试的分水岭。面试官通常从 RLHF 切入，如果你说"RLHF 就是人类反馈强化学习"，那基本上就结束了——这是基础中的基础。高分回答至少要能覆盖三个层次。

第一个层次：RLHF 的训练链路。你要能画出完整流程：先训练一个 SFT 模型，再用人类偏好数据训练一个 Reward Model（RM），最后用 RM 作为奖励信号去优化 SFT 模型（PPO 优化）。这里有个关键细节：RM 输出的是一个标量分数，分数的高低代表回答质量的高低，它取代了传统强化学习中的环境奖励。写训练代码时必须用分类头替换语言模型的输出头，并且只从最后一个 token 输出分数。有不少候选人把 RM 当成"打分器"，用模型最后的 token embedding 过一个 MLP 就完事，实际工程需要关注 label smoothing、overfitting 防止策略。

第二个层次：为什么用 PPO，不用别的强化学习算法？PPO 的优势在于通过 clipped surrogate objective 限制每次更新策略的幅度，避免策略崩坏。LLM 参数空间巨大，直接用原始策略梯度容易损坏模型已经学到的语言能力。你要能说出 PPO 里 4 个核心 loss 项：actor loss（最大化reward的同时维持与参考策略的KL距离）、value loss（critic 网络估计价值）、KL penalty 和 entropy bonus。一场面试里能把这些讲完整的候选人，我遇到的真的是屈指可数。

第三个层次：DPO 为什么能火起来？它的核心贡献是绕开了显式的 RM + RL 训练，直接把"偏好数据"转化为策略优化的损失函数。用 DPO 训练不用起多套模型，也不用写 PPO 的分布式采样逻辑，代码量少很多，训练更稳定。但 DPO 有它的局限——如果你的偏好数据存在标签错误，DPO 的损失会对噪声特别敏感，直接导致生成质量下降，所以数据清洗和偏好校验在 DPO 里格外重要。你回答时把"PPO 适合在线探索和复杂奖励，DPO 适合离线偏好数据"这个边界说清楚，面试官会立刻高看你一眼。

5.2 数据安全与生成安全的实操细节

安全对齐还有一个很多候选人忽略的角度：数据安全。面试官会问"你如何处理训练数据的隐私和安全问题"。这里要能答出几个层次：第一，数据脱敏——训练数据里可能包含用户手机号、身份证号，要做 PII（Personally Identifiable Information）检测和替换；第二，数据合规——版权数据怎么用，要能说清楚"源头授权 + 内容指纹"的基本流程；第三，隐私保护训练——比如 DP-SGD（差分隐私随机梯度下降），虽然牺牲一些模型质量，但能提供数学可证明的隐私保证。

生成侧的安全问题是红队测试。你会被问到：如何评估模型的安全边界？标准回答是设计红队测试集，包括恶意指令攻击、Prompt Injection 攻击、角色扮演诱导等。我的实操经验是，红队测试不能只靠几个人拍脑袋写攻击样本，要用模型生成候选攻击模板，再人工筛选和迭代，因为人的创造力是有限的，而模型的"攻击风格"扩展得很快。如果你在面试里能说一个具体的攻击样本怎么从"无害"被改造成"有害"的案例，比讲 10 分钟概念的价值大得多。

5.3 DPO 和 RLHF 怎么选，给出你的判断依据

这个问题其实就是考察你在真实项目里的决策能力。我的回答框架是：看三个输入——数据量、算力、需求实时性。

如果偏好数据只有几千条，不用犹豫，选 DPO。PPO 需要训练 RM、需要在线采样，几千条数据很难训练出可靠的 reward model，反而 DPO 在做几千条数据时收敛更快、损失更稳定。如果算力充足、偏好数据规模达到几万条以上、并且你想让模型在"对话自然度"上有更大增益，那就上 RLHF。要注意 RLHF 的在线采样阶段非常吃 GPU 资源，因为 PPO 每一步都要做 rollout、算回报、更新策略，四个模型（actor、critic、ref、reward）同时在显存里，7B 模型至少需要 4× 显存占用。如果需求是"模型要持续在线学习，偏好动态变化"，那我建议 PPO，因为可以持续采样新数据做增量更新；DPO 则是离线一次性的，更新一轮就得重训。

面试时把这三条判断依据列出来，然后举一个自己项目的真实例子收尾，比如"我之前用 DPO 做了一个客服模型的偏好对齐，数据量大约 8000 条，3 天跑完，效果和同期用 PPO 尝试的效果打平，但迭代速度快了 5 倍"，这就是一个非常扎实的落地经验。

6. 本地部署与关键工具链：从 GGUF 到评测平台的硬核实操

6.1 本地跑 LLM 的几种方案对比

热词里有"安卓本地运行 gguf 格式 llm 软件"，虽然移动端不是所有面试岗位的方向，但这个问题背后其实对应一个更大的话题：LLM 本地部署和轻量化推理。面试官问本地部署的场景是——你们的产品在私有化部署环境下怎么跑模型，不能什么都用云端 API。

候选方案要有层次。先说格式：GGUF 是 llama.cpp 生态的量化模型格式，它把模型量化成 4-bit、5-bit、8-bit 等精度，体积可以压缩到原始 BF16 的 1/5 甚至 1/10。举个例子，一个 7B 的 BF16 模型大概 14GB，转成 Q4_K_M 量化后可能只有 4.1GB 左右，在消费级显卡和手机上就能跑。但量化是有代价的，Q4 模型在复杂推理任务上的困惑度和 BF16 相比通常有 5%-10% 的差距，所以你不能无脑量化。

第二个层次是推理引擎选型。你要能分场景地说：llama.cpp 适合 CPU 和 Apple Silicon 用户；Ollama 更适合快速体验和原型验证，它直接封装好模型管理，一行命令就能拉模型、起服务；vLLM 适合高并发、长上下文的在线服务场景，它通过 PagedAttention 把显存利用率提升明显，批量推理时可以动态分配 KV cache，吞吐量比普通方案高出不少；如果是安卓端，可以用 llama.cpp 的 Android 版本或者 MediaPipe LLM Inference，对移动端进行了优化。GitHub 上一些 GGUF 的移动端项目其实原理都差不多——模型量化成 4-bit 放到手机内存，通过 Metal 或 OpenCL 做 GPU 加速。你想在手机跑 7B 模型，至少需要 6GB 内存，当前很多旗舰机能跑，但速度只能说是"能对话"，谈实时流式输出可能有点吃力。

第三个层次是评测环节。你部署完模型，不能只看它能不能聊天就收工，得有一套评测体系。常规的公共评测集有 MMLU、GSM8K、HumanEval、BBH——分别测知识、数学、代码、推理。但面试官真正关心的是你如何做业务场景的评测。我的推荐做法是：构造 100 条和你业务强相关的 QA 对做成 Golden Set，定义好打分规则（正确性、相关性、连贯性、安全性），然后跑测试，记录每个维度的分数和失败样例。这里有一个重要的坑：LLM 评测的方差很大，同一条 prompt 可能这次打 4 分、下次打 3 分，所以评测要在同一温度（比如 temperature=0.2）下跑，而且一条数据至少重复 3 次取平均分。做多了你还会发现，很多业务侧问题靠公共评测集根本测不出来，比如"模型在长上下文中间的指令遵循能力"，这个需要专门构造穿插无关文本的测试来验。

6.2 Deployment 的四个隐形杀手

面试里"你在部署 LLM 时遇到的最大挑战是什么"这个问题，其实是想听你说部署的隐性成本。四个隐形杀手是我的真实体验，分享给你。

第一个是显存和 KV Cache 之间的博弈。7B 模型 FP16 权重占 14GB，看起来一张 A100 40GB 完全放得下，但 KV cache 会随着并发和上下文长度疯涨。给你一个估算公式：KV cache 大小约等于 2 × num_layers × num_kv_heads × seq_len × head_dim × batch_size × 每个值字节数。一个 7B 模型如果有 32 层、8 个 KV head、head_dim 128，序列长度 4096、batch 16，那么 KV cache 大约 2×32×8×4096×128×16×2 ≈ 17.2GB，比模型本身还大。如果你没有做过 KV cache 估算，一上生产就爆显存。这个公式你一定要能在面试时现场算出来，面试官对这个印象极深。

第二个是首 token 延迟与 stream 模式。用户对"第一个字出来的时间"非常敏感。不同引擎的首 token 延迟差异巨大，优化有两条主线：一是减少 prompt 的 prefill 时间，比如把冗长的 system prompt 做 embedding 缓存复用；二是把解码阶段改成流式输出，用户看到第一个 token 的体验远好于等完整回答。实测下来，流式输出能把用户感知的响应时间从 8 秒压到 1 秒以内。

第三个是并发控制。LLM 服务不是并发数越高越好，因为每路请求都会抢显存。vLLM 支持 continuous batching，能把不同请求动态拼到一个 batch 里，显存利用率大幅提升；但 continuous batching 也有坑——某个长请求会拖慢同 batch 里的短请求，所以你要给不同请求设置超时时间或者拆分长任务。

第四个是输入长度控制。很多线上部署在长文本输入上会直接崩掉或回答质量严重下降。原因是 prompt 太长挤占了 KV cache 空间。通用的解法是加一套前置处理：截断、摘要、分段检索，比如超过 3000 token 的长文档就做 text splitter，按段落向量化后再做 top-k 检索，把最相关的内容塞给模型。你面试时能主动提到"输入长度控制不是简单截断，而是要做无损压缩"，这个观点很加分。

6.3 主流 LLM 框架选型清单

聊到部署必然聊框架，我给你一份结合实际项目经验的选型清单，面试时可以直接引用数据。

llama.cpp 是我个人最推荐的 CPU 推理方案。它用 GGML 库做量化后的矩阵运算，在 Apple M 系列芯片上可以做 Metal 加速。如果面试官问"怎么在 Mac 上跑 7B 模型"，我的答案就是装 Ollama，ollama run llama3.1:8b —— 一条命令搞定，底层调用的就是 llama.cpp。

vLLM 是生产环境的首选。它支持 PagedAttention、continuous batching、张量并行，多卡部署 7B/70B 模型都很成熟。Batch size 从 1 提到 16，吞吐量实测能翻好几倍，非常适合高并发的在线 LLM 服务。

TGI 是 Hugging Face 家的推理服务器，它对 HF 生态支持最好，量化兼容性也很全面。如果公司已经有 HF 的模型管理流程，TGI 上手最快。

FastAPI/FastChat 是轻量级方案，适合中小团队做原型。把模型包一层 OpenAI 兼容的 API，业务侧直接切换成标准调用接口，省去很多麻烦。

移动端方面，LLM 相关热词里专门提到"安卓本地运行 GGUF"，你如果面的是端侧开发岗，一定要提 llama.cpp 的 Android 适配和 MediaPipe LLM Inference。MediaPipe 支持在骁龙和苹果芯片上通过 GPU 加速跑量化后的小模型，适合做离线助手类功能。要是你说得出"GGUF 的 Q4_K_M 量化 + 手机端 4bit 加载 + Metal/OpenCL 推理"这套组合拳，面试官会非常认可你的边缘部署经验。

7. 面试必杀的答题节奏与复盘清单

7.1 面对不会的问题，用什么策略救场

面试过程中难免遇到不会的问题。我观察到的低分行为是：沉默、硬编、或者直接说"不了解"然后就不说话了。高分行为则完全不同。

首先你要把"不会做"和"不知道怎么开始"区分开。LLM 领域的问题很多是没有唯一答案的，面试官其实在看你的思考路径。比如他问"如何设计一个 RAG 系统来给客服做知识库"，你哪怕对 RAG 细节记忆模糊，也要立刻启动框架性思考：先澄清用户需求→梳理技术选型→拆模块→补细节。你可以说"我会先看输入数据是什么格式，如果是半结构化的 FAQ 就直接切 chunk，如果是非结构化的文档就先用摘要生成问题-答案对再入向量库"。框架感很重要，它能让你在知识不足时依然表现出逻辑。

其次，遇到完全不懂的概念，直接说"这个我没有在工程上实际用过，但我理解它属于 X 方向，我知道它和 Y 问题的关系……"，然后把你懂的部分说出来。面试官其实更反感不懂装懂，因为 LLM 方向变化太快，碰到新概念太正常了。我面试过一个小伙子，他说"这个问题我确实没接触过，但我猜它是为了解决长上下文推理成本的问题，如果让我来做，我会先从……"。这种坦诚 + 推导的组合，比硬憋一个答案强太多。

最后，所有回答尽量"闭环"。所谓的闭环是：给出一个方案之后，立刻补一句"这个方案我看过效果，大概提升 X%，但代价是 Y"。这样面试官会认为你不但知道怎么做，还知道方案的真实效果。

7.2 LLM 岗面试的 3 类软技能考察

这 8 个问题之外，面试官还会从细节里考察你的软技能。第一类是工程习惯。比如你被要求"现场设计一个评测集"，你会不会先确认模型应用场景？会不会写验收指标？会不会设计 AB 测试的样本量？好的候选人会主动把这些考虑进去，而不是一上来就写代码。

第二类是对自己项目的理解深度。很多人面试时把自己的项目讲得像流水账，这一块一定要避免。你可以为每一个项目准备一张"三层认知表"：第一层是我做了什么；第二层是我为什么这样做，不这样做会有什么问题；第三层是我做完了怎么验证它有效，失败了我怎么排查。如果一个项目能讲到第三层，面试官很难不给你加分。

第三类是协作沟通。LLM 项目通常是模型算法、后端、产品三方协同。面试官会通过你如何描述跨团队问题来考察你的沟通能力。比如 model 返回格式改了，会导致下游 API 出错，你会怎么协调？好的回答是"我会先写一个兼容双版本的解析逻辑，降低改动范围，再和算法同事约定好新格式的落地时间表"。这种回答体现的是工程协作思维，而不是单一技术思维。

7.3 面试前最好亲手跑一遍的项目清单

纸上得来终觉浅，面试前一定要亲手跑几个小项目。我的建议是至少做四件套：第一，用 Ollama 或 llama.cpp 在本地跑起一个 7B 模型，试着做一次 GGUF 量化，感受量化前后速度和质量的变化；第二，搭一个最小的 RAG Demo，用 LangChain 或 LlamaIndex，把一份 Markdown 文档切片成 300 字一段，embedding 之后用向量检索，观察 Top-5 召回的内容是否合理；第三，用 Unsloth 或 LLaMA-Factory 在消费级显卡上微调一个小模型，比如用 1000 条客服语料做一次 LoRA 微调，记录训练前后的回答变化；第四，写一个简单的 Agent 工具调用 Demo，让模型调用一个假的天气 API，故意制造 API 返回格式错误，观察容错机制怎么生效。

这四个项目做完，你基本能覆盖 8 个问题里 90% 的实战背景。面试官问任何问题，你都可以用"我实际测试的时候发现……"来支撑。这个细节是巨大加分项，因为我见过太多候选人面试讲概念头头是道，但一被要求举例子就卡壳，这就是缺少亲手实操的体现。

8. 关于 LLM 面试，我再多说几句实在话

8.1 面试的本质是寻找"有系统思维"的人

我除了自己面试也出过不少面试题。LLM 岗位的面试官并不指望候选人什么都懂，因为 LLM 技术栈太广——懂 Transformer 的未必懂部署，懂 RAG 的未必懂 RLHF。大家真正在意的，是你如何把零散的知识点组织成一个系统。

举个例子，一个候选人在聊 Agent 时如果只谈框架，我会觉得他停留在 demo 水平；但如果他能说出"Agent 的容错控制本质上是一个可靠性工程问题，需要从输出校验、状态回退、循环检测三个层次做防御"，我觉得这个人是有系统思维的。你看，同一个问题，看问题的角度完全不同，这就是差距。所以准备面试时，不要孤立地背知识点，而是试着把每个知识点放到"模型怎么训练、怎么部署、怎么维护"这条完整链路里思考，效果会好很多。

8.2 最后再分享一个小技巧：把"经验"变成你的差异化武器

现在市面上的面试攻略很多，面试官也审美疲劳了。同质化的答案是"我知道 RAG 是……"这类填空式回答，差异化的答案是"我在某个场景下踩过一个坑，这个坑是这样的……"。面试官也是人，人对故事的记忆远强于对知识点的记忆。

我建议你在准备 8 个面试题的时候，至少准备一个属于自己的"事故案例"。它可以是一次显存爆掉、一次 RAG 召回率忽高忽低、一次 Agent 死循环、一次 DPO 过拟合。剧情不重要，重要的是你说得出当时的现象、排查路径、最终解法。这种真实项目感，才是 8 个问题之外让你脱颖而出的关键。说到底，LLM 面试是筛选"真正动手做过事的人"，你有经验，你就已经赢了一半。

8.3 常见的三类送命回答，你在面试里避开

最后给大家总结一下三类送命回答，每条都是我的真实观察。

第一类是"教科书式回答"。比如问"Embedding 是什么"，张口就是"Embedding 是把离散符号映射成稠密向量"。这只是定义，不是工程。有经验的人会补充：Embedding 值得关注的是维度选择、训练方式、OOV 处理。你只会背定义，面试官无法判断你有没有做过真实任务。

第二类是"万能药式回答"。比如"这个问题可以用 RAG 解决""这个问题可以用 Prompt Engineering 解决"。要警惕在面 LLM 岗时把所有技术问题都归结到一个方案上。真正靠谱的回答是分场景、分条件，讲清楚"什么时候适合 RAG、什么时候不适合"。

第三类是"不懂装懂式回答"。比如面对一个不熟悉的名词或框架，硬编一个说法。LLM 面试官通常对这个领域极其熟悉，你一开口他就知道你在编。与其那样，不如坦诚 "这块我接触不多，但我理解它属于 X 领域，它和 Y 的关系是……"——至少看起来你是愿意学习和推导的。

这三类送命回答，很难靠突击背题解决，更多是靠平时动手积累。你要是项目做得够多，面试时自然就有底气，不会想着去背一两个"万能答案"应付。希望这篇 LLM 面试题深度拆解能帮到你，祝面试顺利。