8. 企业生产实践

一句话理解：生产环境的 LLM Gateway 要解决的不是“能不能跑”，而是“能不能在高并发、多租户、多区域、多供应商的情况下稳定、低成本、可审计地跑”。

部署形态选择

独立服务（推荐大多数团队）

text

Client -> DNS / Global Load Balancer -> LLM Gateway Cluster -> Providers

适用：

多个业务方共享模型资源。
需要统一成本核算、审计、配额。
团队有运维网关的经验。

高可用要点：

至少 2 个副本，跨可用区部署。
使用 Redis 共享限流、熔断、会话状态。
配置中心支持热更新。
日志、指标、tracing 集中收集。

Sidecar

text

App Pod [App Container + Gateway Sidecar]

适用：

低延迟要求极高。
每个应用需要独立的配额与策略。
已有 Service Mesh 基础设施。

注意：

配置碎片化，需要统一的配置分发机制。
资源占用随 Pod 数线性增长。
成本聚合需要把 sidecar 指标统一汇总。

边缘网关

Cloudflare AI Gateway、AWS API Gateway 等属于此类。深度 AWS 生态的团队还可以评估 AWS Bedrock AgentCore Gateway（2025 年 10 月 GA）：全托管地把 REST API / Lambda / OpenAPI / Smithy 转为 MCP 工具，用 Cedar 策略做默认拒绝的工具级访问控制，并在网关边界集成 Bedrock Guardrails（2026 年 6 月 GA）；按调用量计费（约 $0.005/千次调用），适合不想运维网关但要求企业级工具治理的场景。

适用：

希望零运维、全球加速。
需要边缘缓存与边缘安全。
不担心供应商锁定。

Kubernetes 部署示例

以 LiteLLM Proxy 为例，最小部署：

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-gateway
spec:
  replicas: 3
  selector:
    matchLabels:
      app: llm-gateway
  template:
    metadata:
      labels:
        app: llm-gateway
    spec:
      containers:
        - name: gateway
          image: ghcr.io/berriai/litellm:main-latest   # 生产建议锁定具体版本（如 v1.105.x）并跟进安全补丁
          args: ["--config", "/etc/litellm/config.yaml"]
          ports:
            - containerPort: 4000
          volumeMounts:
            - name: config
              mountPath: /etc/litellm
          envFrom:
            - secretRef:
                name: llm-gateway-secrets
      volumes:
        - name: config
          configMap:
            name: litellm-config
---
apiVersion: v1
kind: Service
metadata:
  name: llm-gateway
spec:
  selector:
    app: llm-gateway
  ports:
    - port: 80
      targetPort: 4000

Secret 管理：

yaml

apiVersion: v1
kind: Secret
metadata:
  name: llm-gateway-secrets
type: Opaque
stringData:
  OPENAI_API_KEY: "sk-..."
  AZURE_API_KEY: "..."

生产上更推荐使用 External Secrets Operator 从 Vault/AWS Secrets Manager 同步。

多租户与配额

多租户是 LLM Gateway 的核心生产场景。常见隔离维度：

维度	说明	限流键示例
Tenant	团队/部门级别	`tenant:team-a`
Application	应用级别	`tenant:team-a:app:chatbot`
User	用户级别	`tenant:team-a:user:u123`
Model	模型级别	`tenant:team-a:model:gpt-4o`

配额策略：

硬配额：超过即拒绝，保护上游。
软配额：超过后允许但告警/降速。
预算上限：按美元设置月度预算，超支后禁止调用昂贵模型。

与 vLLM / Triton 集成

vLLM 作为上游

vLLM 自带 OpenAI-compatible server：

bash

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --tensor-parallel-size 1 \
  --port 8000

Gateway 配置：

yaml

providers:
  vllm-llama:
    kind: openai
    base_url: http://vllm-service:8000/v1
    models: [llama-3.1-8b]

Triton 作为上游

Triton 提供 OpenAI-compatible frontend（2025 年底进入 stable）。Gateway 可直接把它当作 OpenAI provider：

yaml

providers:
  triton-llm:
    kind: openai
    base_url: http://triton-service:8000/v2/models/ensemble/generate
    models: [triton-llama-3.1-8b]

如果 Triton 暴露的是 gRPC，则 Gateway 需要额外做 gRPC ↔ HTTP 转换。

KV-Cache 感知路由（2025 后自托管集群推荐）

自托管 vLLM 集群规模上来后，建议在网关上启用 Gateway API Inference Extension（GIE）风格的推理感知路由：

vLLM 开启 prefix caching（--enable-prefix-caching，新版本默认开启），并让副本暴露指标（vLLM v0.10+ 支持 KV cache 事件流，可做“精确模式”路由）。
网关侧部署 Endpoint Picker（如 llm-d-inference-scheduler、NVIDIA Dynamo EPP，或阿里云推理扩展网关的托管实现）。
按“KV 前缀命中 + 队列深度”打分选副本；连续多轮 Agent 对话天然命中同一前缀，TTFT 收益显著（llm-d 报告热命中 TTFT 降低约 88%）。
EPP 决策增加约 1~2ms 开销，需评估是否小于收益；小规模集群（个位数副本）用 AdaptiveScore 类打分负载均衡即可，不必上完整 EPP。

MCP Gateway 生产实践（2025-2026 新增）

面向 Agent 的工具治理是今年生产落地的新重点：

最小安全基线

deny-by-default 工具白名单：默认拒绝全部工具，按业务逐个放行；不要默认放开上游 MCP Server 的全部能力。
工具级身份隔离：每个调用方（应用 / 用户）使用独立虚拟 key，工具权限挂在 key 上而不是网关全局。
关闭默认 master key，保持版本更新：2026 年披露的 CVE-2026-59822（LiteLLM MCP 认证绕过，影响 < 1.84.0）表明 MCP 端点是新的攻击面，升级与 key 轮换必须进入常规运维；2026 年 10 月最新稳定版为 v1.105，v1.104 起已强制 master key 校验并默认关闭 stdio MCP。
stdio MCP 默认关闭：远程 Gateway 只暴露 HTTP 类 MCP Server；stdio 仅用于受信内网。
工具调用审计：按 Mcp-Method / 工具名记录调用日志，高危工具（支付、删除类）额外告警。

协议与兼容

新旧 MCP 协议（modern 无状态 HTTP Tools / legacy 握手 + 会话）并存期，用支持双向桥接的网关（Higress v2.2.4+、LiteLLM）避免 Agent 与 Server 协议错配。
存量 REST API 可通过 Higress 的“零代码转 MCP Server”能力快速接入，避免为每个服务手写 MCP 封装。

语义缓存生产实践（2025-2026 新增）

先精确、后语义：Redis 精确缓存成本几乎为零，语义缓存每次要付 embedding 费用；级联能省则省。
阈值与场景匹配：FAQ、摘要、代码解释等“答案稳定”的场景适合低阈值（0.85~0.9）；Agent 多轮对话、强上下文依赖的场景建议高阈值或禁用，防止“串味”。
敏感请求不缓存：按租户/请求头标记 no-cache，PII 与商业机密直接跳过两级缓存。
观测命中率：把 cache_hit_total{mode="exact|semantic"} 纳入大盘，命中率低于 10% 时反思场景是否适合。
注意插件档位：Kong 的 ai-semantic-cache、APISIX 的 ai-cache 等能力在不同版本/许可下可用性不同，选型前确认。

多区域与多供应商降级

生产推荐设计 fallback 链：

text

Primary   : Azure OpenAI (us-east)
Backup 1  : OpenAI (global)
Backup 2  : Anthropic Claude (us-west)
Backup 3  : 自研 vLLM (on-prem)

触发条件：

HTTP 5xx 或 429。
延迟超过 SLO（例如 TTFT > 2s）。
内容审查拒绝（不可重试，直接返回）。

实现方式：

Gateway 维护每个 region/provider 的健康状态。
跨 region 路由时优先选择地理最近的 healthy provider。
主 region 故障时，DNS 或 Gateway 自动切到备用 region。

成本优化实践

模型降级：默认用便宜模型处理简单任务，复杂任务才用贵模型。
缓存：重复 prompt 直接返回缓存结果，减少调用。
批量调用：把多个小请求合并成 batch，降低 per-request 开销。
智能路由：按 prompt 长度/复杂度选择 cheapest provider；更进一步用自动路由（如 LiteLLM Auto Router 的 Fuse/Capability 策略）按成本/延迟/能力自动选模，并先以 shadow eval 量化效果再切流。
监控成本异常：按应用/用户设置预算告警，防止某处 burst。
跟上 2026 年的计费细化：缓存读取折扣（主流厂商约 90%，DeepSeek 约 98%）、缓存写入费（如 1.25×）、长上下文附加费已成常态，计费从 input/output 两档变成 input / cached input / cache write / output / reasoning 多档。网关成本核算必须按档计量并透出对应指标（LiteLLM 内置价格表随版本跟进降价，v1.96 即跟进 GPT-5.6 降价；Agent Router v1.1 起支持跨 provider token 计数）；同时可利用厂商错峰计价（LiteLLM v1.101 off-peak pricing）与批量计费（v1.99 end-to-end batch billing）进一步降本。

可观测体系

生产需要三类可观测数据：

类型	工具	关注点
Metrics	Prometheus + Grafana	QPS、延迟、token、成功率、成本
Logs	Loki / ELK	请求详情、错误堆栈、审计
Traces	OpenTelemetry + Jaeger	请求在网关与上游的完整链路

关键告警：

5xx 率 > 1% 持续 5 分钟。
P99 延迟 > 阈值。
某 provider 失败率突增。
租户配额使用接近上限。

安全与合规

Secret 管理：API key 不存代码、不存镜像，使用 Vault / KMS。
传输安全：TLS 1.2+，内部服务间 mTLS。
内容安全：PII 过滤、敏感词检测、越狱提示识别。
审计日志：记录 who/when/what model/how many tokens。
数据驻留：某些合规场景要求数据不出境，Gateway 需要按 tenant 路由到特定 region。

常见踩坑

踩坑	原因	解法
流式响应中断无法重试	chunk 已发送给客户端	重试窗口只放在首包前；建立连接超时设置合理
限流键太粗	一个租户打满全局 bucket	多维度限流：tenant + model + user
fallback 模型能力不匹配	备用模型输出质量差	明确 fallback 模型能力边界，必要时返回错误
上游 429 导致重试风暴	没有 jitter / backoff	指数退避 + jitter + 按 Retry-After 等待
配置热更新导致状态不一致	部分实例先加载新配置	使用配置版本号 + 原子切换
日志泄露敏感信息	prompt 含 PII	日志脱敏，只记录 token 长度与 hash
MCP 工具被越权调用	默认放开上游全部工具 / 默认 master key 未关	deny-by-default 白名单 + 虚拟 key 隔离 + 关闭 master key（参考 CVE-2026-59822）
成本核算与账单对不上	只按 input/output 两档估算，忽略 cached input / cache write / reasoning 分档计费	按档计量并透出指标，价格表随厂商调价更新（2026 年缓存折扣与附加费频繁变化）
语义缓存“串味”	相似度阈值过低或场景上下文依赖强	提高阈值、按租户隔离缓存命名空间、敏感请求禁用缓存

本章小结

生产级 LLM Gateway 需要在部署形态、多租户配额、上游集成、多区域降级、成本控制、可观测、安全合规等方面做系统设计。网关本身不生产模型能力，但它是模型能力能否稳定、经济、合规地交付给业务的关键层。

参考来源

8. 企业生产实践 ​

部署形态选择 ​

独立服务（推荐大多数团队） ​

Sidecar ​

边缘网关 ​

Kubernetes 部署示例 ​

多租户与配额 ​

与 vLLM / Triton 集成 ​

vLLM 作为上游 ​

Triton 作为上游 ​

KV-Cache 感知路由（2025 后自托管集群推荐） ​

MCP Gateway 生产实践（2025-2026 新增） ​

最小安全基线 ​

协议与兼容 ​

语义缓存生产实践（2025-2026 新增） ​

多区域与多供应商降级 ​

成本优化实践 ​

可观测体系 ​

安全与合规 ​

常见踩坑 ​

本章小结 ​

8. 企业生产实践

部署形态选择

独立服务（推荐大多数团队）

Sidecar

边缘网关

Kubernetes 部署示例

多租户与配额

与 vLLM / Triton 集成

vLLM 作为上游

Triton 作为上游

KV-Cache 感知路由（2025 后自托管集群推荐）

MCP Gateway 生产实践（2025-2026 新增）

最小安全基线

协议与兼容

语义缓存生产实践（2025-2026 新增）

多区域与多供应商降级

成本优化实践

可观测体系

安全与合规

常见踩坑

本章小结