1. 为什么现在需要Token算力工厂Token这个词做开发的兄弟应该都不陌生。从前端登录态的JWT到调用大模型API时按Token计费的账单再到这几天各种AI编程工具里频繁出现的token exchange failedtoken endpoint returned 403报错——Token已经从一个冷门的技术术语变成了实打实影响日常开发和业务成本的硬通货。我最早接触Token算力工厂这个概念是在一次内部技术规划会上。当时我们团队负责搭建一套面向多部门共享的AI能力平台需求很直白让不同业务线都能调用大模型但要统一管控成本、统一做鉴权、统一计量用量。传统的做法是每个项目组自己拉一台GPU服务器、自己接大模型API、自己维护一套鉴权逻辑。结果就是重复建设严重有人GPU闲置吃灰有人排队等算力月底账单分摊全靠吵架。后来我们参考了行业里成熟的算力工厂方案结合自己踩过的坑整理出了一套50页PPT级别的完整建设方案。这套方案的核心不是堆硬件、堆显卡而是把算力这件事从资源视角转换到Token生产视角——算力工厂的本质是以Token为计量单位把分散的GPU、API、模型服务、鉴权计费统一纳入一个可调度、可监控、可运营的平台。现在回头想想这个概念之所以在2025年特别火是因为AI应用已经从尝鲜进入规模化落地阶段。早期你调个API填个Key就完事量小无所谓。但当你的业务每天要消耗几千万甚至上亿Token当你的团队里几十个人同时用AI编程工具辅助开发当你的产品需要为终端用户提供动态Token配额——你就需要在系统层面把Token的生产调度计量回收全链路管起来。这篇文章就是基于我们的建设方案做的一次详细复盘把整体的设计思路、核心模块拆解、实操细节、踩坑记录都放出来给正在规划类似平台的同学做个参考。2. 整体架构思路从堆机器到产Token2.1 算力工厂到底生产什么先聊清楚一个根本问题算力工厂和传统的数据中心、超算中心区别在哪传统算力中心的核心指标是总算力比如多少PFLOPS多少张A100资源管理单位是GPU卡、CPU核心、内存GB。业务方申请资源拿到一台机器自己装环境、跑模型。这种方式适合长周期的训练任务但对于AI应用来说太笨重——你不会为了调用一次文本生成单独租一台GPU服务器跑一天。Token算力工厂的抽象思路完全不同它把底层算力包装成Token生产能力用户看到的不是某张显卡而是我每秒能处理多少Token我这个月能消耗多少Token。工厂内部怎么调度GPU、怎么排队、怎么容灾用户完全不需要关心。就像你去超市买电不需要关心发电厂用的是煤还是核能你只需要知道一度电多少钱、这个月用了多少度。这个转换听起来轻描淡写实际上牵一发而动全身。它意味着整个平台的技术栈要从基础设施层向服务治理层迁移你要有统一的接入层、统一的鉴权体系、统一的计量计费模块、统一的模型路由。说白了算力工厂更像是一个AI版的API网关资源调度器计费系统的组合体。2.2 三个关键设计目标统一、弹性、可观测在方案设计初期我们定了三个必须满足的目标后来所有技术选型都围绕这三条展开。第一个目标是统一。所有模型服务统一接入统一输出格式统一鉴权方式。业务方不需要关心底层接的是GPT还是开源模型不需要关心服务部署在哪台机器上只跟一个Endpoint打交道。这个统一层就是我们后来经常说的Token网关它是整个工厂的入口也是管控抓手。第二个目标是弹性。不同业务的调用量波动很大有的业务白天高峰、凌晨低谷有的业务有大促活动、短时间流量冲高。算力工厂必须支持动态扩缩容底层算力池按需伸缩API网关按照队列长度和GPU利用率自动调整并发上限。这个需求直接决定了我们要用容器化调度而不是传统的裸机分配。第三个目标也是普通方案最容易忽略的一点是可观测。Token不是无限发的你要知道每个调用方消耗了多少Token、花费了多少钱、调用是否成功、延迟是多少。所以整套系统从第一天就要埋好日志和指标为后面的成本分析和容量规划留好数据基础。我们见过太多能用就行的AI平台上线三个月后老板问这个月AI成本为什么涨了这么多技术负责人答不上来因为根本没有Token级别的计量数据。一套没有可观测性的Token算力工厂本质上是一个黑盒迟早出大问题。3. 核心模块拆解Token网关、调度引擎与计量计费3.1 Token网关所有流量的唯一入口Token网关是整个工厂的门面所有模型调用请求都从它这里过。它的职责不只是一个简单的反向代理至少要包括下面几块统一鉴权。业务方拿到的是平台签发的Access Token不是底层模型的API Key。这样一来底层模型厂商的Key不会在业务方代码里到处乱飞安全风险大幅下降。而且当某厂商的Key额度用尽或失效时网关可以自动切换备用Key业务方完全无感。协议转换。不同模型服务的API格式不统一OpenAI格式、Anthropic格式、国内厂商格式参数名都不一样。网关把内部统一的协议转发成上游各家的协议业务方永远只面对一套标准接口。模型路由。一个请求进来网关根据模型名、优先级、成本策略决定把这个请求发给哪个后端服务。比如普通问答走便宜的模型高难度代码生成走旗舰模型。限流与配额。每个业务方都有Token配额和QPS限制网关在入口做拦截超过配额直接返回429避免个别调用方拖垮整个工厂。我们在网关层用的方案是基于Nginx二次开发加Lua脚本同时集成了OpenResty的限流模块。选它的原因很简单成熟稳定、性能好、网上资料多遇到问题好排查。如果你团队里对Go更熟也可以基于Envoy做扩展但核心的鉴权、路由逻辑一定要独立成服务不要跟网关代码耦合太深。3.2 调度引擎把请求映射到最合适的算力网关决定了能不能调调度引擎则决定了调到哪里。调度引擎管理的是下游的算力池——可能是一组GPU物理机也可能是一组云上的推理实例甚至可能是外部API服务。调度策略我们参考了云原生领域的做法按优先级和亲和性两层调度第一层是队列策略。每个模型对应一个请求队列队列长度由消费速度和积压量动态调整。某模型并发太高、后端处理不过来时队列会自动拉长同时对新增请求做降速。这层相当于缓冲区防止突发流量打爆后端。第二层是实例选择。请求从队列里被拿出后调度器会检查当前哪些后端实例空闲、哪些机型的推理延迟最低、哪些节点故障被隔离挑一个最合适的实例转发。后端实例会定期上报自身状态调度器基于上报数据做决策避免转发到已过载或已故障的节点。当时我们设计这个调度系统时参考了Kubernetes的调度思想但没直接用它自带的调度器因为推理任务的特点是短平快、请求数极高通用调度器的开销反而成了瓶颈。我们自己实现了一个轻量调度模块核心逻辑不到两千行但完全够用。3.3 计量计费Token用量的水电表计量计费是算力工厂最容易低估、又最不能省的一个模块。没有它你无法回答三个问题谁在用、用了多少、该花多少钱。我们的计量埋点在网关层完成每次请求响应结束后网关会把请求基本信息业务方ID、模型名、输入Token数、输出Token数、响应耗时、状态码异步写入消息队列再由计量服务消费、聚合、落库。这里有一个非常重要的点不要直接在业务请求链路里写数据库。流量大的时候这种串行写库会直接把数据库打满进而拖垮网关正确做法是异步解耦。计费规则支持按Token单价计费也可以按每分钟、每小时的用量汇总出账。价格模型可以灵活配置比如同一模型对内部门A和门部B设置不同单价或者高峰期加价、低谷期打折。这种灵活性在后来对接各个业务线时帮了大忙——不同部门对成本的敏感度完全不同不能一套价格打天下。另外Token的统计必须精确。有的模型API返回的usage字段不准确有的需要自己数有的返回的是字符数而不是Token数。这块需要针对不同上游服务做适配校准否则月底对账的时候你发现网关统计的和厂商Bill的差一大截那场面很酸爽。4. 鉴权、续签与Token生命周期管理4.1 为什么开发中最常踩Token的坑看了最近的热搜词什么sign-in could not be completed token exchange failedyour access token could not be refreshedtoken endpoint returned 403 forbidden全是清一色的Token鉴权问题。开发同学天天跟Token打交道但Token的设计原理真正吃透的人不多所以一出问题就抓瞎。Token本质上是一段具有证明身份能力的凭证分两种主要流派一种是JWT这种自包含令牌服务端不存状态验签即可另一种是不透明字符串服务端要在数据库或缓存里查一下才能确认有效性。算力工厂的Token体系建议两种同时支持发给内部服务的用JWT方便无状态校验发给外部开发者的用不透明Token方便做到秒级吊销。JWT的结构不多讲了Header、Payload、Signature三段式。但有几个细节新手经常翻车签名算法不要用HS256。HS256是共享密钥对称签名一旦密钥泄露谁都能伪造Token。对外服务一定要用RS256或ES256非对称签名私钥放在认证中心各业务服务只拿公钥验签。过期时间不要太长也不要太短。设太短用户频繁掉线体验稀烂设太长一旦泄露攻击者可以用很长时间。标准做法是双Token机制短期Access Token的有效期设为30分钟到2小时配合长期Refresh Token来做无感续签。不要在前端localStorage里存Token。这个说了一万遍还是有人踩。localStorage里的数据JS脚本能直接读只要有XSS漏洞Token就被偷走。优先用httpOnly的Cookie或者至少把Token放在内存里刷新页面时用Refresh Token换新的。4.2 双Token续签机制落地细节双Token续签是这次方案里我花了最多时间打磨的部分因为它是用户感知最强的环节——续签做得顺用户无感做得烂用户每两个小时被迫重新登录一次骂声一片。流程大概是这样用户登录成功后认证中心下发Access Token和Refresh Token。Access Token短命Refresh Token长命。业务请求带着Access Token访问API网关验签验签通过则放行。Access Token过期后API返回401。客户端拿着Refresh Token去认证中心的刷新接口换新的Access Token。认证中心校验Refresh Token的合法性和有效期没问题就签发新的Access Token同时可以旋转Refresh Token旧的作废、发新的。实际做下来真心建议Refresh Token要旋转。虽然多一步操作但安全性提升很明显。如果不旋转一个被窃取的Refresh Token可以在它整个生命周期内不断换取新Access Token等于永久后门。旋转之后一旦发现某个Refresh Token被反复使用或出现异常行为可以立刻把它置为失效。还有一个隐蔽的坑并发续签。客户端同时发起了5个请求Access Token恰好过期这5个请求都会拿到401然后同时触发Refresh逻辑。如果处理不好认证中心会被刷5次甚至产生竞态条件刷新出5个不同的新Token。我们当时的处理方案是加了一个分布式锁基于Redis的SETNX保证同一个Refresh Token同时只有一个刷新请求能成功其他请求等待锁释放后直接用新的Access Token重放即可。4.3 企业场景下Token权限的最小化算力工厂面向多个业务方Token的权限控制必须细致。我特别推崇ABAC的思路——不是简单的角色而是基于属性业务方、模型范围、调用时段、配额级别的组合授权。举个例子A业务线的Token只能访问代码生成模型单日配额100万Token只能在办公时间调用。B合作伙伴的Token可以访问摘要模型和翻译模型但不能访问代码模型配额另算。这些权限在签发Token时就要固化在Token的属性里网关每次校验时都要检查。这里要格外小心的是不要给Token开全部模型的通配权限。我们实操中发现很多团队为了省事一个Token给所有模型的读写权限后面基本都要返工。权限越紧越好宁可后面多签几个Token也不要为了图方便埋雷。5. 实操过程从规划到上线的完整落地记录5.1 环境准备与基础组件选型说完设计聊聊具体落地。我们这套Token算力工厂技术栈大概是这样模块选型说明网关层OpenResty Lua高并发、低延迟灵活的请求处理调度引擎自研轻量调度器管理队列和实例选择核心逻辑约2000行推理算力池Kubernetes GPU节点池弹性伸缩安全隔离但K8s只负责编排不负责请求调度认证中心Spring Boot Redis负责Token签发、续签、吊销计量存储ClickHouse适合高吞吐的日志明细写入和聚合分析配置中心etcd存放路由规则、模型参数、价格策略消息队列Kafka计量数据异步传输选ClickHouse是因为Token计量数据的特性特别适合列式存储——写入频率极高、查询是按业务方和时间段聚合、不需要频繁更新单行数据。比MySQL硬扛强太多MySQL单表写入过万TPS就开始打摆子ClickHouse轻松扛住百万级写入。5.2 网关配置与调度策略的落地清单网关配置里最重要的两块是路由规则和限流规则。路由规则决定请求去哪里限流规则决定请求能不能进来。我们内部定义了一套路由配置格式存在etcd里支持热更新。模型路由规则长这样routes: - model: codegen-v2 match: priority: 10 biz_group: [devplatform] quota_type: code backend: provider: internal pool: gpu-pool-a fallback_pool: gpu-pool-b - model: text-summary match: priority: 5 backend: provider: external endpoint: https://api.llm.example.com/v1/chat路由规则里除了模型名还有优先级和条件匹配。优先级高的规则先匹配匹配成功后不再继续往下走。我们专门留了fallback_pool当主算力池过载或故障时自动切换备用池尽量保证高优先级请求不失败。限流这块用的是网关层滑动窗口令牌桶双层限流。滑动窗口控制每秒最大请求数令牌桶控制每分钟最大Token消耗量。注意这两者独立的一个请求可能QPS很低但单次消耗Token巨大如果只限制了请求数Token量还是会超。所以每个业务方的配额都是QPS和Token双维度任何一个超标都直接拒绝。5.3 并发场景下网关抖动处理上线前压测时我们发现一个很有意思的问题当QPS冲到2000以上OpenResty的Lua代码里如果有一些不经意的同步IO比如读取配置时直接访问etcd延迟会瞬间飙升到500ms以上。排查下来发现是worker进程在抢锁等待配置更新形成了连锁阻塞。优化手段主要是两招一是配置缓存本地化etcd的变更通过watch机制异步推送到网关内存业务请求只读内存缓存不实时访问etcd二是给Lua代码里所有外部调用增加超时熔断默认50ms超时超时直接走降级策略不让外部依赖拖垮主线程。这类问题在压力测试阶段发现还好真上线后才发现那就是事故了。所以无论你的方案PPT画得多好看上线前一定要做充分的压测特别是针对网关这道核心链路。6. 常见问题与排查技巧实录6.1 Token相关报错速查表把最近网上高频出现的Token报错整理成了一张速查表每个问题都有对应的解决思路症状可能原因排查方向token endpoint returned 403 forbidden: country服务商限制了访问地域检查出口IP所属地域考虑换服务节点token exchange failed: error sending request网络不通或认证服务超时检查网络连通性、DNS解析、代理设置your access token could not be refreshedRefresh Token过期或被吊销引导用户重新登录建立续签失败的前端兜底sign-in could not be completed认证流程中断回调地址或状态参数不匹配检查OAuth回调URL与注册应用是否一致auth token is unavailable客户端未正确获得Token检查登录后Token存储是否成功观察网络请求invalid token image/jpegToken被截断或格式损坏检查传输层是否完整传递Token有无大小写问题排查Token问题的大原则先看Token本身再到环境和网络最后看服务端配置。我们排查过上百个Token相关工单绝大多数最后都落在两端要么前端没把Token放到正确位置要么服务端签发Token时的配置有误。6.2 计量数据和账单对不上的根源分析不少搞AI平台的团队都遇到过这种问题平台统计的Token消耗量和模型厂商账单上的数字对不上差距还蛮大。根据我们的经验常见原因有三个第一个是Token统计口径不一致。不同模型厂商对Token的定义和切分规则不同有的按词元切分有的按字符数估算有的会额外统计输入和输出的标记。如果你把两家厂商的原始数据直接对比误差可能高达20%到30%。对策是建立统一的Token换算规则在网关层做归一化。第二个是重试请求的重复计费。客户端调接口超时了自动重发一次如果服务端没有做幂等处理这次请求就计了两次Token。网关层要有一个基于请求ID的幂等机制同一请求的重试只会计一次费。第三个是缓存命中的计费处理。有些后端服务对相同输入做了缓存命中缓存时不实际调用模型但网关如果还按完整Token量计费调用方就觉得被宰了。正确做法是把缓存命中标记出来计费时按优惠折扣处理。6.3 上线前检查清单整理一个我们上线前的检查清单每一项都是真金白银的教训密钥安全模型厂商Key、网关签名私钥、Redis密码、数据库密码等敏感信息是否统一放在密钥管理系统是否避免明文出现在配置文件或代码仓库。限流配置每个业务方的QPS和Token配额是否配置完整是否设置过默认配额而不是无限制。监控告警网关QPS、响应延迟、错误率、Token消耗速率是否都有监控看板是否有异常告警通知到人。故障演练如果网关挂了有没有降级到直连模型的备份方案业务方是否能收到明确提示。日志抽样全量日志在高峰期写入成本很高是否有合理的采样机制既保留排查线索又不至于日志量爆炸。计费测试新接入一个模型时是否有离线的小流量测试流程确认Token统计和计费公式正确。这些检查项看着基础但我们的经验是每漏掉一个上线后就会用一个事故来教会你。宁可在上线前多花一天过一遍清单也不要上线后花三天处理事故。7. Token成本控制与容量规划7.1 单位Token成本怎么算算力工厂运营的核心指标是单位Token成本也就是每处理一百万个Token综合算下来花多少钱。这个成本不是模型单价的简单搬运至少包含四部分上游API调用费如果用外部模型或GPU摊销成本如果自建模型网关和调度层的机器成本这部分相对固定计量系统的存储和计算成本主动请求重试、模型容灾切换造成的额外浪费举个例子假设某个自建模型的服务GPU集群每月摊销成本10万元一个月处理100亿Token那单位成本就是10万元除以100亿即每百万Token成本0.1元。再算上网关和计量系统的机器成本假设每月2万元分摊进去就是每百万Token再加0.02元。这样算出来的才是真实的生产成本。做预算和定价时一定要按这个完整的成本口径去算不要只盯模型单价。很多团队只算了模型API的价格忽略了平台自身的运行成本等业务量大了以后发现平台本身在亏钱运营。7.2 容量规划供需两端都要预估算力工厂的容量规划要从需求和供应两端分别估算。需求端根据各业务方的历史消耗量做趋势预测同时叠加重要营销节点、新业务上线等预期增量算出未来一个季度的总Token需求量。供应端根据GPU集群的算力上限和利用率目标算出自己能生产多少Token。比如一张H100的FP16算力理论上每秒推理可以产生多少Token日利用率按70%估算就能算出单卡月产能。当供应不足以满足需求时优先级应该是优化模型压缩和推理性能提高单卡产出再考虑采购更多算力或者接入外部API补足缺口。我们印象很深的一个案例是某业务方临时要跑一个大规模文本分类任务需求是保底30亿Token。接到需求时整个平台都紧张最后是靠混合部署——内部模型处理核心任务、外部低价API处理非敏感数据才把量扛了下来。7.3 降低Token成本的几条实用经验成本控制我总结了几条实用经验都是实操过的Prompt工程对冲Token消耗。同样的任务一个问题被设计得干净利落Token消耗可以差好几倍。做AI应用的同学有没有算过一个啰嗦的Prompt可能让你每次请求多花20%到30%的Token日积月累就是巨款。合理设置max_tokens。有些模型默认输出长度很大但业务根本不需要那么长的回答。把max_tokens从4096调到1024账单立竿见影地缩水。当然要按业务场景来不能一刀切。模型分级路由。简单任务用小模型处理复杂任务才走大模型这个策略能省下大头。比如判断用户意图用一个小模型就够了没必要每次都用旗舰模型做全文推理。缓存高频内容。如果某些高频请求有固定答案比如常见的FAQ问答把结果缓存起来命中缓存就不消耗上游Token。这块缓存命中率能做到20%整体成本就已经下降很可观了。这些方法组合起来单位Token成本往往能降20%到40%。做算力工厂运营的人如果不对成本敏感这个工厂开一天亏一天。8. 个人经验总结与后续扩展建议这套Token算力工厂方案从最初一张架构草图到最终落地稳定运行前后经历了大概四个月。说实话PPT方案永远比实际落地要光鲜。真到了运维阶段你发现80%的精力不是花在模型本身而是花在网关稳定性、Token生命周期管理、计量对账、成本优化这些基础功课上。我个人最深的体会是Token算力工厂不是一个一次性的项目而是一个持续运营的基础设施。它和电厂、水厂一样建起来只是开始后面还有长期的经营工作——持续优化单位成本、持续扩缩容、持续接入新模型、持续优化开发者体验。如果团队没有这个心理准备光靠上线时的一腔热血后面大概率会疲惫不堪。后续可以扩展的方向我们内部已经在规划的有两个。一个是一套统一的开发者Portal让业务方可以在平台上自助申请Token、查看用量、导出账单不用什么小事都找管理员。另一个是把计量数据接入一个预测模型做Token消耗的智能预测提前预警配额不足或成本异常。这些方向本质上都是围绕让Token的获取和使用变得像水电一样简单这个目标。如果你正在规划类似的算力平台我的建议是先把Token网关和计量计费做扎实再考虑模型接入的广度。这就像盖房子先打地基地基不稳上面装修得再漂亮都是白搭。 Token算力工厂：从网关到计量计费的全链路实践
1. 为什么现在需要Token算力工厂Token这个词做开发的兄弟应该都不陌生。从前端登录态的JWT到调用大模型API时按Token计费的账单再到这几天各种AI编程工具里频繁出现的token exchange failedtoken endpoint returned 403报错——Token已经从一个冷门的技术术语变成了实打实影响日常开发和业务成本的硬通货。我最早接触Token算力工厂这个概念是在一次内部技术规划会上。当时我们团队负责搭建一套面向多部门共享的AI能力平台需求很直白让不同业务线都能调用大模型但要统一管控成本、统一做鉴权、统一计量用量。传统的做法是每个项目组自己拉一台GPU服务器、自己接大模型API、自己维护一套鉴权逻辑。结果就是重复建设严重有人GPU闲置吃灰有人排队等算力月底账单分摊全靠吵架。后来我们参考了行业里成熟的算力工厂方案结合自己踩过的坑整理出了一套50页PPT级别的完整建设方案。这套方案的核心不是堆硬件、堆显卡而是把算力这件事从资源视角转换到Token生产视角——算力工厂的本质是以Token为计量单位把分散的GPU、API、模型服务、鉴权计费统一纳入一个可调度、可监控、可运营的平台。现在回头想想这个概念之所以在2025年特别火是因为AI应用已经从尝鲜进入规模化落地阶段。早期你调个API填个Key就完事量小无所谓。但当你的业务每天要消耗几千万甚至上亿Token当你的团队里几十个人同时用AI编程工具辅助开发当你的产品需要为终端用户提供动态Token配额——你就需要在系统层面把Token的生产调度计量回收全链路管起来。这篇文章就是基于我们的建设方案做的一次详细复盘把整体的设计思路、核心模块拆解、实操细节、踩坑记录都放出来给正在规划类似平台的同学做个参考。2. 整体架构思路从堆机器到产Token2.1 算力工厂到底生产什么先聊清楚一个根本问题算力工厂和传统的数据中心、超算中心区别在哪传统算力中心的核心指标是总算力比如多少PFLOPS多少张A100资源管理单位是GPU卡、CPU核心、内存GB。业务方申请资源拿到一台机器自己装环境、跑模型。这种方式适合长周期的训练任务但对于AI应用来说太笨重——你不会为了调用一次文本生成单独租一台GPU服务器跑一天。Token算力工厂的抽象思路完全不同它把底层算力包装成Token生产能力用户看到的不是某张显卡而是我每秒能处理多少Token我这个月能消耗多少Token。工厂内部怎么调度GPU、怎么排队、怎么容灾用户完全不需要关心。就像你去超市买电不需要关心发电厂用的是煤还是核能你只需要知道一度电多少钱、这个月用了多少度。这个转换听起来轻描淡写实际上牵一发而动全身。它意味着整个平台的技术栈要从基础设施层向服务治理层迁移你要有统一的接入层、统一的鉴权体系、统一的计量计费模块、统一的模型路由。说白了算力工厂更像是一个AI版的API网关资源调度器计费系统的组合体。2.2 三个关键设计目标统一、弹性、可观测在方案设计初期我们定了三个必须满足的目标后来所有技术选型都围绕这三条展开。第一个目标是统一。所有模型服务统一接入统一输出格式统一鉴权方式。业务方不需要关心底层接的是GPT还是开源模型不需要关心服务部署在哪台机器上只跟一个Endpoint打交道。这个统一层就是我们后来经常说的Token网关它是整个工厂的入口也是管控抓手。第二个目标是弹性。不同业务的调用量波动很大有的业务白天高峰、凌晨低谷有的业务有大促活动、短时间流量冲高。算力工厂必须支持动态扩缩容底层算力池按需伸缩API网关按照队列长度和GPU利用率自动调整并发上限。这个需求直接决定了我们要用容器化调度而不是传统的裸机分配。第三个目标也是普通方案最容易忽略的一点是可观测。Token不是无限发的你要知道每个调用方消耗了多少Token、花费了多少钱、调用是否成功、延迟是多少。所以整套系统从第一天就要埋好日志和指标为后面的成本分析和容量规划留好数据基础。我们见过太多能用就行的AI平台上线三个月后老板问这个月AI成本为什么涨了这么多技术负责人答不上来因为根本没有Token级别的计量数据。一套没有可观测性的Token算力工厂本质上是一个黑盒迟早出大问题。3. 核心模块拆解Token网关、调度引擎与计量计费3.1 Token网关所有流量的唯一入口Token网关是整个工厂的门面所有模型调用请求都从它这里过。它的职责不只是一个简单的反向代理至少要包括下面几块统一鉴权。业务方拿到的是平台签发的Access Token不是底层模型的API Key。这样一来底层模型厂商的Key不会在业务方代码里到处乱飞安全风险大幅下降。而且当某厂商的Key额度用尽或失效时网关可以自动切换备用Key业务方完全无感。协议转换。不同模型服务的API格式不统一OpenAI格式、Anthropic格式、国内厂商格式参数名都不一样。网关把内部统一的协议转发成上游各家的协议业务方永远只面对一套标准接口。模型路由。一个请求进来网关根据模型名、优先级、成本策略决定把这个请求发给哪个后端服务。比如普通问答走便宜的模型高难度代码生成走旗舰模型。限流与配额。每个业务方都有Token配额和QPS限制网关在入口做拦截超过配额直接返回429避免个别调用方拖垮整个工厂。我们在网关层用的方案是基于Nginx二次开发加Lua脚本同时集成了OpenResty的限流模块。选它的原因很简单成熟稳定、性能好、网上资料多遇到问题好排查。如果你团队里对Go更熟也可以基于Envoy做扩展但核心的鉴权、路由逻辑一定要独立成服务不要跟网关代码耦合太深。3.2 调度引擎把请求映射到最合适的算力网关决定了能不能调调度引擎则决定了调到哪里。调度引擎管理的是下游的算力池——可能是一组GPU物理机也可能是一组云上的推理实例甚至可能是外部API服务。调度策略我们参考了云原生领域的做法按优先级和亲和性两层调度第一层是队列策略。每个模型对应一个请求队列队列长度由消费速度和积压量动态调整。某模型并发太高、后端处理不过来时队列会自动拉长同时对新增请求做降速。这层相当于缓冲区防止突发流量打爆后端。第二层是实例选择。请求从队列里被拿出后调度器会检查当前哪些后端实例空闲、哪些机型的推理延迟最低、哪些节点故障被隔离挑一个最合适的实例转发。后端实例会定期上报自身状态调度器基于上报数据做决策避免转发到已过载或已故障的节点。当时我们设计这个调度系统时参考了Kubernetes的调度思想但没直接用它自带的调度器因为推理任务的特点是短平快、请求数极高通用调度器的开销反而成了瓶颈。我们自己实现了一个轻量调度模块核心逻辑不到两千行但完全够用。3.3 计量计费Token用量的水电表计量计费是算力工厂最容易低估、又最不能省的一个模块。没有它你无法回答三个问题谁在用、用了多少、该花多少钱。我们的计量埋点在网关层完成每次请求响应结束后网关会把请求基本信息业务方ID、模型名、输入Token数、输出Token数、响应耗时、状态码异步写入消息队列再由计量服务消费、聚合、落库。这里有一个非常重要的点不要直接在业务请求链路里写数据库。流量大的时候这种串行写库会直接把数据库打满进而拖垮网关正确做法是异步解耦。计费规则支持按Token单价计费也可以按每分钟、每小时的用量汇总出账。价格模型可以灵活配置比如同一模型对内部门A和门部B设置不同单价或者高峰期加价、低谷期打折。这种灵活性在后来对接各个业务线时帮了大忙——不同部门对成本的敏感度完全不同不能一套价格打天下。另外Token的统计必须精确。有的模型API返回的usage字段不准确有的需要自己数有的返回的是字符数而不是Token数。这块需要针对不同上游服务做适配校准否则月底对账的时候你发现网关统计的和厂商Bill的差一大截那场面很酸爽。4. 鉴权、续签与Token生命周期管理4.1 为什么开发中最常踩Token的坑看了最近的热搜词什么sign-in could not be completed token exchange failedyour access token could not be refreshedtoken endpoint returned 403 forbidden全是清一色的Token鉴权问题。开发同学天天跟Token打交道但Token的设计原理真正吃透的人不多所以一出问题就抓瞎。Token本质上是一段具有证明身份能力的凭证分两种主要流派一种是JWT这种自包含令牌服务端不存状态验签即可另一种是不透明字符串服务端要在数据库或缓存里查一下才能确认有效性。算力工厂的Token体系建议两种同时支持发给内部服务的用JWT方便无状态校验发给外部开发者的用不透明Token方便做到秒级吊销。JWT的结构不多讲了Header、Payload、Signature三段式。但有几个细节新手经常翻车签名算法不要用HS256。HS256是共享密钥对称签名一旦密钥泄露谁都能伪造Token。对外服务一定要用RS256或ES256非对称签名私钥放在认证中心各业务服务只拿公钥验签。过期时间不要太长也不要太短。设太短用户频繁掉线体验稀烂设太长一旦泄露攻击者可以用很长时间。标准做法是双Token机制短期Access Token的有效期设为30分钟到2小时配合长期Refresh Token来做无感续签。不要在前端localStorage里存Token。这个说了一万遍还是有人踩。localStorage里的数据JS脚本能直接读只要有XSS漏洞Token就被偷走。优先用httpOnly的Cookie或者至少把Token放在内存里刷新页面时用Refresh Token换新的。4.2 双Token续签机制落地细节双Token续签是这次方案里我花了最多时间打磨的部分因为它是用户感知最强的环节——续签做得顺用户无感做得烂用户每两个小时被迫重新登录一次骂声一片。流程大概是这样用户登录成功后认证中心下发Access Token和Refresh Token。Access Token短命Refresh Token长命。业务请求带着Access Token访问API网关验签验签通过则放行。Access Token过期后API返回401。客户端拿着Refresh Token去认证中心的刷新接口换新的Access Token。认证中心校验Refresh Token的合法性和有效期没问题就签发新的Access Token同时可以旋转Refresh Token旧的作废、发新的。实际做下来真心建议Refresh Token要旋转。虽然多一步操作但安全性提升很明显。如果不旋转一个被窃取的Refresh Token可以在它整个生命周期内不断换取新Access Token等于永久后门。旋转之后一旦发现某个Refresh Token被反复使用或出现异常行为可以立刻把它置为失效。还有一个隐蔽的坑并发续签。客户端同时发起了5个请求Access Token恰好过期这5个请求都会拿到401然后同时触发Refresh逻辑。如果处理不好认证中心会被刷5次甚至产生竞态条件刷新出5个不同的新Token。我们当时的处理方案是加了一个分布式锁基于Redis的SETNX保证同一个Refresh Token同时只有一个刷新请求能成功其他请求等待锁释放后直接用新的Access Token重放即可。4.3 企业场景下Token权限的最小化算力工厂面向多个业务方Token的权限控制必须细致。我特别推崇ABAC的思路——不是简单的角色而是基于属性业务方、模型范围、调用时段、配额级别的组合授权。举个例子A业务线的Token只能访问代码生成模型单日配额100万Token只能在办公时间调用。B合作伙伴的Token可以访问摘要模型和翻译模型但不能访问代码模型配额另算。这些权限在签发Token时就要固化在Token的属性里网关每次校验时都要检查。这里要格外小心的是不要给Token开全部模型的通配权限。我们实操中发现很多团队为了省事一个Token给所有模型的读写权限后面基本都要返工。权限越紧越好宁可后面多签几个Token也不要为了图方便埋雷。5. 实操过程从规划到上线的完整落地记录5.1 环境准备与基础组件选型说完设计聊聊具体落地。我们这套Token算力工厂技术栈大概是这样模块选型说明网关层OpenResty Lua高并发、低延迟灵活的请求处理调度引擎自研轻量调度器管理队列和实例选择核心逻辑约2000行推理算力池Kubernetes GPU节点池弹性伸缩安全隔离但K8s只负责编排不负责请求调度认证中心Spring Boot Redis负责Token签发、续签、吊销计量存储ClickHouse适合高吞吐的日志明细写入和聚合分析配置中心etcd存放路由规则、模型参数、价格策略消息队列Kafka计量数据异步传输选ClickHouse是因为Token计量数据的特性特别适合列式存储——写入频率极高、查询是按业务方和时间段聚合、不需要频繁更新单行数据。比MySQL硬扛强太多MySQL单表写入过万TPS就开始打摆子ClickHouse轻松扛住百万级写入。5.2 网关配置与调度策略的落地清单网关配置里最重要的两块是路由规则和限流规则。路由规则决定请求去哪里限流规则决定请求能不能进来。我们内部定义了一套路由配置格式存在etcd里支持热更新。模型路由规则长这样routes: - model: codegen-v2 match: priority: 10 biz_group: [devplatform] quota_type: code backend: provider: internal pool: gpu-pool-a fallback_pool: gpu-pool-b - model: text-summary match: priority: 5 backend: provider: external endpoint: https://api.llm.example.com/v1/chat路由规则里除了模型名还有优先级和条件匹配。优先级高的规则先匹配匹配成功后不再继续往下走。我们专门留了fallback_pool当主算力池过载或故障时自动切换备用池尽量保证高优先级请求不失败。限流这块用的是网关层滑动窗口令牌桶双层限流。滑动窗口控制每秒最大请求数令牌桶控制每分钟最大Token消耗量。注意这两者独立的一个请求可能QPS很低但单次消耗Token巨大如果只限制了请求数Token量还是会超。所以每个业务方的配额都是QPS和Token双维度任何一个超标都直接拒绝。5.3 并发场景下网关抖动处理上线前压测时我们发现一个很有意思的问题当QPS冲到2000以上OpenResty的Lua代码里如果有一些不经意的同步IO比如读取配置时直接访问etcd延迟会瞬间飙升到500ms以上。排查下来发现是worker进程在抢锁等待配置更新形成了连锁阻塞。优化手段主要是两招一是配置缓存本地化etcd的变更通过watch机制异步推送到网关内存业务请求只读内存缓存不实时访问etcd二是给Lua代码里所有外部调用增加超时熔断默认50ms超时超时直接走降级策略不让外部依赖拖垮主线程。这类问题在压力测试阶段发现还好真上线后才发现那就是事故了。所以无论你的方案PPT画得多好看上线前一定要做充分的压测特别是针对网关这道核心链路。6. 常见问题与排查技巧实录6.1 Token相关报错速查表把最近网上高频出现的Token报错整理成了一张速查表每个问题都有对应的解决思路症状可能原因排查方向token endpoint returned 403 forbidden: country服务商限制了访问地域检查出口IP所属地域考虑换服务节点token exchange failed: error sending request网络不通或认证服务超时检查网络连通性、DNS解析、代理设置your access token could not be refreshedRefresh Token过期或被吊销引导用户重新登录建立续签失败的前端兜底sign-in could not be completed认证流程中断回调地址或状态参数不匹配检查OAuth回调URL与注册应用是否一致auth token is unavailable客户端未正确获得Token检查登录后Token存储是否成功观察网络请求invalid token image/jpegToken被截断或格式损坏检查传输层是否完整传递Token有无大小写问题排查Token问题的大原则先看Token本身再到环境和网络最后看服务端配置。我们排查过上百个Token相关工单绝大多数最后都落在两端要么前端没把Token放到正确位置要么服务端签发Token时的配置有误。6.2 计量数据和账单对不上的根源分析不少搞AI平台的团队都遇到过这种问题平台统计的Token消耗量和模型厂商账单上的数字对不上差距还蛮大。根据我们的经验常见原因有三个第一个是Token统计口径不一致。不同模型厂商对Token的定义和切分规则不同有的按词元切分有的按字符数估算有的会额外统计输入和输出的标记。如果你把两家厂商的原始数据直接对比误差可能高达20%到30%。对策是建立统一的Token换算规则在网关层做归一化。第二个是重试请求的重复计费。客户端调接口超时了自动重发一次如果服务端没有做幂等处理这次请求就计了两次Token。网关层要有一个基于请求ID的幂等机制同一请求的重试只会计一次费。第三个是缓存命中的计费处理。有些后端服务对相同输入做了缓存命中缓存时不实际调用模型但网关如果还按完整Token量计费调用方就觉得被宰了。正确做法是把缓存命中标记出来计费时按优惠折扣处理。6.3 上线前检查清单整理一个我们上线前的检查清单每一项都是真金白银的教训密钥安全模型厂商Key、网关签名私钥、Redis密码、数据库密码等敏感信息是否统一放在密钥管理系统是否避免明文出现在配置文件或代码仓库。限流配置每个业务方的QPS和Token配额是否配置完整是否设置过默认配额而不是无限制。监控告警网关QPS、响应延迟、错误率、Token消耗速率是否都有监控看板是否有异常告警通知到人。故障演练如果网关挂了有没有降级到直连模型的备份方案业务方是否能收到明确提示。日志抽样全量日志在高峰期写入成本很高是否有合理的采样机制既保留排查线索又不至于日志量爆炸。计费测试新接入一个模型时是否有离线的小流量测试流程确认Token统计和计费公式正确。这些检查项看着基础但我们的经验是每漏掉一个上线后就会用一个事故来教会你。宁可在上线前多花一天过一遍清单也不要上线后花三天处理事故。7. Token成本控制与容量规划7.1 单位Token成本怎么算算力工厂运营的核心指标是单位Token成本也就是每处理一百万个Token综合算下来花多少钱。这个成本不是模型单价的简单搬运至少包含四部分上游API调用费如果用外部模型或GPU摊销成本如果自建模型网关和调度层的机器成本这部分相对固定计量系统的存储和计算成本主动请求重试、模型容灾切换造成的额外浪费举个例子假设某个自建模型的服务GPU集群每月摊销成本10万元一个月处理100亿Token那单位成本就是10万元除以100亿即每百万Token成本0.1元。再算上网关和计量系统的机器成本假设每月2万元分摊进去就是每百万Token再加0.02元。这样算出来的才是真实的生产成本。做预算和定价时一定要按这个完整的成本口径去算不要只盯模型单价。很多团队只算了模型API的价格忽略了平台自身的运行成本等业务量大了以后发现平台本身在亏钱运营。7.2 容量规划供需两端都要预估算力工厂的容量规划要从需求和供应两端分别估算。需求端根据各业务方的历史消耗量做趋势预测同时叠加重要营销节点、新业务上线等预期增量算出未来一个季度的总Token需求量。供应端根据GPU集群的算力上限和利用率目标算出自己能生产多少Token。比如一张H100的FP16算力理论上每秒推理可以产生多少Token日利用率按70%估算就能算出单卡月产能。当供应不足以满足需求时优先级应该是优化模型压缩和推理性能提高单卡产出再考虑采购更多算力或者接入外部API补足缺口。我们印象很深的一个案例是某业务方临时要跑一个大规模文本分类任务需求是保底30亿Token。接到需求时整个平台都紧张最后是靠混合部署——内部模型处理核心任务、外部低价API处理非敏感数据才把量扛了下来。7.3 降低Token成本的几条实用经验成本控制我总结了几条实用经验都是实操过的Prompt工程对冲Token消耗。同样的任务一个问题被设计得干净利落Token消耗可以差好几倍。做AI应用的同学有没有算过一个啰嗦的Prompt可能让你每次请求多花20%到30%的Token日积月累就是巨款。合理设置max_tokens。有些模型默认输出长度很大但业务根本不需要那么长的回答。把max_tokens从4096调到1024账单立竿见影地缩水。当然要按业务场景来不能一刀切。模型分级路由。简单任务用小模型处理复杂任务才走大模型这个策略能省下大头。比如判断用户意图用一个小模型就够了没必要每次都用旗舰模型做全文推理。缓存高频内容。如果某些高频请求有固定答案比如常见的FAQ问答把结果缓存起来命中缓存就不消耗上游Token。这块缓存命中率能做到20%整体成本就已经下降很可观了。这些方法组合起来单位Token成本往往能降20%到40%。做算力工厂运营的人如果不对成本敏感这个工厂开一天亏一天。8. 个人经验总结与后续扩展建议这套Token算力工厂方案从最初一张架构草图到最终落地稳定运行前后经历了大概四个月。说实话PPT方案永远比实际落地要光鲜。真到了运维阶段你发现80%的精力不是花在模型本身而是花在网关稳定性、Token生命周期管理、计量对账、成本优化这些基础功课上。我个人最深的体会是Token算力工厂不是一个一次性的项目而是一个持续运营的基础设施。它和电厂、水厂一样建起来只是开始后面还有长期的经营工作——持续优化单位成本、持续扩缩容、持续接入新模型、持续优化开发者体验。如果团队没有这个心理准备光靠上线时的一腔热血后面大概率会疲惫不堪。后续可以扩展的方向我们内部已经在规划的有两个。一个是一套统一的开发者Portal让业务方可以在平台上自助申请Token、查看用量、导出账单不用什么小事都找管理员。另一个是把计量数据接入一个预测模型做Token消耗的智能预测提前预警配额不足或成本异常。这些方向本质上都是围绕让Token的获取和使用变得像水电一样简单这个目标。如果你正在规划类似的算力平台我的建议是先把Token网关和计量计费做扎实再考虑模型接入的广度。这就像盖房子先打地基地基不稳上面装修得再漂亮都是白搭。