Apache APISIX 提供的 AI 插件，核心目的是让 API Gateway 从传统的流量代理层，升级为具备 AI 流量治理能力的网关。
它们并不是用来训练模型，也不是用来实现 Agent，而是把原本需要业务服务自行实现的一部分 AI 基础设施能力下沉到网关层。
可以把它理解为：在模型服务前面增加一层 AI 专用中间件，统一处理模型路由、请求转换、访问控制、缓存、限流和可观测性。
https://apisix.apache.org/plugins/#AI
一、AI 插件主要能做什么
我把它们分成六类：
| 插件 | 核心能力 | 实际应用场景 |
|---|---|---|
| ai-proxy | 统一代理不同厂商的 LLM API | 用统一入口访问 DeepSeek、OpenAI、Claude、Gemini |
| ai-proxy-multi | 多模型负载均衡、重试、故障转移、健康检查 | 多个 DeepSeek 渠道按策略分流，故障时自动切换 |
| ai-rate-limiting | 基于 Token 用量进行限流 | 限制用户每天使用 100 万 Token |
| ai-cache | LLM 响应缓存，支持精确匹配和语义匹配 | 重复问题直接返回缓存，减少模型调用成本 |
| ai-request-rewrite | 使用 LLM 改写请求内容 | 敏感信息脱敏、请求内容规范化、上下文补充 |
| ai-prompt-decorator | 自动添加前置和后置 Prompt | 统一追加企业级 System Prompt |
| ai-prompt-template | 预定义 Prompt 模板，支持变量填充 | 将模型调用封装为标准化业务模板 |
| ai-prompt-guard | 根据规则检查 Prompt | 拦截包含特定关键词或不符合规则的请求 |
| ai-aws-content-moderation | AWS 内容安全审核 | 检查用户输入是否包含有害内容 |
| ai-aliyun-content-moderation | 阿里云内容安全审核 | 对接阿里云内容审核服务 |
| ai-rag | 检索增强生成 | 调用外部数据源检索相关资料，注入模型上下文 |
| ai-lakera-guard | 接 Lakera，给 LLM 流量做提示词安全护栏 | 查注入越狱、PII泄露与违规，按策略拦截或告警 （防用户套取系统提示与敏感数据） |
这里有几个比较值得展开的能力。
二、几个重要插件的实际价值
-
ai-proxy：统一模型 API
假设你有以下模型渠道：
- DeepSeek 官方 API
- DeepSeek 第三方渠道 A
- OpenAI 官方 API
- Claude API应用只需要调用 APISIX：
POST /v1/chat/completions Authorization: Bearer your-api-key网关根据 Route 和插件配置，选择对应的模型供应商，并完成必要的协议转换。
它还支持将 Anthropic Messages API 转换为 OpenAI 兼容接口格式。
需要注意：它不是完整的模型管理系统，不会自动发现供应商的所有模型，也不会自动维护模型价格和能力元数据。
Apache APISIX+1
-
ai-proxy-multi：模型高可用
这是我认为最值得关注的插件。
例如你有四个模型渠道：
APISIX | ai-proxy-multi | +----------+----------+ | | | 渠道 A 渠道 B 渠道 C | | | DeepSeek DeepSeek DeepSeek可以实现：
- 多个模型供应商之间负载均衡。
- 请求失败后自动重试。
- 当前供应商不可用时切换备用供应商。
- 健康检查。
- 记录 Token 用量、模型信息和首字节响应时间。这与普通的 proxy_pass 有明显区别，它已经具备一定的 LLM 专用流量调度能力。
-
ai-rate-limiting：Token 维度的流量控制
传统 API Gateway 通常按请求次数限流：
用户 A：每分钟最多 60 次请求但 LLM 的请求成本与 Token 消耗直接相关：
用户 A：每分钟最多 10000 Prompt Tokens 用户 B：每天最多 100 万 Tokens这类控制更符合 AI 服务的计费模式。
-
ai-cache：降低模型调用成本
它支持两种缓存机制：- L1：精确匹配，相同 Prompt 直接命中。
- L2：语义匹配，通过 Embedding 和向量相似度检索历史回答。
例如：
第一次：什么是 APISIX？ ↓ 调用模型 ↓ 保存结果 第二次：什么是 APISIX？ ↓ 命中缓存 ↓ 直接返回语义缓存则可以让表达不同但含义接近的问题复用回答。需要注意缓存一致性、用户权限隔离以及相似度阈值设置。
三、它能否替代 NewAPI？
结合你正在做的 AI Gateway 项目，我认为这是最值得关注的问题。
两者定位有重叠，但不是同一类产品。
| 能力 | APISIX | NewAPI |
|---|---|---|
| 多模型供应商代理 | 支持 | 支持 |
| 多渠道负载均衡 | 支持 | 支持 |
| 故障转移 | 支持 | 支持 |
| 协议转换 | 支持部分协议转换 | 支持多种模型协议 |
| Token 限流 | 支持 | 支持 |
| 用户、令牌管理 | 基础 Consumer 体系 | 面向 AI 用户的管理体系 |
| 模型价格管理 | 需要自行扩展 | 核心能力 |
| 额度、计费、充值 | 需要自行开发 | 核心能力 |
| 模型渠道管理后台 | 需要自行开发 | 支持 |
| Prompt 治理 | AI 插件支持 | 需要扩展 |
| RAG | 有基础插件 | 需要外部服务 |
四、我认为 APISIX 最有价值的地方
如果将 AI Gateway 拆成三个层次：
- 业务管理层
用户、API Key、模型目录、价格、额度、计费、渠道管理
NewAPI / 自研 Go 服务 - 流量治理层
负载均衡、故障转移、限流、缓存、Prompt 治理、审计
Apache APISIX - 模型供应商层
DeepSeek、OpenAI、Anthropic、第三方模型渠道
我更倾向于这种组合架构，而不是用 APISIX 完全替换 NewAPI。
但有一个重要问题：不要让 APISIX 和 Go 服务重复实现渠道调度。
例如：
- Go 服务负责根据模型、价格、用户策略，确定可用渠道。
- APISIX 负责实际请求转发、渠道健康检查、故障重试和流量治理。
- Go 服务负责记录最终账单、计算成本和用户额度。
两者通过明确的职责边界协作。
另外，APISIX 的 ai-rate-limiting 是根据模型返回的 Token 使用量进行统计限流，不等同于完整的预扣费、余额检查和结算系统。
五、几个需要注意的限制
- ai-rag：目前官方实现主要支持 Azure OpenAI Embedding + Azure AI Search，并不是通用 RAG 引擎。
- ai-cache：需要 Redis，语义缓存还需要 Embedding 和向量检索能力。
- ai-prompt-guard：主要是规则匹配，不要将它理解为具备完整语义判断能力的 AI 安全系统。
- ai-proxy-multi：虽然支持多渠道调度，但复杂的业务路由，例如按模型价格、用户等级、渠道利润动态选择，仍然更适合放在业务层。
我的最终建议：
如果你的目标是建设一个支持 DeepSeek 官方渠道、第三方渠道、模型定价、用户额度和动态路由的 AI Gateway：
- NewAPI：适合直接承担业务管理和计费。
- APISIX：适合承担底层高性能流量治理。
- Go：负责两者之间的业务策略、模型目录和计费协调。
可以先不引入 APISIX，等到需要更复杂的流量治理、跨渠道高可用、统一 API 基础设施时再引入。
