第 130 期·AI 网关·Go·Apache-2.0
痛点其实很具体。你为了不被单一模型供应商绑住，在业务和模型之间插了一层网关；这层东西在开发阶段很舒服，统一协议、藏掉各家的报错格式差异，换模型不用改代码。但一旦并发上去，它就从便利层变成了瓶颈层：每次请求都得多等一跳，限流、重试、key 轮换、token 计费全挤在这一个进程里，而 Python 写的网关在几千 QPS 下最容易先撑不住。Bifrost 的判断就是冲着这一条来的：网关本身就该按热路径的性能问题来设计，而不是当成一个调度用的胶水脚本。
一、它到底是什么
一句话：把二十多家模型供应商收敛到一个 OpenAI 兼容的 /v1 端点后面，同时把重试、故障转移、key 轮换、限流、预算、观测这些生产上必须有的东西，塞进同一个进程里。
它自己的定位是高性能 AI 网关。README 里列的供应商包括 OpenAI、Anthropic、AWS Bedrock、Google Vertex、Azure、Cerebras、Cohere、Mistral、Ollama、Groq 等二十多家。模型名带前缀就能路由，比如 openai/gpt-4o-mini、anthropic/claude-sonnet-4 这种写法，客户端只认一套协议。
工程上是 Go 单二进制，自带一个 Web 控制台，零配置就能起。仓库按模块拆得比较清楚：core 放核心与各家供应商实现，framework 放配置、日志、向量存储三类落盘后端，transports/bifrost-http 是 HTTP 网关，ui 是控制台，plugins 里是治理、日志、语义缓存、遥测、MCP 这些中间件。
功能面上，它把几件原本要自己写的事做进了网关层：按 key 和模型的加权分发、供应商之间的自动故障转移、基于语义相似度的缓存、MCP 工具调用、多模态与流式，以及用虚拟密钥做的分团队预算与用量追踪。观测方面直接吐 Prometheus 指标，也支持 OpenTelemetry 链路。
二、怎么用
照 README 的快速开始，起一个网关就是两条命令里选一条：
# 本地安装并运行 npx -y @maximhq/bifrost # 或者用 Docker docker run -p 8080:8080 maximhq/bifrost
起来之后打开 http://localhost:8080 就是自带控制台，供应商、key、预算都在图形界面上配。然后直接发第一个请求，模型名带供应商前缀：
curl -X POST http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-4o-mini",
"messages": [{"role": "user", "content": "Hello, Bifrost!"}]
}'要留住配置和日志，README 给了挂卷的写法：
docker run -p 8080:8080 -v $(pwd)/data:/app/data maximhq/bifrost
不想走 HTTP 的可以直接嵌 Go SDK：
go get github.com/maximhq/bifrost/core
已经在用各家官方 SDK 的，改成替换 base_url 就行。这是 README 里的原样写法：
# OpenAI SDK - base_url = "https://api.openai.com" + base_url = "http://localhost:8080/openai" # Anthropic SDK - base_url = "https://api.anthropic.com" + base_url = "http://localhost:8080/anthropic" # Google GenAI SDK - api_endpoint = "https://generativelanguage.googleapis.com" + api_endpoint = "http://localhost:8080/genai"
许可证这边我逐字读了 LICENSE：就是标准的 Apache-2.0 全文，附录之后没有任何追加条款，没有商用限制，也没有写着不许宣传。只提一个细节可能有人会在意：附录里写的版权方是 H3 Labs Inc.，组织账号叫 maximhq，官网品牌叫 Maxim —— 同一个东西身上有三个名字。
三、它好在哪
- 迁移成本是真低。客户端说的是 OpenAI 协议，所以从 LiteLLM 或者从直连官方 SDK 切过来，多数情况下就是把 base_url 指到本地 8080，业务代码不用动。
- 部署面很小。一个 Go 二进制、一个端口、一个自带控制台，不用再为网关单独维护一套 Python 环境和依赖。
- 生产上要的东西开箱就有。自动故障转移、加权分发、虚拟密钥加预算、Prometheus 与 OTel，这些不用自己拼。
- 语义缓存做在网关层。问法不一样但意思相近的请求能命中同一份缓存，对客服问答、内部知识库这类重复度高的场景，省的是真金白银。
- 许可干净、发版勤。Apache-2.0 没有附加条款，最近一次发布就在抓取当天。
四、缺点和坑
第一，性能数字全出自自家基准，这必须认真对待。仓库简介写的是五千 RPS 下开销低于 100 微秒，而 README 里那张表写的是 t3.xlarge 上 11 微秒、t3.medium 上 59 微秒 —— 同一个项目，两个口径。它自家几篇文章里反复出现的倍率更灵活：50 倍、54 倍、45 倍、40 倍、9.4 倍，说法不固定。
结论不是它不快。Go 数据面比 Python 数据面省开销，这件事方向可信。但幅度不可信，别拿对方的基准当自己的验收标准 —— 真要做选型，就在你自己的机器、你自己的上游、你自己的并发曲线上压一遍。
第二，最能打的几个功能在企业版。README 里有一个单独的 Enterprise Deployments 段落，明说企业部署才解锁自适应负载均衡、集群、护栏和 MCP 网关。官网企业页把门禁列得更全：
| 能力 | 免费开源版 | 企业版 |
| 统一入口 / 故障转移 / 加权分发 | 有 | 有 |
| 语义缓存 / 虚拟密钥 / 预算 | 有 | 有 |
| Prometheus / OTel 观测 | 有 | 有 |
| 自适应负载均衡（按实时性能调权重） | 无 | 有 |
| 集群模式（多节点高可用） | 无 | 有 |
| 护栏 / MCP 网关 | 无 | 有 |
| SSO / SAML 与 RBAC | 无 | 有 |
| 审计日志 / 日志导出 / 告警 | 无 | 有 |
| Vault 等密钥托管 | 无 | 有 |
| VPC / 私有云部署 | 无 | 有 |
这张表要提前对着架构图点一遍。单机跑统一入口，免费版够；但只要你的方案里出现多节点高可用或者审计合规，那就是要谈合同的事。注意 README 的功能清单里，MCP 是写在 Advanced Features 下面的，而企业部署段落又把 MCP 网关算成企业能力 —— 这一处边界在自家文档里就没说得很整齐，选型时值得直接找他们确认。
第三，涉及钱的那部分用了浮点数。这条是问题单里一条被标成高严重度的报告，编号 #4755。它指出 Go 代码里用 float64 普遍地表示金额：模型单价在 governance_model_pricing 表里是约七十个 float64 列，预算表 governance_budgets 的 MaxLimit 与 CurrentUsage 是 float64，请求日志的费用、MCP 工具调用的费用也都是 float64，预算还在 CAS 循环里用累加的方式一层层叠加。报告给的实际后果是两条：小额累加会漂移，仪表盘对大量结果做求和会舍入。
这一条已被指派给维护者，但到抓取时仍然是打开状态。实用建议就一句：拿它做预算硬拦截时留余量，账单金额不要当成唯一依据，该对账还是得跟供应商后台对。
第四，一批正在坏的地方，按编号看得很清楚。挑几条影响体感的：
- #6390 流式请求：上游没发完成标记就关流，客户端收到 unexpected EOF。
- #5040 的流式适配器会把上游 SSE 里的错误体直接丢掉，排障时你看不到上游到底说了什么。
- #7202 MCP 客户端在 initialize 还没完成时就发 tools/list，对使用官方 go-sdk 的服务端会间歇性报错。
- #7191 MCP 的 OAuth 授权会丢，而且手动重新登录救不回来。
- #7195 供应商没有 /models 端点时，模型既不能刷新也不能手动添加。
- #7206 Bedrock 上 Anthropic 原生的 InvokeModel 不走护栏配置。
- #7204 OTel 链路里缺 finish_reason，模型拒答在观测里看不见。
- #7213 DeepSeek 适配层在带工具调用的轮次里会把思考静默关掉。
第五，几条工程习惯上的信号，不算 bug 但你得知道。默认分支是 dev 而不是 main；一个网关的仓库体积约 970 MB；发版被拆成多条独立版本号（transports/v2.2.0、plugins/telemetry/v1.7.0 各算一条），你要跟版本得同时看几条线；问题单长期保持高水位。这些加在一起说明它迭代非常快，同时也说明它还在剧烈变动期，镜像 tag 建议钉死到具体版本，不要用 latest。
五、最终能达到什么效果
做完之后你手上会有这么一个东西：一个自托管、说 OpenAI 协议的入口，现有客户端只改一行 base_url；某个供应商挂了，按你配的规则自动切到备用；用虚拟密钥把预算和限流分给不同团队；控制台里能看到每条请求打到哪个供应商、哪个模型、花了多少时间。它替掉的是你自己写的重试逻辑、key 轮换脚本和一堆埋点。
不适合谁：只连一两个模型、QPS 很低的个人项目 —— 多一跳和一套配置不划算；需要多节点高可用和审计合规但不想付费的；对计费精度要求非常高的场景。
三个坑：一是别拿它的基准当验收，自己压一遍；二是选型前把企业版功能清单对着架构图点一遍，别做完才发现集群要买；三是预算拦截留余量，float64 记账这件事还没修好。
仓库地址：github.com/maximhq/bifrost；文档：docs.getbifrost.ai。文中的命令与配置写法均取自 README 原文，功能边界与性能口径取自 README、官方文档站与官网企业页，问题单条目取自仓库公开的 issue 编号。本轮未实际部署、未跑基准，所以所有性能数字都只作为对方口径引用，不当结论。
下期预告：把统一入口这一层单独拎出来做一次横向对比 —— Bifrost、LiteLLM，以及云厂商自带的网关方案，讲清楚这件事到底该不该自己搭、自己搭的话哪一层最容易被低估。