当生成式 AI 从零散实验扩展到 5,000 多名内部用户时，问题就不再只是“选择哪个模型”。平台团队还要统一接入方式、隔离供应商差异、治理 Agent 工具调用，并持续在准确率、延迟和成本之间做取舍。
DoorDash 分享的演进路径很有代表性：早期优先使用外部模型供应商快速验证需求，随后逐步引入开放权重模型，并将 LLM Gateway 与 Agent Gateway 作为不同层次的基础设施能力。这里真正值得借鉴的，不是某个模型名称，而是平台边界如何随着使用规模变化。
Vendor-first 适合起步，但不应该成为永久架构
在需求还不明确时，直接使用供应商 API 往往是最快的做法。团队不必先建设 GPU 集群、推理服务和模型发布流水线，就可以验证客服辅助、文本摘要、知识检索或代码生成等场景。
这种方式也容易形成隐性耦合：
- 业务代码直接依赖某家供应商的请求与响应格式；
- Prompt、重试、超时和安全规则分散在各个应用里；
- 模型成本难以按照团队、项目和环境归集；
- 切换模型时，需要同时修改多个业务系统；
- 新增开放权重模型后，两套调用方式无法统一治理。
因此，更稳妥的核心赌注是先稳定“平台契约”，再允许底层模型变化。应用只向内部 Gateway 提交任务、延迟目标和质量等级，不直接决定具体模型。供应商模型、开放权重模型以及未来的新推理后端，都成为可替换的执行资源。
一个典型请求可以抽象为：
{
"task": "support_reply",
"prompt": "请根据订单状态生成回复",
"quality_tier": "high",
"max_latency_ms": 2500,
"contains_sensitive_data": true
}
这里的关键不是字段名称，而是将业务意图和模型实现解耦。调用方表达“我要什么”，平台负责决定“由谁执行”。
LLM Gateway 与 Agent Gateway 解决的是两类问题
LLM Gateway 主要管理模型调用。它通常承担认证、限流、路由、重试、降级、配额、日志和成本归集等职责。无论后端是商业 API 还是内部部署的开放权重模型，上层应用都使用同一套协议。
Agent Gateway 的治理范围更大。Agent 不只生成文本，还可能搜索文档、查询数据库、调用内部服务，甚至触发退款、修改配置等有副作用的操作。因此，Agent Gateway 需要关注：
- 哪个 Agent 可以使用哪些工具；
- 工具参数是否满足策略约束；
- 高风险操作是否需要人工确认；
- 一次任务允许执行多少步、消耗多少预算；
- 如何记录完整轨迹，支持审计和故障复盘；
- 如何阻止模型把不可信输入直接转换成工具调用。
把两者混成一个简单反向代理，会掩盖风险边界。模型网关控制“生成请求”，Agent 网关控制“行动权限”。尤其涉及写操作时，不能仅依靠 Prompt 中的一句“请谨慎执行”。
一个可以运行的最小路由网关
下面是一个教学用的 FastAPI 示例。它不会真正调用模型，而是模拟两个后端，重点展示统一契约、策略路由和可观测元数据。实际落地时，可以将 invoke_model 替换为供应商 SDK、OpenAI 兼容接口或内部推理服务。
在 Linux 或 macOS 中执行：
mkdir genai-gateway-demo && cd genai-gateway-demo
python3 -m venv .venv
source .venv/bin/activate
pip install fastapi uvicorn
cat > app.py <<'PY'
from typing import Literal
from uuid import uuid4
from fastapi import FastAPI
from pydantic import BaseModel, Field
app = FastAPI(title="Internal GenAI Gateway")
class GenerateRequest(BaseModel):
task: str
prompt: str = Field(min_length=1, max_length=20000)
quality_tier: Literal["standard", "high"] = "standard"
max_latency_ms: int = Field(default=3000, ge=100, le=30000)
contains_sensitive_data: bool = False
def choose_backend(req: GenerateRequest) -> str:
# 示例策略：敏感数据留在内部部署的模型中。
if req.contains_sensitive_data:
return "open-weights-internal"
# 高质量任务优先走能力更强的供应商模型。
if req.quality_tier == "high" and req.max_latency_ms >= 2000:
return "vendor-premium"
return "open-weights-internal"
def invoke_model(backend: str, prompt: str) -> str:
# 演示环境不连接真实模型；生产环境应在这里调用推理后端。
return f"[{backend}] simulated response for: {prompt[:80]}"
@app.post("/v1/generate")
def generate(req: GenerateRequest):
request_id = str(uuid4())
backend = choose_backend(req)
output = invoke_model(backend, req.prompt)
return {
"request_id": request_id,
"task": req.task,
"backend": backend,
"output": output,
"policy": {
"quality_tier": req.quality_tier,
"sensitive_data": req.contains_sensitive_data,
},
}
PY
uvicorn app:app --reload --port 8000
另开一个终端测试：
curl -s http://127.0.0.1:8000/v1/generate \
-H 'Content-Type: application/json' \
-d '{
"task": "support_reply",
"prompt": "根据订单延迟信息生成一段客服回复",
"quality_tier": "high",
"max_latency_ms": 2500,
"contains_sensitive_data": true
}' | python3 -m json.tool
生产化时，至少还要补上身份认证、租户配额、流式响应、超时与熔断、Prompt 脱敏、缓存、指标采集以及不可篡改的审计记录。路由规则也不应永远硬编码在 Python 中，可以迁移到带版本的配置或策略服务，并支持灰度发布和快速回滚。
准确率、延迟和成本必须放在同一个评估闭环里
只比较模型排行榜，很难做出有效的平台决策。内部平台面对的是不同任务：摘要任务可能重视速度，客服回复更看重事实一致性，执行型 Agent 则必须优先控制越权和误操作风险。
可以为每类任务维护独立评测集，并在发布前同时检查：
| 维度 | 可观测指标 | 典型决策 |
|---|---|---|
| 准确率 | 任务成功率、事实错误率、人工评分 | 是否允许替换现有模型 |
| 延迟 | 首 Token 延迟、端到端 P95/P99 | 是否启用小模型或降级路径 |
| 成本 | 单请求成本、单成功任务成本、GPU 利用率 | 选择供应商 API 还是自托管 |
| 安全 | 越权调用率、敏感数据暴露、策略拦截率 | 是否允许 Agent 执行写操作 |
| 稳定性 | 超时率、重试率、后端可用性 | 是否需要多后端容灾 |
“单成功任务成本”通常比“每百万 Token 价格”更接近业务价值。一个便宜但需要多次重试的模型，最终可能比价格更高、一次完成任务的模型更昂贵。
开放权重模型也不是天然低成本。它会引入 GPU 容量规划、批处理、量化、版本升级、推理框架维护和峰值流量调度等工作。只有将这些运维成本与外部 API 费用放到同一模型中比较，迁移决策才有意义。
采用时先守住四条边界
从供应商优先架构走向多模型平台，可以按以下顺序推进：
- 统一调用契约：先让应用脱离特定 SDK，再讨论模型替换。
- 建立任务级评测：没有稳定评测集，就无法判断路由调整是优化还是退化。
- 分离模型调用与工具执行：LLM Gateway 管生成，Agent Gateway 管权限和行动。
- 让路由可观测、可回滚：每次响应都应能追溯到模型版本、策略版本和调用链。
对 5,000 多名内部用户而言，平台价值不只体现在少写几行 SDK 代码。更重要的是，团队可以在不要求所有业务同时改造的情况下，更换模型、调整成本结构，并为越来越自主的 Agent 设置明确的安全边界。