在Kubernetes中部署LiteLLM
内容提要
本文介绍了作者搭建LiteLLM网关，统一管理多个大模型接口，供Hermes使用。配置了PostgreSQL、Redis、Traefik和ArgoCD，并分享了Kustomize管理配置、Redis缓存及部署中的坑。文章强调通过模型映射切换底层模型，无需改动客户端，并计划后续补充健康检查等功能。
延伸解读
模型映射的灵活性
通过LiteLLM，作者将不同渠道的模型统一为OpenAI兼容接口，并定义了main-fast、main-pro、main-vision等入口。客户端只需固定使用这些入口名，切换底层模型时仅需在LiteLLM后台修改映射，无需改动客户端配置。这种设计降低了模型更换的成本，但也要求维护好映射关系，避免入口名与实际模型脱节。
缓存与状态共享的区分
文中强调cache_params用于缓存模型响应，而router_settings中的Redis用于共享路由状态（如限流计数、模型冷却）。理解这一区别对配置Redis至关重要：前者影响响应速度和token消耗，后者影响多副本部署时的状态一致性。若只配置前者，多副本时路由状态可能不一致。
配置管理的注意事项
作者使用Kustomize的configMapGenerator自动生成带哈希的ConfigMap，配置变更可触发滚动更新。但当前敏感信息（如API Key）仍直接写在config.yaml中，作者建议改用Secret注入。此外，LITELLM_SALT_KEY必须固定，否则数据库中的模型凭据将无法解密。部署时建议先手动同步，确保变更可控。
Q&A
LiteLLM 在 Kubernetes 中部署时，如何实现配置变更自动触发滚动更新？
使用 Kustomize 的 configMapGenerator 从 config.yaml 生成 ConfigMap，生成的名称会包含内容哈希。当 config.yaml 变化时，哈希变化，Deployment 引用的 ConfigMap 名称随之改变，从而触发 Pod 模板更新，实现滚动发布。
LiteLLM 中 Redis 缓存和 router_settings 中的 Redis 配置有什么区别？
cache_params 中的 Redis 用于缓存模型响应，相同请求可直接返回缓存结果，节省时间和 token。router_settings 中的 Redis 用于共享路由状态，如限流计数和模型冷却，为多副本部署做准备。
在 LiteLLM 中，如何实现切换底层模型而不修改客户端配置？
在 LiteLLM 的管理页面或通过 API 修改模型映射，将逻辑模型名（如 main-fast）指向不同的真实模型。客户端只需固定使用逻辑模型名，无需改动。
LiteLLM 部署中，为什么建议将敏感配置放入 Secret 而不是 ConfigMap？
ConfigMap 通常以明文存储，而 Secret 可以加密存储敏感信息，如 API 密钥、数据库密码等。文章建议将敏感配置迁移到 Secret 以提高安全性，当前示例中直接写在 config.yaml 中仅适用于私有仓库。
LiteLLM 中 store_prompts_in_spend_logs 配置有什么风险？
该配置会将请求和响应写入 Spend Logs，便于排查问题，但会保存真实对话内容。多人使用或处理敏感数据时，存在隐私泄露风险，建议关闭或设置日志保留时间。
LiteLLM 缓存命中率低的原因是什么？如何提高？
缓存命中率低通常是因为请求内容变化，如 system prompt 带时间、随机 ID，或多轮聊天历史不同。提高命中率的方法包括：对稳定内容（如 FAQ、翻译）使用缓存，避免在 prompt 中加入动态元素，合理设置 TTL。
LiteLLM 中 LITELLM_SALT_KEY 的作用是什么？为什么需要固定？
LITELLM_SALT_KEY 用于加密和解密数据库中存储的模型凭据。如果更换 Salt Key，旧凭据将无法解密，导致模型配置失效，因此必须固定。
