如果你在生产环境里接入了两个以上的 LLM 提供商（OpenAI、Anthropic、Gemini、Groq……），大概率已经踩过这些坑：供应商的 API 格式不统一、重试逻辑要写 N 份、想把 Claude 和 GPT 的调用日志合并看也做不到、换个供应商代码要改一大坨。

这就是 AI Gateway 存在的意义——在你和所有模型供应商之间加一层抽象，对外暴露统一的 OpenAI 兼容 API，你改供应商只需要改配置，不用动业务代码。

这个赛道最知名的是 LiteLLM（Python），今天要聊的是一个用 Go 写的竞争方案——GoModel，4 个月时间，511 Stars，GitHub 最后一次提交就在昨天。

背景：多供应商困境

先说个真实的场景。

你做 AI 产品，接入了 GPT-4o 做主力、Claude Sonnet 做复杂推理、Gemini 2.5 Flash 做快速摘要。三个供应商，三套 SDK，三套错误处理，三套重试策略，三套计费逻辑。然后产品经理说：「能不能把这个月各模型 token 消耗做个报表？」

你翻了三天日志，发现各家日志格式完全不一样，计量单位都不统一。这就是为什么需要一个 AI Gateway——它把所有调用收敛到一个统一的接口，同时帮你把日志、计费、缓存这些事情做好。

LiteLLM 是这个方向最成熟的开源方案，但它是 Python 写的，GIL 限制了并发能力，而且配置相对复杂。

GoModel 是什么

GoModel 是来自波兰华沙的独立开发者 Jakub（GitHub @santiago-pl）的作品，2024 年 12 月开始开发，定位是高性能 AI Gateway，用 Go 编写，对外暴露完整的 OpenAI 兼容 API。

核心特性：

  • 11 家供应商支持：OpenAI、Anthropic、Google Gemini、xAI Grok、OpenRouter、Z.ai、Azure OpenAI、Oracle Cloud AI、Ollama、vLLM
  • OpenAI 兼容端点全覆盖：/v1/chat/completions、/v1/embeddings、/v1/files、/v1/batches
  • 双层响应缓存：精确匹配缓存 + 语义缓存（基于向量相似度），官方案例中语义缓存将命中率从 18% 提升到 60-70%
  • Guardrails：可配置的请求/响应过滤管道
  • Provider Passthrough：原生端点透传（/p/{provider}/...），绕过网关直接访问供应商特性
  • Admin API：用量统计、Token 消耗追踪、审计日志

说白了就是：LiteLLM 能做的 GoModel 基本都能做，但用 Go 写的，高并发下性能更好，内存占用地更低。

技术设计亮点

语义缓存的两层架构

让我展开说说缓存这块，因为它解决的是一个真实痛点。

Layer 1 是精确匹配缓存，Hash 请求体（包括 path、workflow 和 body），字节相同就直接返回缓存结果，延迟在亚毫秒级。但它的局限性也很明显——只有完全相同的请求才能命中。

Layer 2 是语义缓存，把用户最后一条消息用 Embedding 模型向量化，然后在向量数据库里做 KNN 相似度搜索。“法国的首都是什么"和"法国首都城市是哪个"语义等价，能命中同一缓存。官方数据是预期命中率达到 60-70%，相比精确匹配的 18% 提升显著。

支持的向量后端包括 Qdrant、Pgvector、Pinecone 和 Weaviate，配置一个 config.yaml 即可切换。

响应式 Provider 注册

大多数网关需要你在配置文件里写清楚要用哪些模型，GoModel 的设计更灵活——只需要提供供应商的 API Key，运行时自动从供应商拉取模型列表，注册到网关里。

docker run --rm -p 8080:8080 \
  -e OPENAI_API_KEY="sk-***" \
  -e ANTHROPIC_API_KEY="sk-ant-***" \
  -e GEMINI_API_KEY="***" \
  enterpilot/gomodel

模型注册是动态的，不需要重启服务。如果你有多个 OpenAI 兼容的 endpoint（比如一个给 GPT-4o，一个给某开源模型），可以用 OPENAI_EAST_API_KEY + OPENAI_EAST_BASE_URL 这样带后缀的环境变量注册多个同名类型供应商。

Guardrails 实用场景

Guardrails 在 AI Gateway 语境里通常指内容安全过滤。GoModel 支持在请求到达模型之前和响应回到客户端之前各加一道过滤。

典型使用场景：你在做一个客服 AI，用户输入可能包含 prompt injection 攻击，Guardrails 可以自动检测并拒绝请求，而不是让恶意指令被当作正常 prompt 发给模型。

Admin API 的计量价值

这个对 B 端场景很关键——你把 API 租给不同客户使用时，需要知道每个客户消耗了多少 token。GoModel 的 /admin/api/v1/usage/summary 和 /admin/api/v1/usage/daily 提供了开箱即用的计量接口，不用自己接 DataDog 或者自己写日志分析。

实际部署体验

Docker 部署一条命令起服务：

docker run --rm -p 8080:8080 \
  -e LOGGING_ENABLED=true \
  -e LOGGING_LOG_BODIES=true \
  -e OPENAI_API_KEY="sk-***" \
  enterpilot/gomodel

注意文档里特意提到不要在命令行直接写 API Key（docker run -e KEY=xxx 会让密钥出现在进程列表里），生产环境建议用 --env-file .env 从文件加载。

健康检查和 Prometheus metrics 都有， /metrics 端点直接对 Prometheus 暴露，配合 Grafana 五分钟能搭出一个用量监控面板。

生产级存储支持 SQLite（默认）、PostgreSQL 和 MongoDB。

局限性也要说清楚

GoModel 目前 Star 511，和 LiteLLM 的 2.2 万+不在一个量级上。LiteLLM 背后有商业公司，社区活跃度高，文档更完善，踩坑了容易找到解决方案。GoModel 是一个个人项目，开发者 Jakub 是 solo founder，虽然 GitHub 提交很活跃，但长期维护的持续性是一个需要考量的因素。

另一个是 Guardrails 功能还在完善中（ Roadmap 里写的是 “hardening: better UI, simpler architecture, easier custom guardrails”），如果你对内容安全有强监管合规要求，建议先做 PoC 验证。

什么场景选 GoModel

适合的场景：

  • 已经在用或计划用多个 LLM 供应商，想统一管理
  • Go 技术栈的生产环境，不想引入 Python 服务
  • 对并发性能有要求（Go 的并发模型天然优于 Python GIL 限制）
  • 需要语义缓存来降低 token 成本

可能不适合的场景：

  • 只需要单一模型供应商，直接调用 SDK 更简单
  • 需要企业级 SLA 支持和文档（LiteLLM 生态更成熟）
  • 对 Guardrails 有强合规要求（等 0.2.0 完善后再评估）

坦白说，这个项目让我想起早期 Tailscale——也是一个独立开发者做出一个方向对、体验好的工具，然后靠社区口碑传播。能不能成气候不好说，但作为基础设施它已经是一个可用的生产级选择。

如果你正在评估 AI Gateway，可以花半小时跑一下 Quick Start，感受一下配置逻辑和 API 体验，比读文档更直观。

信源：