扒了 35 家 AI 公司面经，考最多的居然不是 Transformer

《面试题目》

1. KV 缓存是什么？显存占用怎么算？（8 家公司问过）
2. MoE 混合专家的路由和负载均衡是怎么做的？专家负载不均怎么办？（6 家公司问过）
3. Prompt、RAG、微调三种方案怎么选？（6 家公司问过）
4. 给几亿用户的聊天助手设计架构，需要考虑哪些问题？（5 家公司问过）

《参考解析》

1. KV 缓存与显存计算：自回归解码时每个新 token 都要和全部历史 token 做注意力，历史部分的 key/value 每一步都重复计算太浪费，于是把它们缓存下来，这就是 KV Cache。显存占用约等于 2（K 和 V）× 层数 × KV 头数 × head_dim × 序列长度 × 并发 batch × 每元素字节数。以 70B 级别模型为例，80 层、8 个 KV 头、head_dim 128、FP16，单条 128k 上下文大约就是 2 × 80 × 8 × 128 × 131072 × 2 字节，级别在几十 GB；乘上并发数就是推理服务真正的容量瓶颈。所以要能顺口说出压缩手段：GQA 减少 KV 头数、量化到 INT8/FP8、PagedAttention 减少碎片与预留浪费、前缀共享复用系统提示词的块、以及滑窗或稀疏注意力限制有效历史长度。面试官问这题，考的是你有没有真的部署过——算不清这笔账，就说明没在显存上撞过墙。

2. MoE 的路由与负载均衡：MoE 把前馈层拆成多个专家，每个 token 只激活其中 Top-K 个（常见 K=2），路由由一个轻量 gate 网络打分选出，这样总参数量可以很大而单 token 计算量保持在小模型的水平。难点在均衡：训练初期 gate 容易偏向少数专家，强者恒强，最后大部分专家拿不到梯度、等于白占显存。工程手段有几类——辅助负载均衡损失（给专家使用率方差加惩罚项）、容量因子与 token 丢弃（每个专家设容量上限，超出的 token 跳过该专家）、专家并行下的 all-to-all 通信优化，以及把 gate 的 logits 加噪或做归一化抑制极端分布。推理侧还要考虑专家并行部署时的通信开销与路由抖动，专家热度不均会让某些卡成为瓶颈，所以服务化时通常要监控每个专家的命中率并做重排布。成本上，MoE 省的是计算量不是显存——总参数决定了权重要常驻，这也是被追问最多的一点。

3. Prompt、RAG、微调的选型逻辑：第一刀按「知识更新频率」切——知识经常变、要求可溯源，走 RAG，把最新内容放进检索库，改知识不用动模型；知识稳定、变化慢，才考虑微调。第二刀按「要改的是知识还是行为」切——需要模型掌握新的风格、格式、领域术语或固定推理流程，微调更合适；只是要它按给定材料回答，RAG 加少量示例就够。第三刀按成本切——Prompt 最便宜、迭代最快，但受上下文长度与模型能力限制；RAG 要维护切分、索引和召回质量，工程量大但在知识型问答上性价比最高；微调要标注数据、训练和后续版本管理，只有前三者都解决不了才值得上。实践中三者是叠加的：好的系统通常是 Prompt 定格式、RAG 供事实、微调改行为。

4. 面向海量用户的聊天助手架构：这类系统和传统后端的区别集中在四件事。并发与排队——请求量远超单卡吞吐，需要网关层做限流与优先级队列，按用户等级或会话活跃度分配额度，避免长尾请求把队列拖垮。推理批处理——用连续批处理把不同请求的解码步拼在一起，配合 PagedAttention 管理 KV 显存，把吞吐从「一张卡一路对话」提到几十路。上下文存储——多轮对话历史不能一直留在显存里，要按会话存到 Redis 或对象存储，做摘要压缩与窗口裁剪，超长会话只回填最近若干轮加一份历史摘要。成本控制——分级路由是核心，简单意图用小模型或规则处理，复杂请求才升级到大模型；再叠加前缀缓存复用系统提示词、输出长度上限、以及对重复问题的语义缓存。最后别忘了可观测性：按会话记录 token 消耗、首 token 延迟和失败率，否则成本失控和体验劣化都发现不了。