“大模型面经”“100题”“99%通过率”——这类标题你最近一定刷到过不少。坦白说，把题目背完并不能保证拿到 offer，真正拉开差距的是你能不能把“原理、训练、部署、应用”串成一条线，并且用项目经历说服面试官。
这篇文章不承诺“刷完就通过”，但会给你一套比题单更值钱的准备框架：先讲大模型面试的考察逻辑，再按高频考点拆解 Transformer、微调、推理部署、RAG/Agent 四大块，最后落到简历撰写和投递全流程。读完你可以直接照着梳理自己的知识树和项目文档。
1. 大模型面试到底在考什么
很多人准备大模型岗位面试，第一反应是去搜“面试100题”。但如果你只背题，不建立知识结构，面试官多追问一句“为什么这样设计”就会露馅。
大模型岗位面试和传统后端面试有明显区别。后端面试考的是“你用过什么框架、踩过什么坑”，大模型面试考的是“你是否理解模型内部发生了什么，以及能不能把模型真正跑起来服务业务”。
1.1 三类面试官的考察重心
面试官大致分三类，考察侧重点完全不同：
| 面试官类型 | 考察重点 | 典型问题方向 |
|---|---|---|
| 算法/研究型 | 模型原理、训练机制、论文复现 | Attention 公式、RLHF、位置编码、loss 设计 |
| 工程落地型 | 部署、推理优化、稳定性、成本 | 精度选型、显存估算、vLLM 加速、量化原理 |
| 业务应用型 | 场景理解、RAG、Agent、Prompt 工程 | 怎么设计知识库问答、工具调用怎么保证可靠 |
很多求职者只准备了算法方向，结果面试官是工程团队，问的全是“FP16 和 BF16 有什么区别”“7B 模型要多少显存”，这就很容易冷场。
1.2 高频考点地图
综合各厂大模型相关岗位的公开面经，高频考点大致分布在六个模块：
- 基础原理：Transformer、自注意力、位置编码、KV Cache、GPT 系列演进、RLHF。
- 训练微调：预训练与 SFT 的区别、LoRA/QLoRA、P-Tuning、数据构造、灾难性遗忘。
- 推理部署：精度问题（FP32/FP16/BF16）、量化、vLLM、ollama、流式输出、显存估算。
- 应用工程：RAG 流程、向量数据库、Agent、Function Calling、Prompt 优化。
- 评估与安全：模型评估指标、幻觉问题、越狱防护、数据隐私。
- 项目经历：简历上的项目是不是自己做的、技术选型理由、效果指标。
把这张地图打印出来，对照自己薄弱的地方逐项补，比收集一百道题更有效。
1.3 面试准备的正确姿势
面试准备要形成“面经收集 → 知识归类 → 动手验证 → 口头复述”的循环。看到一个题目，不要直接看答案，先自己试答，再去跑一段最小代码验证原理。比如“KV Cache 到底省了什么”，你可以写一个 100 行的小脚本对比有无 KV Cache 的计算量，理解立刻不一样。
接下来的章节，我会把高频题目按这个思路拆开讲，并且给出可以直接运行的代码或配置示例。
2. 高频原理题：从 Transformer 到注意力机制
2.1 Attention 是怎么算出来的
在 Transformer 中，每个输入 token 会生成三个向量：Query、Key、Value。Attention 的本质是“根据 Query 和所有 Key 的匹配程度，对 Value 做加权求和”。
公式是：
Attention(Q, K, V) = softmax(Q * K^T / sqrt(dk)) * V这里有一个高频追问点：为什么要除以sqrt(dk)？
如果dk很大，Q * K^T的点积值会很大，softmax 会进入梯度极小区域，导致训练不稳定。除以sqrt(dk)可以把点积的方差拉回接近 1 的量级，让梯度更稳定。
2.2 为什么需要位置编码
自注意力本身是“无序”的。它计算 token 两两之间的相关性时，完全不考虑谁先谁后。为了建模语言顺序，必须在输入中加入位置信息。
常见方案有三种：
- 绝对位置编码：把 token 位置编号编码进 embedding，如正弦位置编码。
- 相对位置编码：建模两个 token 之间的相对距离，如 T5 的 Relative Bias。
- 旋转位置编码 RoPE：把位置信息通过旋转矩阵注入 Q/K 向量，是目前主流大模型最常用的方案。
面试如果只答“Transformer 没有位置信息，所以要加位置编码”，只是及格分。能说出 RoPE 的核心思想，会更加分。
2.3 KV Cache 的作用
KV Cache 是推理优化里最基础的概念。生成第 N 个 token 时，前面的 token 对应的 Key 和 Value 已经算过了，不需要重新计算，把它们缓存起来就叫 KV Cache。
面试官常问：KV Cache 是省显存还是省计算？
答案是主要省重复计算，但代价是增加显存占用。随着序列变长，KV Cache 占用会线性增长，这也是长文本推理显存吃紧的关键原因之一。很多推理框架做 PagedAttention、缓存复用、量化 KV Cache，都是为了缓解这个问题。
2.4 实现一个最小注意力计算
下面是一个最简单的 scaled dot-product attention 实现，可以在本地跑通：
import torch import torch.nn.functional as F def scaled_dot_product_attention(query, key, value, mask=None): """ query: [batch, heads, seq_len, dk] key: [batch, heads, seq_len, dk] value: [batch, heads, seq_len, dv] """ d_k = query.size(-1) scores = torch.matmul(query, key.transpose(-2, -1)) / (d_k ** 0.5) if mask is not None: scores = scores.masked_fill(mask == 0, float("-inf")) weights = F.softmax(scores, dim=-1) return torch.matmul(weights, value) if __name__ == "__main__": batch, heads, seq_len, d_k = 1, 4, 8, 64 q = torch.randn(batch, heads, seq_len, d_k) k = torch.randn(batch, heads, seq_len, d_k) v = torch.randn(batch, heads, seq_len, d_k) out = scaled_dot_product_attention(q, k, v) print("output shape:", out.shape)你可以把 mask 参数换成因果 mask，观察生成模型训练时为什么每个 token 只能看到前面的 token。
3. 大模型训练与微调：从 SFT 到 LoRA
3.1 面试官最常问的训练问题
训练相关题目是算法岗和工程岗都会问的模块。常见问题包括：
- 预训练和 SFT 有什么区别？
- SFT 训练数据怎么构造？
- 全参数微调和 LoRA 的区别？
- LoRA 为什么能减少显存？rank 怎么设置？
- 微调之后模型“变傻”了怎么办？
预训练的目标是让模型学会语言规律，SFT 的目标是让模型学会按人类期望的方式回答。两者数据规模、学习率、训练轮数都不同。SFT 数据量通常几万到几十万条即可，但质量要求很高，需要覆盖目标场景的真实问题。
3.2 LoRA 的显存优势
LoRA 的核心思想是冻结原始模型权重，在旁路插入低秩矩阵来模拟权重更新。训练时只更新这部分参数，大幅减少需要保存梯度的参数量。
用一个粗糙但直观的计算来解释：7B 模型全参数微调，每个参数都需要保存梯度，再加上优化器状态，显存需求往往要几十 GB。而 LoRA 只更新几百万到几千万参数，显存需求大幅下降，普通消费级显卡也能跑起来。
关于 rank 的设置，没有一个万能值。r=8和r=16是常见的起点，任务简单或数据量少时用小 rank，任务复杂且数据充足时可以适当加大。更大的 rank 不一定带来更好的效果，反而可能过拟合。
3.3 LoRA 微调最小配置与代码
使用 Hugging Face 的peft库可以快速跑通 LoRA：
from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model, TaskType model_name = "Qwen/Qwen2.5-7B-Instruct" base_model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype="auto", device_map="auto" ) lora_config = LoraConfig( task_type=TaskType.CAUSAL_LM, r=8, lora_alpha=32, lora_dropout=0.1, target_modules=["q_proj", "v_proj"], ) model = get_peft_model(base_model, lora_config) model.print_trainable_parameters()这里的关键配置项：
r：低秩矩阵的秩，决定新增参数量。lora_alpha：LoRA 缩放系数，实际缩放比例是lora_alpha / r。target_modules：需要插入 LoRA 的模块，常见选择是q_proj和v_proj，也可以覆盖所有线性层。
运行后会看到可训练参数量远小于全量参数，这就是 LoRA 显存占用的优势来源。
3.4 微调失败的排查思路
很多人在微调时遇到两个典型问题：loss 不下降、微调后模型通用能力变差。
loss 不下降，首先要检查数据集是否太脏，包括空文本、重复文本、标签错位。其次检查学习率，SFT 的初始学习率通常比预训练小 1 到 2 个数量级，比如 1e-5 到 2e-5。
微调后模型“变傻”，通常是因为 SFT 数据太单一，覆盖不到通用场景。补救方式是在数据集里混合一定比例的通用对话数据，也叫“通用能力保持数据”。这个比例没有固定标准，一般根据任务难度调整，建议从 5% 到 20% 之间做实验。
4. 大模型部署与推理优化：精度、量化与 vLLM
部署和推理优化是 2026 年大模型岗位面试中权重最高的模块之一。原因很简单：大部分公司不会从零训练大模型，而是基于开源模型做微调和私有化部署。能不能把模型跑起来、跑得快、跑得省，是工程团队最关心的事。
4.1 FP32 / FP16 / BF16 精度问题
先说结论：训练和推理对精度的要求不同，主流选择也不同。
| 精度 | 位宽 | 数值范围 | 适用场景 | 显存占用 |
|---|---|---|---|---|
| FP32 | 32 位 | 大 | 训练基准、调试 | 高 |
| FP16 | 16 位 | 中等，小数值易溢出 | 部分训练和推理 | 中 |
| BF16 | 16 位 | 与 FP32 接近，尾数少 | 大模型训练主力 | 中 |
| INT8 | 8 位 | 小 | 推理量化 | 低 |
| INT4 | 4 位 | 很小 | 推理量化、本地部署 | 极低 |
面试经常会问：为什么训练大模型偏好 BF16 而不是 FP16？
因为 BF16 的指数位与 FP32 相同，动态范围大，不容易出现梯度溢出。FP16 尾数精度高，但数值范围小，大模型训练时很容易在反向传播中出现下溢或上溢。
你可以在本地跑一个简单的数值验证：
import torch fp16_value = torch.tensor(100000.0, dtype=torch.float16) bf16_value = torch.tensor(100000.0, dtype=torch.bfloat16) print("fp16:", fp16_value) print("bf16:", bf16_value) print("fp16 * 1000:", fp16_value * 1000) print("bf16 * 1000:", bf16_value * 1000)运行后你会发现 FP16 在乘大数时容易出现inf，而 BF16 表现更稳定。
4.2 量化：INT8 / INT4 原理与分类
量化是把高精度权重用低精度表示，从而减少显存占用和计算量。面试常问两种量化方式：
- PTQ（训练后量化）：在模型训练完成后，用少量校准数据推算量化参数，不需要重新训练，速度快，但可能有一定精度损失。
- QAT（量化感知训练）：在训练过程中模拟量化误差，让模型权重适应低精度表示，精度损失更小，但成本更高。
实际工程中，PTQ 是常态。比如用bitsandbytes加载 4-bit 模型，或者用 AWQ、GPTQ 做离线量化。
4.3 vLLM 与 PagedAttention
vLLM 是目前最常用的开源推理服务框架，面试官可能会追问它为什么比原生 Hugging Face 推理快。
关键原因是 PagedAttention。类似于操作系统管理内存的分页机制，PagedAttention 把 KV Cache 分成固定大小的块来管理，减少显存碎片，并支持共享前缀，从而提升并发吞吐和长序列处理能力。
实际部署一个模型时，可以通过一行命令启动 OpenAI 兼容的服务：
vllm serve Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9参数说明：
--tensor-parallel-size：使用多张显卡时的张量并行度。--max-model-len：最大上下文长度，会影响 KV Cache 预留空间。--gpu-memory-utilization：控制显存利用率上限，避免 OOM。
4.4 Ollama 本地部署私有大模型
本地部署大模型是很多中小团队和个人的首选，Ollama 以“安装简单、开箱即用”著称，很适合在面试中作为项目底座来聊。
部署一个开源模型的整个过程只需要两条命令：
ollama pull qwen2.5:7b ollama run qwen2.5:7b拉取完成后，Ollama 会启动一个本地服务，默认监听11434端口。你可以通过 REST API 调用：
curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "用一句话解释什么是大模型"}] }'注意，Ollama 的 API 不是所有版本都原生兼容 OpenAI 格式，使用前建议查看当前版本的接口文档。不过整体趋势是越来越多的本地推理服务开始兼容 OpenAI 接口，这也降低了应用层接入成本。
4.5 显存估算方法
面试官经常给出一个模型参数规模，让你估算推理需要多少显存。
估算公式可以这样拆：模型权重显存加上 KV Cache 显存，再乘以工程冗余系数。
def estimate_memory(model_size_b, precision_bytes=2, context_len=4096, layers=32, kv_heads=8, head_dim=128, overhead=1.2): # 权重显存 weight_mem = model_size_b * 1e9 * precision_bytes / 1024**3 # GB # KV Cache 显存（简化估算） block_size = 2 * layers * kv_heads * head_dim * precision_bytes kv_mem = context_len * block_size / 1024**3 # GB total = (weight_mem + kv_mem) * overhead return total print(estimate_memory(7))这个估算很粗糙，但足够用来判断“7B 模型在 16GB 显存上能不能跑”。实际部署时，还要考虑激活值、框架自身开销等因素。
5. RAG 与 Agent：大模型应用层的高频考点
应用层题目经常出现在二面和三面，尤其是做业务应用的公司。面试官会给你一个业务场景，比如“企业内部知识库问答”“客服自动化”，然后让你设计方案。
5.1 RAG 为什么是必备知识点
RAG（检索增强生成）是当前大模型落地最成熟的技术路线。它的核心价值是：让模型在生成时能参考外部知识，减少幻觉，并且知识可以随时更新，不需要重新训练。
面试常问：RAG 和微调怎么选？
一个可复用的回答框架：
- 知识变化频率高、需要实时更新：优先 RAG。
- 需要改变模型行为风格、输出格式、专业术语：优先微调。
- 两者可以结合：先微调让模型适应任务，再用 RAG 补充领域知识。
5.2 RAG 最小流程实现
RAG 的完整链路是：文档加载 → 文本切分 → 向量化 → 存储 → 检索 → 重排 → 生成。
下面是一个精简伪代码，用来串起整个流程：
# 伪代码：展示 RAG 最小流程 from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载文档 loader = TextLoader("docs/qa.txt") documents = loader.load() # 2. 切分文本 splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(documents) # 3. 向量化并存储 embedding = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5") vectorstore = FAISS.from_documents(chunks, embedding) # 4. 检索 query = "公司年假政策是什么？" retrieved_docs = vectorstore.similarity_search(query, k=3) # 5. 构造 Prompt 并交给大模型 context = "\n\n".join([doc.page_content for doc in retrieved_docs]) prompt = f"请根据以下资料回答问题：\n\n{context}\n\n问题：{query}"这里每一步都可以深挖。比如为什么chunk_size=500、为什么要有chunk_overlap，面试官追问时，你要能答出“切分过大导致检索噪声，切分过小导致上下文不完整，overlap 是为了保持段落语义连贯”。
5.3 Agent 与 Function Calling
Agent 是另一个高频话题。面试官会问：Agent 和普通对话有什么区别？Agent 怎么调用外部工具？怎么避免 Agent 死循环？
Agent 的核心是“让模型能够规划行动、调用工具、观察结果并决定下一步”。Function Calling 是实现工具调用的常见方式：模型输出一个结构化参数，系统解析后调用真实函数。
一个简单的 Function Calling 示例：
{ "name": "get_weather", "description": "获取指定城市的天气信息", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } }实际面试中，建议把表达重心放在“工具定义是否清晰、结果如何反馈给模型、出现错误如何处理”这三个点上。比如模型调用了不存在的工具，系统应该返回一个可读的错误信息，让模型有机会重新规划，而不是直接崩溃。
5.4 面试回答“RAG 还是微调”的得分话术
低分回答：RAG 便宜，微调贵。
高分回答思路：先给判断标准，再给实际案例。
“我一般按三个维度判断。第一，知识是否需要高频更新，如果是，选 RAG。第二，是否需要改变模型的表达风格或领域术语，如果是，选微调。第三，两者并不互斥，我最近做的一个项目是先微调让模型适应客服语气，再用 RAG 接入最新产品手册，效果比单独用任何一种都好。”
这种回答既展示了知识面，又体现了工程经验。
6. 简历怎么写才能通过初筛
前面所有技术准备，最终都要通过简历和面试表达出来。简历环节最容易出现两个问题：一是堆砌名词，二是有项目无成果。
6.1 技术简历的底层逻辑
筛选简历的人想看到三件事：
- 你做过和岗位相关的事情。
- 你在这个事情里有清晰的技术选型和落地成果。
- 你的成果可量化、可验证。
不要写“精通大模型”，而是写“基于 Qwen2.5 搭建了私有大模型问答系统，使用 LoRA 微调解决了领域术语识别问题，最终专业问答准确率提升了若干百分点”。
这里有两个原则：
- 数字要真实，没有数据就写清楚“指标提升待完整评测”。
- 技术栈要匹配岗位要求，不要为了凑关键词把没做过的东西写上去。
6.2 一份有竞争力的项目描述模板
项目经历可以按这个模板写：
项目名称：基于大模型的中文法律知识问答系统 项目周期：2025.09 - 2025.12 个人职责：负责模型微调、RAG 链路搭建和部署优化 核心工作： 1. 以 Qwen2.5-7B-Instruct 为基座，构造 2 万条法律领域 SFT 数据，使用 LoRA 完成参数高效微调； 2. 基于向量数据库构建 RAG 检索链路，实现回答内容可溯源； 3. 使用 vLLM 部署推理服务，对比原生 Transformers 推理，验证了吞吐提升效果； 4. 项目代码和评估报告已整理到 GitHub。 技术栈：Python、PyTorch、transformers、peft、vLLM、FAISS、Ollama这段描述的价值在于：每个工作点都能对应一个面试追问。面试官问“数据怎么构造”“为什么选 LoRA”“FAISS 和 pgvector 怎么选”，你都有东西可以展开。
6.3 投递渠道与流程节奏
投递渠道优先级建议是：内推 > 公司官方招聘官网 > 主流招聘平台。
全流程通常是：
简历筛选 -> 笔试/测评 -> 一轮技术面 -> 二轮技术面 -> 交叉/主管面 -> HR面 -> offer沟通笔试阶段很可能包含算法题和机器学习基础题，所以 LeetCode 刷题和必要的 ML 基础都不能完全放下。技术面二轮往往更偏向项目深挖，你要能把简历里每个细节讲清。
7. 面试全流程模拟与答题方法
7.1 四轮面试常见结构
| 面试阶段 | 时长 | 考察重点 | 应对策略 |
|---|---|---|---|
| 技术一面 | 40-60 分钟 | 基础原理、编码能力 | 先把概念框架讲清楚，再写代码 |
| 技术二面 | 40-60 分钟 | 项目深度、系统设计 | 用 STAR 逻辑讲项目，突出冲突和取舍 |
| 主管面 | 30-45 分钟 | 软素质、业务思维 | 多谈业务价值，少谈技术炫技 |
| HR 面 | 15-30 分钟 | 稳定性、薪资预期 | 保持真诚，展示学习能力和稳定性 |
7.2 答题方法论：先结论后展开
面试答题最忌讳上来就背一段书。推荐用“结论 + 理由 + 例子”的结构。
例如被问“为什么选择 RAG？”：
- 先给结论：因为业务知识更新快，RAG 能在不改动模型参数的情况下接入最新内容。
- 再给技术理由：RAG 通过检索外部知识为模型提供上下文，减少幻觉，并且支持知识增量更新。
- 最后给例子：我在法律问答项目中接入最新法规库，检索链路返回原文，模型回答可溯源。
这种结构让面试官很容易抓住你的重点，也方便他继续追问。
7.3 遇到不会的题怎么办
不要硬编，也不要直接说“不会”。比较得体的处理方式是：
- 承认这部分没有深入实践过。
- 基于已有知识做合理推断。
- 表达学习意愿。
比如说：“这个问题我之前没有在工程里用过，不过基于我对 Transformer 的理解，我推测它和 KV Cache 的显存管理有关，我后续会去补一下这一块的源码。”
这种回答方式比沉默或乱猜要好得多。
7.4 反问环节这样问更加分
面试官一般会问“你有什么想问我的”，这是加分机会。可以问：
- 团队现在对大模型技术栈的选型是什么？
- 新同学入职之后主要接手哪类项目？
- 团队目前在推理成本优化上做到了什么程度？
这些问题能让面试官觉得你关注实际工作，而不是只想要一份 offer。
8. 常见问题与避坑指南
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 背了很多题，面试时依然讲不清 | 没有建立知识树，问题之间是孤立的 | 自己模拟面试，录音回听 | 按本文的六模块整理知识树，每个知识点准备3分钟口头讲解 |
| 简历写“精通大模型”，被追问就崩 | 项目不够真实，细节撑不住 | 找朋友模拟深挖简历 | 把项目里的技术选型、失败经历、效果数据全部补充完整 |
| 微调损失下降但效果差 | 数据集质量低或指标错误 | 检查数据样本，增加评测集 | 清洗数据，构造更贴近真实应用的评测集 |
| vLLM 启动后 OOM | max-model-len 设置过大 | 查看启动日志和显存监控 | 降低max-model-len或gpu-memory-utilization |
| 本地部署大模型后响应速度慢 | 未使用推理加速框架 | 对比原版推理和 vLLM 推理的时间 | 引入 vLLM，打开 continuous batching 特性 |
| 只知道 RAG 流程，不能处理失败情况 | 缺乏错误处理经验 | 构造坏数据，观察检索和生成的问题 | 加入检索结果数量监控、空结果兜底逻辑、重排序环节 |
避开这些坑，比多刷 50 道题更有效。
9. 总结与后续学习方向
回到开头那句话，刷完一百题并不能保证通过面试。真正有价值的准备方式是：以“原理 → 训练 → 部署 → 应用 → 表达”为骨架，把高频考点做成自己的知识树，再通过实际项目或开源 Demo 把每一个知识节点验证一遍。
如果你时间有限，优先补三块：LoRA 微调的最小代码示例、本地部署大模型并用 vLLM 加速、RAG 全流程的工程实现。这三个能力最容易在面试中被量化考察，也最容易迁移到实际业务里。
后续学习方向建议按需深入：想做算法研究就多看 RLHF 和模型架构源码；想做工程落地就多研究推理优化、量化、高并发服务和成本控制；想做应用开发就多研究 RAG、Agent、评估体系和少样本学习。
面试本质上是“把一件事讲清楚”的能力。大模型领域变化很快，2026 年的面试题和 2024 年已经有很多不同，但面试官想要的人一直是同一种：既能理解原理，也能动手落地，还能把方案讲明白。你不需要真的刷完一百题，只需要顺着这条线，把每一个核心知识点都变成自己的东西。
