一、项目背景

这个项目开始的时候，我们所在的团队服务于某省级国资集团的智能化中台建设。彼时他们内部已经陆续上线了七八种大模型能力，既有私有化部署在推理一体机上的稠密模型，也有对接某头部云厂商的托管模型，还有几个团队基于开源社区权重自行微调出来的垂直领域模型。问题随之而来：这些模型实例散落在不同团队的服务器上，命名完全不统一，有时候同一个基座模型被三个团队各部署了一份，版本号还互相打架。业务侧要调一个"能处理长文档摘要的模型"，得先去问清楚到底哪个服务的哪个版本可用、还剩多少显存、单次调用大概多少钱。

我们当时接到的需求很朴素：先把所有能用的模型"登记造册"，让业务方不用关心背后部署在哪、叫什么名字，只需要在网关上声明"我要一个支持中文长文本、延迟低于 800 毫秒、性价比优先的模型"，系统就能把请求分发出去。这背后就是模型注册中心与能力画像要解决的问题——它是一套我们采用的 AI 网关的核心模块，负责把底层杂乱的模型实例抽象成一个个可检索、可比较、可治理的"能力对象"。没有这层抽象，上层的智能路由、计量配额都无从谈起。

二、落地场景

落地场景集中在四个环节。第一是模型注册中心：所有模型实例上线后都先到网关登记，注册信息包括接入地址、协议类型（OpenAI 风格或 gRPC）、所属团队、上线时间与负责人。第二是能力画像：每个模型被打上结构化标签，覆盖语言支持（中文/英文/多语）、模态（文本/视觉/语音）、上下文窗口大小、单次推理成本、典型延迟分位数、适用任务类型。第三是版本管理与灰度：同一模型的不同版本共存于注册中心，通过权重路由做灰度放量，出问题时一键回滚。第四是健康探测与摘除：网关对模型实例做定时探活，异常实例自动移出路由池，避免把流量打到坏实例上。

在这个项目里，能力画像真正发挥作用的地方是智能分发。过去业务方硬编码调用地址，换模型要改代码、走发版；现在只写语义化请求，网关根据画像实时计算最优实例。注册中心相当于给整个中台的模型能力建了一张"总账本"，谁有什么能力、健康与否、花多少钱，第一次有了统一视图。

三、关键技术挑战与解决思路

多模型统一注册。 我们面对的第一个问题是接入协议不统一。私有化推理框架暴露的是 OpenAI 兼容接口，自研微调服务用的是内部 gRPC，还有一部分旧模型只提供 WebSocket 流式接口。我们的做法是网关接入层做协议归一化，把各种协议都收敛成一套内部统一的能力描述对象，注册中心只认这套标准化 schema，不关心背后的具体实现。注册信息里额外带一个"能力指纹"，由模型自报的 tokenizer 类型、最大 batch、KV 缓存上限等组成，避免后续路由层误判。这样即便底层换了推理框架，注册中心的记录也不用改。

能力画像建模。 画像不是拍脑袋打标签，而是把静态属性和动态指标分开处理。静态属性（语言、模态、上下文窗口）由注册时填写；动态指标（延迟 P50/P95、单位 token 成本、当前 QPS 水位）由计量层实时回灌。我们用一张维度表来描述画像，前端看板按维度筛选。难点在于成本怎么统一计算——私有化模型的电费、折旧要折算成单位成本，托管模型按调用量计费，最终统一归一到"每千 token 成本"这一可比维度，路由策略才能算得清楚。

版本灰度与回滚。 同一模型的多版本共存是常态。我们的方案是注册中心给每个模型维护一个版本链表，路由层按版本权重做流量分配。灰度时先把约 5% 流量切到新版本，观察错误率和延迟基线，再逐步放量。回滚不是删版本，而是把权重瞬间调回旧版本，保证切换耗时控制在秒级。这里的关键是把"版本"作为注册中心的一等公民，而不是藏在部署脚本里——版本信息一旦进入注册中心，灰度、回滚、审计都变成可配置的操作。

健康探测与摘除。 模型实例比普通微服务更脆弱：显存碎片、长尾请求堆积都会导致个别实例"假死"但进程还在。我们设计了两级探测——轻量级探活（ping 一次小请求）每 10 秒一次，业务级探针（丢一个真实结构的短请求看能否正常返回）每 60 秒一次。连续两次业务级探测失败即标记为不健康，路由层立即摘除。摘除后保留实例元数据，便于排障而非直接销毁，等实例恢复探活通过再自动加回路由池。

四、效果数据

上线约一个季度后，我们统计了关键指标（均为脱敏示意值）：

从集团中台视角，最大的收益是"能力可见"——哪个团队用了什么模型、花了多少钱、健康与否，第一次有了统一视图，而不是靠口口相传。

五、可复用经验总结

第一，先有注册再有路由。我们当时踩过的坑是有人想直接做智能路由，但底层模型都没收口，路由策略写不出也测不了。注册中心是地基，必须先把模型"登记造册"再做上层分发逻辑，否则一切都是空中楼阁。

第二，画像驱动智能分发。把模型能力结构化、可比较，业务方用语义而不是地址来调用，这才是网关的价值所在。成本、延迟、语言这些维度统一到可比口径后，路由策略才能算得清楚，分发才有依据。

第三，版本和探活要内置。版本灰度、健康摘除不要靠运维手动操作，必须做成注册中心与路由层的原生能力，否则线上一出问题就只能靠人肉切流量，既慢又容易出错。

案例片段（已脱敏）： 模型注册与能力画像配置片段（网关注册中心 YAML）：yaml models:  - id: qwen-chat-72b-v2    provider: private-vllm    endpoint: grpc://10.20.3.11:9000    protocol: openai-compat    profile:      languages: [zh, en]      modality: [text]      context_window: 32768      cost_per_1k_tokens: 0.012   # 私有化折算单位成本      latency_p95_ms: 760      tasks: [summary, qa, classify]    version_chain:      - tag: v2.1        weight: 0.95      - tag: v2.0        weight: 0.05    health:      liveness_interval_s: 10      probe_interval_s: 60      fail_threshold: 2