企业官网建设流程全解析

前一阵在折腾跨中心大模型托管的时候，我最大的感受是——真正麻烦的往往不是模型本身，而是怎么把几十台异构算力、各式各样的推理框架和一堆业务方的调用需求端到端地串起来。每个超算节点都有自己的卡型、驱动、框架版本和鉴权方式，API风格更是五花八门。我们需要一个东西，能让上层业务像访问一个API一样去使用分布在不同物理位置的模型服务。于是就有了AI模型网关这个层级，我在做的这个内部项目代号叫TokenLat，下面顺着实践聊聊它到底在解决什么问题。

1. 超算互联网联合体里，痛点从来不是“没有算力”

1.1 算力节点“各说各话”的现状

超算互联网联合体的概念背后，本质上是想把多个高性能计算中心、智算中心连成一张可以统一调度的网。以前大家各自运营各自的集群，对外提供独立的作业提交入口，用户想用哪个中心就去哪个中心开户、充值、上传代码。现在想把它们拉通，最先遇到的不是网络带宽，也不是硬件差异，而是“接口不一致”。

我接触过的几个节点里，有的对外只提供基于OpenAI协议的接口，有的只暴露vLLM的API，还有的必须走自己的命令行工具。卡型就更不用说了，既有训练大模型常用的加速卡，也有各家自研的推理卡，再叠加不同的驱动版本和算子库，同一个模型在不同节点上跑出来的可用性和并发上限都不一样。这种“各说各话”的状态，直接导致上层应用团队根本不敢做多中心调度——因为兼容成本太高。

1.2 从“算力调度”到“模型托管”的范式变化

早期做算力互联，大家关注的是作业调度器之间的互联，人们对它的理解也更接近“排队提交计算任务”。但最近一年，整个需求场景发生了明显变化：越来越多的任务不是一次性批处理，而是需要以在线服务的方式对外提供推理能力，也就是常说的模型托管。

一个模型托管平台要处理请求怎么进来、如何鉴权、如何按业务方分配配额、如何处理突发流量、如何记录调用明细用于结算。这些事在单一中心内部还好办，一旦分散到多个中心，就会变成一组很棘手的问题。联合体里的每个节点不可能为了迁就你的上层业务去改自己的接口风格，所以只能由中间层来适配。模型网关在这个链条里的定位，就是一个专门解决“把分散的模型服务变得可控、可管、可用”的中间层。

1.3 为什么不能用“多套API硬拼”来解决问题

有人可能会说，既然每个节点都有自己的API，那我做一个简单的路由脚本，把请求按节点转发过去不就行了？这个思路听起来简单，实际一跑就会发现问题。

首先是协议差异。有的节点支持流式返回，有的不支持；有的用HTTP调用即可，有的需要内部消息队列中转。其次是对外暴露的模型名各不相同，A节点把模型命名为“model-72b-chat”，B节点里同样一个模型叫“chat-72b-v3”，你要怎么对上？然后是配额和鉴权，每个节点都有自己的访问凭据和调用限额，统一管理起来非常费劲。

我在TokenLat里踩过最大的坑就是早期试图“基于脚本转发”，结果一到高并发就出问题：某个节点超时了脚本线程卡死，后面的请求全部排队堆积，最后拖垮整个网关。这件事让我明确了一个判断——模型网的复杂度已经不再是“转发”能覆盖的，它需要一套真正的网关体系。

2. AI模型网关到底要解决哪些核心问题

2.1 群体接入：把异构模型“翻译”成统一接口

网关的第一层能力是适配。从外部看，业务方只需要面对一套API协议，无论是OpenAI兼容格式还是自定义的RESTful格式，网关都能承接。从内部看，网关负责把标准请求转换成各个节点能理解的格式，再调用对应中心的服务。

看起来简单，实际做的时候有几个比较深的细节。

一个是多级路由。一个请求进来，先要做协议解析，得到模型名、输入内容、请求参数；然后网关要根据模型名去查路由表，确定这个模型在哪些节点有部署；再根据每个节点的负载、健康状态、历史时延，选出一个目标节点；最后才是调度执行。有些网关会设置两级甚至三级缓存，比如普通命中缓存放在网关内存里，精确匹配缓存放在中心存储里，这都是在实践里慢慢摸索出来的。

另一个是模型服务的逻辑一致性。不同节点对同一个模型，可能因为算子优化不同，输出结果有细微差异。你不能让业务方感觉到“今天拿到的答案和昨天不一样”。TokenLat在处理这个问题时，会优先把请求路由到相同版本模型的节点，同时记录每个节点的最后健康检查状态，尽量避免跨版本跳转引发的结果漂移。

2.2 智能路由：按成本、时延和负载把请求送到最合适的地方

路由是模型网关最核心的技术点之一。不能说“哪个节点空闲就送哪个”，因为不同的节点背后有不同的成本结构、不同的网络路径和不同的可用性特征。

TokenLat里设计了一个简单的打分机制，对每个候选节点做实时评估：

• 健康状态权重：最近一分钟的错误率和超时率，错误率越高分数越低
• 队列深度权重：节点当前积压的请求数，排队越长分数越低
• 网络时延权重：从网关到目标节点的最近5次平均往返时延
• 成本权重：不同节点的单价，成本越高分数越低

每个权重可以配，不一定面面俱到，但至少让路由决策有依据。举个例子，A节点的单价是B节点的两倍，但A节点的时延只有B节点的三分之一。对于一个实时交互类业务来说，时延敏感权重高于成本权重，那么网关会优先把请求送到A节点；反之，对成本敏感的业务，网关会把请求送到B节点。

这个机制还有一个好处，就是可以做故障转移。某个节点突然开始报错，网关可以在几十秒内把它从候选集合里剔除，让新的请求自动落到其他健康节点上。实测下来，这种做法比靠“人工切换”可靠得多，因为人工反应速度不可能赶上一个多中心环境下的故障扩散速度。

2.3 计量与摊分：跨机构的钱到底怎么算

算力联合体里，多个中心共同服务一个业务，成本怎么摊？如果只是内部使用还好，一旦涉及对外商业化，计量就变成一个绕不开的问题。网关需要在每次请求通过时，记录这些关键信息：

• 调用方是谁（租户维度）
• 调用的是哪个模型（模型维度）
• 实际消耗了多少卡时或者Token数（资源维度）
• 命中了哪个节点（物理维度）
• 请求什么时间发生，耗时多少（时间维度）

这些数据聚合之后，可以按小时、按天生成账单。如果只依赖各个节点自己上报的日志，很难对齐——因为每个节点的计量口径不一样，有的按请求数计，有的按并发时长计，有的按Token计。网关的好处是统一在入口处做计量，这样无论底层节点怎么计费，至少上层业务看到的口径是一致的。

TokenLat在早期版本里只记录请求数和耗时，后边才补上Token计量。做Token计量比想象中麻烦，因为它涉及模型内部的分词逻辑，不同模型的分词器不一样，不能简单地按文本长度估算，否则账目会有偏差。

2.4 安全与合规：数据不出域，但请求要跑出去

多中心互联还有一个非常敏感的问题，就是数据边界。某些中心接入的业务涉及敏感数据，用户要求数据不能离开特定区域，但是模型服务本身分布在其他中心，怎么处理？

网关的方案是做两级隔离：第一级在入口层做数据脱敏，把请求文本中的敏感字段进行替换；第二级在路由策略里做强制约束，允许特定租户的请求只路由到指定范围内的节点，其他节点一律不进入候选集合。这两种机制，前一个是数据层面的策略，后一个是节点层面的策略，配合使用能避免很多麻烦。

跨中心调用还涉及另一类安全问题——凭据管理。每个节点有自己的访问密钥，如果全部放在网关配置里，一旦泄露就是事故。TokenLat采用的是动态下发方式，密钥不落在磁盘上，而是由中心的密钥服务在启动时下发，网关内存中持有，定期轮换。

3. TokenLat的模型网关实践

3.1 整体架构：三张“网”各司其职

TokenLat当前的架构可以简化成三部分：外部接入层、网关控制层、节点适配层。

接入层负责处理来自业务方的HTTP/HTTPS请求，做协议解析、鉴权、限流。控制层是核心，路由决策、缓存管理、计量生成都在这层完成。适配层负责对接不同中心的模型服务，把标准请求转换为目标节点能识别的调用格式。

控制层里有几个容易忽略的组件：模型配置中心、健康检查任务、配额计算器。模型配置中心保存所有模型的路由规则和版本信息，网关节点启动时会拉取全量配置并缓存到本地，配置更新时通过事件通知增量刷新。健康检查任务会定期对各个候选节点做一次探活调用，探活频率默认30秒一次，这个参数其实很讲究，太频繁了会白白消耗节点资源，太疏了又没法及时发现故障。

3.2 关键实现：从路由打分到冷启动控制

路由打分的过程，TokenLat是这么实现的：网关维护一个候选节点列表，对每个节点保存最近状态数据，包括平均时延、错误计数、队列长度等。当一个请求进来，网关会先过滤不可用节点，再按权重计算每个节点的综合得分，得分最高的节点被选中。如果多个节点分数接近（差值小于5%），则按轮询方式在它们之间分配，避免所有请求都涌向一个节点。

这里提到了一个指标（队列长度），很多人会直接看网关侧到节点侧的并发数，其实不太准。因为节点内部还可能排队。TokenLat的做法是让节点适配器在返回响应时附带一个内部队列水位字段，如果节点不支持，就退化为用网关侧的未完成请求数来估算。

模型冷启动是另一个容易踩的坑。一个中心节点如果没有预先加载某个模型，第一次接到请求时要临时加载权重，可能要花几十秒甚至几分钟，这个时间用户根本等不了。TokenLat的处理是用预热任务，在路由表里标记模型在哪些节点已经加载完成，默认情况下新请求只会路由到已加载节点；只有配置了“允许冷启动”的目标，才会进入加载流程。这样可以避免因为看不见的加载过程拖垮用户的交互体验。

3.3 实测数据：接入多个节点之后的真实效果

我拿一个实际场景说话。某内部业务需要跨三个中心调用同一个开源大模型，模型配置为72B参数版本，每个中心各有不同的推理框架。直接对接时，业务方需要自己维护三套API调用代码。接入TokenLat之后，业务方统一走网关的OpenAI兼容接口，对外只需要配置一个API地址和密钥。

实测下来有几个数字值得参考：

• 原有对接代码从三套约1800行缩减为一套约200行，这是代码层面的收益
• 网关层引入的额外缓存完成后时延约3-8毫秒，可以接受
• 通过路由打分，跨中心请求的平均首Token延迟比之前人工指定节点下降约22%
• 成本方面，低峰时段的请求能被自动调度到低价节点，单月推理成本大约节省15%

这些数据不一定适用于所有环境，但至少说明一个问题：网关层不是纯粹的性能损耗，它可以通过路由优化把消耗找回来，甚至带来净收益。

4. 实操中遇到的典型问题与排查记录

4.1 鉴权冲突：各中心都有自己的“入口规则”

第一个遇到的问题是鉴权冲突。每个中心都有自己的账号体系，有的用签名机制，有的用BearerToken，还有的要先申请临时票据再访问。TokenLat做了一层“账号映射”，把一个外部调用方映射到多个中心的不同账号，再由网关统一做二次鉴权。

这个过程中最容易出问题的环节是凭证过期。某个中心返回401错误，网关会尝试刷新对应的账号凭证，刷新失败则把该目标节点标记为“需要人工介入”，同时继续服务其他节点，不能让一个节点的凭证问题影响全局。

4.2 超时设置不当导致连锁堆积

之前提过，早期网关的线程模型被超时拖垮过。后来我们花了很大力气调超时参数。

网关到节点的连接超时设为2秒，读超时设为30秒（不同模型差异很大，流式输出和非流式输出的等待时间完全不同，这个参数不能一刀切）。同时给每个目标节点设置了最大并发上限，达到上限后新的请求直接排队而不是继续往里灌，这样可以把故障控制在一个节点内部，不会殃及整个网关。

这个问题的本质是“快速失败”。与其让所有请求都卡在一个慢节点上，不如尽早让部分请求失败返回，让调用方去重试。规则很简单：容忍单点失败，不允许全局阻塞。

4.3 模型版本管理与灰度路由

多中心部署相同的模型，但中心A的模型版本可能比中心B新一两个小版本。如果业务方没有指定版本，网关默认去哪里？这个策略在TokenLat里叫“版本匹配优先”，即网关先查询业务方是否声明了版本偏好，没有声明的按“默认最新稳定版”处理。

灰度路由就是在此基础上做的。比如新版本模型先在中心A上线，网关把10%的特定测试流量分给新版本，90%走旧版本，观察一段时间没有明显问题再逐步放量。这个功能靠脚本转发是做不到的，需要网关层参与流量分配。

4.4 可观测性：不是“记了日志”就够了

模型网关的可观测性比普通API网关更难做，因为除了常规的请求量、错误率、时延，还需要关注Token消耗分布、节点健康趋势、路由命中率等指标。

实践中我比较推荐的做法是打点明细加采样聚合并行。所有请求都会记录一条最小日志，包括模型名、目标节点、耗时、结果码；涉及Token消耗的记录按1:10采样后上报到监控系统。这样既控制了数据量，又能保留全量请求的追踪能力。出现问题时，先用聚合趋势定位时间窗口，再根据抽样事件做链路回溯，基本能覆盖大部分排查场景。

我还专门给TokenLat做了几个关键告警：新模型请求成功率低于80%且持续5分钟，自动把对应节点从候选集里摘除；路由错误数量每分钟超过50次，通知值班人员；Token计费差额大于10%时，提示人工核对。

5. 如果让我重新做一遍模型网关，有哪些事我会更早做

5.1 先把协议收敛，再谈功能扩展

一开始做TokenLat时，我很想在网关里实现一堆高级能力：多级缓存、复杂路由策略、多租户配额管理。后来发现，这些功能如果没有一个稳定的协议层，全都是在沙子上盖楼。

如果重新来一遍，我会先把协议层做扎实：统一鉴权方式、统一错误码、统一流式格式。这三件事不做完，后面所有功能都会反复返工。网关的接入协议稳定了，业务方才能在上面安心建设，否则今天改一个响应字段，明天换一个鉴权头，上下游都会被你折腾到疯。

5.2 用一个最小闭环验证链路，再横向扩容

不要一上来就接三个中心六个模型。我建议先找两个节点，一个模型，跑通一条完整的链路：外部调用进来，网关选路，节点处理，结果返回，计量落库，账单生成。链路打通的成本远低于同时接入多个节点的适配工作。

这一步走通之后，往横向扩展就有了模板。每新增一个节点，你需要做的工作就变成：部署适配器、配置健康检查、确认模型映射、做一轮全链路回归。四件事，清晰可控。

5.3 控制器的配置变更一定要有“灰度”能力

网关配置变更影响的是所有接入方，频繁出错的配置下发比停服还可怕。TokenLat里加了一个回滚机制，每次配置变更之前自动备份版本，变更后如果告警指标出现异常，可以一键回滚到上一版本。

这个机制的实现并不复杂，但对整个系统的稳定性贡献巨大。我见过不少网关项目，路由规则写错了，直接把请求打到不存在的节点上，结果排查了一整天才发现是配置问题。有了版本化配置管理，这类问题可以控制在几分钟内解决。

6. 一个判断：模型网关会变成算力互联的“默认组件”

在做TokenLat的过程中，我越来越觉得模型网关不是一个临时过渡的组件，而是算力互联网体系里长期存在的基础设施。只要算力节点还在各自为政，只要模型部署依旧异构，网关就有存在的价值。单中心的推理网关可能未来会被模型平台内置能力取代，但跨中心场景下的模型路由、计量、策略控制，短时间内很难被原生系统替代——因为没有任何一个中心为了保护你的上层业务，去改变自己的底层协议。

后面我会继续分享TokenLat在具体流量调度策略上的细化实践，包括动态权重调参、灰度发布流程和成本优化案例。如果你也在做类似的跨中心模型网关项目，欢迎一起交流遇到的坑和解决方案。个人体会就一句话：先把链路跑通，再谈优化；先把一个场景做到极致，再复制到更多场景。