2. 模型Serving基础概念高频问题
模型Serving岗位的第一轮技术面，往往不会直接考你写没写过CUDA Kernel，而是先用一组基础概念题快速判断你是否真正“在生产环境里跑过模型”。在线推理、批处理、模型加载、版本管理这四个词，几乎构成了Serving工程师日常工作的最小闭环。面试官问它们，不是要听定义，而是想确认你能否把概念落到延迟、吞吐、显存、发布节奏这些工程约束上。
本章回答主线：先给一句工程化定义，再补一个关键权衡，最后落到你项目中的具体数字或做法。概念题答成“教科书定义”只能拿及格分，答成“约束下的取舍”才是加分项。
一、核心原理：四个概念其实在回答同一件事
在线推理（Online Inference）指请求实时到达、要求低延迟返回的服务形态，典型约束是P99延迟和并发QPS。批处理（Batch Inference）指离线或准离线场景下，把大量样本攒成批次统一计算，追求吞吐和资源利用率。模型加载（Model Loading）是把权重从磁盘搬到显存并完成图优化、算子编译的过程，直接决定冷启动时间。版本管理（Version Management）则是让多个模型版本可灰度、可回滚、可观测的发布体系。
这四个概念共享一个底层矛盾：资源有限，而延迟、吞吐、稳定性三者互相拉扯。面试官真正想听的，是你是否理解这个矛盾，并能用具体手段去平衡它。
二、方法流程：从请求到发布的完整链路
- 在线推理链路：请求接入 → 鉴权与限流 → 预处理 → 动态组批 → 模型前向 → 后处理 → 返回。关键参数包括最大批大小、等待窗口、超时阈值。
- 批处理链路：数据分片 → 离线队列 → 固定批次推理 → 结果落库。关键指标是吞吐量和单位算力成本。
- 模型加载流程：拉取权重 → 初始化显存 → 加载图/编译 → 预热推理 → 注册到路由。冷启动常是发布事故的高发点。
- 版本管理流程：版本注册 → 灰度放量 → 指标对比 → 全量或回滚。核心是让新旧版本可共存、可切换。
# 典型在线推理服务启动日志
[INFO] loading model version=v3.2.1 device=cuda:0
[INFO] weights loaded in 4.8s, peak mem 18.2GB
[INFO] warmup batch=8 done, p99=42ms
[INFO] register route /predict -> v3.2.1
[INFO] ready to serve, max_batch=32, wait_ms=10
三、案例与场景：把概念讲成项目故事
假设面试官问：“你们在线推理和批处理是怎么分工的？”一个合格回答是：“在线走实时接口，批处理走离线任务，两者共用同一份模型权重但加载方式不同。” 而加分回答会补上取舍：
- 在线服务为控制P99，把最大批大小限制在32，等待窗口10ms，避免大batch拖尾。
- 批处理任务用更大的batch和更长超时，把GPU利用率从35%拉到80%以上。
- 模型加载阶段做了权重预取和显存池复用，冷启动从90秒降到25秒。
- 版本管理上用双版本并行加流量比例切换，出问题5分钟内回滚。
面试时尽量给出一个具体数字，例如“P99从120ms降到65ms”或“冷启动从90秒降到25秒”。数字比形容词更能证明你真的做过。
四、误区与复盘：概念题最容易踩的坑
| 常见误区 | 问题本质 | 修正答法 |
|---|---|---|
| 只背定义，不谈约束 | 缺少工程视角 | 补一句延迟/吞吐/显存的权衡 |
| 把在线和批处理对立 | 忽略共用基础设施 | 说明两者共享权重与调度层 |
| 模型加载只说“加载权重” | 忽略编译与预热 | 补充图优化、算子编译、warmup |
| 版本管理只说“打tag” | 缺少发布体系 | 讲灰度、回滚、指标对比 |
不要在没有数据支撑时夸大优化效果。面试官常会追问“怎么测的”“基线是多少”，答不上来反而扣分。宁可说“我们观测到明显下降”，也不要编造精确数字。
五、公司侧重点差异
不同公司对这四个概念的考察权重不同。云厂商和基础设施团队更关注在线推理的延迟与弹性伸缩；推荐和广告团队更关注批处理吞吐与特征一致性；大模型团队则把模型加载和版本管理视为发布生命线。回答时可以先判断岗位方向，再调整叙述重心。
把在线推理、批处理、模型加载、版本管理串成一条“请求—计算—发布”的链路来回答，你就从“背概念”升级成了“讲系统”。这正是Serving面试第一轮最想看到的信号。