孔小哥1. 多模型服务统一部署：为什么这件事必须做
1.1 从“模型上线”到“模型运营”的痛点转移
做了三四年 AI 平台相关的工作，我越来越明显地感觉到一件事：算法团队真正卡脖子的地方，早就不在训练环节，而是在“模型训练完之后怎么办”这一环。以前大家关心 loss 降没降、准确率涨没涨，现在模型迭代速度快了、业务场景多了，问题变成了——手上十几个甚至几十个 PyTorch 模型，怎么把它们稳定、高效地同时跑起来，还让不同业务线互不干扰。
举一个我实际遇到的场景。公司原来只有一套推荐模型，单独起了几个 Python 进程部署，用 Nginx 做负载均衡，勉强能跑。半年后，算法团队陆续上线了 CTR 预估、向量召回、文本分类、图像审核四个方向的模型，有的模型还拆成了多个版本同时灰度。问题很快就来了：每个模型的依赖版本不一样（有的是 PyTorch 1.13，有的升到了 2.x），单独拉进程部署导致端口越开越多，配置散落在一堆 systemd 脚本和 Dockerfile 里，新同事接手光梳理服务关系就花了整整一周。更难受的是，GPU 显存利用率参差不齐，有的模型卡跑得冒烟，有的模型卡闲着。
这就是我写这篇实战笔记的初衷：把多模型服务统一部署、统一管理的门道讲清楚。对 AI 平台工程师、MLOps 工程师、后端开发，以及模型训练完不知道怎么上生产的算法工程师来说，这篇文章应该能帮上忙。我会把架构思路、技术选型、实操步骤、问题排查都展开聊，基本上都是我在企业环境里踩过坑之后沉淀下来的东西。
1.2 统一部署方案选型：从并发进程到共享服务层
面对多模型部署，最直接的想法是每个模型单独起一个服务，然后用负载均衡把流量分过去。这种方案在小规模场景下没毛病，优点是完全隔离、故障域清晰、出问题互不影响。但一旦模型数量上了两位数，运维复杂度就指数上升，主要显现在三个方面。
第一是资源碎片化严重。每个模型单独分配一个或者两个 GPU 实例，但不同模型对资源的需求差别很大：有的模型一次推理只要几十毫秒、显存占用 1~2GB，单独占一张 A10 实在浪费；有的模型峰值流量一天只有几百次请求，给它单独留的 GPU 基本处于闲置状态。第二是版本和依赖管理成本高。PyTorch 版本、CUDA 版本、Python 包依赖，每个模型各有一套，镜像仓库越来越臃肿，安全补丁更新一次要重新构建一堆镜像。第三是接口风格不统一。不同算法工程师写的服务端代码风格差异巨大，有的用 FastAPI，有的用 Flask，有的直接裸写 socket，接入方调用起来非常痛苦。
所以我更推荐的做法是：在模型推理层之上加一个共享的服务治理层，统一接收请求，按模型名和版本路由到底层具体的推理实例。底层实例可以是独立进程，也可以是共享进程内的模型副本，具体取决于框架支撑能力。这样做的好处是——接入方只面对一个入口，接口规范统一；资源的分配可以在服务层动态调度，显存紧张的模型实例可以合并到同一张卡上，提升了利用率；模型版本升级可以只在服务层做灰度切换，不需要给调用方发通知。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. PyTorch 多模型服务的技术地基与核心组件
2.1 模型生产化前的三个准备步骤
很多人在本地跑 PyTorch 模型很顺，一旦要放到服务端做多模型共享部署，就发现一堆问题。根源在于模型还没有“生产化”，我总结了三个必须提前处理的步骤。
第一步是模型序列化格式的统一。直接保存 model.state_dict() 加上 pickle 序列化完整模型对象，在单机实验时没问题，但到服务端就麻烦了：pickle 本质上会执行任意代码，存在设计风险，而且对 PyTorch 版本的强依赖让模型很难跨版本加载。现在主流做法是导出成 TorchScript 格式，或者用 TorchDynamo 把模型编译成更稳定的中间表示。TorchScript 的核心思路是把模型的 forward 计算过程固化成静态图描述，脱离原始 Python 类也能加载执行，这为多模型共存提供了版本隔离的基础。有些模型里包含动态控制流（比如根据不同输入长度走不同分支），导出时容易报错，我通常用 torch.jit.trace 加一组覆盖典型输入形状的样例数据来绕过，或者直接改用 TorchDynamo 的 torch.compile 导出。
第二步是模型文件的版本化存储。这不是简单地把 model.pt 传到对象存储就完事，而是要建立一个清晰的版本命名规范，并和算法团队的实验管理平台打通。我的习惯是目录结构按 模型名/版本号/模型文件 组织，版本号用语义化规范（主版本.次版本.修订号），同时记录模型的精度指标、训练数据集、PyTorch 版本、输入输出签名等信息。这些元数据看起来琐碎，多模型规模大了以后，回溯线上模型行为异常时就是救命稻草。
第三步是输入输出的协议约定。每个模型最好在服务启动时就注册自己的输入输出 schema，比如输入是文本还是向量、维度是多少、字段名是什么。统一 schema 之后，服务层可以做请求校验、数据预处理、结果后处理，算法工程师就不再需要为每个模型写一套独立的参数解析逻辑了。
2.2 服务框架选型对比：TorchServe、Triton、vLLM
多模型服务的框架选择，直接决定了后面运维的体感。市面上主流的开源方案有三个方向，我分别说一下我的实际使用感受。
TorchServe 是 PyTorch 官方推出的模型服务框架，和 PyTorch 生态集成的顺滑度最高。它的 management API 支持运行时注册模型、查询模型状态、设置模型版本，这个能力在动态增加模型时非常关键。基本流程是先用 torch-model-archiver 把模型打成 .mar 包，然后通过 REST 请求或者配置文件的 model_store 目录来管理模型加载和卸载。TorchServe 也内置了模型版本管理，支持在同一个模型名下维护多个版本流量分发，这对灰度发布非常有帮助。缺点是高并发场景下原生性能不算最极致，需要配合批处理参数调优，另外对 GPU 显存的精细控制只能做到每个模型一个工作线程的模式，没法直接在框架层做显存共享。
NVIDIA Triton Inference Server 是另一种主流选择，它在性能优化上做得更激进，尤其对 GPU 推理场景有深度优化。Triton 支持 PyTorch 模型通过 TorchScript 或者 ONNX 格式加载，支持动态批处理（Dynamic Batching），可以把多个请求自动聚合后一起推理，显著提升 GPU 利用率。在多模型场景下，Triton 的模型仓库管理机制和调度策略非常灵活，可以给每个模型单独设置实例数量、显存占比、最大批处理大小。代价是学习曲线比较陡峭，配置项非常多，初次上手容易被各种参数淹没。
如果是处理 LLM 或者生成式模型，vLLM 是专门针对这类场景做了优化的框架，基于 PagedAttention 机制管理 KV Cache，吞吐量明显优于通用推理框架。如果企业内部同时有传统 CV 模型、推荐模型和 LLM 模型，我建议不要试图用一个框架吃遍所有场景，而是统一服务入口、底层混合部署多种推理引擎。这个思路后面会详细讲。
2.3 请求路由与多模型注册：API 网关层如何设计
有了底层的推理框架，接下来需要解决的关键问题就是“请求到底应该发给谁”。我在实际项目里的做法是在推理框架之上加一层 API 网关，它不负责具体的模型计算，而是负责协议转换、路由分发、鉴权限流和灰度策略。
路由规则的设计主要靠模型名加版本号来标识目标。比如一个请求的路径设计为 /v1/models/{model_name}/versions/{version}/predict，网关解析出模型名和版本后，再到内部的模型注册表里查对应实例的地址。
模型注册表是实现多模型统一管理的中枢，我会用一个分布式协调服务（比如 etcd 或者 Consul）来维护模型实例的存活状态和元数据。每个模型实例启动后主动上报自己的模型列表、健康状态、当前负载、GPU 显存数据，网关定期拉取并缓存一份快照。这样当某个模型实例崩溃或扩缩容时，网关不需要手动改配置就能感知到变化，实现了服务发现的自动化。
灰度发布是这个架构里收益很大的能力。新模型版本上线时，在注册表里把新版本的权重从 0% 逐步调到 100%，网关按照权重随机分配流量，遇到线上指标波动马上回滚。这里的配置和开关我习惯全部外置到一个配置中心，改动不需要重新部署代码。
3. 核心实操：从零搭建统一模型服务网关
3.1 模型仓库与版本控制设计
这部分我结合一个实际的搭建过程来写，目标是给读者一套可以直接套用的落地路径。假设现在有三个 PyTorch 模型需要统一部署：一个 BERT 文本分类模型、一个 ResNet 图像分类模型、一个 DeepFM 推荐排序模型，分别来自三个算法团队，PyTorch 版本和使用场景各不相同。
第一步是在对象存储上建立模型仓库目录，结构如下：
code复制models/
├── text_classifier/
│ ├── v1.0.0/
│ │ ├── model.pt
│ │ └── metadata.json
│ └── v1.1.0/
│ ├── model.pt
│ └── metadata.json
├── image_classifier/
│ └── v2.3.1/
│ ├── model.pt
│ └── metadata.json
└── rank_model/
└── v0.9.0/
├── model.pt
└── metadata.json
metadata.json 记录关键信息，我通常至少包含这些字段：
json复制{
"model_name": "text_classifier",
"model_version": "1.1.0",
"framework": "pytorch",
"pytorch_version": "2.1.0",
"input_schema": {
"type": "object",
"properties": {
"text": {"type": "string"},
"max_length": {"type": "integer", "default": 128}
}
},
"output_schema": {
"type": "array",
"items": {"type": "number"}
},
"gpu_memory_mb": 2048,
"created_at": "2026-03-10T10:00:00Z",
"metrics": {"accuracy": 0.931, "f1": 0.902}
}
这里的经验是：input_schema 和 output_schema 一定要在模型注册时就写清楚，网关做请求校验会依赖它，后续接入方的 SDK 自动生成也会基于这份 schema。
3.2 动态模型加载与 GPU 显存调度
多模型服务落地过程中，GPU 显存的分配策略是最容易引发争论的环节。模型推理服务和训练不同，它不是持续打满 GPU 的，而是按请求流量波动。如果每个模型静态独占 GPU，资源浪费是必然的。我的方案是引入“热点模型驻留 + 冷模型按需加载”的机制。
核心思路是在一个 GPU 实例上启动多个模型服务，每个模型以 worker 形式存在，通过显存剩余量判断是否可以继续加载新模型。用 Triton 来举例，每个模型可以配置独立的 instance_group 和 max_batch_size，加载多少个模型由模型仓库的配置和显存规划共同决定。
在资源规划上，我一般先做一轮模型画像评估：把每个模型在不同 batch size 下的显存占用和推理时延跑一遍，形成一张表格。假设一张 32GB 显存的 A100 上，BERT 模型 FP16 精度占用 4GB，ResNet 占用 3GB，DeepFM 占用 5GB，那理论上可以同时驻留 3~4 个模型，还需要额外预留 2GB 作为推理过程的中间缓冲。
这里有一个比较实用的调度策略：对于时延敏感的在线模型，保持常驻；对于离线或准实时的批量推理模型，支持运行时动态加载和卸载。比如 DeepFM 推荐模型，白天核心时段流量高，保持常驻；凌晨流量低，可以临时卸载，把 GPU 让给凌晨跑批任务，这样能明显降低 GPU 资源的总体占用。
实际操作中我用到的加载和卸载接口，以 Triton 为例：
bash复制# 加载指定模型
curl -X POST http://localhost:8000/v2/repository/models/rank_model/load
# 卸载指定模型
curl -X POST http://localhost:8000/v2/repository/models/rank_model/unload
# 查询模型状态
curl http://localhost:8000/v2/repository/models/rank_model
这套接口组合起来，就可以在外部写一个定时任务或者响应式调度器，根据业务流量的波峰波谷自动调整模型驻留状态。我在实际项目里用 Python 写了一个简单的调度器，每天早上 7 点加载核心推荐模型，晚上 11 点卸载不重要模型，部署在 K8s 的 CronJob 上，运行非常稳。
3.3 请求编排与动态批处理
统一服务网关要处理的另一个重要问题是“请求过来之后，内部如何组织并行计算”。多模型并存时，流量天然是异构的：图像分类请求可能是一批 32 张图片，文本分类请求是几段长短不一的文本，推荐模型请求的特征维度又不一样。
如果单独逐个处理请求，GPU 的算力实际上被浪费了。动态批处理是解决这个问题的关键手段，它的原理是：将一小段时间窗口内到达的请求自动聚合为一个 batch，一次性送入模型推理，再从 batch 层面拆开返回结果。因为 GPU 适合并行计算，batch 越大单位算力成本越低，但 batch 太大会引入等待延迟，需要在吞吐和响应时间之间做权衡。
Triton 的 Dynamic Batching 配置比较直观，关键参数在模型的 config.pbtxt 里：
code复制max_batch_size: 32
dynamic_batching {
preferred_batch_size: [4, 8, 16]
max_queue_delay_microseconds: 1000
}
preferred_batch_size是希望凑到的 batch 尺寸，达到 4、8、16 就立即送入推理，避免让请求傻等。max_queue_delay_microseconds是最大排队时间，超过这个时间即使 batch 没凑满也会送去推理，避免尾部延迟过高。
TorchServe 也提供了类似的 batch_size 和 max_batch_delay 参数，在 config.properties 里配置：
code复制batch_size=16
max_batch_delay=1000
这部分的调优经验是：batch 大小的选择不能拍脑袋，得根据实际的流量模型和模型计算量来定。对于计算密集型模型（如 ResNet），batch 增大带来的吞吐收益明显，可以把 batch 设大一点；对于小模型或者 IO 密集型模型，batch 增大反而可能因为排队等待拉高延迟，需要更保守地设置。
4. 生产环境的日志、安全与数据治理
4.1 日志采集规范与审计
多模型服务上线之后，日志问题是我个人体会最深的一个环节。做模型训练时大家往往只关心 loss 曲线，但到了生产环境，模型服务的日志就是整个系统的“黑匣子”，出了问题全靠日志定位。
我在统一网关层面强制要求所有请求和响应都记录结构化日志，至少包含以下字段：请求 ID、时间戳、调用方应用名、模型名、模型版本、输入数据的校验摘要（不记录完整明文）、推理耗时、返回状态码。之所以不记录完整输入数据，是为了避免用户隐私数据在日志系统中过度留存。
前段时间业内热议过的“AI 中转站用户请求日志泄露”事件，其实就是典型的日志治理缺失。一些模型服务聚合平台在处理大量用户请求时，把输入输出的全部明文内容直接写进日志，并且保存在了权限管控不严的对象存储里，被安全研究人员扫描到后形成了数据泄露。这个教训非常值得警醒——凡是涉及用户数据的日志，哪怕只是文本片段，也要做脱敏处理。
我常用的脱敏手段包括：用户 ID 做 Hash 处理，只保留前几位便于关联分析；文本内容做关键词掩码；向量数据直接丢弃或者只记录维度信息。日志系统本身的权限也要严格管理，生产环境的日志存储必须和测试环境隔离，访问需要走审批流程。
4.2 数据脱敏与访问控制
模型服务层的数据流通常有三段：入口请求、内部处理、返回响应。三段各自的安全侧重点不同。
入口请求的访问控制是基础层。网关会对每个请求做身份认证和权限校验，判断调用方是否有权限访问某个模型。这里我建议使用标准的 API Key 或者 JWT 机制，API Key 按调用方维度下发，支持独立吊销和限额，方便控制滥用。权限粒度细化到“模型 + 版本”级别，不允许存在一个 Key 能调用所有模型的通配模式。
内部处理阶段的数据保护核心是“最小化原则”。比如文本分类模型，只需要输入文本内容，不需要用户 ID、IP 这些元信息，网关在把请求转发给推理实例时就要主动剥离无关字段。很多框架默认会把原始请求体原样传给模型 worker，这一点需要重点检查。
返回响应阶段要注意的是模型推理结果可能本身就有敏感信息。比如图像审核模型输出的人脸坐标、文本生成模型输出的私人信息片段。我的做法是在网关层对输出做统一的检查和后处理，加上漏出检测策略，一旦发现可疑内容就走告警流程。
4.3 监控告警体系
多模型服务的监控维度，和普通 Web 服务相比要更多样一些。除了常规的 QPS、延迟、错误率，还需要关注模型特有的指标。
第一个是推理精度漂移。模型上线后，输入数据的分布会随着时间变化，导致推理结果的准确率下降。比如一个做文本情感分类的模型，训练数据主要来自电商评论，上线三个月后突然接入了社交媒体的评论内容，语料风格差异大，模型表现就会明显下滑。我在网关层设计了抽样回放机制，按比例采样线上请求，做人工标注或者弱标签比对，定期计算精度变化趋势。
第二个是 GPU 资源指标。除了 CPU、内存、网络，GPU 利用率、显存使用量、GPU 温度、功耗这些指标都要纳入监控。显存泄漏是 PyTorch 服务一个多发问题，长时间运行后显存占用逐渐上涨，最终触发 OOM。我用一个定时任务每 5 分钟记录所有推理实例的显存占用曲线，设置增长趋势告警，能在 OOM 发生前提前介入。
第三个是依赖健康状态。模型服务往往依赖特征存储、向量数据库、对象存储等外部组件，这些依赖的可用性和延迟变化，会直接影响模型服务的稳定性。监控系统需要对这些下游依赖做主动健康检查（比如用探针请求模拟真实调用），而不是单纯依赖被动指标。
5. 落地过程中的常见问题与排查实录
5.1 多版本 PyTorch 依赖冲突
这是个非常典型的问题。不同算法团队用的 PyTorch 版本不一样，如果想把多个模型的推理实例塞进同一个镜像，import torch 阶段就可能直接报错。我在项目的早期阶段，曾经尝试把 BERT 模型（PyTorch 1.13）和最新的 Llama 模型（PyTorch 2.2）打到一个镜像里，结果两个模型的 Python 依赖互相覆盖，模型加载时各种报错，浪费了整整两天时间排查。
后来我定了一条铁律：推理镜像按 PyTorch 大版本拆分，不同版本跑在不同的实例池里。具体落地是——基于 PyTorch 2.x 的模型用一套镜像，基于 PyTorch 1.x 的模型用另一套镜像，两套实例在 K8s 上用 Deployment 分组管理，通过网关层的路由规则分发流量。虽然底层实例不是一个进程，但对外依然是统一的服务入口，用户感知不到内部差异。
这个设计其实符合“共享服务层、隔离执行层”的思想。网关可以是一套独立的服务，多个执行层可以有不同的运行时环境，各有各的资源配额、弹性扩缩容策略和故障域。只要注册中心把模型和实例的归属关系记录清楚，网关做路由时就能准确分发。
5.2 显存碎片化与 OOM
多模型共存于一张 GPU 卡时，显存碎片化是我反复遇到的另一个问题。PyTorch 默认的显存分配策略是先向 CUDA 申请一大块显存，然后在内部按需分配，模型加载和卸载多次后，显存中会出现大量不连续的碎片，导致明明总显存还有剩余，新的模型却无法加载。
排查手段是定期执行 nvidia-smi，查看显存分配情况。如果发现已用显存远超模型实际需求，大概率就是碎片化或者内存泄漏。缓解措施有两个方向。
第一个方向是固定显存分配策略，在 PyTorch 初始化时手动设置：
python复制import torch
# 固定显存分配，避免每次加载都重新向CUDA申请
torch.cuda.memory._set_allocator_settings("expandable_segments:True")
第二个方向是引入显存池化机制。模型加载时估算所需显存，统一从显存池里申请和释放，避免碎片化累积。还可以定期做一个“整理”操作：把当前模型全部挂起，清空 CUDA 缓存，再按固定规则统一加载。
5.3 多模型路由的时延抖动
统一网关汇聚流量后，一个常见的现象是：整体 QPS 不高，但个别请求的时延忽高忽低，P99 和 P50 差距巨大。这类问题的排查路径，我建议先看三个层面。
第一层是网关本身是否有热点。路由逻辑如果涉及复杂的正则匹配或者数据库查询，在流量峰值时可能成为瓶颈。处理方式是路由表做成全内存缓存，只用一个简单的哈希查表。
第二层是 batch 等待。动态批处理机制下，如果请求到达不均匀，有些请求会在队列里等待凑 batch，这个等待时间就成了尾延迟的主要来源。调整方向是缩短 max_queue_delay_microseconds，或者对高优先级的请求绕过批处理直接推理。
第三层是 GPU 资源争抢。同一个 GPU 上多个模型并发推理时，计算资源会互相挤占，特别是没有做算力隔离的场景。我踩过这个坑之后，给模型实例配置 GPU 计算优先级，或者直接把两个高负载模型部署到不同的物理 GPU 上，立刻就稳定了。
5.4 配置管理的隐性成本
多模型服务的配置项数量非常惊人——模型路径、版本号、批处理大小、延迟阈值、资源配额、脱敏规则，每一项都可能需要调整。如果配置散落在各个代码仓库和 YAML 文件里，交付效率会非常低下。
我经历过的真实状态是：部署一个新模型版本需要改四个配置，漏改一个就导致线上流量打到旧版本上。后来我把所有配置统一收口到配置中心，通过 API 动态下发，配合灰度策略逐步放量。每个模型在配置中心里有一份完整的配置树，改动后立即生效并留痕。现在新模型上线从“迁移代码”变成了“填配置表”，效率提升了不止一个档次。
6. 性能优化与成本治理的进一步实践
6.1 模型压缩与推理加速
多模型统一部署之后，你很快会发现另一个真相：模型数量多了，算力成本是线性甚至超线性增长的。如果说架构解决的是“能不能跑起来”的问题，那么接下来需要面对的就是“能不能跑得更快、更便宜”。
模型量化是我做的第一件事。PyTorch 模型默认是 FP32 精度，推理时存在大量精度冗余。用 PyTorch 自带的量化工具把模型转成 FP16 或者 INT8，显存占用和推理延迟都能明显下降。实测在文本分类模型上，FP16 精度下显存占用直接减半，推理速度提升约 1.6 倍，精度损失不到 0.1%。INT8 量化收益更大，但对模型结构的兼容性和校准数据集的要求更高，不是所有模型都能直接套用。
算子融合是另一个重要手段。一个模型的计算图中往往有很多可以合并的算子，比如卷积后的 BatchNorm 可以合并成一次卷积操作。PyTorch 的 TorchScript 编译优化和 NVIDIA TensorRT 都提供了自动算子融合能力，合并之后减少了算子启动和内存读写的开销。我通常的措施是先用 ONNX 导出模型，再用 TensorRT 转成优化引擎。这里要提醒的是，TensorRT 生成的引擎文件是针对特定 GPU 架构的，换卡型之后需要重新转换，多卡混用场景要提前规划。
6.2 弹性扩缩容与资源池化
多模型服务的流量不是恒定的。电商大促、节假日活动、新功能上线，都会带来流量脉冲。资源池化和弹性扩缩容是控制成本的关键手段。
在 K8s 环境里，我使用 HPA（Horizontal Pod Autoscaler）结合自定义指标做弹性伸缩。伸缩的指标不是单纯的 CPU 使用率，而是结合了 GPU 利用率、请求排队长度和 P99 延迟。扩缩容的时候，模型服务能依赖显存调度机制在实例之间动态调整，不会出现新增的 Pod 因找不到可用 GPU 而长时间 Pending 的状态。
还有一层是针对“潮汐业务”的调度。有些模型服务业务高峰集中在白天，有些集中在晚上，通过时间维度的调度错峰复用 GPU 资源，本质上比单纯做扩缩容更省钱。我设计过一个简单的 CronJob 流程：白天的核心模型实例数量多，晚间批量任务实例数量多，两者共享同一个 GPU 资源池，由调度器按照时间窗口调整实例的优先级和资源占用。
6.3 多业务异构场景的治理体系
最后想聊一点偏方法论的内容。多模型统一部署做到后面，真正难的已经不是技术，而是治理体系的建设。
企业里的多业务异构场景，意味着不同的业务线有不同的优先级、不同的合规要求、不同的 SLA 目标。比如核心交易链路里的推荐模型，要求 P99 在 20ms 以内，出问题要分钟级恢复；而离线的文档分类模型，跑批任务只要在几小时内完成，中断一两次也无所谓。如果用同一套标准去管理这两类模型，要么过度设计浪费资源，要么保障不足引发事故。
我的实践做法是建立“模型服务分级制度”。每一级都绑定明确的资源配额、监控告警策略、SLA 承诺和支持响应速度。比如：
- L1 级：核心在线业务模型，资源全额保障，7x24 监控，5 分钟响应，支持秒级扩缩容。
- L2 级：常规在线业务模型，资源按需分配，工作时间段监控，30 分钟响应。
- L3 级：离线批量模型，资源池空闲时调度，每日巡检，处理时效要求较低。
分级之后，运维资源的投入更聚焦，不需要为每一个模型提供同等级别的保障，也能有效控制整体成本。这套治理体系配合前面说的统一路由、模型注册、监控告警和执行层隔离，整个多模型服务的架构才算真正完整收了口。
最后想再说几句
我是从单一模型部署一步步走到多模型统一管理这个架构的，最大的体会是：架构改造最难的地方不是技术实现，而是让各个算法团队愿意把模型的“部署方式”交出来，统一到一套体系里。这里面有沟通成本，也有习惯上的阻力。但只要统一之后尝到了甜头——新模型上线从一周缩短到几小时、线上故障定位从小时级缩短到分钟级——后面大家就会主动愿意往这个体系里迁移。
最后再分享一个小技巧：多模型服务统一部署之后，一定要建立一个“模型上线检查清单”。从模型格式转换、Schema 校验、资源评估、批处理参数配置、监控告警策略、日志脱敏规则，到灰度发布计划，每一项都打钩确认。这张清单看起来没什么技术含量，但它在忙乱的时候真的能救命——至少我因为漏掉某一项而在深夜紧急修复的经历，已经不想再来第二次了。