vLLM部署实战重难点

Kubernetes + 容器化部署

• vLLM官方docker镜像: vllm/vllm-openai
  • 这是官方提供的 Docker 镜像，可以用来快速部署 vLLM 服务，便于容器化管理。
• 实战: helm chart 部署
  • 本地集群: 使用 Helm 安装和配置 vLLM 在本地 Kubernetes 集群中，方便调试和开发。
  • 云端集群: 在云端（如 AWS、Google Cloud、Azure 等）部署 vLLM 集群，扩展性和高可用性较好。
• CPU/内存/GPU 如何分配
  • 根据集群的资源需求，合理分配 CPU、内存和 GPU，确保 vLLM 实例的高效运行，特别是在处理大规模请求时，GPU 资源尤为关键。

vLLM 状态监测

• /health 以及 /metrics 端口用于监控实例状态
  • /health 用于检查实例是否存活，/metrics 提供监控指标，帮助开发人员和运维人员及时掌握系统运行状态。
• 核心 metrics 监测
  • 通过监控一些关键指标，可以实时了解系统的负载和性能。
  • num_waiting_request > 0: 如果 vLLM 无法及时处理请求，请求就会排队，此时需要通过告警机制来提醒管理员。
  • num_running_requests: 反映当前系统的负载，随着请求量的增加，vLLM 会动态调整 batch size 来优化性能。
  • SLO 相关指标:
    • e2e_request_latency_seconds: 请求延迟，常见 0.5s 为标准值，用来衡量服务的响应速度。
    • time_per_output_token_seconds: 从请求到首个 token 生成的时间，表示生成响应的速度。
    • prompt/generation_tokens_total: 每秒生成的 token 数量，反映了 vLLM 处理请求的吞吐能力。
• 实战
  • 通过实际监控工具，如 Prometheus 配合 Grafana，来展示和分析这些指标，确保 vLLM 服务的高效运行。

负载均衡与路由算法

• 因为可能会部署多个 vLLM，在生产环境中运行，压力和请求处理差异较大
  • 负载均衡: 需要判断哪些节点的负载过高，哪些节点已经无法再处理请求，通过负载均衡策略确保请求均匀分配。
  • 路由算法实例:
    • Prefix-caching: 一种重要概念，是需要路由的原因。前缀缓存存储了模型对以前遇到的前缀进行计算的中间结果，因此当相同的前缀再次出现时，模型不需要重新计算整个序列，而只需检索缓存的结果。这种技术可以显著地加快推理时间，特别是在处理长序列或执行具有相似前缀的多个推理的时候。
    • Round-robin: k8s 默认的路由算法，它会把请求均匀地分发到所有的服务器，但可能会将同一 session 的请求分配到不同的节点，这可能会影响性能。
    • Session-based: 为了提高性能和避免重复计算，同一用户的请求应该尽量路由到同一个节点，避免重新加载和处理历史记录。
    • 最大前缀匹配: 通过将请求拆分成小块，使用哈希值匹配请求和历史记录，从而找到最合适的节点进行处理。
• Session 长度较长时: 参考 Prebel UCSD Yiying Zhang 的论文，或者使用强化学习或其他 AI 算法来预测和优化路由，确保较长 session 的高效处理。

自动扩容/压容

• 在集群中流量波动大（用户多或少）
  • 实例: 通过 Kubernetes 的 Horizontal Pod Autoscaler (HPA) 和 Prometheus Adapter 监控资源使用情况，自动增加或减少 pod 数量，以应对不同的流量负载。
  • 何时触发: 观察关键指标如 CPU 使用率、内存消耗、请求数等，动态调整集群规模，确保在流量增加时能够平稳扩展，在流量减少时节约资源。

容灾处理

• 不仅是节点断了后重启，可能会对业务逻辑产生影响
  • 路由层的处理: 当节点宕机时，路由算法需要动态更新，避免将请求路由到不可用的节点。
    • 业务层异常捕获：通过在业务层捕获异常并进行重试或转发，避免服务中断。
    • 动态更新路由：当节点失效时，实时更新路由，确保请求能够被有效处理。
    • 重新发送请求：确保请求不会丢失，及时重新发送到可用节点。
  • 在业务端的一种挑战
    • 生成到一半时的中断问题：如果在生成 token 时节点宕机，需要能够将中间状态保存并转移到其他节点继续处理，确保任务不被中断。