面试大模型岗位时，很多人简历上有项目但被问细就露馅：注意力怎么算、显存怎么估、并发上不去怎么排查，答不出具体口径。这篇按算法原理、开发实践、系统部署三段给一份考点清单，每条都写清面试官想听什么、你自己怎么验证会没会。适合转岗、应届和做了应用但没碰过底层的人；如果你已经带过完整训练或推理集群，可以直接跳到排查类问题。
面大模型岗位，简历上有项目但一问细就露馅，是特别常见的情况。注意力怎么算、显存怎么估、并发上不去怎么排查，这些答不出具体口径，面试官三句话就摸到你的底。这篇按算法原理、开发实践、系统部署三段给你一份考点清单，每条都写清面试官想听什么、你自己怎么验证到底会不会。
适合转岗、应届，以及做了应用但没碰过底层的人。如果你已经带过完整的训练或推理集群，前面原理部分可以快速扫过，直接跳到部署和排查类问题。全文不给死数字，凡是涉及模型规模、显存、延迟这类会变的量，都告诉你去站内哪个页面按当时的实测口径核对。
算法原理：把概念讲到能被追问三层
原理部分的坑不在「知不知道」，而在「能不能被追问三层还不崩」。面试官问注意力，不是要你背公式，是要你顺着张量维度一路走下去。所以你准备的粒度应该是「每一步的 shape 和为什么」，不是「一句话定义」。
- 注意力机制要能手推 shape 变化：从输入张量到 Q/K/V、缩放、softmax 归一化、多头拼接，面试官常顺着 batch 和 head 维度继续追问，你要能当场说出每一步维度是多少
- 训练三阶段（预训练、微调、对齐）的数据规模和目标函数差异要能对比着讲，尤其是为什么微调的数据量级远小于预训练，这题答不清会被判定只背过名词
- 量化、蒸馏、剪枝几种压缩路线解决的不是同一个问题，要按显存占用、推理延迟、精度损失三个维度分别说明适用边界和代价
- 自检方式：挑一道「为什么这个操作要除以根号 d」之类的问题，用自己的话连续讲 90 秒，中途卡壳就说明没吃透
这里有个判断标准：如果对方换一个提问角度，你还能从同一套原理推出去，那才算会；如果只能回答被问过的那一个版本，基本是背的。压缩路线那块尤其明显，很多人能说出名词，但问「显存降了延迟为什么不一定降」就答不上来。
开发实践：从提示到微调的取舍要能报出依据
开发实践这段的失分点不是「你不会用」，而是「你说不出为什么选它」。提示工程、RAG、微调这三条路，面试官想听的是你的判断依据，不是你的偏好。
| 判断维度 | 倾向提示工程 | 倾向 RAG | 倾向微调 |
|---|---|---|---|
| 是否需要外部实时知识 | 不需要 | 需要 | 不太需要 |
| 输出格式是否要稳定 | 宽松即可 | 中等 | 要求严格 |
| 标注数据能不能拿到 | 不需要 | 少量可用 | 需要成规模 |
| 知识更新频率 | 低 | 高 | 低 |
数据侧要能讲清训练集、验证集、测试集怎么划分，以及过拟合时表现出的现象和排查顺序。评估不能只报一个分数，要说明用什么数据集、什么口径、有没有做人工校验抽样。这三句话一说，面试官就知道你是真跑过还是只看过教程。
- 上下文超长怎么截断：按什么策略丢、丢哪一段、丢了之后怎么保证关键信息还在
- 多轮对话怎么管理历史：是滑动窗口、摘要压缩还是检索回填，各自在什么场景下会失效
- 结构化输出失败怎么兜底：重试、schema 校验、降级成自由文本再解析，哪一层先做
- 评估抽样怎么设计：人工看多少条、看哪些失败样本、发现的问题怎么回流到数据侧
系统部署：显存、并发、吞吐要算得出来
部署类问题是多数人真正翻车的地方，因为可以纯靠嘴糊过去的空间最小。先算显存再谈卡数：权重、KV 缓存、激活值各占多少，量化档位如何改变这笔账。具体数字随模型参数和序列长度变化很大，到站内部署测算页按你的实际配置核当时的估算口径，别背别人的数。
并发和吞吐不是一回事。延迟敏感的场景和吞吐敏感的场景，批处理策略和框架选择完全不同。面试官问「你怎么压测的」，其实是在问「你有没有量过」。答不好往往卡在没量过，建议先用站内测速工具量出自己的延迟基线，再谈优化，不然全是空话。
- 算显存账按权重、KV 缓存、激活值拆成三块分别估，写出公式再代你的参数，验证方式是问自己：序列长度翻倍，哪一块先爆。
- 分开看并发与吞吐明确你的服务是延迟优先还是吞吐优先，据此选批处理策略，验证方式是量出不同并发下的延迟曲线拐点。
- 选框架看形态说清每种推理框架擅长的部署形态，比背名字有用；具体取舍对照站内推理框架选型内容核当时的对比口径。
- 量基线再优化先用站内测速工具测一组自己的延迟和吞吐数据，任何优化结论都挂在这组基线上，验证方式是优化前后对比同一口径。
上场前的自查顺序与常见丢分点
最后给一套自查顺序：按「原理—开发—部署」倒着自测。先挑一个你真的部署过的服务讲出来，然后让追问一路往下走到原理层，如果能讲通，说明你的链路是完整的；哪一层断掉，就回去补那一层。
- 准备两个真实踩坑：一个显存或并发类，一个数据或评估类，讲清现象、排查过程、最后怎么定的方案
- 避免只背结论：说「某某框架更快」不如说「在什么并发和序列长度下测出来的差异是什么口径」
- 明确说不适用的边界：小团队、单卡环境、数据不能出内网时，很多通用最优解并不成立，能说出这点反而是加分项
- 把会变的数据全部指向站内页面：模型规模、显存、延迟这类数字，面试时如果拿不准，就说你的口径来源和估算方法，别硬报
说白了，面试官想招的是能把一件事从原理讲到部署、并且知道自己在哪个环节不确定的人。会算、会量、会说边界，比记住一堆结论有用得多。丢分最多的情况就是结论对但过程讲不出来，所以自查时一定要把过程讲一遍。
下一步拿站内测速工具跑一组你自己的延迟基线，再对照部署测算页核一遍显存估算口径，带着真实数据去面试，追问到哪层都不慌。→常见问题
没有训练经验，只做过应用开发，面试能过吗？
能过一部分岗位，但要把应用侧讲深。重点准备 RAG 链路、评估方法、超长上下文处理和成本控制这几块，被问到训练细节时诚实说没做过，但能讲清原理和你会怎么验证，比硬答更好。
面试问显存怎么估，我应该背公式还是讲思路？
讲思路加口径最重要。先说清权重、KV 缓存、激活三部分各自和什么成正比，再说明量化会压缩哪一部分，最后给出你去站内部署测算页按具体参数核对的做法。面试官想听的是你会不会算，不是记住某个数。
算法原理和工程部署哪块该花更多时间？
看岗位描述。偏研究和训练的岗要能把原理追到推导层；偏平台和工程的岗，显存测算、并发排查、框架选型权重更高。两边都不熟的，先把部署链路讲通，因为原理问题通常可以顺着你的项目往深问。
