LLM 网关怎么选?SMA 网关、LiteLLM、Portkey、Kong、Higress 对比
主流 LLM 网关定位差异明显:LiteLLM 重开源自运维,Portkey 重托管与可观测,Kong 与 Higress 把 AI 能力挂在既有 API 网关设施上,SMA 网关(smaapi)重企业治理与国产模型接入。选型先对场景,再按六维标准逐项核对。
各项目的定位差异(以各项目官方文档为准,口径 2026-06)
| 项目 | 形态 | 定位与突出点 | 典型适用 |
|---|---|---|---|
| SMA 网关(smaapi) | 托管 / 自部署 | 企业级 AI 网关:智能路由 + 成本与权限治理 + 全链路审计,国产模型一线支持 | 需要组织级治理与国产模型合规接入的企业 |
| LiteLLM | 开源(Python) | 代理 + SDK 双形态,供应商覆盖广,社区活跃 | 有自运维能力、追求自由度的工程团队 |
| Portkey | 托管为主 | AI 网关 + 可观测性 + 提示管理一体 | 接受海外 SaaS、重观测体验的团队 |
| Kong AI Gateway | 开源 + 商业 | 在 Kong API 网关上扩展 AI 插件,复用既有流量治理 | 已深度使用 Kong 的组织 |
| Higress | 开源(阿里系) | 云原生网关 + AI 插件生态,K8s 原生 | 阿里云 / 云原生技术栈的团队 |
表内各项目口径来源(核对日期 2026-06):LiteLLM 官方文档 · Portkey 官方文档 · Kong 官方文档 · Higress 官网;SMA 网关能力以本站说明与合同条款为准。
定位差异不必靠揣测,各项目自己写得很清楚。LiteLLM 官方文档开篇的一句自述是:
「Call 100+ LLMs using the OpenAI Input/Output Format」
来源:LiteLLM 官方文档(核对日期 2026-07)
这句话本身就是边界:它解决的是协议与接入——用一套 OpenAI 格式调用多家模型,这件事它做得很好;它没有声称要解决预算归属、团队授权、审计留痕这类组织问题,因为那不是它的定位。选型分歧多半不在"哪个更好",而在把工具的定位错配到自己的问题上:接入层的问题用接入层解决,治理层的问题才需要治理层。
选型该看哪六个维度?
- 协议兼容性:OpenAI 协议兼容的完整度(流式、函数调用、多模态),现有 SDK 能否零改造。
- 路由能力:策略是否可配置、可校准;故障降级是否自动且对应用透明。
- 治理粒度:预算、配额、权限能否细到团队 / 应用 / 密钥,而不是全局一刀切。
- 审计完整性:能否支撑合规审查与成本对账,日志是否覆盖全链路。
- 模型覆盖的真实性:宣称支持与真实连通是两回事——要可验证的实时连通数据。
- 数据边界:提示词、密钥、日志保存在谁的环境;是否提供自部署形态。
不同场景下该怎么选?
中国企业、多模型含国产模型、有合规要求
优先核对国产模型一线支持与数据边界(标准第 5、6 条)——这是多数西方项目的弱区,也是 SMA 的设计重心。
纯工程团队、海外模型为主、自运维意愿强
LiteLLM 起步最快;团队规模扩大、治理要求出现后,再评估是否引入治理层或更换形态。
已有成熟 API 网关设施
先看 Kong / Higress 的 AI 插件能否复用既有设施满足需求,不满足再引入专职 LLM 网关,避免重复建设。
常见问题
开源自部署和托管网关怎么取舍?
看两件事:运维能力与合规姿态。有专职平台团队、希望完全掌控基础设施的,开源自部署(LiteLLM、Higress 类)自由度最高;希望把网关本身的运维、升级、故障处置外包,聚焦业务的,托管形态更划算。对数据边界有硬性要求的企业,优先考察供应商是否提供自部署版本——两种形态都有的产品可以随合规要求演进。
需要重点接入国产模型,选型有什么不同?
多数西方项目对国产模型的支持依赖社区适配,协议细节(流式、函数调用、计费口径)的兼容质量参差。重点考察三点:国产模型是否一线支持而非社区插件;连通状态是否有可验证的实时数据;合规与备案语境是否被产品正面处理。
参考来源
- OpenAI API 官方文档——OpenAI 兼容协议的字段与语义以官方文档为准
关于名称:smaapi(SMA 网关)是均路科技的企业级 AI 网关,SMA 取自黏菌架构(Slime Mould Architecture)。 smaapi 与金融指标「简单移动平均线」、光伏逆变器厂商 SMA Solar Technology AG,以及同名的 SMA 射频连接器标准均无关联。