在 Kubernetes 中 Autoscale LLM 的实践
内容提要
本文分享了2023年构建无服务器LLM推理平台ModelZ的经验，重点介绍了其架构设计、冷启动优化（包括模型缓存与镜像加载）、自动扩缩容及负载均衡策略。通过Kubernetes部署，利用缓存加速模型下载，采用GCP镜像流技术，并预留GPU节点池以减少扩容延迟。文章还探讨了kvcache对负载均衡带来的新挑战，为社区提供了实践参考。
延伸解读
冷启动优化的关键路径
文章指出，LLM推理服务的冷启动延迟主要来自镜像加载和模型加载。模型加载可通过集群内缓存（如Huggingface Hub缓存）避免重复下载，并利用流式加载（如tensorizor）将8B模型加载时间从50秒降至15秒。镜像加载则可采用GCP image streaming等懒加载技术，理想情况下应混合急切与懒加载，以充分利用IO资源。
预留GPU节点池的权衡
为避免集群自动扩缩容带来的1-5分钟延迟，作者使用cluster-proportional-autoscaler维护预留GPU节点池，通过占位pod占住资源。但这增加了成本，且新节点无镜像缓存，需引入kube-fledged预热，并修复其bug。这种设计在节省成本与保证扩容速度之间做了权衡，适合对延迟敏感的场景。
kvcache对负载均衡的新挑战
2024年推理引擎引入kvcache后，LLM推理服务不再无状态，传统roundrobin负载均衡可能失效。文章提出两种思路：一是kvcache的live migration，如LMCache通过redis共享kvcache，类比分布式session管理，从而简化负载均衡策略。这提示读者在构建LLM服务时需考虑状态管理对负载均衡的影响。
Q&A
ModelZ 是什么？它的主要功能是什么？
ModelZ 是一个在 2023 年构建的无服务器 LLM 推理平台，用户上传模型文件后，当请求到来时，推理服务会自动运行并返回结果，支持自动扩缩容，用户无需关心底层基础设施。
ModelZ 的计费单位是什么？与 Together.AI 或 Fireworks 有何不同？
ModelZ 的计费单位是 GPU 时间，而 Together.AI 或 Fireworks 的计费单位是 Token。
在 Kubernetes 中部署 LLM 时，冷启动的主要延迟来源有哪些？
冷启动的主要延迟来源是镜像的加载和模型参数的加载。镜像从镜像仓库拉取到本地，模型从远程存储下载到本地并加载到 GPU。
ModelZ 如何加速模型下载？
通过在集群内部署一个 Huggingface Hub 的缓存服务器，设置 HF_ENDPOINT 环境变量将模型下载请求转发到缓存服务器，模型只需下载一次即可在集群内共享，从而加速下载。
ModelZ 如何加速镜像加载？
使用了 GCP image streaming 技术来加速镜像加载，该技术允许容器在启动时只加载必要部分，同时后台继续下载镜像，从而减少启动延迟。
ModelZ 的自动扩缩容是如何实现的？
采用与 OpenFaaS 类似的系统设计，Gateway 负责从 0 到 1 的扩容，Autoscaler 负责其他扩缩容操作，根据用户设置的参数和 Prometheus metrics 调整副本数。
为了避免 GPU 节点扩容延迟，ModelZ 采用了什么策略？
使用 cluster-proportional-autoscaler 维护一个预留的 GPU 节点池，通过 taint 和抢占调度，这些节点作为 placeholder 占住资源，当需要部署新服务时，这些 pod 会被抢占，从而避免扩容延迟。
kvcache 对负载均衡带来了什么挑战？有哪些解决思路？
kvcache 使得 LLM 推理服务不再是无状态的，给负载均衡带来挑战。解决思路包括 kvcache 的 live migration，例如 LMCache 支持通过 redis 等方式共享 kvcache，类似分布式 session 管理，从而简化负载均衡策略。
