AI Gateway、AI Nacos：大模型应用从 Demo 到生产，中间差一个治理层

昙花一现。

180人浏览 · 2026-07-18 21:57:44

昙花一现。 · 2026-07-18 21:57:44 发布

小刘檀木的大模型日记 · Day18 · AI Gateway、AI Nacos-帮普通人把AI学进简历系列

Day18|AI Gateway、AI Nacos：大模型应用从 Demo 到生产，中间差一个治理层

封面：系列统一封面大模型.png

前言：一次“换模型改代码”的小事故

上周四晚上 10 点半，一个朋友给我发消息，说他们的 AI 客服准备第二天灰度。

结果临上线前，老板突然来了一句：“把模型从 A 换成 B，成本便宜一点，效果也试试。”

这事听起来很小：改个 base_url，换个 model，再改一把 api_key。二本小透明当年刚做工程时，也觉得这不就是三行配置的事。

然后事故就来了。

测试环境改了，生产环境没改；生产环境改了，灰度策略没改；灰度策略改了，日志里又分不清到底是哪一路模型在回答。

这就是大模型应用从 Demo 走向生产时，最容易被忽略的一层：

模型调用也需要治理。

应用直连多个大模型与接入 AI Gateway 和 Nacos 控制面的架构对比

今天这篇，我们聊两个越来越重要的词：AI Gateway 和 AI Nacos。

先记一个粗暴版本：

AI Gateway 管入口，Nacos 管控制面。一个负责请求怎么进来、怎么转发；一个负责配置怎么变、服务怎么发现、工具怎么注册。

PART 01：AI Gateway 管入口——把模型调用从业务代码里拆出来

很多人听到 Gateway，第一反应是“网关不就是反向代理吗？”

放在传统 Web 系统里，这句话不算错。但到了 AI 应用里，Gateway 的价值会明显变大。

因为大模型调用背后多了几层麻烦：

模型供应商多：OpenAI、Claude、通义、DeepSeek、本地 LLaMA
调用成本高：一个用户狂点刷新，钱真的会烧
返回时间长：流式输出、超时、重试都要处理
内容有风险：Prompt 注入、敏感词、越权工具调用
观测很关键：你得知道哪个模型贵、慢、错得多

所以 AI Gateway 不只是转发请求，更像模型调用的统一入口。

AI Gateway 统一代理多模型和 MCP Server 的流量图

它至少能帮你做几件事：

统一鉴权：业务方只拿内部 token，不直接接触模型厂商 key
模型路由：简单问题走便宜模型，复杂问题走强模型
限流熔断：防止某个用户或某个应用把额度打爆
观测统计：记录 token、延迟、错误率和成本
安全治理：对输入输出做内容检查，对工具调用做权限控制

这样业务代码就不用写一堆 if model == ...。

它只需要面对一个统一入口。

比如用 OpenAI 兼容协议，业务代码可以长这样：

from openai import OpenAI

client = OpenAI(
    api_key="internal-app-token",
    base_url="https://ai-gateway.example.com/v1",
)

resp = client.chat.completions.create(
    model="customer-service-fast",
    messages=[
        {"role": "system", "content": "你是企业客服助手，回答必须基于知识库。"},
        {"role": "user", "content": "我的发票怎么重新开？"},
    ],
)

print(resp.choices[0].message.content)

注意这里的 model="customer-service-fast"，它不一定是真实模型名，而是内部逻辑名。真正转到 gpt-4.1-mini、qwen-plus、deepseek-chat，还是本地 LLaMA，由 Gateway 的路由策略决定。

这就像你去饭店点“今日套餐”，不用关心后厨今天是哪口锅炒的。对业务代码来说，稳定最重要。

PART 02：Nacos 管控制面——配置、服务、MCP 工具都要能动态发现

那 Nacos 在这里干嘛？

如果说 AI Gateway 是流量入口，那 Nacos 更像控制面。

传统微服务里，Nacos 常做两件事：服务发现 和 配置管理。

服务发现解决“谁还活着、地址在哪”；配置管理解决“参数怎么改、改完谁生效”。到了 AI 应用，对象变了。

以前你注册的是订单服务、用户服务。现在你还可能注册：

模型服务：llama-local-8b、qwen-plus、embedding-service
MCP Server：文件系统工具、数据库查询工具、工单工具
Prompt 模板：客服 prompt、审核 prompt、总结 prompt
Agent 配置：可用工具、模型策略、超时参数

这就是 AI Nacos 值得关注的地方：它不只是管传统微服务，也开始往 AI Registry / MCP Registry / Agent 管理 这类方向延伸。

AI Gateway 数据面与 Nacos 控制面的分工图

分工可以这样理解：

Gateway：每一次请求怎么进、怎么鉴权、转给谁、怎么限流
Nacos：有哪些模型/工具可用、配置是什么、变更怎么推送

一个管“跑在路上的车”，一个管“路网和信号灯”。

比如模型路由策略，不应该散落在每个应用仓库里。

它更适合放进配置中心：

routes:
  customer-service-fast:
    primary: qwen-plus
    fallback: deepseek-chat
    max_input_tokens: 8000
    timeout_ms: 15000
    rules:
      - when: "intent == 'refund' and vip == true"
        model: gpt-4.1-mini
      - when: "input_tokens < 1000"
        model: qwen-turbo

这段配置表达的是：业务仍然调用 customer-service-fast，但背后可以按意图、用户等级、输入长度去路由。

更关键的是：你可以改配置，而不是重新发版。

这对生产系统太重要了。

上线后你会经常遇到这种情况：