1. 模型孤岛到底卡在哪不是API数量多而是决策分散1.1 一个典型的模型调度现场如果你手里同时维护着七八个模型API大概能体会每个模型都是一座孤岛的别扭。我们2026年年初就是这个状态业务方要的文本生成、多模态理解、语音意图识别散落在不同平台有Qwen系列、GLM系列还有GPU服务器上用 vLLM 起的VLM服务。每个接入方都有自己的SDK、计费口径、限流策略连模型名都不叫一个名字这种事都成了日常——上游传过来的model字段是A平台的命名到B平台就得做一层映射再到本地推理服务又得改成别名。维护成本全堆在人身上。更痛的是故障切换。某个模型一抖业务方第一反应不是看路由层而是直接找人把XXX的流量切到备模型上。人工切流量听起来不难但切之前得回答三个问题备模型的上下文长度够不够这个任务类型它支持工具调用吗成本会不会直接翻倍我当时就意识到这不是模型能力的问题是架构问题。模型越来越多选择模型这个决策却还停留在人肉查文档 拍脑袋的阶段。1.2 为什么2026年这个问题更痛2026年再回头看多模型已经不只是多几个供应商的问题而是出现了几类新的撕裂多尺寸VLM普及同一个系列模型为了适配不同算力出了小尺寸、标准尺寸、大尺寸版本能力曲线不一样价格曲线也不一样。你不可能让所有请求都走最大尺寸。Agent场景的网状调用一个Agent会话里可能涉及主模型、工具调用模型、多模态分析模型、语音ASR模型链路变长任何一个环节的故障都会被放大。入口爆炸同一个Agent中枢要同时服务IM、笔记工具、网页端、定时任务入口多意味着流量模式差异大对路由的诉求也完全不同。模型孤岛的本质就不是模型数量多而是每个模型都自带一套接入方式、一套鉴权、一套运维习惯团队被这些差异牵着走。要终结这种孤岛需要把入口和出口拆开治理入口统一承接各种渠道的会话出口统一接管到底调用哪个模型。这个拆法就是我们最终搭出OpenClaw加良星链4SAPI这套多模型动态路由网关的起点。1.3 解决思路入口和出口分开治理我们的最终架构其实只有两层。第一层是OpenClaw负责所有入口的会话接入和Agent编排第二层是良星链4SAPI负责所有模型出口的统一路由、鉴权和稳定性治理。OpenClaw不直接关心这次调用是qwen还是glm它只把请求交给4SAPI4SAPI也不关心请求来自Teams还是Obsidian它只按任务类型、成本预算、健康状态选一个最合适的模型。这个拆法最大的好处是接入一个新模型时OpenClaw不用动入口通道不用动只需要在4SAPI的模型注册表里加一条记录再配一条路由规则模型就算进网了。下面我会把OpenClaw的部署、4SAPI的设计、动态路由的实现以及踩过的关键坑完整过一遍。2. OpenClaw当Agent中枢部署和接入模型的完整路径2.1 OpenClaw更适合做入口而不是出口OpenClaw这个项目在我们的架构里定位是Agent中枢它不是一个聊天机器人也不是模型网关。它本身处理会话管理、工具调用、多通道接入Microsoft Teams、Obsidian、Web端、命令行都能统一接到同一套Agent逻辑上。我看中它的是两点会话模型清晰一次会话对应一个上下文session有独立的生命周期这对后面接动态路由非常重要。模型层可插拔OpenClaw的模型适配层是一个标准接口我可以把模型调用整体重定向到我们自己搭的4SAPI而不用改OpenClaw的编排逻辑。网上有人拿OpenClaw和WorkBuddy这类个人助手工具比。我的体会是WorkBuddy偏开箱即用的个人助理OpenClaw更像可编程的Agent底座你愿意花时间折腾它给你的扩展空间是完全不同的。尤其是我们这种要接多模型、做动态路由的架构底座的可编程性比开箱体验重要得多。2.2 Ubuntu服务器上的部署步骤我当时是在一台4核16G的Linux服务器上部署的Ubuntu 22.04用Docker Compose方式跑。之所以没用官方的一键脚本是因为我要长期跑网关需要自己控制日志目录、session存储目录和版本升级节奏。Docker Compose的配置大概是这个样子services: openclaw: image: openclaw/openclaw:latest container_name: openclaw-gateway ports: - 8080:8080 volumes: - ./config:/etc/openclaw - ./sessions:/var/lib/openclaw/sessions - ./logs:/var/log/openclaw environment: - OPENCLAW_HOME/var/lib/openclaw - OPENCLAW_LOG_LEVELinfo restart: unless-stopped部署步骤我梳理成清单创建项目目录/opt/openclaw把上面的Compose文件放进去。在./config下准备openclaw.yaml配置基础账号、会话超时、通道开关。先启动一次生成默认目录结构docker compose up -d。用docker compose logs -f确认服务没有初始化报错。用自带的健康检查命令确认各通道就绪openclaw doctor。这里有个容易忽略的细节session目录一定要挂到宿主机持久化。我一开始为了省事没挂volume容器一重建所有会话丢光正在调试的Teams通道直接掉线排查了半天才发现是session没了。Docker部署的首要原则就是配置、会话、日志全部外挂容器随时可丢。2.3 让OpenClaw与4SAPI对话的接入设计OpenClaw的模型层适配在我的场景里改得很直接把它的模型Provider地址指向4SAPI的统一入口例如http://127.0.0.1:9100/v1。这样OpenClaw发起的任何模型调用实际上都会先经过4SAPI做路由再被分发到真正的模型Provider。当时踩过一个理解偏差我以为OpenClaw会自己管理模型列表实际上它的模型列表只是一个命名空间。我在OpenClaw里只需要定义一个逻辑模型名比如agent-main然后把它的base_url指向4SAPIAPI key填4SAPI的网关key。真正的qwen、glm、vlm这些真实模型全部收在4SAPI侧OpenClaw完全不感知。这种逻辑模型名 真实模型路由的分离是多模型网关能落地的基础。如果OpenClaw直接对着每个真实模型配一套连接那我又回到了模型孤岛的老路上。3. 良星链4SAPI四个S构成的路由网关骨架3.1 4SAPI的由来与定位良星链4SAPI是我们内部的项目代号全称是良星链四阶段模型接入网关。4S不是4S店那个4S而是四个以S开头的治理阶段Select能力画像与准入、Switch动态路由与切换、Stabilize稳定性治理、Secure鉴权与审计。之所以叫4SAPI是因为接入一个新模型时无论多简单都必须走完这四个阶段就像车子进4S店保养一样一步都不能省。阶段解决什么典型动作Select新模型到底能干什么能力标签、上下文上限、模式登记Switch请求到底该走哪个模型任务分类、评分路由、权重调整Stabilize模型跪了怎么办健康检查、熔断、重试、故障转移Secure密钥和成本怎么管网关Key、租户配额、成本审计这四件事如果靠口头约定每个模型都会有自己的土规则固化成API网关的强制流程之后新模型接入才能变成填空式操作。3.2 模型注册表先把每个模型的身份证立起来4SAPI的第一步是建模型注册表。我们给每个模型生成一份profile类似身份证里面固定字段包括模型名、所属family、能力标签是否支持Vision、是否支持工具调用、上下文窗口大小、Provider类型云API还是本地vLLM、单千token折算成本、健康检查端点。注册表用YAML维护存到git里做版本管理providers: qwen-max: family: qwen capabilities: [text, tool_call, long_context] context_window: 128000 provider_type: cloud base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 cost_per_1k_tokens: 0.02 health_path: /health timeout_ms: 30000 enabled: true local-glcm-vlm: family: glcm capabilities: [vision, text, tool_call] context_window: 32000 provider_type: vllm base_url: http://10.0.8.6:8000/v1 cost_per_1k_tokens: 0.004 health_path: /health timeout_ms: 60000 enabled: true注意provider_type这个字段。云API和本地推理服务的延迟特征、故障模式完全不同路由算法必须把它们当成两个物种对待。云API胜在稳定、上下文可以开很大本地vLLM胜在便宜、数据不出内网但GPU负载一高延迟就会飙。我们的路由策略里同族模型优先走本地只有任务复杂度超过阈值或本地池健康分不足时才切云上这套逻辑完全靠provider_type来区分。3.3 路由策略默认不选最强只选最合适注册表建好之后最难的不是技术而是产品共识。最开始业务方总是说给我上最强的模型但最强不等于最合适最强模型贵、慢、容易打满限流而实际业务里大量请求都是简单总结、信息抽取用中等模型完全够。4SAPI路由策略里最重要的一条我总结为默认不选最强只选最合适。我们路由时按任务类型分档简单文本问答、关键词抽取走本地小尺寸模型。结构化分析、长文档总结走中等尺寸云模型。多模态图片理解走本地VLM但图片分辨率过高时自动升级到大尺寸VLM。Agent工具调用强制走工具调用能力最强的模型family避免其他模型假装调用工具。这个分档不是拍脑袋定的前期我们做了两周的盲测把历史请求按任务类型切出来用不同模型跑了同样的prompt和评测集对比准确率和成本最后才定下路由表。只要你肯花这个时间后面调路由就有数据支撑而不是哪个模型新就用哪个。4. 动态路由的核心实现评分、熔断和故障转移4.1 请求在网关里的完整生命周期动态路由的难点不在能路由而在路由得好。我把一次完整请求在4SAPI里的流转拆成五个阶段每一步都有明确输入输出入口鉴权校验网关Key拿到调用方身份和配额。任务分类根据prompt特征、请求参数推断任务类型。候选筛选从注册表里找出能力匹配且健康状态正常的模型。评分排序对候选模型算综合分选最高分。调用与兜底调用选中模型失败则按熔断策略转移并记录全链路日志。这四个阶段对应到代码上就是一个类似下面的结构我们内部称它为路由核心整个4SAPI服务的其他部分全是围绕它转的。4.2 评分式路由的落地代码评分路由是我用得最顺的方案。它的核心思想是不追求一种永远正确的规则而是把质量、成本、延迟、健康四个维度做成一个可调权重的评分函数。import time def route(request, registry, runtime): task classify_task(request) # Select阶段硬性过滤 candidates [] for m in registry.providers(): if not m.enabled: continue if not task.required_capabilities.issubset(m.capabilities): continue if runtime.health_score(m.name) 0: continue candidates.append(m) if not candidates: raise NoCandidateError(task) # Switch阶段综合评分 best None best_score -1 for m in candidates: s score(m, task, runtime) if s best_score: best_score s best m # Stabilize阶段带熔断的调用 return invoke_with_circuit(best, request)score函数的权重长这样def score(m, task, runtime): quality runtime.quality_score(m.name, task.type) latency 1 - _normalize(runtime.p95_latency_ms(m.name)) cost 1 - _normalize(m.cost_per_1k_tokens) health runtime.health_score(m.name) # 质量和成本是掐架的两头权重需要按业务调 return (0.4 * quality 0.2 * latency 0.25 * cost 0.15 * health)为什么这么配权重质量放在第一位因为它直接决定业务满意度成本放在第二是因为在质量达标的情况下省钱就是省出了扩容空间。延迟和健康更像安全网前者避免慢模型拖垮体验后者保证不把流量打到已经快死的模型上。权重不能死记我们的经验是每季度review一次。新模型上线时先给它一个保守的质量初值跑两周再让真实数据说话。4.3 预算约束和冷热模型切换评分路由解决最优选择但解决不了预算上限。2026年多模型架构里成本控制已经从事后看账单变成事中熔断。我们给4SAPI加了一层预算约束租户维度每个调用方每天有成本硬顶超过直接返回预算耗尽。动态降价当某个模型当日成本消耗超过阈值自动降权把流量引导到更便宜的模型。夜间削峰低峰期把更多请求导向本地vLLM节省云API配额。这套约束说起来简单做到位的关键在于成本预估要准。我们在注册表里不只是记单价而是实时算单次调用预估成本——prompt长度和max_tokens一起估算避免出现路由选了便宜模型但因为输出特别长反而比贵模型更贵的倒挂。还有一个细节叫冷热模型切换。一个模型如果连续15分钟没被路由选中我们会给它发一个低优先级的探测请求保证权重缓存和连接池不是冷的。否则突发流量一来冷模型被选中后首个请求会白白多花两三秒的预热时间这个延迟用户是能感知的。4.4 熔断器别让故障扩散故障转移不是检测到失败就换一个重试这么简单。我们在4SAPI里给每个模型配了熔断器状态机是经典的三态关闭、打开、半开。关闭正常调用连续失败次数超过阈值我们配的是5次就打开熔断器。打开直接拒绝流量让模型冷静一会儿默认30秒。半开放一个探测请求进来成功就关闭熔断器恢复流量失败则继续保持打开。重点说一个经验熔断要基于task_type分维度统计而不是全局统计。你可能会觉得一个模型挂了就是挂了但实际不是。云上大模型经常出现文本任务正常但多模态任务超时的情况因为多模态请求的图片处理链路额外依赖其他服务。如果全局熔断多模态任务失败几次把文本流量也一起断了这就属于过度反应。我们把熔断键设计成model_name task_type互相不影响效果好很多。5. 踩坑实录session file locked 的完整排查链路5.1 报错现场把网关流量真正打进去之后第一个大坑不是模型路由而是OpenClaw本身抛出的错误agent failed before reply: session file locked (timeout 60000ms)报错发生在OpenClaw回复前session文件被锁等待60秒后超时。最诡异的是它是间歇性的流量一高峰必现低峰期又完全消失。我当时一度怀疑是4SAPI路由太慢导致OpenClaw等不及后来发现完全不是。5.2 逐步排查我先翻了OpenClaw的日志目录在/var/log/openclaw看到大量 worker 进程都在尝试加载同一个session文件。定位过程我走了一遍完整链路确认不是模型调用问题4SAPI侧日志显示请求全部正常返回响应时间也正常。确认报错位置在OpenClaw的回复前阶段说明它还没发起模型请求是本地会话加载卡住了。用lsof /var/lib/openclaw/sessions/xxx.json查看文件占用发现同一个session文件同时被3个进程打开。查进程树发现这几个进程分别来自Teams通道、Web通道和一个定时任务通道。结论逐渐清晰三个入口在相同conversation_id上产生了并发操作而OpenClaw默认用文件锁保护session一致性。设计意图是好但锁等待上限60秒流量冲击下就变成排队排到超时。5.3 根因和解法根因有两层。第一层是OpenClaw的session存储用的单文件锁粒度太粗第二层是我们网关侧在收到响应超时信号后会重试同一个conversation_id相当于自己往火里添柴。重试本意是提高成功率但在session锁场景下重试只是在加长锁等待队列。我们的解法分两步在4SAPI侧重试策略改成只对未达到模型的请求重试一旦模型侧已经返回或确认收到绝不重试。并且给每个conversation_id加了一个去重标记同一个请求id在网关内只处理一次。在OpenClaw侧把session存储从单个JSON文件切换到SQLite锁粒度直接从全局锁变成行级锁并发读写不再互相卡死。# openclaw.yaml 关键调整 session: store: sqlite lock_timeout_ms: 10000 # 之前是文件存储并发一高就锁死顺手还改造了session目录按conversation_id的前两位分目录进一步降低单目录文件数量。改完后再跑压力测试同样的流量下session相关报错归零。5.4 顺带治好的另外两个并发毛病排查过程中还牵出两个并发问题值得提一下。第一个是provider连接池耗尽。4SAPI到vLLM本地的连接池默认只有10个连接一旦多个任务同时请求本地VLM连接池排队严重偶尔把健康检查请求也挤掉造成假故障。把连接池调到50并加了队列上限之后才缓解。第二个是内网推理服务的幂等问题。vLLM在负载高时会返回503OpenClaw会重试但重试的请求如果已经进入推理队列最终是重复计算的。我们在4SAPI侧对每个入站请求生成了唯一request_idvLLM侧用这个id做了幂等过滤才算根治了重复计费。这些坑单看都不难难的是它们同时发作。我复盘时的感受是多模型网关的稳定性问题一半出在模型本身一半出在入口并发和出口路由叠加后的连锁反应。排查时一定要把链路每一层的日志对齐时间戳一层一层剥千万别一上来就怀疑底层模型。6. 跑通之后的验证和运维思路6.1 三组典型用例验证路由结果网关上线前我们做了三组端到端用例验证每一组都代表一类真实流量第一组是纯文本FAQ预期路由到本地小模型。实测延迟从2.8秒降到了1.1秒单次成本下降了约60%。第二组是长文档总结预期路由到云上中等尺寸长上下文模型。实测效果稳定没有出现截断后胡编的问题。第三组是图片理解预期先路由到本地VLM图片分辨率超过阈值时自动升级。实测小图全部留在内网只有大图才走云API成本结构明显优化。为什么要看这三组因为它们基本覆盖了快、好、省三种诉求。路由网关不是单纯省钱的工具而是把快、好、省按任务类型做三角平衡。只要每组用例的结果符合预期路由策略就是对的。6.2 线上该盯哪些指标跑通之后日常运维我只看四类指标路由命中分布每个task_type到底打到了哪些模型上有没有流量意外集中到某个贵的模型。模型健康分每个模型的实时健康分和熔断次数熔断次数飙升说明模型侧在恶化。成本日曲线按租户、按模型维度看成本消耗有没有预算熔断触发。端到端错误率按入口通道看错误率Teams、Obsidian、Web分开统计。我个人强烈建议在仪表盘上把路由决策日志单独列出来。每条决策记录应该包含请求id、任务类型、候选模型列表、每个候选的分数、最终选中模型、实际延迟和成本。这个日志是后续调权的唯一依据。没有这个日志你调的路由权重都是拍脑袋。6.3 后续扩展方向这套架构跑稳之后我们已经在规划几个扩展方向。一是多尺寸VLM的动态分派。同一张图缩略图分析用7B小模型高清细节理解用更大尺寸模型。路由依据不再只是任务类型还要结合图片的分辨率和具体任务要求例如识别画面中的印刷文字和描述画面氛围需要的能力完全不同。二是成本感知的模型训练反馈。4SAPI沉淀了海量任务类型 模型 结果质量的数据这些数据反过来可以指导微调专用小模型让更多流量留在低成本档位。三是更细粒度的会话路由。现在路由是request级别的每一条请求独立决策。后续想做到session级别一个会话的上下文历史如果已经累积到很长就优先路由到长上下文模型而不是让短上下文模型去硬抗。最后分享一个我体会最深的原则多模型动态路由网关这个事开始得越早越好。模型孤岛不会因为模型数量少就不存在哪怕你手里只有两个模型也值得在中间加一层。因为真正值钱的不是那层转发逻辑而是从那层开始沉淀下来的路由数据与治理规范。等模型真多起来的时候你已经有了一套让它们有序协作的机制了。 
长河君 · 2026/9/30 10:38:54 · 阅读 1.2k 多模型动态路由网关：终结模型孤岛的架构设计与落地实践
1. 模型孤岛到底卡在哪不是API数量多而是决策分散1.1 一个典型的模型调度现场如果你手里同时维护着七八个模型API大概能体会每个模型都是一座孤岛的别扭。我们2026年年初就是这个状态业务方要的文本生成、多模态理解、语音意图识别散落在不同平台有Qwen系列、GLM系列还有GPU服务器上用 vLLM 起的VLM服务。每个接入方都有自己的SDK、计费口径、限流策略连模型名都不叫一个名字这种事都成了日常——上游传过来的model字段是A平台的命名到B平台就得做一层映射再到本地推理服务又得改成别名。维护成本全堆在人身上。更痛的是故障切换。某个模型一抖业务方第一反应不是看路由层而是直接找人把XXX的流量切到备模型上。人工切流量听起来不难但切之前得回答三个问题备模型的上下文长度够不够这个任务类型它支持工具调用吗成本会不会直接翻倍我当时就意识到这不是模型能力的问题是架构问题。模型越来越多选择模型这个决策却还停留在人肉查文档 拍脑袋的阶段。1.2 为什么2026年这个问题更痛2026年再回头看多模型已经不只是多几个供应商的问题而是出现了几类新的撕裂多尺寸VLM普及同一个系列模型为了适配不同算力出了小尺寸、标准尺寸、大尺寸版本能力曲线不一样价格曲线也不一样。你不可能让所有请求都走最大尺寸。Agent场景的网状调用一个Agent会话里可能涉及主模型、工具调用模型、多模态分析模型、语音ASR模型链路变长任何一个环节的故障都会被放大。入口爆炸同一个Agent中枢要同时服务IM、笔记工具、网页端、定时任务入口多意味着流量模式差异大对路由的诉求也完全不同。模型孤岛的本质就不是模型数量多而是每个模型都自带一套接入方式、一套鉴权、一套运维习惯团队被这些差异牵着走。要终结这种孤岛需要把入口和出口拆开治理入口统一承接各种渠道的会话出口统一接管到底调用哪个模型。这个拆法就是我们最终搭出OpenClaw加良星链4SAPI这套多模型动态路由网关的起点。1.3 解决思路入口和出口分开治理我们的最终架构其实只有两层。第一层是OpenClaw负责所有入口的会话接入和Agent编排第二层是良星链4SAPI负责所有模型出口的统一路由、鉴权和稳定性治理。OpenClaw不直接关心这次调用是qwen还是glm它只把请求交给4SAPI4SAPI也不关心请求来自Teams还是Obsidian它只按任务类型、成本预算、健康状态选一个最合适的模型。这个拆法最大的好处是接入一个新模型时OpenClaw不用动入口通道不用动只需要在4SAPI的模型注册表里加一条记录再配一条路由规则模型就算进网了。下面我会把OpenClaw的部署、4SAPI的设计、动态路由的实现以及踩过的关键坑完整过一遍。2. OpenClaw当Agent中枢部署和接入模型的完整路径2.1 OpenClaw更适合做入口而不是出口OpenClaw这个项目在我们的架构里定位是Agent中枢它不是一个聊天机器人也不是模型网关。它本身处理会话管理、工具调用、多通道接入Microsoft Teams、Obsidian、Web端、命令行都能统一接到同一套Agent逻辑上。我看中它的是两点会话模型清晰一次会话对应一个上下文session有独立的生命周期这对后面接动态路由非常重要。模型层可插拔OpenClaw的模型适配层是一个标准接口我可以把模型调用整体重定向到我们自己搭的4SAPI而不用改OpenClaw的编排逻辑。网上有人拿OpenClaw和WorkBuddy这类个人助手工具比。我的体会是WorkBuddy偏开箱即用的个人助理OpenClaw更像可编程的Agent底座你愿意花时间折腾它给你的扩展空间是完全不同的。尤其是我们这种要接多模型、做动态路由的架构底座的可编程性比开箱体验重要得多。2.2 Ubuntu服务器上的部署步骤我当时是在一台4核16G的Linux服务器上部署的Ubuntu 22.04用Docker Compose方式跑。之所以没用官方的一键脚本是因为我要长期跑网关需要自己控制日志目录、session存储目录和版本升级节奏。Docker Compose的配置大概是这个样子services: openclaw: image: openclaw/openclaw:latest container_name: openclaw-gateway ports: - 8080:8080 volumes: - ./config:/etc/openclaw - ./sessions:/var/lib/openclaw/sessions - ./logs:/var/log/openclaw environment: - OPENCLAW_HOME/var/lib/openclaw - OPENCLAW_LOG_LEVELinfo restart: unless-stopped部署步骤我梳理成清单创建项目目录/opt/openclaw把上面的Compose文件放进去。在./config下准备openclaw.yaml配置基础账号、会话超时、通道开关。先启动一次生成默认目录结构docker compose up -d。用docker compose logs -f确认服务没有初始化报错。用自带的健康检查命令确认各通道就绪openclaw doctor。这里有个容易忽略的细节session目录一定要挂到宿主机持久化。我一开始为了省事没挂volume容器一重建所有会话丢光正在调试的Teams通道直接掉线排查了半天才发现是session没了。Docker部署的首要原则就是配置、会话、日志全部外挂容器随时可丢。2.3 让OpenClaw与4SAPI对话的接入设计OpenClaw的模型层适配在我的场景里改得很直接把它的模型Provider地址指向4SAPI的统一入口例如http://127.0.0.1:9100/v1。这样OpenClaw发起的任何模型调用实际上都会先经过4SAPI做路由再被分发到真正的模型Provider。当时踩过一个理解偏差我以为OpenClaw会自己管理模型列表实际上它的模型列表只是一个命名空间。我在OpenClaw里只需要定义一个逻辑模型名比如agent-main然后把它的base_url指向4SAPIAPI key填4SAPI的网关key。真正的qwen、glm、vlm这些真实模型全部收在4SAPI侧OpenClaw完全不感知。这种逻辑模型名 真实模型路由的分离是多模型网关能落地的基础。如果OpenClaw直接对着每个真实模型配一套连接那我又回到了模型孤岛的老路上。3. 良星链4SAPI四个S构成的路由网关骨架3.1 4SAPI的由来与定位良星链4SAPI是我们内部的项目代号全称是良星链四阶段模型接入网关。4S不是4S店那个4S而是四个以S开头的治理阶段Select能力画像与准入、Switch动态路由与切换、Stabilize稳定性治理、Secure鉴权与审计。之所以叫4SAPI是因为接入一个新模型时无论多简单都必须走完这四个阶段就像车子进4S店保养一样一步都不能省。阶段解决什么典型动作Select新模型到底能干什么能力标签、上下文上限、模式登记Switch请求到底该走哪个模型任务分类、评分路由、权重调整Stabilize模型跪了怎么办健康检查、熔断、重试、故障转移Secure密钥和成本怎么管网关Key、租户配额、成本审计这四件事如果靠口头约定每个模型都会有自己的土规则固化成API网关的强制流程之后新模型接入才能变成填空式操作。3.2 模型注册表先把每个模型的身份证立起来4SAPI的第一步是建模型注册表。我们给每个模型生成一份profile类似身份证里面固定字段包括模型名、所属family、能力标签是否支持Vision、是否支持工具调用、上下文窗口大小、Provider类型云API还是本地vLLM、单千token折算成本、健康检查端点。注册表用YAML维护存到git里做版本管理providers: qwen-max: family: qwen capabilities: [text, tool_call, long_context] context_window: 128000 provider_type: cloud base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 cost_per_1k_tokens: 0.02 health_path: /health timeout_ms: 30000 enabled: true local-glcm-vlm: family: glcm capabilities: [vision, text, tool_call] context_window: 32000 provider_type: vllm base_url: http://10.0.8.6:8000/v1 cost_per_1k_tokens: 0.004 health_path: /health timeout_ms: 60000 enabled: true注意provider_type这个字段。云API和本地推理服务的延迟特征、故障模式完全不同路由算法必须把它们当成两个物种对待。云API胜在稳定、上下文可以开很大本地vLLM胜在便宜、数据不出内网但GPU负载一高延迟就会飙。我们的路由策略里同族模型优先走本地只有任务复杂度超过阈值或本地池健康分不足时才切云上这套逻辑完全靠provider_type来区分。3.3 路由策略默认不选最强只选最合适注册表建好之后最难的不是技术而是产品共识。最开始业务方总是说给我上最强的模型但最强不等于最合适最强模型贵、慢、容易打满限流而实际业务里大量请求都是简单总结、信息抽取用中等模型完全够。4SAPI路由策略里最重要的一条我总结为默认不选最强只选最合适。我们路由时按任务类型分档简单文本问答、关键词抽取走本地小尺寸模型。结构化分析、长文档总结走中等尺寸云模型。多模态图片理解走本地VLM但图片分辨率过高时自动升级到大尺寸VLM。Agent工具调用强制走工具调用能力最强的模型family避免其他模型假装调用工具。这个分档不是拍脑袋定的前期我们做了两周的盲测把历史请求按任务类型切出来用不同模型跑了同样的prompt和评测集对比准确率和成本最后才定下路由表。只要你肯花这个时间后面调路由就有数据支撑而不是哪个模型新就用哪个。4. 动态路由的核心实现评分、熔断和故障转移4.1 请求在网关里的完整生命周期动态路由的难点不在能路由而在路由得好。我把一次完整请求在4SAPI里的流转拆成五个阶段每一步都有明确输入输出入口鉴权校验网关Key拿到调用方身份和配额。任务分类根据prompt特征、请求参数推断任务类型。候选筛选从注册表里找出能力匹配且健康状态正常的模型。评分排序对候选模型算综合分选最高分。调用与兜底调用选中模型失败则按熔断策略转移并记录全链路日志。这四个阶段对应到代码上就是一个类似下面的结构我们内部称它为路由核心整个4SAPI服务的其他部分全是围绕它转的。4.2 评分式路由的落地代码评分路由是我用得最顺的方案。它的核心思想是不追求一种永远正确的规则而是把质量、成本、延迟、健康四个维度做成一个可调权重的评分函数。import time def route(request, registry, runtime): task classify_task(request) # Select阶段硬性过滤 candidates [] for m in registry.providers(): if not m.enabled: continue if not task.required_capabilities.issubset(m.capabilities): continue if runtime.health_score(m.name) 0: continue candidates.append(m) if not candidates: raise NoCandidateError(task) # Switch阶段综合评分 best None best_score -1 for m in candidates: s score(m, task, runtime) if s best_score: best_score s best m # Stabilize阶段带熔断的调用 return invoke_with_circuit(best, request)score函数的权重长这样def score(m, task, runtime): quality runtime.quality_score(m.name, task.type) latency 1 - _normalize(runtime.p95_latency_ms(m.name)) cost 1 - _normalize(m.cost_per_1k_tokens) health runtime.health_score(m.name) # 质量和成本是掐架的两头权重需要按业务调 return (0.4 * quality 0.2 * latency 0.25 * cost 0.15 * health)为什么这么配权重质量放在第一位因为它直接决定业务满意度成本放在第二是因为在质量达标的情况下省钱就是省出了扩容空间。延迟和健康更像安全网前者避免慢模型拖垮体验后者保证不把流量打到已经快死的模型上。权重不能死记我们的经验是每季度review一次。新模型上线时先给它一个保守的质量初值跑两周再让真实数据说话。4.3 预算约束和冷热模型切换评分路由解决最优选择但解决不了预算上限。2026年多模型架构里成本控制已经从事后看账单变成事中熔断。我们给4SAPI加了一层预算约束租户维度每个调用方每天有成本硬顶超过直接返回预算耗尽。动态降价当某个模型当日成本消耗超过阈值自动降权把流量引导到更便宜的模型。夜间削峰低峰期把更多请求导向本地vLLM节省云API配额。这套约束说起来简单做到位的关键在于成本预估要准。我们在注册表里不只是记单价而是实时算单次调用预估成本——prompt长度和max_tokens一起估算避免出现路由选了便宜模型但因为输出特别长反而比贵模型更贵的倒挂。还有一个细节叫冷热模型切换。一个模型如果连续15分钟没被路由选中我们会给它发一个低优先级的探测请求保证权重缓存和连接池不是冷的。否则突发流量一来冷模型被选中后首个请求会白白多花两三秒的预热时间这个延迟用户是能感知的。4.4 熔断器别让故障扩散故障转移不是检测到失败就换一个重试这么简单。我们在4SAPI里给每个模型配了熔断器状态机是经典的三态关闭、打开、半开。关闭正常调用连续失败次数超过阈值我们配的是5次就打开熔断器。打开直接拒绝流量让模型冷静一会儿默认30秒。半开放一个探测请求进来成功就关闭熔断器恢复流量失败则继续保持打开。重点说一个经验熔断要基于task_type分维度统计而不是全局统计。你可能会觉得一个模型挂了就是挂了但实际不是。云上大模型经常出现文本任务正常但多模态任务超时的情况因为多模态请求的图片处理链路额外依赖其他服务。如果全局熔断多模态任务失败几次把文本流量也一起断了这就属于过度反应。我们把熔断键设计成model_name task_type互相不影响效果好很多。5. 踩坑实录session file locked 的完整排查链路5.1 报错现场把网关流量真正打进去之后第一个大坑不是模型路由而是OpenClaw本身抛出的错误agent failed before reply: session file locked (timeout 60000ms)报错发生在OpenClaw回复前session文件被锁等待60秒后超时。最诡异的是它是间歇性的流量一高峰必现低峰期又完全消失。我当时一度怀疑是4SAPI路由太慢导致OpenClaw等不及后来发现完全不是。5.2 逐步排查我先翻了OpenClaw的日志目录在/var/log/openclaw看到大量 worker 进程都在尝试加载同一个session文件。定位过程我走了一遍完整链路确认不是模型调用问题4SAPI侧日志显示请求全部正常返回响应时间也正常。确认报错位置在OpenClaw的回复前阶段说明它还没发起模型请求是本地会话加载卡住了。用lsof /var/lib/openclaw/sessions/xxx.json查看文件占用发现同一个session文件同时被3个进程打开。查进程树发现这几个进程分别来自Teams通道、Web通道和一个定时任务通道。结论逐渐清晰三个入口在相同conversation_id上产生了并发操作而OpenClaw默认用文件锁保护session一致性。设计意图是好但锁等待上限60秒流量冲击下就变成排队排到超时。5.3 根因和解法根因有两层。第一层是OpenClaw的session存储用的单文件锁粒度太粗第二层是我们网关侧在收到响应超时信号后会重试同一个conversation_id相当于自己往火里添柴。重试本意是提高成功率但在session锁场景下重试只是在加长锁等待队列。我们的解法分两步在4SAPI侧重试策略改成只对未达到模型的请求重试一旦模型侧已经返回或确认收到绝不重试。并且给每个conversation_id加了一个去重标记同一个请求id在网关内只处理一次。在OpenClaw侧把session存储从单个JSON文件切换到SQLite锁粒度直接从全局锁变成行级锁并发读写不再互相卡死。# openclaw.yaml 关键调整 session: store: sqlite lock_timeout_ms: 10000 # 之前是文件存储并发一高就锁死顺手还改造了session目录按conversation_id的前两位分目录进一步降低单目录文件数量。改完后再跑压力测试同样的流量下session相关报错归零。5.4 顺带治好的另外两个并发毛病排查过程中还牵出两个并发问题值得提一下。第一个是provider连接池耗尽。4SAPI到vLLM本地的连接池默认只有10个连接一旦多个任务同时请求本地VLM连接池排队严重偶尔把健康检查请求也挤掉造成假故障。把连接池调到50并加了队列上限之后才缓解。第二个是内网推理服务的幂等问题。vLLM在负载高时会返回503OpenClaw会重试但重试的请求如果已经进入推理队列最终是重复计算的。我们在4SAPI侧对每个入站请求生成了唯一request_idvLLM侧用这个id做了幂等过滤才算根治了重复计费。这些坑单看都不难难的是它们同时发作。我复盘时的感受是多模型网关的稳定性问题一半出在模型本身一半出在入口并发和出口路由叠加后的连锁反应。排查时一定要把链路每一层的日志对齐时间戳一层一层剥千万别一上来就怀疑底层模型。6. 跑通之后的验证和运维思路6.1 三组典型用例验证路由结果网关上线前我们做了三组端到端用例验证每一组都代表一类真实流量第一组是纯文本FAQ预期路由到本地小模型。实测延迟从2.8秒降到了1.1秒单次成本下降了约60%。第二组是长文档总结预期路由到云上中等尺寸长上下文模型。实测效果稳定没有出现截断后胡编的问题。第三组是图片理解预期先路由到本地VLM图片分辨率超过阈值时自动升级。实测小图全部留在内网只有大图才走云API成本结构明显优化。为什么要看这三组因为它们基本覆盖了快、好、省三种诉求。路由网关不是单纯省钱的工具而是把快、好、省按任务类型做三角平衡。只要每组用例的结果符合预期路由策略就是对的。6.2 线上该盯哪些指标跑通之后日常运维我只看四类指标路由命中分布每个task_type到底打到了哪些模型上有没有流量意外集中到某个贵的模型。模型健康分每个模型的实时健康分和熔断次数熔断次数飙升说明模型侧在恶化。成本日曲线按租户、按模型维度看成本消耗有没有预算熔断触发。端到端错误率按入口通道看错误率Teams、Obsidian、Web分开统计。我个人强烈建议在仪表盘上把路由决策日志单独列出来。每条决策记录应该包含请求id、任务类型、候选模型列表、每个候选的分数、最终选中模型、实际延迟和成本。这个日志是后续调权的唯一依据。没有这个日志你调的路由权重都是拍脑袋。6.3 后续扩展方向这套架构跑稳之后我们已经在规划几个扩展方向。一是多尺寸VLM的动态分派。同一张图缩略图分析用7B小模型高清细节理解用更大尺寸模型。路由依据不再只是任务类型还要结合图片的分辨率和具体任务要求例如识别画面中的印刷文字和描述画面氛围需要的能力完全不同。二是成本感知的模型训练反馈。4SAPI沉淀了海量任务类型 模型 结果质量的数据这些数据反过来可以指导微调专用小模型让更多流量留在低成本档位。三是更细粒度的会话路由。现在路由是request级别的每一条请求独立决策。后续想做到session级别一个会话的上下文历史如果已经累积到很长就优先路由到长上下文模型而不是让短上下文模型去硬抗。最后分享一个我体会最深的原则多模型动态路由网关这个事开始得越早越好。模型孤岛不会因为模型数量少就不存在哪怕你手里只有两个模型也值得在中间加一层。因为真正值钱的不是那层转发逻辑而是从那层开始沉淀下来的路由数据与治理规范。等模型真多起来的时候你已经有了一套让它们有序协作的机制了。