1. 为什么这8个问题能决定面试生死
面过几十个LLM岗位候选人之后，我越来越确信一件事：面试官问的那些问题，表面上在考知识点，实际上在筛人。筛什么？筛你有没有真正动手跑过模型、调过参数、踩过坑。背八股文的人能说出"Transformer由Encoder和Decoder组成"，但一问"你实际部署时KV Cache怎么处理的"就露馅了。
这篇内容适合三类人看：正在准备LLM岗位面试的工程师、想转行进入大模型领域的开发者、以及需要面试别人的技术负责人。我会把LLM面试中最常被问到的8个核心问题逐一拆解，不光给答案，更要讲清楚面试官问这个问题时到底想听到什么，以及你应该怎么组织回答才能体现真正的实战经验。
先说说这8个问题的分布逻辑。它们基本覆盖了LLM从输入到输出的完整链路：Tokenization处理原始文本、Embedding把token变成向量、Transformer架构完成核心计算、注意力机制决定信息流动、Function Calling让模型与外部世界交互、微调和推理优化则考察工程落地能力。面试官通过这条链路，能快速判断你是"只看过论文"还是"真正跑过模型"。
面试官的心理：我问的每一个问题，都在判断你是在复述别人的结论，还是在分享自己的经验。
我见过太多候选人，简历上写着"熟悉Transformer"，结果连Multi-Head Attention里为什么要除以根号d_k都说不清楚。也见过工作三年的工程师，被问到"你们线上推理的batch size怎么定的"时支支吾吾。这些问题不难，但需要你真的想过、做过。
接下来的内容，我会按照面试中问题出现的自然顺序来组织，每个问题都给出：面试官的真实意图、回答的核心框架、容易踩的坑、以及加分项。你可以把它当作一份面试准备清单，也可以当作一次知识体系的自我检查。
2. Tokenization：被低估的第一道分水岭
2.1 面试官到底在问什么
"你能说说Tokenization是怎么回事吗？"这个问题看起来像是热身，实际上淘汰率不低。面试官想听到的不是"把文本切成token"这种废话，而是你对分词粒度、词表设计、多语言处理、以及分词对下游任务影响的理解。
我面过一个候选人，他说"Tokenization就是把句子切成词"。我追问："那中文怎么切？代码怎么切？"他愣了几秒说"用jieba吧"。这个回答直接暴露了他没有真正处理过LLM的输入数据。现代LLM用的都是子词分词（Subword Tokenization），主流方案有BPE、WordPiece、Unigram Language Model这几种，每种都有自己的适用场景和取舍。
2.2 BPE、WordPiece和SentencePiece的实际差异
BPE（Byte Pair Encoding）的核心思路是从字符级别开始，不断合并出现频率最高的相邻字符对，直到达到预设的词表大小。GPT系列用的就是这种方案。它的优势在于能平衡词表大小和序列长度，但缺点是分词结果依赖于训练语料的分布。
WordPiece是BERT用的方案，和BPE类似，但它合并的标准不是频率最高，而是能最大化训练语料的似然概率。实际效果上，WordPiece倾向于产生更"合理"的子词切分。
SentencePiece则是把空格也当作普通字符处理，不依赖预分词，对中文、日文这类没有天然空格分隔的语言特别友好。LLaMA系列、T5都用的这个方案。
| 方案 | 代表模型 | 核心思路 | 适用场景 |
|---|---|---|---|
| BPE | GPT系列 | 频率最高的字符对合并 | 英文为主，通用场景 |
| WordPiece | BERT | 最大化似然概率 | 理解类任务 |
| SentencePiece | LLaMA、T5 | 无预分词，空格视为字符 | 多语言、中日韩 |
面试时如果你能说出"我们当时对比过BPE和SentencePiece在中文语料上的压缩率，最终选了SentencePiece因为它的词表利用率更高"，这比背定义强一百倍。
2.3 词表大小怎么定：一个容易被追问的细节
面试官经常会追问："词表大小设多少合适？"这个问题没有标准答案，但你有思路就行。词表太小，序列会变得很长，推理成本飙升；词表太大，Embedding矩阵参数量暴涨，低频token训练不充分。
常见的词表大小在32K到128K之间。LLaMA 2用的是32K，GPT-4据传用了100K左右。实际选择时需要考虑：目标语言的字符集大小、训练语料的规模、以及推理时的显存预算。我自己的经验是，如果主要做中文任务，50K左右的词表是个比较稳妥的起点。
还有一个坑：特殊token的设计。[PAD]、[UNK]、[CLS]、[SEP]这些在BERT时代很重要，但在生成式LLM里，更重要的是<|im_start|>、<|im_end|>这类对话控制token。如果你在面试中提到"我们自定义了对话模板的special token来区分角色"，面试官会觉得你真的做过对话系统。
3. Embedding：从离散符号到连续空间的桥梁
3.1 不只是"把词变成向量"
Embedding这个词在面试中出现频率极高，但很多人对它的理解停留在"词向量"层面。面试官问Embedding的时候，可能是在问三个不同层面的东西：词嵌入层（模型内部的Embedding矩阵）、句向量模型（如BGE、M3E这类用于检索的模型）、以及位置编码（Position Embedding）。
你得先判断面试官问的是哪个。如果是架构层面的讨论，他大概率在问词嵌入层和位置编码；如果是在RAG（检索增强生成）的上下文里，他问的是句向量模型。
3.2 词嵌入层的参数量与初始化
词嵌入层本质上就是一个[vocab_size, hidden_dim]的矩阵。以LLaMA 2 7B为例，词表32K，隐藏维度4096，这个矩阵就有1.3亿参数，占了总参数的近2%。这也是为什么词表大小不能随便设太大的原因之一。
初始化方面，早期用Word2Vec预训练好的向量来初始化，现在主流做法是随机初始化然后端到端训练。但有一个细节：Embedding层和输出层是否共享权重。GPT-2就采用了权重共享（Weight Tying），这样可以减少参数量，同时让输入和输出的语义空间保持一致。面试时提到这一点，能体现你对模型结构的深入理解。
3.3 句向量模型选型：排行榜之外的考量
如果面试官问的是RAG场景下的Embedding模型选型，那你要准备好回答：为什么选这个模型、维度是多少、检索效果怎么评估的。
现在市面上主流的句向量模型有BGE系列、M3E、GTE、以及OpenAI的text-embedding-3系列。选型时不能只看排行榜，还要考虑：
- 维度：768维和1024维的模型，检索精度和存储成本差异明显。1024维的索引文件大小差不多是768维的1.3倍。
- 最大输入长度：很多模型只支持512个token，处理长文档时需要切块。BGE-M3支持8192，适合长文本场景。
- 语言支持：中文任务上，BGE和M3E的表现通常比多语言模型更好。
- 推理速度：如果用GPU做在线检索，模型大小直接影响QPS。
我自己的做法是：先用排行榜筛出3-5个候选，然后在自己的业务数据上跑一遍检索评测，看Recall@10和MRR指标。排行榜上的分数和你的实际场景可能差很远。
一个真实的坑：我们曾经用某个英文排行榜很高的模型做中文检索，结果发现它对中文成语和缩写的理解很差，后来换成BGE-large-zh才解决问题。
4. Transformer架构：面试官真正想听的细节
4.1 从"八股文"到"你实际调过什么"
"介绍一下Transformer架构"——这是LLM面试中出现频率最高的问题，没有之一。但面试官想听的绝对不是"Transformer由Encoder和Decoder组成，Encoder有N层，每层有Multi-Head Attention和前馈网络"这种维基百科式的回答。
他想听的是：你在实际使用中遇到过什么问题，怎么解决的。比如：
- 为什么现在的LLM大多只用Decoder？因为生成式任务不需要完整的Encoder，Decoder-only架构更简洁，训练效率更高。
- Pre-LN和Post-LN有什么区别？Pre-LN把LayerNorm放在注意力之前，训练更稳定，不需要warmup也能收敛，这是现在的主流做法。
- 位置编码从正弦函数到RoPE再到ALiBi，各自解决了什么问题？
如果你能说出"我们在训练7B模型时发现Post-LN在深层网络里梯度消失严重，换成Pre-LN之后训练稳定了很多"，这比背十遍架构图都管用。
4.2 注意力机制的参数量计算
面试官经常会让候选人现场算一下注意力的参数量。以标准Multi-Head Attention为例，假设隐藏维度d_model=4096，头数h=32，那么每个头的维度d_k=128。Q、K、V、O四个投影矩阵的参数量是：
- Q投影：4096 × 4096 = 16.7M
- K投影：4096 × 4096 = 16.7M
- V投影：4096 × 4096 = 16.7M
- O投影：4096 × 4096 = 16.7M
总共约67M参数。前馈网络（FFN）通常是两层，中间维度是4倍d_model，参数量是2 × 4096 × 16384 = 134M。所以每个Transformer层的参数量大约是200M，32层就是6.4B，加上Embedding和其他部分，差不多就是7B模型。
这个计算过程面试时能流畅说出来，面试官会知道你不仅懂原理，还有工程直觉。
4.3 KV Cache：推理优化的必考题
"你们线上推理怎么优化的？"这个问题几乎必问。KV Cache是标准答案，但你要能说清楚它的原理和代价。
自回归生成时，每生成一个token都需要重新计算所有历史token的Key和Value。KV Cache的思路是把之前算过的K和V缓存下来，新token只需要计算自己的Q，然后和缓存的K、V做注意力。这样把每步的计算复杂度从O(n²)降到了O(n)。
但KV Cache的代价是显存。以LLaMA 2 7B为例，32层，32个头，每个头128维，序列长度2048，batch size为1时，KV Cache的大小是：2 × 32 × 32 × 128 × 2048 × 2字节（FP16）≈ 1GB。如果batch size是16，序列长度4096，那就是32GB，直接爆显存。
所以实际部署时会用MQA（Multi-Query Attention）或GQA（Grouped-Query Attention）来减少KV Cache。MQA让所有头共享一组K、V，GQA则是分组共享。LLaMA 2 70B用的就是GQA，把KV Cache减少了8倍。
面试时如果你能说出"我们用了GQA，把KV Cache从XXGB降到了XXGB，支持的并发数提升了X倍"，这就是实打实的工程经验。
5. Function Calling与Agent：从"会聊天"到"能干活"
5.1 Function Calling的本质是什么
Function Calling这个词听起来很高级，本质上就是让LLM输出结构化的JSON，告诉程序该调用哪个函数、传什么参数。面试官问这个问题，是想看你有没有做过LLM与外部系统集成的项目。
实现方式有两种：Prompt驱动和模型原生支持。Prompt驱动就是在系统提示里写清楚可用函数的描述，让模型自己生成调用格式；原生支持则是模型在训练时就学会了输出特定的函数调用格式，比如OpenAI的tools参数、Anthropic的tool_use。
面试时你要能说清楚：函数描述怎么写模型才容易理解、参数校验怎么做、调用失败怎么重试、多轮调用怎么管理上下文。这些都是实际落地时绕不开的问题。
5.2 Agent的容错设计：面试官最看重的工程能力
现在稍微高级一点的LLM岗位都会问Agent相关的问题。Agent的核心是自主决策：给定一个目标，模型自己规划步骤、调用工具、观察结果、调整策略。但面试官真正关心的是：你怎么保证Agent不出错。
我面过一个候选人，他说"我们用ReAct框架做了个Agent，能自动查天气、订机票"。我问他："如果模型调用了一个不存在的函数怎么办？如果函数返回了错误信息，模型会怎么处理？如果模型陷入循环调用同一个函数呢？"他答不上来。
这些才是Agent落地的核心难点。实际工程中需要做：
- 函数白名单：只允许调用注册过的函数，防止模型幻觉出不存在的工具。
- 参数校验：对模型生成的参数做类型检查和范围校验，不合法就返回错误让模型重试。
- 最大调用轮数：设置硬性上限，防止无限循环。
- 超时和降级：单个工具调用超时后要有降级策略，不能卡死整个流程。
- 结果截断：工具返回的内容可能很长，需要截断后再喂给模型，防止上下文溢出。
一个实用的经验：在系统提示里明确告诉模型"如果连续两次调用同一个函数且参数相同，请停止并输出当前结论"，能有效减少循环调用。
5.3 多Agent协作的坑
如果面试官问到多Agent系统，你要小心了。这是当前比较前沿的方向，但坑也很多。多个Agent之间怎么通信、怎么避免信息丢失、怎么处理冲突、怎么控制成本，每一个都是难题。
我的建议是：如果你没有实际做过多Agent项目，就诚实地说"我主要做单Agent的工具调用，多Agent还在调研阶段"。面试官更看重你的诚实和学习能力，而不是硬编一个不存在的项目经验。
6. 微调与对齐：从"能用"到"好用"的关键一步
6.1 全量微调、LoRA、QLoRA怎么选
"你们模型微调用什么方法？"这个问题几乎每个LLM岗位都会问。答案取决于你的资源预算和任务需求。
全量微调效果最好，但需要大量显存。7B模型全量微调至少需要4张A100 80G，普通团队根本玩不起。LoRA（Low-Rank Adaptation）冻结原模型参数，只训练低秩矩阵，显存需求降到1/3左右，效果能到全量微调的90%以上。QLoRA在LoRA基础上把原模型量化到4-bit，单张24G显存就能微调7B模型，适合个人开发者和小团队。
| 方法 | 显存需求（7B） | 效果 | 适用场景 |
|---|---|---|---|
| 全量微调 | 4×A100 80G | 最好 | 大厂、核心业务 |
| LoRA | 1×A100 40G | 接近全量 | 中小团队、快速迭代 |
| QLoRA | 1×RTX 4090 24G | 略低于LoRA | 个人开发者、实验 |
面试时如果你能说出"我们用QLoRA在单卡上微调了7B模型，rank设的64，alpha设的128，在业务数据上跑了3个epoch，效果比prompt engineering提升了15个百分点"，这就是非常扎实的回答。
6.2 数据质量比数据数量重要十倍
微调的效果，七分靠数据，三分靠方法。我见过太多团队花大力气调参，结果数据里全是噪声，怎么调都没用。
数据准备的核心原则：
- 多样性：覆盖各种输入模式，避免模型过拟合到某一种问法。
- 准确性：标注必须准确，错误的标注比没有标注更糟糕。
- 格式一致：训练数据的格式必须和推理时的prompt格式完全一致，否则模型会"迷惑"。
- 数量适中：对于特定任务，1000-5000条高质量数据通常就够了，太多反而容易过拟合。
一个实操技巧：用强模型生成训练数据，再用人工筛选。比如用GPT-4生成候选回答，人工审核后作为训练数据。这样效率比纯人工标注高很多，质量也比纯模型生成好。
6.3 对齐：RLHF和DPO的取舍
如果面试官问到对齐（Alignment），说明这个岗位比较高级。RLHF（基于人类反馈的强化学习）是ChatGPT成功的关键，但流程复杂：先训练奖励模型，再用PPO算法优化策略。DPO（Direct Preference Optimization）则跳过了奖励模型，直接用偏好数据优化，实现更简单，效果在很多场景下不输RLHF。
面试时你可以说："我们对比过RLHF和DPO，RLHF效果略好但训练不稳定，DPO实现简单、训练稳定，最终选了DPO。"这种有对比、有取舍的回答，比单纯说"我们用了RLHF"要加分很多。
7. 推理优化与部署：面试官最看重的落地能力
7.1 量化：精度与速度的平衡
"模型太大跑不动怎么办？"量化是标准答案。从FP16到INT8再到INT4，模型大小减半再减半，推理速度提升，但精度会下降。
实际选择时：
- FP16：精度最好，显存需求最高，适合A100/H100。
- INT8：精度损失很小（通常<1%），显存减半，适合大多数场景。
- INT4：精度损失明显（2-5%），但显存只有FP16的1/4，适合消费级显卡。
量化方法上，GPTQ和AWQ是当前最主流的两种。GPTQ训练后量化，速度快；AWQ对激活值敏感的权重做保护，精度更好。我自己的测试中，AWQ在7B模型上的困惑度比GPTQ低0.2左右，但推理速度慢10%。
7.2 推理框架选型：vLLM、TGI、TensorRT-LLM
面试官问"你们用什么推理框架"时，你要能说出选型理由。
vLLM的核心优势是PagedAttention，把KV Cache分页管理，显存利用率高，吞吐量大。TGI（Text Generation Inference）是HuggingFace的方案，集成度高，支持连续批处理。TensorRT-LLM是NVIDIA的方案，性能最强，但编译复杂，灵活性差。
| 框架 | 核心优势 | 适用场景 | 上手难度 |
|---|---|---|---|
| vLLM | PagedAttention，高吞吐 | 高并发在线服务 | 中 |
| TGI | 集成度高，易用 | 快速原型、中小规模 | 低 |
| TensorRT-LLM | 极致性能 | 大规模生产环境 | 高 |
我自己的经验是：如果团队没有专门的推理优化工程师，vLLM是最稳妥的选择，社区活跃，文档齐全，遇到问题容易找到解决方案。
7.3 批处理与并发：吞吐量和延迟的博弈
线上服务最核心的指标是吞吐量（每秒处理多少请求）和延迟（单个请求多久返回）。这两个指标往往是矛盾的：增大batch size能提升吞吐量，但会增加单个请求的延迟。
实际调优时，需要根据业务场景找平衡点。如果是对话场景，用户对延迟敏感，batch size要小；如果是离线批量处理，吞吐量优先，batch size可以大。
连续批处理（Continuous Batching）是当前的主流方案：不等一个batch的所有请求都完成，而是动态地把新请求加入正在处理的batch。vLLM和TGI都支持这个特性，能把吞吐量提升2-5倍。
一个容易忽略的细节：Prefill和Decode阶段的资源需求完全不同。Prefill是计算密集型，Decode是显存带宽密集型。把这两个阶段分开调度，能显著提升整体效率。vLLM的chunked prefill就是做这个的。
8. 面试中那些"答不上来直接淘汰"的送命题
8.1 场景设计题：没有标准答案，但有标准思路
面试官经常会抛出一个开放场景："如果让你从零搭建一个企业知识库问答系统，你会怎么做？"这种问题没有标准答案，但面试官在看你的思考框架。
一个合格的回答应该覆盖：
- 需求分析：知识库规模多大、更新频率如何、用户量多少、延迟要求是什么。
- 技术选型：Embedding模型选什么、向量数据库用哪个、LLM用API还是自部署。
- 架构设计：文档切块策略、检索策略（稠密+稀疏混合）、重排序、生成控制。
- 评估方案：怎么衡量检索质量、怎么衡量生成质量、怎么做A/B测试。
- 迭代计划：先跑通MVP，再逐步优化。
如果你能说出"我们先用BGE-M3做Embedding，Milvus做向量库，检索Top-20后用bge-reranker重排取Top-5，再喂给LLM生成答案"，这就是一个非常具体的方案，面试官会觉得你真的做过。
8.2 故障排查题：考察你的实战经验
"线上模型突然开始输出乱码，你怎么排查？"这种问题考察的是你的排查思路。
一个系统的排查链路：
- 先看输入：是不是输入格式变了？有没有特殊字符？
- 再看模型：是不是加载错了模型？量化版本对不对？
- 然后看推理参数：temperature、top_p是不是被改了？
- 最后看环境：GPU显存够不够？有没有OOM导致的静默错误？
面试时你要展示的是分层排查的思路，而不是直接猜一个原因。
8.3 成本控制题：LLM工程师的必修课
"你们怎么控制推理成本？"这个问题越来越常被问到，因为LLM的推理成本是实打实的钱。
控制成本的手段包括：
- 模型选型：不是所有任务都需要最大的模型，7B能做的不用70B。
- 量化：INT8量化能省一半显存，成本直接减半。
- 缓存：相似问题缓存答案，减少重复推理。
- 路由：简单问题用小模型，复杂问题用大模型。
- 批处理：提高GPU利用率，摊薄单次推理成本。
我自己的经验是，通过模型路由和缓存，能把推理成本降低60%以上。面试时说出这个数字，比说"我们做了优化"有说服力得多。
9. 我面了几十个人之后的一些真实体会
准备LLM面试，背八股文只能帮你过第一轮。真正决定成败的，是你有没有自己的项目故事。面试官每天听几十个"熟悉Transformer"的回答，早就麻木了。但如果你能说出"我在微调LLaMA 2的时候发现loss突然飙升，排查后发现是数据里混入了大量重复样本，去重之后训练就稳定了"，他会立刻记住你。
我的建议是：面试前把你做过的项目从头到尾捋一遍，每个技术选型都问自己"为什么选这个不选那个"，每个参数都问自己"为什么设这个值"。这些"为什么"的答案，才是面试中最有价值的东西。
还有一点：诚实比装懂重要。遇到不会的问题，说"这个我没有实际做过，但我的理解是……"比硬编一个答案要好。面试官都是过来人，你编没编他一眼就能看出来。
最后分享一个我自己的习惯：每次面试结束后，把没答好的问题记下来，回去查清楚。面完十家公司，你的知识体系就补得差不多了。面试本身就是最好的学习过程。
