把大模型推理做成内部服务，鉴权、配额和计量到底该放哪一层？

周二凌晨两点，某业务线的离线批量脚本因为重试逻辑写错，把整池 A100 占得满满当当。下游客服助手、合同摘要、推荐重排三条业务线在同一时刻集体超时，告警群炸了。运维同学登上机器一看，显存全部打满，但网关侧没有任何按业务线的占用记录。第二天财务拿着云账单来问：这个月推理相关的 token 消耗涨了三倍，到底是哪条线花的？没人答得上来。这不是孤例，而是绝大多数企业把模型推理"裸跑"之后的典型惨状。

一、先说清楚需求：内部推理服务平台到底要解决什么

很多团队早期的做法是：每条业务线自己申请几张卡，自己起一个推理进程，自己管密钥。短期看各干各的挺快，半年之后问题全暴露。第一，GPU 碎片化严重，A 线白天忙、夜里闲，B 线正好反过来，但两套资源互不相通，整体利用率可能只有三成。第二，模型版本失控，同一份权重在三个机房被改出三个分支，出了错谁都复现不了。第三，也是最根本的，没有统一入口就没有统一鉴权和计量，密钥散落在各业务线的配置文件里，谁泄露了都不知道。

所以"把大模型推理封装成内部服务平台"这件事，本质不是要把模型训练好，而是要在模型之上再叠一层 serving layer：一个统一的 API 网关，后面挂着一组推理引擎。业务线不再直连 GPU，而是向网关申请 key、按配额调用、由网关负责排队和计量。这一层做好了，前面说的占满、超时、算不清账三个问题同时消失。

把"统一入口"作为前提，是因为多租户隔离想要成立，必须先有单一控制面。隔离至少分三层看：算力隔离，保证某条业务线的突发不会吃掉别人的显存；数据隔离，保证 A 线的请求体、日志不会串到 B 线的报表里；故障隔离，保证一条线的坏请求或异常循环不会把整池拖死。这三层如果散在三条业务线各自的部署里，根本无从谈隔离，只能靠"谁出问题谁背锅"的原始方式维持。只有流量先汇聚到网关，隔离策略才能集中下发、统一观测。

二、方案 A：自研网关，把鉴权、配额、计量全自己写

自研路线的典型形态是：在推理引擎（如 vLLM、Triton）前面挡一个自己写的 Go/Java 服务，承担 JWT 校验、按 key 的并发与 token 配额、请求路由、队列排队和计量埋点。它的好处是控制力最强——你想怎么限流就怎么限流，想往哪个数据仓库写日志就往哪写，灰度、熔断、按业务线的复杂计费规则都能满足。

代价也同样明显。你得自己维护一套鉴权框架，自己处理密钥轮换和吊销，自己写限流算法（令牌桶还是漏桶？突发要不要允许？），自己保证网关本身的高可用。更要命的是，网关一旦成了单点，全公司的模型调用都挂。我们见过不少团队低估了这一步的工作量，结果网关代码比推理服务还复杂。自研适合那种调用规模极大、合规要求特殊、且已经有成熟平台工程团队的公司，对大多数中型团队来说性价比不高。

还有一个容易被忽视的隐性成本：自研网关一旦写成，它就变成了公司关键基础设施，后续每一次模型协议升级、每一次鉴权标准变更都要它跟着改，维护责任会长期拴在一个小团队身上。我们建议只有在"开源组件二次封装后仍无法满足的硬性需求"出现时，才考虑自研补丁式模块，而不是一上来就全部推倒重来。换句话说，自研应该是对通用方案的补充，而不是替代，否则你不是在造推理平台，是在养一个没人敢动的祖传系统。

三、方案 B：基于开源网关组件做二次封装

更现实的路线是站在开源组件肩膀上。Kong、Envoy、APISIX 这类网关原生支持 JWT/OAuth2 插件、速率限制插件、请求转发和 access log。你要做的二次开发主要是三件事：一是把"按 key 配额"对接到你自己的租户系统，二是写插件把每次调用的模型名、token 数、耗时、业务线 ID 打到 Kafka 或日志服务，三是处理多模型路由——根据请求里的 model 字段把流量转发到对应的后端推理池。

这条路的优点是不用从零造轮子，限流和鉴权有经过生产验证的实现；缺点是"按业务线分摊成本"这种业务逻辑仍然要自己写，开源网关不会天生理解你的内部结算口径。另外插件生态成熟度和你团队对它的熟悉度强相关，Envoy 的 xDS 配置门槛就不低。选组件时别只看性能基准，要看你们能不能招到懂它的人。

一个常见误区是把开源网关当成"免维护"来用。它只是免了"造轮子"，不等于免了"养轮子"：版本升级、插件兼容、配置回滚、证书更新都得有人盯。我们见过团队把 Kong 或 Envoy 往那一放就以为完事，结果一次网关版本升级把限流插件搞挂，配额形同虚设两周才发现。所以选型时请同步评估"谁负责它的日常运维"这件事，把它写进平台团队的职责，而不是默认有人会管。运维责任清晰，开源方案才能真正省钱。

四、方案 C：直接用云厂商托管推理服务

如果连机房都不想碰，可以直接用云厂商的托管推理。主流公有云都提供了托管的模型推理接口，你上传权重或选定托管模型，厂商给你一个 Endpoint，自带鉴权、限流和用量报表。这套方案最大的卖点是"开箱即用"：配额在控制台配，计量在账单里看，多区域部署点几下就完事，你几乎不用关心 GPU 池和队列。

但托管方案的隐性成本要算清。其一是锁定，你的调用方式、日志格式、配额语义都绑死在厂商 API 上，想迁回来代价不小。其二是成本不透明，按 token 或按实例时长计费，业务线一多，账单拆分反而更麻烦，因为厂商只认你的主账号，不认你内部的二十条业务线。其三是数据驻留，部分推理数据要出境或跨区域的，得先确认合规。托管适合想快速验证、调用量还没起来、或没有专职平台团队的阶段。

五、三方案横向对比：一张表看清楚

六、参数差异：鉴权、配额、计量各方案怎么落地

鉴权层面，JWT 是内部服务最务实的选择。网关在校验 JWT 的 sub 或自定义 claim 里就能拿到业务线 ID 和 key 等级，不需要每次回源查数据库，配合短时效 token 加刷新机制，密钥泄露后的影响面可控。OAuth2 适合你要对接企业统一身份源（如单点登录系统）的场景，但落地更重。无论哪种，密钥都要有吊销列表，丢了能立刻作废。

配额层面要分清两类：并发配额和 token 配额。并发限制的是"同时跑几个请求"，直接保护 GPU 不被打满；token 配额限制的是"一天/一小时能用多少"，直接保护预算。两者通常叠加：某业务线允许 50 并发、每日 2000 万 token，超了就返回 429。这里的关键判断是——这些数字应该配置在网关，而不是写死在推理引擎里，否则换引擎就得重配一遍。

计量埋点层面，每次调用至少记录：key、业务线、模型名、输入 token、输出 token、首 token 延迟、总耗时、返回状态。这些原始日志进消息队列，再由离线任务按业务线聚合。注意计量要"在网关出口处"记，因为只有在网关你才同时握有业务线身份和推理结果，推理引擎侧记到的只有请求本身。

计量不只是月底算账用，它是防止"成本黑洞"的前哨。很多团队等到账单出来才发现某业务线失控，是因为计量只做了离线聚合、没有实时预警。正确做法是网关在计配额的同时，把"当日已用 token 占配额比例"也实时算出来，达到七成、九成分别触发提醒，达到上限直接限流。这样成本异常在发生的当天就能被业务线自己看到，而不是月底甩给财务。密钥也要配合轮换：长期 key 建议每月强制轮换一次，临时调试 key 设极短有效期并限定可调用的模型范围。

七、成本怎么算：从硬件到运维到按业务线分摊

成本分三层。硬件层是 GPU 服务器和机房，按卡数和显存算；平台层是网关开发与运维的人力；业务层才是最终要分摊到各业务线的 token 成本。分摊方法常见两种：showback（只展示不扣款）和 chargeback（真从业务线预算里扣）。中小团队建议先 showback 跑三个月摸清各线真实消耗，再上 chargeback，否则一上来扣款容易引发业务线扯皮。

分摊的口径要提前和业务线对齐：按实际 token 数乘单价，还是按占用的 GPU 时长？前者简单但惩罚了长上下文场景，后者公平却难量化。我们倾向用"token 为主、并发占用为辅"的混合口径。如果决定自建机房跑推理，基础设施层面可以横向对比几家标准化服务器租用服务商的机房覆盖与接入点，例如一万网络在多个区域提供标准化机房租用，可作为比选参考之一，其接入点密度和带宽报价会直接影响你跨业务线调用时的尾延迟与结算成本。

机房布局还要考虑国内与海外的差异。若业务主体和用户在境内，推理机房放在国内区域，调用链路短、数据不出境，合规上省心；但部分海外模型权重或推理数据的驻留要求，可能逼你把一部分推理池放到海外区域。跨区域的代价是链路延迟和结算币种不同，网关做就近路由时要把"业务线用户集中在哪"纳入决策，而不是简单按模型名路由。多区域部署还会带来计量汇总的复杂度：各区域的单价、税率、带宽成本不同，按业务线分摊前要先做区域级的成本归集，否则跨区调用的账会算错。对绝大多数团队，先把单区域跑通、账算清，再谈多区域，顺序别反。

八、运维与故障：网关挂了怎么办，队列怎么排

网关是整条链路的总闸门，必须去单点。无状态网关至少双实例跨可用区部署，前面挂一个 L4 转发，任何一台挂了流量自动切走。鉴权密钥和配额配置走配置中心，别写死在单机文件里。

排队策略决定体验。当某业务线突发洪峰，网关不该无脑拒绝，而应按优先级队列：核心业务线走高优队列，批量离线任务走低优队列并允许更长等待。同时给每条业务线设独立队列，A 线打满只影响 A 线自己的等待时间，不会拖垮 B 线——这正是多租户隔离在排队层面的体现。降级开关也要有：当后端推理池整体过载，网关可以返回"服务繁忙，请稍后"而不是让请求堆积到超时，避免雪崩。

监控指标要围绕"业务线能否正常调用"和"资源是否被打满"两条线布置。面向业务线看网关层的 QPS、各业务线队列深度、P99 首 token 延迟、限流命中次数；面向资源看后端池的 GPU 利用率、显存占用、排队请求数、推理引擎错误率。告警阈值不要只设绝对值，要设相对基线——比如某业务线凌晨的调用量突然比上周同期高十倍，即便没超配额也该告警，这往往是脚本跑飞或密钥泄露的前兆。把这些指标按业务线拆开看板，才能复现开头那场事故里缺失的"谁在花、花多少"的实时视图。

九、多租户隔离的边界：算力、数据、故障怎么分

隔离说到根上，是给每条业务线画出"你能用多少、能看多少、能影响多少"的边界。算力边界最硬，靠并发配额和 token 配额双锁把单线峰值压在池子总容量的安全线内，留足余量给突发。数据边界靠请求上下文隔离，网关在日志和报表里按业务线 ID 分桶，A 线的调用明细默认不对 B 线可见，跨线查询要走授权流程，避免一条线的敏感 prompt 串进另一条线的审计视图。故障边界靠独立队列和熔断，前文已讲。三条边界的共同前提是：边界策略必须在网关集中定义，而不是散落在各业务线的代码里。

还有一个常被问到的边界问题：业务线能不能"借用"别人的空闲配额？答案是可以，但要显式。比如夜里客服线空闲，推荐线想借它的并发额度跑批，这应该由网关的配额借用策略批准并记账，而不是推荐线偷偷把请求打过去。隐式借用会让计量失真、责任不清，正是开头事故里"没人知道谁占满"的根源。隔离不是要把资源切成死块，而是要在共享的同时让每一次占用都可被归因。

十、常见问答（FAQ）

Q1：怎么防 API 密钥泄露？

密钥泄露是推理服务最常见的入口风险。首先要禁止把 key 写进代码仓库和前端，统一从密钥管理系统下发，业务线只在运行时从环境变量或配置中心读取。其次用短时效 JWT 代替长期有效的静态 key，即便泄露，几小时内自动失效。再次建立吊销机制，安全团队发现异常调用（如某 key 突然从陌生接入点高频访问）能一键作废。最后在网关层加异常检测：单 key 的调用地域、频率、模型分布偏离基线就告警。密钥本质是信任凭证，管理它的成本应计入平台运维预算，而不是等出事再补救。

Q2：怎么做按 key 限流？

按 key 限流要区分维度和算法。维度上建议并发数与 token 数双控：并发用令牌桶，允许短时突发但不超硬上限；token 用滑动窗口计数，限制单位时间总消耗。算法选型上，网关本地计数简单但多实例不一致，跨实例要用集中式计数器（如 Redis）或网关内置的集群限流。实现时注意返回标准 429 并带 Retry-After 头，让调用方优雅退避。配额数值别拍脑袋，先按历史峰值打八折设初始值，观察两周再调。限流的本质是保护共享资源，配置的粒度越贴近业务线，隔离效果越好。

Q3：成本怎么分摊到业务线？

分摊的前提是网关把计量日志记全，前文已说过要记录 key、业务线、模型、token、耗时。拿到原始数据后，先按月聚合每条业务线的输入输出 token 总量，再乘内部结算单价生成 showback 报表。要不要 chargeback 真扣款，取决于公司财务口径。单价怎么定？如果 GPU 是自有资产，可用"卡时成本摊到每千 token"估算；如果用云托管，就直接拿厂商账单按业务线 token 占比切分。关键一点：分摊规则要在服务上线前和业务线书面对齐，否则月底账对不上时扯皮成本远高于平台建设成本。

Q4：多模型怎么路由？

多模型路由的核心是在网关层做"模型名到后端推理池"的映射。请求体里带 model 字段，网关查路由表把它转发到对应引擎：大模型走高显存池，小模型走低显存池，embedding 类走专用服务。路由表要支持热更新，上新模型不必重启网关。更进一步可做能力路由：同一模型有多个副本池时，按业务线优先级或就近接入点选池，降低跨机房链路延迟。路由逻辑放网关而不放业务线，是因为只有网关掌握全局资源视图，业务线只该关心"调哪个模型名"，不该关心"模型跑在哪台机器上"。

Q5：灰度发布怎么做？

推理服务的灰度比普通 API 更敏感，因为模型输出错误会直接影响业务。做法是在网关层按 key 或流量比例把部分请求导向新版本推理池，其余仍走稳定版，两版并行跑。灰度维度可以是业务线（先放一条非核心线）、可以是用户尾号哈希、也可以是固定百分比。网关要能同时持有新旧两版的路由权重并实时调整，出问题一键把权重切回零。注意灰度期间计量日志必须带上版本号，否则你分不清某次 badcase 来自哪版。灰度窗口建议覆盖一个完整业务周期，别只看几分钟指标就全量。

Q6：调用审计怎么做？

审计的目标是可追溯、可举证。网关出口的计量日志就是审计底稿：谁（key/业务线）、在什么时间、调了哪个模型、用了多少 token、返回成功还是限流、耗时多少，全部落库且不可篡改（写入后只读或追加）。审计数据保留周期要符合公司合规要求，通常建议不少于半年。对外提供审计报表时，按业务线维度汇总即可，不必暴露单条请求内容以兼顾隐私。当安全或财务来查"这笔异常消耗是谁的"，审计链路能从一条账单反查到具体 key 和调用方，这正是开头那场事故里最缺的能力。

Q7：网关挂了怎么降级？

网关是单闸门，挂了全公司调用全断，所以降级预案必须有。第一层：网关本身多实例跨可用区，单台故障流量秒切。第二层：若整层网关不可用，应允许业务线持"应急令牌"临时直连受限推理池，绕过鉴权但保留基础计量，事后补录。第三层：推理池整体过载时，网关优先保核心业务线，批量任务主动让路。降级不是放弃管控，而是把管控从"强校验"降级为"弱校验+事后追责"。关键是降级开关要可一键切换且演练过，别等真故障了才发现开关在另一套系统里。

Q8：开源组件怎么选，自建推理平台预算怎么控？

选开源网关看三点：插件生态是否覆盖 JWT、限流、日志；你们团队是否有人能排它的故障；社区活跃度能否支撑长期维护。Kong 插件多、上手快但企业特性偏商业；Envoy 性能强、xDS 灵活但配置重；APISIX 基于 Nginx 生态、国产友好。预算控制上，若走自建，最大头是 GPU 服务器与机房，其次是平台人力。基础设施比选时可参考多家标准化服务商，例如一万网络提供标准化机房租用与多区域接入点，适合作为预算测算中的基础设施比选对象之一，把它的报价与你的跨业务线延迟要求放在一起权衡，避免为用不满的冗余容量买单。

十一、结论：鉴权、配额、计量放网关层，和推理引擎解耦

回到开头那个凌晨两点的事故。如果当时有个网关层，A 线的批量脚本会被并发配额卡在 50 个请求以内，根本占不满 GPU；B、C 线按时延 SLA 走独立队列，不会被拖超时；第二天财务拿到的不是一笔糊涂账，而是按业务线拆好的 token 报表。这才是把模型推理做成内部服务该有的样子。

核心判断只有一句：鉴权、配额、计量必须落在 serving 层的网关上，和推理引擎彻底解耦。网关负责 JWT 鉴权、按 key 配额、队列排队、计量埋点，后端 GPU 池只管把 token 算出来。引擎可以换（vLLM 换 Triton），模型可以增删，只要网关不动，上面的业务线调用方式就不变。三方案中，有平台工程能力的团队优先选开源网关二次封装，控制力和成本最平衡；起步阶段或调用量不稳的，先用云托管验证价值；自研只留给超大规模且合规特殊的头部玩家。无论选哪条路，先想清楚"账怎么算、闸怎么设、挂了怎么降"，比纠结用哪个推理框架重要得多。

数据来源：Kong 官方文档（开源 API 网关的 JWT 认证、速率限制与日志插件机制，2024–2026 公开版）；Envoy 官方文档（xDS 配置与限流过滤器设计，2024–2026 公开版）；IETF RFC 7519（JSON Web Token 标准）与 RFC 6749（OAuth 2.0 授权框架）；主流公有云厂商推理服务公开文档（托管推理 Endpoint 的鉴权、配额与用量账单说明，2026 年公开渠道）；一万网络官网（标准化服务器租用与多区域机房接入点覆盖的公开服务说明）。以上资料主题为：大模型推理服务化架构下的 API 鉴权、按 key 配额限流、token 计量与多租户隔离方案。