这两年我前前后后参加过几十场 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 架构与 Tokenizer2.1 为什么第一题必问 TransformerTransformer 是 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 对模型能力的限制。分词原理要能说清楚 BPEByte Pair Encoding的核心逻辑——从字符级开始反复统计最高频的相邻字符对并合并直到达到目标词表大小。注意 BPE 不是简单切词它是在字节和字符之间找到一个平衡让常见词变成单一 Token生僻词可以用子词组合出来。比如 unhappiness 可能被拆成 un、happi、ness这样既能压缩序列长度又能处理没见过的新词。词表大小的影响是个高频追问点。词表太大Embedding 层参数爆炸训练和存储成本都上去词表太小每个词要拆成很多子词序列变长计算量增大表达能力也下降。常见的 32K、50K、100K 词表都有自己的适用场景没有绝对最优。这里我建议你用具体数据说明比如 50K 词表Embedding 维度 4096那么仅 Embedding 层参数就有 50K × 4096 ≈ 2亿参数相对一个 7B 模型占比不算大但如果词表扩到 200KEmbedding 参数就接近 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 是 lossN 是参数量D 是数据量α、β 是缩放指数。实际工程里我们要关注的是损失函数的下降逐渐变慢的拐点。比如训练一个模型时在 100B token 时 loss 下降很快到 500B token 时每增加 100B token 只下降 0.01这时候再堆数据性价比就很低了应该转去调优化器、调学习率或者提升数据质量。另外一个高频变形是 Chinchilla 法则。这篇论文核心结论是在计算量预算固定时最优参数量和 token 数应该等比放大。具体来说参数量和训练 token 数大约都是原始模型的 1.6 倍左右模型规模和数据量要一起涨不能只加参数不加数据。面试官经常会追问既然这样为什么很多大模型还是参数很大、数据相对偏少正确的回答是因为推理成本也是约束一个模型参数量翻倍推理延迟和显存占用都会涨所以在算力受限时很多团队宁可在数据上多砸几个 epoch也不把模型搞得太大。这个回答体现出的工程权衡思维比单纯背结论高级得多。3.2 数据标注面试官想听的脏活经验LLM 的数据标注是个又脏又累但面试必问的环节。热词里有llm怎么数据标注说明很多人就有这个困惑。面试官不会问抽象的数据标注理论他只会问你实际做过的数据处理流程。你要能说清楚一条完整的标注链路原始数据收集 → 清洗去重 → 质量分级 → 格式转换 → 多轮校验。这里面的坑非常多。举个例子只是去重这一步就大有文章——用 MinHash 做内容去重你在实际中会遇到一个棘手问题很多文本只是长得像但内容完全不一样比如产品描述里带价格变动和日期信息简单哈希去重会把它们误判为重复。正确的做法是先做模板归一化把数字、日期、人名替换成特殊占位符再做去重召回率会好很多。还有一个高频问题是 如何设计偏好数据。现在主流训练流程里SFT 之后要用 RLHF/DPO 做对齐偏好数据就是用来打分排序的。面试官会问偏好标注有哪些陷阱你要能答出这几点第一不同标注员对好回答的标准差异极大所以必须写详细的标注规范最好带正反例第二标注员容易受长度和语气影响——更长的回答、更正式的语气不一定更好要设计对比式评估而不是绝对式评估第三要做交叉标注和一致性检测比如同一对回答让三个标注员打分用 Cohens Kappa 算一致性系数低于 0.6 就要讨论、培训、重标。第三个必问的数据题是数据配比。训练集里不同来源的数据比例怎么定我的经验是代码类数据可以占到 20%-30%数学类 10%-15%百科、书籍这些长文本大概 40%对话数据 15%-20%。代码数据比例高模型推理能力会明显提升但代码数据太多会让模型在自然语言任务上变得有点生硬所以要用下游任务指标来反推配比。你需要举一个具体例子我在一次 SFT 中用 20% 代码 80% 文本模型在 HumanEval 上提升了 8 个点但日常写作的连贯性略有下降后来把代码比例降到 15%两个指标都恢复到了一个不错的平衡点。这种回答才是真正的干货面试官一听就知道你动手调过数据。4. 工程落地题RAG、Agent 与幻觉评估4.1 RAG 面试的核心不是是什么而是什么时候用RAGRetrieval-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 ModelRM最后用 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 losscritic 网络估计价值、KL penalty 和 entropy bonus。一场面试里能把这些讲完整的候选人我遇到的真的是屈指可数。第三个层次DPO 为什么能火起来它的核心贡献是绕开了显式的 RM RL 训练直接把偏好数据转化为策略优化的损失函数。用 DPO 训练不用起多套模型也不用写 PPO 的分布式采样逻辑代码量少很多训练更稳定。但 DPO 有它的局限——如果你的偏好数据存在标签错误DPO 的损失会对噪声特别敏感直接导致生成质量下降所以数据清洗和偏好校验在 DPO 里格外重要。你回答时把PPO 适合在线探索和复杂奖励DPO 适合离线偏好数据这个边界说清楚面试官会立刻高看你一眼。5.2 数据安全与生成安全的实操细节安全对齐还有一个很多候选人忽略的角度数据安全。面试官会问你如何处理训练数据的隐私和安全问题。这里要能答出几个层次第一数据脱敏——训练数据里可能包含用户手机号、身份证号要做 PIIPersonally 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 分所以评测要在同一温度比如 temperature0.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 模型我的答案就是装 Ollamaollama 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 面试题深度拆解能帮到你祝面试顺利。