最近面了不少做大模型方向的候选人，自己也被人面过好几轮。一个很明显的感受是：简历上写着“精通大模型”“熟悉Transformer原理”的人不少，但真到技术面，很多人会在几个最基础的问题上突然卡壳。我复盘了一下，真正有区分度的其实是8个问题，从模型原理、训练策略一路问到工程部署，覆盖了LLM从业者日常必碰的几块硬骨头。这8个问题不偏不怪，每道都指向一个核心事实：你到底是背过概念，还是真的把模型跑起来、调过、部署过。所以说“答不上来直接淘汰”，并不是吓唬人。
如果你正在准备大模型方向的面试，或者你需要给团队设计一套能筛人的考察题，这份整理可以直接拿去用。每个问题我都会拆清楚三件事：考察意图是什么、标准回答的核心逻辑是什么、以及最常见的答法坑在哪里。
1. 原理题：自注意力凭什么踢掉RNN，70B参数配多少数据才不会“喂不饱”
面试官只要想确认你是不是“懂底层”，基本都会从这题开始。
1.1 Q1：Transformer为什么用自注意力，不用RNN或LSTM
问这个问题不是要你背“效果更好”这种废话，而是考察你对模型结构的理解深度。自注意力能取代RNN，本质上来自三个维度：
第一是并行度。RNN不管怎么优化，计算都是逐时间步展开的，第t个token必须等前面所有token算完才能算。序列一长，训练起来就是灾难。而Transformer的自注意力是把整个序列一次性丢进矩阵运算，GPU可以把所有位置同时并行处理。同样一个batch，RNN等不起，Transformer等得起，这是工程上最直接的代差。
第二是信息路径长度。RNN要把最早位置的信息传递到最后，理论上要走很多个时间步，每一步过一遍非线性激活，梯度基本就衰减到可以忽略不计了。LSTM虽然用门控缓解了一下，但本质上还是靠“接力棒”一步步传。而自注意力里任意两个token之间的交互只需要一步，直接做点乘，信息路径是O(1)的长度。这个差异对长距离依赖非常关键，比如指代消解、篇章连贯性这类任务，模型需要把一个段落开头的信息保留到结尾，路径越短越不容易丢。
第三是表达能力的上界。RNN的结构限制导致它在建模“任意两个位置之间的关系”时需要靠隐状态去逐步编码，信息有损。而注意力机制直接对“所有位置两两打分”，模型可以选择性地关注任意位置，这种显式的相关性建模天然更适合自然语言这种高度依赖语境的任务。
不过自注意力不是没有代价，它的复杂度是O(n²)，序列一长，内存和时间都会爆炸。所以这个问题的加分项是：你能主动提一句FlashAttention是怎么通过分块计算、重计算来削减显存占用的，或者提到稀疏注意力、局部窗口注意力这类后续优化。只要你说了这个，面试官基本就能判断你是懂工程而不是只会背八股。
常见的死法是只答“因为效果好”“因为能并行”，然后什么深层原因都讲不出来。这种回答在初级岗位可能勉强过关，面中高级岗基本一票否决。
1.2 Q2：参数量70B的模型，到底需要多少训练数据
这题很多人一上来就瞎猜，有人说“几百G”，有人说“能塞多少塞多少”，都不对。它考察的是你对训练规律和数据规模匹配有没有概念，核心要看Chinchilla法则。
DeepMind在2022年发过一篇论文，专门研究“给定算力预算，模型参数和训练token数应该怎么配”。结论近似可以总结成一句话：训练token数大约等于参数量的20倍是最划算的均衡点。这个结论不是说“低于这个数就不能训练”，而是说在这个比例下，同样的算力能换来最好的模型效果。
按这个逻辑来估算：70B参数约等于700亿参数，乘20就是1.4万亿token，也就是1.4T。换算一下，大概是1.4万亿个词元。所以当你听到“这个模型用1.5T token训练”时，说明它基本踩在Chinchilla法则附近，属于标准配置。
| 参数量 | 按Chinchilla估的token数 | 常见工业配置参考 |
|---|---|---|
| 7B | 140B token | 1T左右也常见，超训一点效果更好 |
| 13B | 260B token | 300B-500B |
| 70B | 1.4T token | 1.5T-2T |
这里有一个细节值得展开：实际工业界很少严格按20倍来，因为高质量数据本身稀缺，很多团队会“超支”训练，比如GPT-3当年175B的参数只用了300B token，不到两倍，明显处于欠拟合状态。后来的模型普遍把数据量拉上去了，就是为了把参数喂饱。反过来，数据也不是越多越好，重复数据滚太多次会让模型过拟合，训练损失降不下去，评测指标反而变差。
加分项是你能说出“数据和参数的匹配本质是在算力预算下找收益最大化”，甚至能谈到小模型直接拿大模型生成的数据做蒸馏、清洗过滤、去重去污这些实操。死法是把训练数据和训练轮次混为一谈，或者把token数和文本字节数搞混，这种基础错误一旦出现，后面问什么都不太好救了。
2. 行为题：幻觉不是bug是特性，长上下文越用越笨的根因在哪
第一类题确认你懂原理，第二类题直接转向“你了解模型的劣根性吗”。很多人栽在这，因为训练时学到的模型是理想化的，真实用起来全是坑。
2.1 Q3：大模型为什么一本正经地胡说八道，工程上怎么压幻觉
幻觉这题几乎每个面试官都会问，因为它直接关系到模型能不能落地。你要先理解一个反直觉的事实：幻觉不是模型学歪了，而是当前技术路线的必然副产品。
大模型的训练目标是什么？是预测下一个token。这个目标本质上是在学“这段文本后面最可能接什么”，它不区分这句话是事实还是编造。模型把训练语料里的知识以参数形式“软存储”下来，不同来源的信息互相矛盾时，参数里的记忆就会打架，生成时随便挑一个看起来合理的答案，就成了幻觉。再加上推理时我们还会用temperature、top-p这类采样策略引入随机性，幻觉概率进一步上升。低温能降低随机性，但没法消除参数里的“事实冲突”。
工程上压幻觉的手段是分层的，我给一个完整的答题框架：
数据层。训练数据里重复出现矛盾事实，模型必然学歪。所以清洗、去重、事实性过滤是第一步。很多团队会单独做事实性标注，让模型在训练时看到“哪个回答是有证据支持的”。
对齐层。用RLHF或DPO让模型学会“不知道就承认不知道”，而不是硬编。偏好对里明确把“拒绝回答”当成比“瞎编一个”更好的行为，模型经过对齐后，幻觉率会明显下降。
推理层。这是工程上最常用的一层。最常见的手段是RAG，先检索再生成，答案必须有出处；其次是低温解码，把temperature压到接近0；还有约束解码，强制模型只能从给定候选里选词；再就是自一致性，让模型对同一个问题采样多次，对答案做投票，少数服从多数。
评测层。压幻觉不能只靠感觉，得有检测机制。常用的做法是用NLI模型来判断“生成内容是否被检索到的证据文本蕴含”，或者用FactScore这类工具对回答里的每个事实点单独打分。
这题的加分点是你能结合具体场景说清楚“哪些幻觉能压，哪些压不掉”。比如常识性反问、多步推理里的错误传递，这类问题靠RAG解决不了，得靠思维链和步骤约束。死法是张口就“加RAG”，结果连RAG自己也会召回错误文档，生成了带引用链接的错误答案，这在生产环境里比没引用更危险。
2.2 Q4：模型宣称支持128K上下文，为什么一长就开始变笨
这题非常有意思，因为简历上人人写“熟悉长文本”，一追问就露馅。你要知道一个残酷的现实：宣称的上下文窗口和有效上下文窗口，通常不是一个东西。
先说根因。第一，训练阶段长文本数据占比非常低。互联网语料大多是几百到几千token的短文，几十万token的长文档很少，模型在训练时根本没有见过足够多的“长序列模式”，所以到了超长输入时，它的注意力机制虽然能算，但学过的统计规律不够用。
第二是位置编码的外推问题。现在主流模型基本都用RoPE（旋转位置编码），它理论上能处理任意长度，但实际外推到训练长度之外时，注意力分数的分布会变得不稳定，甚至出现振荡。要让模型真正支持长文本，要么用NTK、YaRN这类插值方法改位置编码，要么做长文本继续预训练，不是改个参数就行。
第三是“lost in the middle”现象。测试发现，把关键信息放在长文本中间时，模型的回答准确率会显著下降，比放在开头和结尾差一大截。原因很简单：注意力机制对超长序列的分布不够集中，中间信息被开头和结尾的token“挤掉”了。
我在实际测试里用过一些宣称128K的模型，8K以内表现稳定，16K开始偶尔漏细节，到32K以上错误率就很明显了。这不是个别模型的问题，是长上下文技术的普遍现状。所以遇到这类需求，工程上我一般不走“让模型硬读全文”路线，而是先做检索截断，只把相关片段喂给模型，或者把长文档分段总结之后再拼接。面试时你能说出这套“先用召回压缩，再进上下文”的思路，比背一堆窗口参数值有用得多。
| 输入长度 | 常见表现 | 主要原因 |
|---|---|---|
| 4K-8K | 稳定 | 训练数据覆盖充分 |
| 16K-32K | 开始漏中间信息 | 注意力分布退化、长文本数据稀缺 |
| 64K以上 | 错误率明显上升 | 位置编码外推不稳定 |
3. 工程题：RAG、微调、RLHF、DPO，这四件套的边界到底在哪
这一组问题是落地环节的核心。说实话，很多候选人对单点技术很熟，但说不清“什么时候该用哪个”，而这才是企业真正关心的事。
3.1 Q5：企业知识库问答，先做RAG还是先微调，还是干脆不微调
这题几乎是我面试必问的实战题。先说结论：常规知识库问答场景，RAG是主干，微调是配角，大多数项目应该先RAG后微调，甚至只RAG不微调。
背后的逻辑很简单。
RAG负责解决“模型知道多少”和“答案从哪来”的问题。企业知识库最大的特点是知识天天在变——产品文档更新、政策调整、FAQ迭代。RAG只需要把最新文档加入索引，不用动模型权重，改造成本极低。而且RAG可以带着引用回答，用户看到出处，信任度完全不一样。
微调负责解决的是“模型的回答风格、行为模式和特殊能力”问题，它不是用来背知识的。比如你希望客服模型说话更简洁、不要大量免责声明、或者必须按特定JSON格式输出，这些用RAG做不了，只能用微调把模型的行为“掰”过来。
| 维度 | RAG | 微调 |
|---|---|---|
| 知识更新成本 | 低，换索引即可 | 高，要重新训练 |
| 答案可溯源 | 可以带引用 | 无法天然溯源 |
| 回答风格控制 | 弱，靠prompt | 强，直接改行为 |
| 领域术语理解 | 一般，取决于prompt | 好，能学会专有用法 |
| 幻觉控制 | 明显改善 | 有限改善 |
| 适合场景 | 知识库问答、时效性内容 | 风格约束、工具调用、格式输出 |
我接过一个企业知识库问答项目，最初方案就是纯RAG，结果业务方天天抱怨“答非所问”。查下来问题根本不在模型，而在检索链路：文本切块太碎，语义被切断；Embedding又只做向量检索，同义词和专有名词匹配不上，召回率只有六成左右。后来把Chunk大小从512调整到256，拆成语义完整的段落，加了BM25和向量检索的混合召回，再补一个Rerank重排模型，答案准确率才算真正到了能上线的水平。这个经历也说明，RAG这个方案看着简单，真正做好需要对“切分、召回、重排、上下文组装”每一节都有感觉。
所以面试时，不要只说“用RAG”，你得说出切块怎么切、召回率怎么测、重排为什么重要。微调同理，你要能给出微调的具体目的，而不是“因为大家都微调”。
3.2 Q6：RLHF和DPO到底什么关系，什么时候不能不用RLHF
这题考察的是对齐技术是不是真做过，还是只看过几篇公众号文章。你得分清楚两者的原理差异和适用边界。
RLHF是三段式：先做SFT，再训练一个奖励模型，然后用PPO让模型学会“根据奖励模型打分来优化自己”。它的特点是复杂、不稳定、资源消耗巨大，但上限高。因为奖励模型是单独学的，它可以在任何样本上打分，模型有机会学到训练集之外的行为模式。
DPO跳过奖励模型，直接拿“偏好对”（同一问题的人类偏好答案和普通答案）优化模型。核心思想是：奖励模型的信息已经隐式包含在偏好数据里了，不需要单独训练一个打分器，直接用带隐式奖励的损失函数训练就行。它的优点是简单、稳定、训练资源要求低。
那什么时候用哪个？
我的判断逻辑是：如果对齐目标很复杂，要同时兼顾帮助性、安全性和事实性，而且你有足够多的偏好数据，那RLHF还是更稳，因为它可以对同一个输出做连续打分，微妙的行为差异也能体现。如果目标相对简单，比如“拒绝回答敏感问题”或者“尽量不用太长回复”，直接用DPO就够，成本低，迭代快。
还有一个场景必须提一下：如果你的偏好数据是“在线反馈”性质的，比如用户对回复点踩/点赞，你希望模型持续从新反馈里学习，那RLHF因为有明确的奖励信号，配合在线采样会更好调。DPO如果偏好对本身质量不稳定，模型很容易学偏，而偏好数据恰恰是最难清洗的。
加分项是你知道RLHF里PPO为什么要加KL散度惩罚——防止模型走捷径去“刷分”，把奖励模型钻穿。以及你可以提到DPO在数据偏移时的脆弱性，或者KTO、IPO这些变体。
死法也很典型：一说RLHF就只提“人类反馈”，完全没做过奖励模型训练；或者把DPO说成“RLHF的简化版”就结束了，不给适用边界。
4. 部署题：70B推理显存怎么手算，以及一道综合设计题怎么答
最后这两道题是拉开差距的关键。前六题答好只能证明你有理论功底，后两题答好才能证明你能把东西跑起来。
4.1 Q7：70B模型FP16推理到底需要多少显存，KV cache怎么算
这题很有意思，因为我见过有人说“买几块4090就行”，也见过有人说“至少几十张卡”，都是拍脑袋。真要算，一页纸就能搞定。
模型权重的显存非常直接：参数量乘以每个参数占的字节数。FP16是2个字节，70B参数就是70 × 10⁹ × 2字节 ≈ 140GB。这还只是把权重放进去，还没算优化器状态、激活值和KV cache。所以FP16精度推理，70B模型的权重就要140GB显存，一块80G的A100装不下，至少要两块才能勉强放权重。实际部署考虑并行和KV cache，8卡A100-80G是常规起步配置。
真正容易被忽略的是KV cache。它是一张大账单：KV cache大小 = 2 × 层数 × 每层KV维度 × token数 × 2字节。按70B模型常见的80层、64个注意力头、每个头128维来计算，每生成一个token，KV cache大约要2.6MB。听起来没多少，但你算一下：生成1000个token就要2.6GB，生成10万token就要260GB，比一个FP16权重的70B模型还要大。
| 精度 | 70B权重显存 | 单卡A100-80G是否够 |
|---|---|---|
| FP16 | 约140GB | 不够，需多卡 |
| INT8 | 约70GB | 勉强装下权重，KV cache空间紧张 |
| INT4 | 约35GB | 够，本地单卡有戏 |
所以为什么大家都在推量化？因为70B模型量化到INT8，权重降到约70GB，INT4能压到35GB左右，一张带大显存的卡就能跑权重，KV cache和其他开销也腾出了空间。这也是现在地方化部署里GGUF格式流行的原因，模型压一压，笔记本都能慢跑起来。
加分项是你能主动提vLLM的PagedAttention——它把KV cache分页管理，模仿操作系统的虚拟内存，显存利用率大幅提升，而且支持连续批处理，线上推理吞吐能翻好几倍。再往上说，还能提一下GQA（分组查询注意力），很多70B模型用GQA之后KV cache占用能降到原来的1/8，这才是长上下文能跑起来的关键设计之一。能说到这层，面试官基本不会再刁难你。
4.2 Q8：一道综合设计题，现场设计一个企业级LLM应用
最后一题通常是个开放题，我面人时经常这么出：“假设一家企业要做一个2000人使用的内部客服助手，要求离线部署，基于开源模型，知识库有几万份内部文档，你来设计整个系统。”
这种题没有标准答案，但有很多标准失分点。我最怕听到的回答是“直接上32卡H100”，说明这个人只懂耗钱，不懂约束。
我的答题框架通常是四步：
第一步，定义边界。先问清楚并发量、延迟要求、预算上限、离线部署的具体含义。2000人不会同时提问，真正高峰期可能只有50-100个并发，这就决定了模型规模和硬件规格不可能太大。边界没搞清楚就谈架构，等于白干。
第二步，设计数据与检索链路。几万份文档不可能全塞进上下文，必须走RAG。先把文档清洗、去重，再做语义切块，每块控制在256-512 token，保留结构化标题信息。Embedding模型选一个效果不错的开源中文模型，索引建好之后，检索要加混合召回，BM25和向量检索并行，再用一个Rerank模型做精排，只把Top5-10的片段交给LLM。
第三步，选模型和部署方案。离线部署不开源不行，选一个开源基座，回答质量和工具调用能力都要够。如果预算有限，7B模型做INT8量化加多副本部署，应对几十个并发没问题；想要质量上限，可以上70B量化版本。推理服务用vLLM或同类框架，KV cache和并发管理交给框架处理。
第四步，安全和评测。客服助手要防越狱提示词，还得定义一套离线评测集，覆盖正常问答、敏感问题、超纲问题、多轮对话四类场景，分别统计准确率、误拒绝率和幻觉率。没有评测集就上线，这是我在项目里见过最多的失败原因。
这题考的不是“标准答案”，而是你能不能在有约束的条件下做取舍。你说清楚每一步为什么这么设计、预算花在哪、可能的风险是什么，就已经是合格回答。
我对这套综合设计题最大的体会是：大部分候选人都能聊RAG和微调，但能把量化和KV cache算明白的人很少，能主动谈评测的人更少。归根结底，这8道题考的是同一件事——你有没有用工程思维去理解大模型，而不是只会调API。准备的时候别只刷题，自己动手跑一个推理服务，做一次RAG检索，调一次模型参数量，比背十篇总结都有用。
