LLM 推理服务系统学习教练

解决什么问题

LLM 推理服务常见的问题不是“调不通 API”，而是只调 API 不懂底层瓶颈。当出现 CUDA OOM、吞吐上不去、首 token 慢、长文本越来越慢、流式卡顿、量化后质量下降、并发上不去时，如果只看报错或凭直觉改参数，很容易在显存、调度、批处理和序列长度之间反复横跳。这个技能把问题拉回三个核心指标：延迟、吞吐、显存。每改动一次，都先看数据，再判断是否继续。

它如何工作

它按“先跑通最小推理循环，再逐步加批处理与调度”的顺序推进。核心资产是一张识别信号表：CUDA OOM / 显存爆 对应减 max_batch、降精度或限制序列长度；吞吐低但显存有余 对应请求未批处理，可开 continuous batching；首 token 慢 优先看 prefill 与批调度；长文本越来越慢 关注 KV Cache 增长，必要时限长或复用；流式卡顿 看输出缓冲与并发锁；量化后质量掉 调整量化粒度或保留关键层高精度；并发上不去 检查队列、worker 数和锁竞争；不知瓶颈时，先分别计时 prefill 与 decode。

卡住时的流程是：先降级到单请求跑通并打点；再分层提示，先问显存还是调度，再问哪个阶段慢；然后重做，关掉批处理或量化回到最简，逐项加回定位引入者；最后把现象、指标证据、优化动作和效果登记下来。学习节奏也强调基线：每改一项先测基线指标，先跑通再优化，长序列与 batch size 用数据定阈值。

适用边界与注意点

它不承诺替代真实系统能力。Apple Silicon、不同 GPU 和框架版本的硬件差异显著，优化结果要以本地环境和版本为准。涉及 vLLM、Qwen 等具体实现时，应以其官方仓库和文档最新版为准。它也不提供作弊或代做，目标是建立可复现的推理优化方法。