Posted by on | Featured

你们首先推出了第一个基于大语言模型的功能模块，它运行正常，用户也非常喜欢。随后另一个团队又添加了另一个功能模块，该模块使用了不同的模型；而第三个团队则选择了完全不同的技术提供商来实施他们的功能。

六个月后，你们已经开发出了十四个微服务，每个微服务都拥有自己的API密钥，自行编写重试逻辑，并且以各自独特的方式出现故障。

没有人知道你们在令牌上花费了多少钱，也不知道是哪个服务频繁触发了速率限制。而当OpenAI出现问题时，所有系统都会随之陷入瘫痪。

这种情况每天都在各个工程团队中发生，其根本原因几乎总是相同的：人们过于急于利用大语言模型来推进开发，却忽略了那些在大规模应用环境中维持系统稳定性的基础设施。

幸运的是，有一种成熟的架构模式能够有效解决这些问题。如果你已经在使用Kubernetes，那么你已经走到了实施这一方案的一半路程之上。这种模式就是“大语言模型网关模式”，本文将向你详细解释它的含义、重要性以及如何实际应用它。

目录

什么是大语言模型网关模式？

大语言模型网关模式是一种架构设计方案，在这种模式下，来自应用程序的所有与大语言模型相关的API请求都会首先经过一个集中式的代理服务，之后才会被发送到外部服务提供商那里。可以把它看作是AI领域中的“API网关”，只不过它是专门为应对语言模型所带来的各种特殊挑战而设计的——比如令牌使用限制、流式响应处理、模型路由管理、语义缓存机制以及多服务提供商的备用方案等。

在你的集群中，所有服务并不会直接与 OpenAI 或 Anthropic 进行通信，而是都会通过一个内部网关来传递请求。这个网关负责处理身份验证、路由选择、速率限制、日志记录以及故障转移等功能。这样，你的应用程序服务就可以保持简洁，专注于业务逻辑的实现，而所有的运营相关问题则由网关来处理。

这种设计模式本身并不是什么新鲜事物。工程师们多年来一直使用 API 网关来管理 REST 请求。不过，LLM 网关的特殊之处在于，它们能够理解 LLM 请求的具体格式，包括令牌数量、模型参数、提示语的结构以及数据流的处理方式。

工作原理

Kubernetes 上的 LLM 网关的核心组件非常简单。其工作流程如下：

Kubernetes 上 LLM 网关的工作原理示意图

应用 Pod会使用标准的 OpenAI 兼容 API 格式向网关发送请求。因此，大多数现有的 LLM 客户端库都可以直接使用这种格式，你只需要将基础 URL 更改为指向你的内部网关服务即可。

网关服务会接收每一条传入的请求，对调用者进行身份验证，应用配置好的速率限制规则，检查缓存内容，根据路由规则选择合适的后端服务来处理请求，并在返回响应之前记录令牌的使用情况与延迟时间。

ConfigMap用于存储路由规则。例如：哪些模型应该处理被标记为“快速”的请求？如果主后端服务不可用，系统应该切换到哪个备用服务？所有这些配置信息都保存在 ConfigMap 中，而不是代码中，因此你可以随时更新路由规则而无需重新部署任何组件。

Secrets用于存储各个后端服务的 API 密钥。在集群中，只有网关服务需要访问这些密钥，应用 Pod 从未直接接触过这些凭证信息。

后端服务端点就是那些实际的 LLM API 接口，比如 OpenAI、Anthropic，或者是你在集群中运行的自托管 vLLM 实例，以及任何提供 OpenAI 兼容接口的服务提供商。

没有网关会带来的问题

要理解为什么这种设计模式如此重要，就需要看看如果不使用它会发生什么。

1. 密钥分散且缺乏集中管理

任何需要调用 LLM 的服务都离不开 API 密钥。在 Kubernetes 中，通常意味着需要为每个命名空间或每个部署创建一个 Secret 对象。

当这些密钥过期或被泄露时，你就得在大量的配置文件中逐一查找并更新它们。同时，也不存在一个统一的机制来撤销某些服务的访问权限或审计哪些服务正在调用哪些 API。

2. 无法了解成本或使用情况

大语言模型API是按令牌计费的。如果没有一个中央层来收集使用数据，你就无法准确判断是哪项服务导致了你的月度账单金额突然增加。

3. 在应用层面被绑定在特定提供商上

当你将https://api.openai.com直接嵌入到你的服务中时，想要更换提供商或将某些请求路由到更便宜的模型，就需要修改代码。仅仅为了改变处理某种类型请求的模型，你就必须重新部署整个应用程序。

4. 不支持缓存机制

许多大语言模型应用会反复发送语义相似或完全相同的请求。如果没有共享的缓存层，每次发送请求都会产生全部的令牌费用并导致延迟。而即使使用最基本的缓存技术，也能带来显著的效率提升。

随着团队规模的扩大以及越来越多的服务开始使用大语言模型，这些问题会变得更加严重。而“网关模式”通过一个简单的架构决策，就能解决所有这些问题。

在Kubernetes上部署大语言模型网关

在Kubernetes环境中，有几种工具可以充当大语言模型网关，包括LiteLLM Proxy、Portkey、OpenRouter，以及带有自定义过滤器的Envoy。

在接下来的讲解中，我们将使用LiteLLM Proxy。它配备了Helm模板，支持市面上主流提供商提供的上百种模型，并且提供了易于使用的管理界面，使得初始配置变得非常简单。

安全存储API密钥

首先，创建一个Kubernetes Secret来保存你的提供商API密钥。网关容器会将这些密钥作为环境变量来使用，这样一来，就无需将任何提供商的密钥放在应用程序容器内部了：

apiVersion: v1
kind: Secret
metadata:
  name: llm-gateway-secrets
  namespace: ai-platform
type: Opaque
stringData:
  OPENAI_API_KEY: "sk-..."
  ANTHROPIC_API_KEY: "sk-ant-..."

在ConfigMap中定义路由规则

路由配置决定了网关能够使用哪些模型以及如何访问这些模型。将这类配置保存在ConfigMap中，意味着你可以在不修改任何应用程序代码的情况下更新路由规则：

apiVersion: v1
kind: ConfigMap
metadata:
  name: llm-gateway-config
  namespace: ai-platform
data:
  config.yaml: |
    model_list:
      - model_name: gpt-4o
        litellm_params:
          model: openai/gpt-4o
          api_key: os.environ/OPENAI_API_KEY
      - model_name: claude-sonnet
        litellm_params:
          model: anthropic/claude-sonnet-4-20250514
          api_key: os.environ/ANTHROPIC_API_KEY
      - model_name: fast
        litellm_params:
          model: openai/gpt-4o-mini
          api_key: os.environ/OPENAI_API_KEY

通过这种配置，集群中的任何应用程序都可以使用标准的OpenAI客户端格式，通过http://llm-gateway.ai-platform.svc.cluster.local这一地址访问网关，而无论实际上提供该服务的是哪家供应商。

扩展网关的规模

由于网关属于无状态架构，因此进行水平扩展非常简单。你可以使用HorizontalPodAutoscaler根据CPU利用率或请求量来自动调整网关的规模：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: llm-gateway-hpa
  namespace: ai-platform
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: llm-gateway
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

建立监控机制

如果无法监控某个网关，那就意味着无法信任它；因此，在将其投入生产环境之前，花时间建立监控机制是值得的。

LiteLLM提供了以Prometheus格式输出的/metrics接口。如果你使用了Prometheus Operator，就可以使用标准的ServiceMonitor来收集这些数据；或者直接配置Prometheus来监控该网关服务。

在日常运营中，最需要关注的指标包括：每个模型每秒处理的请求数量、请求延迟的百分位数、各供应商的错误率以及缓存命中率。

一旦Prometheus开始收集这些数据，你就可以使用Grafana制作仪表板，从而按调用者、模型和时间段来详细分析各项指标。这样，工程管理人员和财务团队就能清楚地了解相关成本情况了。而且，一旦建立了数据采集机制，设置这些监控工具其实并不需要花费太多精力。

如果你在集群中运行了OpenTelemetry收集器，还可以配置网关，使其为每个LLM请求生成追踪数据。这样你就可以详细了解从用户触发请求开始，到服务端响应结束这一整个过程中的延迟情况。因此，当发现某些操作出现延迟时，你可以立即判断问题是出在你的服务上、网关上，还是上游的供应商那里。

多供应商路由机制

一个设计良好的网关会根据一些明确定义且可配置的规则，将请求转发到不同的供应商那里。这意味着，即使需要更换使用的模型，也不必重新部署整个系统。

语义缓存机制

与仅仅缓存内容完全相同的提示不同，语义缓存会利用嵌入向量之间的相似性来判断两个看似不同的提示实际上是否在询问相同的问题。这种机制能够显著减少不必要的API调用次数。

针对每个消费者的速率限制

网关应允许您为每个团队、每个命名空间或每个应用程序设置令牌预算和请求限额，这样就不会有某个服务因过度消耗资源而影响整个集群的正常运行，也不会导致成本不受控制地上升。

回退机制与故障转移

当主提供者出现故障或其延迟超过可接受的范围时，网关应自动切换到预设的备用方案。这种集中式的处理方式能够有效解决那些在单个服务中难以实现的正确逻辑问题。

令牌使用情况追踪

每条请求都应生成详细的记录，其中包含输入令牌、输出令牌、使用的模型、调用者的身份信息以及响应延迟等数据。这些信息能为工程管理人员提供关于AI系统资源消耗情况的清晰数据，帮助他们做出有效的决策。

总结

“大语言模型网关模式”有效解决了一系列所有大规模使用语言模型的团队都会遇到的运营问题：分散管理的密钥配置、隐藏的成本开销、不一致的故障处理机制，以及供应商锁定的现象——这些问题的根源都是基础设施相关的问题渗入了本不应涉及这些细节的服务中。

Kubernetes平台上的集中式网关为应用程序开发团队提供了稳定且与具体供应商无关的接口，同时也让平台维护团队能够有效地控制成本并保障系统的可靠性。当某个提供者在夜间发生故障时，预设的备用方案会自动生效，而无需有人手动进行处理。

建议您先从使用LiteLLM Proxy开始，连接Prometheus监控数据源，构建一个简单的Grafana仪表盘，然后亲身体验这种集中式管理机制带来的高效效果。一旦您了解了实际应用中这种管理方式的优势，就很难再回到传统的处理方式去了。

Related Posts:

Tags:
Comments are closed.