2026年3月22日，Emily Fies指出：在生产环境中运行LLM不能简单依赖传统CPU/内存扩缩容，而需基于LLM特性定制策略。传统HPA在批处理模式下易导致队列积压、延迟飙升——如GPU利用率80%时延迟可激增230%。关键在于三大核心指标：**预填充队列长度**（反映等待请求数）、**已用槽位占比**（体现并行资源占用）、**TPU HBM利用率**（真实生成负载）。三者协同可精准判断系
2026年3月22日
分享
作者：Emily Fies 评论数：0
在生产环境中运行大型语言模型（LLM）远非部署一个简单的Web应用那么简单。你不能简单地“加更多CPU”就万事大吉。若真这么做了，轻则导致云服务账单急剧飙升，重则让用户等待本应只需半秒的响应却长达五秒之久。那么，如何让LLM服务既经济高效又响应迅速？关键在于自动扩缩容（Autoscaling）——但绝非传统Web服务中那种基于CPU或内存使用率的扩缩容方式。LLM需要一套专为自身特性量身定制的扩缩容策略。
为什么传统自动扩缩容对LLM失效？
多数企业最初采用Kubernetes水平Pod自动扩缩容器（HPA），依据CPU或内存使用率进行伸缩。该方案对单请求处理型API尚可奏效；但LLM的工作机制截然不同——它们采用批处理（batching）模式，即单块GPU可在合理排队调度下同时处理10、20甚至50个输入提示（prompts）。倘若仍以CPU使用率作为扩缩容触发条件，系统将等到GPU负载达95%才增加实例数量。此时，请求队列早已严重积压，延迟飙升，用户流失不可避免。
谷歌云内部数据显示，当GPU利用率升至80%时，若请求未被有效批处理，延迟可能激增230%。这并非硬件性能瓶颈所致，而是扩缩容策略失当的结果。传统指标如CPU使用率乃至GPU利用率仅能揭示问题的63%真相；真正的瓶颈在于：有多少请求正排队等待处理——而非芯片当前多繁忙。
真正决定LLM服务稳定性与效率的三大核心指标
以下三个指标能为你提供关于服务是否即将崩溃或尚有余裕的精准洞察，彻底摆脱传统Web服务器监控仪表盘的思维惯性——这些指标本质完全不同：
1. 预填充队列长度（Prefill queue size） 指尚未进入生成阶段、正在等待模型开始解码的待处理请求数量。一旦该队列填满，延迟将呈指数级爆炸式增长。谷歌云实测表明：当队列容量达到70%时，第95百分位延迟上升超200%；而当队列占用率达85%时启动扩容，则可预留缓冲空间应对突发流量，避免过度配置。
2. 已用槽位占比（Slots_used percentage） 衡量模型服务中已被占用的并行处理槽位比例。每个槽位可承载一批次中的一个请求。若90%以上槽位已满，说明系统已达容量极限。此指标比队列长度更灵敏——它直接反映的是“并行计算资源耗尽”，而非单纯请求堆积。CloudOptimo测试显示，据此策略触发扩缩容可使高峰时段的延迟峰值降低47%。
3. TPU高带宽内存（HBM）利用率 TPU上的高带宽内存（HBM）是生成token的实际“燃料”。与GPU利用率不同，后者因存在空闲周期而易产生误导；而HBM利用率与每秒生成token数之间的相关性高达92%。若HBM使用率低但队列满，说明硬件未被充分利用；若HBM使用率高却无待处理请求，则意味着资源浪费。因此，必须结合HBM数据判断实际负载状况。
上述三项指标并非可选项，而是唯一能真实反映系统底层运行状态的关键信号。切勿再依赖CPU、RAM或网络指标——它们只是噪音，无法提供决策依据。
如何选择合适的扩缩容策略？
来源：