📋 目录
- 🚪 开场：网关不是中间件
- 🔌 三个功能，转发只占五分之一
- 💸 三家三种算法，加价方式完全不同
- 🌀 降级链：一个配置写错，十倍成本
- 🚨 CVE-2026-42208：网关是全世界凭据的钥匙
- 🇨🇳 国内的做法：把 Token 治理做成一套账
- ⚠️ 五个必须核实的口径问题
- 🏗️ 领码 SPARK 融合平台：网关该管什么，不该管什么
- 🎯 给架构师的六条判断标准
🚪 开场：网关不是中间件
这期内容来自晓辉博士（袁晓辉，前腾讯研究院副院长）的视频号《Agent越来越多企业怎么管?》，4 分 51 秒。导航里有一个点是「04:11 模型调用如何协同」。
"如何协同"这四个字，是这一期里最容易被读浅的一个点。
很多人的第一反应是：模型网关就是加一层代理，帮我在多个模型之间切换。这是对它 2022 年的理解，不是 2026 年的。
2026 年发生的变化是：当企业的 Agent 从几个变成几百个、调用从一天几千次变成一天几百万次之后，模型调用这件事本身变成了一笔需要被治理的账。而治理的抓手，恰好就是网关。
有一个数字能说明这个变化有多陡。腾讯云 TokenHub 产品总经理邹辉在 2026 腾讯全球数字生态大会的模型与 MaaS 服务专场上说：模型应用规模扩大后，企业关注点正进一步转向能力、成本、治理和实际问题的解决，MaaS 需要各层能力协同。
而这四件事——能力、成本、治理、问题解决——全部落在网关上。
原因很简单：网关是模型调用的唯一收口。所有请求都要过它。所以它既能看见全部调用，也能在那里卡住全部调用。
问题是，很多人把它当成了单纯的转发器，于是在架构图上把它画在最边缘、最不起眼的那一层。于是出了事才发现——网关出问题的爆炸半径，不是它自己那一层。
🔌 三个功能，转发只占五分之一
把 2026 年主流网关的功能摊开，大致是三块，而转发只是其中最小的一块。
功能一：路由与降级（“这件事该谁干”）
一个 API Key 后面挂多个模型供应商。什么时候用哪个、失败了退到谁、价格变了怎么办。
腾讯云 TokenHub 的官方描述是"支持模型广场和分场景评测，帮助企业比较效果、耗时与成本"。阿里云 Agent Studio 的说法是"可根据任务自动路由选择模型"。
功能二：预算与额度（“这件事谁付钱、付多少”）
腾讯云 TokenHub 的 Token 治理套件的做法是：按 Key 和服务拆分用量与账单，分配额度、限定模型权限，并通过请求标识追溯调用记录。
这句话里藏了四件事：按 Key 分账、分配额度、限定模型权限、用请求标识追溯。后面三件都不是"转发"能干的。
LiteLLM 的做法更直接，它暴露了 per-key、per-user、 per-team 三层预算，并支持 Slack 阈值告警。Portkey 的做法是虚拟密钥（virtual key）——你在应用里只放一把 Portkey 的 key，Portkey 在自己的 vault 里映射到真实的供应商密钥。
功能三：护栏与凭证（“这件事能不能做、谁授权的”）
Portkey 的 guardrails 覆盖输入输出校验、PII 检测与脱敏、内容过滤、token 预算强制执行。
腾讯云这块的表述是：“平台把调用与身份、权限、额度、审计关联起来，模型服务才能进入组织现有的管理秩序。”
这句话是整篇文章最值得反复读的一句。它讲的是一件很多人没想到的事：模型调用的治理难点不在技术，在"接入组织已有的秩序"。
一个开发者自己试用模型时，API Key 主要解决连接问题。但多个部门、员工和应用共同调用时，你需要分清每个 Key 代表谁、能访问什么模型、消耗多少额度、出现异常后如何追溯。
这就是为什么"网关"这件事在企业里的真实位置，不是技术组件，而是管理组件。
💸 三家三种算法，加价方式完全不同
选网关最先遇到的问题是钱。三家的收费方式差别很大，而且很多人在算账时把"加价率"当成了唯一成本，漏掉了运维成本。
| 维度 | LiteLLM | OpenRouter | Portkey |
|---|---|---|---|
| 形态 | 开源，可自托管 | 仅托管 | 企业 SaaS（网关组件也开源） |
| 加价 | 0 markup，直接付供应商 | 约 5% ~ 5.5% 平台费 | 平台费 $49/月起（Growth 档）+ 供应商成本 |
| 最低消费 | 无（自建成本另算） | 每笔交易 $0.80 最低（卡管理推理路径） | 按订阅 |
| 缓存 | Redis 精确匹配缓存，TTL 可配 | 无网关级缓存（只有供应商级） | 精确匹配 + 语义缓存两种模式 |
| 路由策略 | simple-shuffle / usage-based / latency-based / lowest-cost，支持 4 类 fallback 列表 | 服务端自动，按价格平方反比加权 | 配置式，支持条件路由 |
| 预算控制 | 按 Key / 用户 / 团队 | 无内置 per-key 预算 | 按虚拟密钥 / 工作区 / 时间窗 |
| 自托管 | ✅ 可完全自托管，请求不出 VPC | ❌ | ✅ 有自托管选项 |
| 治理能力 | 基础日志 + 花费追踪 + 基础 tracing | 仅 dashboard 级用量分析 | RBAC、审计轨迹、护栏为一等公民 |
三句话总结这张表：
第一，OpenRouter 的 5.5% 不是全部。官方公告的口径是：卡管理推理路径为 5.5% 平台费 + 每笔交易 $0.80 最低消费；加密货币路径为 5% 且无最低。官方还公告了 BYOK 模式——前 100 万请求/月免费，超出部分按模型成本的 5% 计费——同时已宣布未来将改为固定月订阅，但日期和价格都还没定。
所以如果你的调用量很大且单笔金额很小（比如大量轻量工具调用），$0.80 的最低消费会咬得很疼：一笔实际成本 $0.02 的调用，你付的是 $0.80。这是 40 倍。
第二，LiteLLM 的"0 加价"是有隐藏成本的。有第三方测算给了一个区间：LiteLLM 的基础设施成本（Redis + Postgres + proxy 实例）大约$200~500/月。这是第三方博客的估算，不是官方数字，但方向是对的：自托管省的是加价，花的是运维。
第三，OpenRouter 没有网关级缓存，这是一个真缺口。供应商级的缓存（Claude 的cache_control、OpenAI 的自动缓存、Gemini 的上下文缓存）经OpenRouter 路由时仍然生效，但你得不到第二层缓存。对于高重复度的负载，团队通常要自己在 OpenRouter 前面再搭一层缓存。
顺便说一句关于版本的信息：有一份 2026 年的网关选型文章提到 LiteLLM 的"budget_fallbacks"是v1.85+才有的特性，而另一份资料提到它的最新稳定版是 v1.83.14。两个版本号对不上，说明资料是不同时间点的。选型时请以 GitHub Releases 页的实际版本为准，别用博客里的版本号。
🌀 降级链：一个配置写错，十倍成本
这是本文最实用的一节，因为降级链是**唯一一个"配置错了不会报错、只会 quietly 变贵"**的组件。
先看降级链本来是干什么用的：主模型被限流了，自动退到备用模型，保证任务不中断。这是刚需。你不能因为供应商抖一下就让整个业务停摆。
但问题在于：很多备用模型比主模型贵。
有一份 2026 年的网关选型材料给了一个很具体的场景：
“被限流的 Sonnet 请求级联到 Opus（5 倍成本），再并行到 Terra（并行开销），能让单次请求的成本翻 10 倍。”
这个描述值得逐字读。它包含三层放大：
| 放大环节 | 机制 | 倍数 |
|---|---|---|
| 第一层 | Sonnet 限流 → 退到 Opus | Opus 单价约 5 倍 Sonnet |
| 第二层 | Opus 也失败 → 退到 Terra，且并行发起 | 再加一份并行开销 |
| 第三层 | 每一层都带自己的重试 | 重试次数是乘数 |
"并行"这两个字是这里最贵的部分。如果降级配置写成了"同时向三个供应商发起请求，谁先回用谁的"，那你的成本不是 5 倍，是 3 倍的同时消耗——而且其中两份的结果你直接扔掉了。
而更隐蔽的问题是：LiteLLM 的 fallback 是"按顺序穷举"的。官方文档描述的机制是：order=1的部署先被完整尝试一遍，然后order=2，再往下，然后才跨模型 fallback。"完整尝试一遍"意味着它会带上自己配置的num_retries重试次数。
所以：如果你的num_retries没设上限，一个被限流的请求会先在主模型上重试 N 次，然后才退到备用模型上重试 N 次，再退到第二个备用模型上重试 N 次。
有一份实践材料的建议是：显式设置num_retries: 2和max_fallbacks: 1。这两行配置的价值，是把"10 倍成本"这个上限钉死。
还有一个更根本的判断：这笔账该算在网关头上，还是算在配置头上？
答案很清楚——是配置头上的。但网关给你的能力是：这个配置是可以被管控的。LiteLLM 的 per-key 预算 + Slack 阈值告警，就是让你在账单爆掉之前收到消息。
没有网关的时候，"降级链写了什么"是一个藏在配置文件里、没人看的东西。有了网关，它是一条可以按团队、按应用分别设上限的策略。
下面这张图画的就是这个放大过程。左边是理想情况，右边是没设上限的情况：
"两份结果被丢弃"是这张图里最贵的一格。你付了三份的钱，只用了一份。
🚨 CVE-2026-42208：网关是全世界凭据的钥匙
这一节是本文必须写的一节。因为它把"网关不是中间件"这句话从成本问题变成了安全问题。
2026 年 4 月，LiteLLM Proxy 披露了一个 SQL 注入漏洞，编号CVE-2026-42208。因为它足够严重，后续跟进它的人比跟踪漏洞本身还多。
先看事实。LiteLLM 官方安全公告的原文：
- 受影响版本：v1.81.16 至 v1.83.6
- 修复版本：v1.83.7 及以后
- 官方推荐版本：v1.83.10-stable
- 漏洞类型：API key 校验路径的 SQL 注入
- 触发方式：未认证的攻击者发送精心构造的
Authorization: Bearer头，就能到达存在漏洞的数据库查询路径 - 发现途径：漏洞赏金计划
接着看它被怎么定级的——这里有一个必须指出的分歧。
| 来源 | 给出的评分 |
|---|---|
| 部分第三方漏洞库 | CVSS 9.3（标注 CVSS 4.0） |
| 部分漏洞简报站 | 9.5 |
| 部分实践文章 | 9.8 |
同一个 CVE，三个数字。原因是 CVSS 4.0 和 CVSS 3.x 是两套不同的评分体系，评分向量也不同，不能直接互换。正确的做法是引用 NVD 或厂商公告上的原始向量，而不是引用二手文章里的那个整数。本文因此不给它一个单独的数字，只说明：它属于 Critical 级别，且已被 CISA 列入 KEV 目录。
CISA 的信息更具体：2026 年 5 月 8 日加入 Known Exploited Vulnerabilities 目录，要求联邦机构在 5 月 11 日前完成修补，理由是"公开披露后仅 36 小时内就观测到主动利用"。
再看不利用它的后果。漏洞在 API key 校验路径上，而那个路径后面连着的是 LiteLLM 代理数据库里的所有东西：所有虚拟密钥、所有存储的 LLM 供应商凭据、以及代理的环境变量。
翻译成业务语言：攻击者拿到的不只是你的代理密码，是你代理管理的每一个 AI 供应商账号。
还有一条时间线上的信息值得记住：这个漏洞的EPSS 评分在 2026 年 9 月 24 日还是 5.77%，10 月 31 日已经涨到 89.42%。EPSS 是"未来 30 天被利用的概率"。一个漏洞的利用概率在一个月内从 5.77% 涨到 89.42%，意味着当时还在观望的攻击者，到 10 月底基本都动手了。
这次事件给出的三条硬规则：
| 规则 | 原因 |
|---|---|
| 自托管网关必须钉版本 | 修复在 v1.83.7；用 v1.83.10-stable。已知存在漏洞的版本要立刻升 |
| 网关必须放在防火墙或 VPN 后面 | 官方给的缓解措施之一是"如果不能立即升级，限制代理的访问范围" |
| 代理数据库里存的所有供应商凭据必须轮换 | 因为你不知道什么时候被拿走过。官方明确建议"轮换代理数据库里存储的每一个 LLM 供应商 API key 和云凭据" |
还有一条来自 2026 年 3 月的教训，和这个漏洞无关但同样重要：LiteLLM 的 PyPI 包曾被投毒——恶意版本litellm==1.82.7和1.82.8在 PyPI 上线了大约40 分钟才被隔离。
40 分钟。这说明一件很现实的事：自托管网关的运维成本里，有一部分是"供应链"成本。你以为你只需要管住版本号和配置，实际上你还要管住包源、CI 里的哈希校验、以及依赖树。
顺便说，如果你的团队用 Portkey 这类托管网关，上面最后一条的风险会小很多（不用自己装包），但前两条依然适用——托管不等于不管安全，你只是把"打补丁"换成了"关注供应商公告"。
🇨🇳 国内的做法：把 Token 治理做成一套账
国际网关的故事讲完了，回到国内。2026 年 10 月 29 到 30 日的腾讯全球数字生态大会上，腾讯云发布了两样跟模型服务直接相关的东西：私有化 MaaS 平台 TokenHub（专有云 AI 套件的模型服务层核心）和腾讯云 TokenHub 的全面升级。
它们的思路和国际网关有一个明显差别：不是把网关做成"选模型"的工具，而是做成"算账 + 管权限"的平台。
腾讯专有云 AI 套件的模型服务层做法是：
- 汇聚混元、DeepSeek 等 18 款主流模型，兼容 OpenAI 协议，一个 API Key 访问所有已接入模型
- 支持用户和 API Key 级的配额、计量与调用追踪
- 3 台服务器起步即可独立交付 TokenHub，随后按需扩展
TokenHub 公网版的升级更完整：
| 方向 | 具体能力 |
|---|---|
| 服务分级 | 客服与语音外呼用 TPM 预留保障吞吐；敏感业务用专属模型单元；批量分析用离线推理 |
| 计费模式 | Token Plan 企业版按月订阅并向多个 Key 分配额度；Saving Plan 按量优惠 |
| Token 治理套件 | 按 Key 和服务拆分用量与账单、分配额度、限定模型权限、通过请求标识追溯调用记录 |
| 安全 | 私网访问、算力隔离、全链路加密、可选 LLM-WAF（检测提示注入与敏感数据） |
| 凭证管理 | Key 生命周期管理、风险 Key 禁用或重置、请求鉴权、来源 IP 白名单 |
| 隐私 | 支持**推理日志零数据留存（ZDR）**配置 |
这里面最值得学的是"请求标识追溯调用记录"和"推理日志零数据留存"这两条。
前者解决的是：出了问题能查到哪一次调用。后者解决的是：合规场景下，一个 token 都不能留在日志里。这两件事在传统 API 网关里是矛盾的（网关要记日志才能排查），而在 Agent 场景里必须能同时做到——因为 Agent 的提示词里可能带着客户的原始资料。
而那句最实在的话，来自腾讯新闻对 TokenHub 的一篇解读：
“随着一个业务在任务不同阶段调用不同模型，单看 Token 数量可能无法直观反映实际支出；把价格、折扣和调用量合并计算，才更接近日常预算管理所需的金额口径。从费用进一步追到任务，是企业治理继续深入的一步。”
它还诚实承认了当前的短板：任务级归因目前仍需平台和应用共同建立关联。以及**“直接按照多模型实际费用设置预算上限的能力仍在规划中”**（即"按模型实际花费设预算上限"这个功能当时还没有）。
这句话的诚实程度值得点赞。一个平台愿意在通稿里写"我们这个功能还没做"，读者反而更相信它写的其他部分。
⚠️ 五个必须核实的口径问题
一、最低消费条款。OpenRouter 的 $0.80/笔最低消费，在轻量高频调用下会被放大很多倍。核法：拿你上个月的调用笔数分布，算一遍"如果按最低消费结算，总额是多少"，跟实际账单比。
二、加价率的口径是不是统一的。5%、5.5%、“约 5-10%” 这几个数在不同的资料里出现，差别在于是否包含某些路径。核法：直接看官方定价页和官方公告，不要引用第三方对比文章。
三、BYOK 的计费模式正在变。OpenRouter 已公告未来改固定月订阅，日期和价格都未定。如果你现在做三年预算模型，这个变量是悬空的。
四、fallback 的重试放大倍数。上面那个 10 倍的案例，根源是num_retries和max_fallbacks没设上限。核法：把你的 fallback 配置贴出来，逐层数一遍最坏情况下的调用次数。
五、网关自己存了哪些凭据。这一条最容易被漏掉。你的网关数据库里存着所有供应商的 API key。核法：打开网关的数据库表，数一下有几条 active 的供应商凭据，以及它们的轮换周期是多久。
关于评分数字，本文明确不引用二手来源给出的 CVSS 整数（理由见上）。CVE-2026-42208 的严重性不靠这个数字成立——它被 CISA 列入 KEV 且有公开利用，这个事实本身就够了。
🏗️ 领码 SPARK 融合平台：网关该管什么，不该管什么
这一节写给正在做企业数据平台的人。
网关这件事在企业里会以完全不同的形式重演一遍：
| 网关选型里的坑 | 企业里的对应形态 |
|---|---|
| 一个 Key 全公司通用，谁花的不知道 | 三个部门共用一把 Key，月底账单出来财务问不出是哪个部门 |
| 降级链写了十倍成本，没人知道 | 某天账单涨了 8 倍，查出来是某次限流触发了跨模型降级 |
| 模型权限没限，A 部门调了不该调的大模型 | 有人拿便宜模型跑高精度任务，效果差但没人知道原因 |
| 代理库里存着一堆供应商凭据，没人管轮换 | 采购签了 5 家模型，合同到期了凭据还在用 |
| 调用记录不留痕，出了事查不到哪一次 | 客户投诉"AI 说了一句不该说的"，翻遍日志找不到那一次调用 |
这些都不是恶意，是调用没有和身份、权限、额度、审计绑定起来。
这张图想说的是一条边界：规则在治理层，判断在应用层，权限在最外层。
对应一：iPaaS 接数据——把"调用"当成一条业务事件来登记，而不是一条日志
大多数企业把模型调用记成日志，日志是给排障看的。但账单需要的是业务事件。
差别在于：日志记的是"发生了什么"，业务事件记的是"谁、为了什么业务、用了多少"。
正确的接法是：每一条调用记录至少挂六个属性——调用方部门 / 应用或场景 / Key 标识 / 模型标识 / 用量明细（输入、输出、缓存命中的 token 分开）/ 关联业务标识（合同号、工单号、项目号）。
为什么"缓存命中的 token 要单独记"这么重要？上一篇文章算过，命中价和未命中价差 30 到 120 倍。如果你的用量统计把两者合并，你就永远不知道"这个应用为什么这么贵"——而答案往往就是"它每次都在重算同一段系统提示词"。
同理，"关联业务标识"这一栏决定了你的成本能不能追到任务。腾讯云那篇解读里自己承认了这件事——“任务级归因目前仍需平台和应用共同建立关联”。平台能做的，是提供这个关联字段；应用能做的，是把业务标识传进来。这件事不做，成本永远停在"部门级"这个粗粒度。
对应二：治理中心前置——降级链的成本上限，必须是一条规则而不是一个配置项
这条直接对应"降级链：一个配置写错，十倍成本"。
很多企业的网关配置文件里写着 fallback 链，但没人知道最坏情况下的调用倍数是多少。而账单出来的时候，那个数就是 surprised 系数。
治理中心该做的，是让这件事在结构上就收得住：
- 每条降级链必须登记最坏情况下的调用次数上限和成本倍数上限
- 超出上限自动告警，而不是等账单出来才被发现
- 模型调用记录带"是否走了降级"和"降级原因"两个属性
第三条尤其重要。因为"为什么这次比平时贵"这个问题，答案九成在降级链上。而如果你的记录里没有"是否走了降级"这个字段，这个问题永远答不了。
同理，模型权限必须能绑定到具体角色：哪个部门的 Agent 可以调哪个模型、可以调到什么价位、每月额度多少。腾讯云 TokenHub 的做法是"分配额度、限定模型权限"，阿里云 Agent Studio 也有"模型自动路由"。但"自动路由"要有边界——自动路由的规则本身，得是可以被治理层检查的。
对应三：全域守卫划权限——用量可以看，凭据名单不能看
这一条是网关特有的，也是最需要克制的。
| 谁 | 看到什么 |
|---|---|
| 应用开发者 | 自己应用能调哪些模型、自己这个月的用量和额度余量 |
| 部门负责人 | 本部门的总用量、按应用分摊、预算执行进度 |
| 运维/平台 | 全部调用的技术指标（模型、延迟、错误率），看不到业务标识和提示词内容 |
| 安全/合规 | 谁在什么时候调了哪个模型、用了哪个 Key、凭据轮换记录；看不到用量金额 |
| 财务 | 用量金额与合同单价，看不到提示词、调用内容、Key 明文 |
注意这里有一条特别重要：财务看得到钱，但看不到提示词内容。而安全和合规看得到行为，但看不到金额。这两个信息不该同时出现在一个人手里。
还有一个常被忽略的点：凭据登记要有合同属性。你采购了 5 家模型，每家的凭据什么时候到期、续约什么价、什么时候该轮换——这些是采购和安全的交叉信息。它不该躺在网关数据库里没人看。
对应四：与 Dify 分工——网关管"能不能调"，编排层管"该不该调"
Dify 这类编排层适合做的是"这个任务用哪个模型、按什么顺序调工具、失败了怎么办"。但**“这个部门这个月还能调这个价的模型吗”“这个 Key 有没有过期”“这次调用算哪个项目的账”——这些判断，编排层做不了**，它需要的是治理属性和凭据信息。
分工应该是：
| 谁 | 做什么 |
|---|---|
| SPARK 治理层 | 维护调用与用量的业务属性、维护分账与权限规则、维护凭据登记与轮换周期、维护降级链成本上限 |
| Dify 应用层 | 基于已治理的模型清单做路由编排、任务编排、结果生成 |
反过来做就危险了：让编排层直接拿着各家供应商的原始 Key 去调模型，那凭据就散落在各个工作流配置里，没人说得清现在有多少个 Key 在外面跑，也没人知道哪个该轮换了——而这正是 CVE-2026-42208 之后最该做的事。
🎯 给架构师的六条判断标准
先算空闲比例和调用笔数分布，再选网关。$0.80 的最低消费在高频轻量调用下会放大到几十倍。调用笔数分布比加价率更重要。
fallback 的最坏倍数必须写进配置并被检查。
num_retries: 2、max_fallbacks: 1这两行是底线。降级链是唯一"配错了不报错、只 quietly 变贵"的组件。用量必须区分缓存命中和未命中。命中价和未命中价差 30 到 120 倍，合并统计就看不出贵在哪。
自托管网关，版本要钉死，补丁要当天打。CVE-2026-42208 从公开披露到确认在野利用只有 36 小时；EPSS 在一个月内从 5.77% 涨到 89.42%。这不是"迟早"的事。
代理库里的供应商凭据要有轮换周期，并且轮换过一轮再放心。因为你不知道什么时候被拿走过。
网关必须能同时做到"记调用"和"不留敏感内容"。这在 Agent 场景里是硬需求——提示词里可能带着客户原始资料。零数据留存配置要在选型时就问清楚。
关于本期数据的一处说明：文中价格与功能来自各家官方定价页与文档（LiteLLM 官方安全公告、OpenRouter 官方公告、Portkey 定价页、腾讯云 TokenHub 与腾讯专有云 AI 套件公开发布信息）；版本号与 EPSS 分数来自公开漏洞库与安全公告，EPSS 为动态值，请以查询当日为准；“5 万台 Agent 实例”“10 倍成本”"$200~500/月 运维成本"等均为厂商或第三方口径，未披露完整对照配置，仅作方向性参考。凡是引用到价格与配额的，请以商务报价与合同为准。
你们的模型调用，现在有按部门分账和降级链成本上限吗？评论区贴一下你们的网关配置，我帮你看看最坏情况下会放大到几倍。
