从零搭建AI模型调度平台：架构设计、核心实现与踩坑实录

这两年做AI基础架构的团队应该都有同样的感受：模型数量越来越多，GPU成本居高不下，业务方隔三差五就提一个新模型上线的需求，手工管理推理服务根本忙不过来。我自己从零搭过一套AI模型调度平台，从需求拆解、架构设计到落地压测，前后折腾了大半年，踩了不少坑，也把K8s生态里和调度相关的组件翻了个底朝天。这篇文章就以AI模型调度平台的系统架构为主线，把整体设计思路、核心模块、关键实现和排障经验完整梳理一遍。如果你正准备从0搭建模型服务调度体系，或者已经有一套简单的推理服务、想往平台化方向演进，这份总结应该值得你花20分钟仔细读一遍。

1. 需求拆解与架构设计思路

1.1 需求反推架构：平台到底要解决什么问题

做架构最忌讳凭空画框，先把真实痛点理清楚。我梳理下来，团队对模型调度平台的核心诉求集中在四个层面。

第一是资源利用率问题。手上有几十个模型，有的模型只有早上流量高，有的模型凌晨才被调用，如果每个模型固定占几个实例，GPU资源浪费非常明显。实际算过一笔账：32个模型，每个模型按常驻2个实例、每实例占用12GB显存的规模估算，至少需要768GB显存。如果按波峰波谷动态复用，把闲时实例释放给其他模型，同等业务量只需要大约420GB显存，节省接近一半。

第二是模型多版本灰度问题。算法团队每周都会迭代模型，今天上线v3，明天回滚到v2，手工改Nginx配置根本追不上节奏。平台需要做到按流量比例灰度、按调用方灰度、一键回滚。

第三是异构资源管理问题。GPU节点不是单一型号，可能出现A100、L40S、RTX 4090混部的情况，不同模型对显存、算力、PCIe带宽的需求差异很大，手工调度很难做到“把合适的模型放到合适的卡上”。

第四是稳定性保障问题。流量突增时，如果实例扩容速度跟不上，请求就会大量超时甚至拖垮整个服务。平台需要具备自动伸缩、排队保护、过载降级的能力，而不是靠运维半夜爬起来手动扩容。

把这些问题摆在一起，架构目标就很清晰了：构建一套能统一管理异构GPU资源、自动调度模型实例、支持多版本发布、具备弹性伸缩和过载保护能力的模型推理调度平台。

1.2 为什么不能直接裸用K8s默认调度器

很多人第一反应是，直接用Kubernetes不就行了？我在早期验证时也这么干过，但实际跑下来，K8s默认调度器在模型推理场景存在几个明显的盲区。

默认调度器感知的资源维度主要是CPU、内存、存储端口等，对GPU显存的调度虽然通过Extended Resource可以上报，但它不知道“一个模型实例加载到显存里需要多少显存”这种业务级信息，更不能理解模型之间的冷热关系。K8s调度器把一个Pod调度到节点上之后，只要Pod不退出，它就认为资源一直占用，这其实没问题，但它无法做到“某个模型的请求量低了，把实例缩掉之后再把显存让给高优先级的模型”这种业务层面的决策。更麻烦的是，模型加载本身是个重量级操作，很多大模型加载到显存需要几十秒甚至几分钟，默认调度器完全没有冷启动规避的概念，流量一来，调度的Pod还在拉镜像、加载权重，用户请求早就超时了。

所以我最终的结论是：K8s可以继续作为资源调度的底座，但在它之上必须自建一层面向模型推理场景的调度控制面，K8s负责Pod生命周期，我们负责模型实例的分配、预热、缩容和流量调度。

1.3 整体分层架构：五层模型各司其职

最终的架构分为五层，我按从外到内的顺序讲。

接入层：统一API网关，承接业务方的推理请求，做模型路由、版本匹配、流量灰度和基础限流。

调度层：这是整个平台的头脑，由调度引擎、排队器、弹性伸缩控制器、模型实例注册中心组成。调度引擎根据请求的模型ID、资源水位、实例状态计算出最优分配方案，排队器负责在实例不足时缓存请求，弹性伸缩控制器负责实例的扩容和缩容。

资源层：底层GPU/NPU节点池，通过K8s纳管，但每个节点都会上报显存总量、已用显存、当前实例列表、GPU利用率等维度数据，供上层调度决策。

存储层：模型仓库负责管理模型文件和多版本元数据；配置中心负责保存路由规则、伸缩策略、配额信息；时序数据库用于落监控指标。

可观测层：指标监控、日志采集、链路追踪三位一体，支撑日常运维和容量规划。

整体形态就是一个典型的控制面+数据面架构，控制面不碰用户流量，只做决策，数据面承载实际推理请求。各层之间通过消息队列解耦，调度指令和状态上报走Kafka，避免高并发情况下各组件互相阻塞。

2. 核心模块设计与关键机制

2.1 接入层与模型路由：业务方怎么精准找到模型实例

接入层的设计核心是模型抽象和路由规则。我给每个模型分配唯一的模型ID，模型每次发布都生成新的版本号，比如llm-detect-v32。业务方调用时，在请求头里带上model_id和version，网关根据这两个参数路由到对应实例。

关于版本路由，我采用了三种策略组合。第一种是固定版本路由，业务方指定某个具体版本，所有请求都打到该版本，适合迁移场景。第二种是加权灰度，比如v31占20%、v32占80%，适合新模型逐步放流量。第三种是业务方维度路由，根据调用方标识强制走某个版本，方便算法团队定向验证。

这里面比较隐蔽的一个问题是路由一致性。网关层有多个副本，如果每个副本本地保存路由规则，更新时需要广播，很可能出现部分副本还没收到新规则、流量仍然打到旧版本的情况。我的做法是把路由规则放到Redis里，网关启动时加载全量快照，运行期间订阅变更消息更新本地缓存，同时兜底设置30秒的规则拉取周期，保证最迟30秒内所有网关收敛到同一份规则。

网关对流控的处理也值得一提。平台提供两种限流模式：按模型维度的QPS限流和按调用方维度的配额限流。前者保护模型实例不被流量打死，后者保证大客户不会占用所有配额。限流算法的选择上，高精度用令牌桶，一般场景用滑动窗口计数，实测下来单机也能支撑几十万QPS的规则判断，性能足够。

2.2 调度引擎：四个关键输入和一个核心决策

调度引擎是整个平台里最核心的部分。它的决策质量直接决定了集群的整体资源利用率和推理服务质量。我把它抽象成一个多目标优化问题，权重排序是：稳定性 > 资源效率 > 平均延迟。

调度引擎决策时需要四个维度的输入。模型维度：请求属于哪个模型、目标实例的冷热状态、最大可接受实例数。资源维度：集群每个节点的显存总量、剩余可用显存、GPU利用率、显存带宽占用率。实例维度：当前每个实例的QPS、P99延迟、健康状态、正在处理的请求数。队列维度：当前排队请求数、队列平均等待时间、是否触发过载降级。

核心决策分为三步。第一步，根据模型ID找到当前可用的实例集合，如果存在热实例且容量足够，直接选择一个负载最低的实例路由过去。第二步，如果热实例容量不足，就尝试在集群中寻找能够放置新实例的节点，筛选条件是显存剩余量足够、GPU利用率低于80%、节点上没有正在执行的冷加载任务。第三步，如果找不到合适节点，请求进入排队器，同时触发扩缩容评估。

调度策略我最终选择的是“最小负载优先 + 显存适配”的贪心算法。理由很简单：在线推理场景的请求到达是随机过程，不存在能完美预知未来的最优解，贪心策略实现简单、决策时延低，实测在几百个节点的规模下也足够用。全链路调度决策耗时被控制在5毫秒以内，完全不影响在线接口的体验。

2.3 实例预热与调度协同：冷启动问题必须前置解决

模型冷启动是我认为整个平台里最容易翻车、也最需要设计技巧的环节。一个5GB的模型文件从对象存储拉下来需要12秒，加载进GPU显存、做权重初始化需要8秒，如果模型内部有CUDA kernel编译流程，再加10秒。也就是说，一个冷实例从创建到真正接流量，可能需要30秒以上。线上业务根本等不了这么久。

因此我在架构里增加了一个预加载池机制。每个模型常驻1到2个预热实例，即使完全没有流量，也保持实例处于最小资源模式。当流量突增时，调度引擎不是从零创建实例，而是把预加载池里的实例切到正式模式，整个过程只需要几百毫秒。这有点像一个汽车服务站在高峰时段提前把代步车准备好，客户来了直接换车走人，而不是临时去造车。

预加载池的大小需要精细控制。太少起不到缓冲作用，太多浪费显存。我设计了一个经验公式：预加载实例数 = 过去7天模型最大瞬时QPS对应的实例数 x 20% + 1。如果一个模型峰值需要10个实例，那预加载池就保持3个实例。后续可以通过监控数据持续修正这个比例。

还有一个容易被忽略的点，就是模型加载位置的选择。加载目标节点时，尽量选择和该模型其他实例不在同一台物理机的节点，避免单机故障导致整个模型全部不可用；同时要考虑节点数据亲和性，如果节点本机缓存了模型文件，加载速度会快不少。

2.4 弹性伸缩策略：扩容要快，缩容要稳

弹性伸缩是我后来反复调的一块。模型请求量不像Web服务那么平稳，经常是突刺式增长，几个月不用的模型突然被活动拉起来，一天内流量翻几十倍都有可能。所以扩缩容策略必须同时考虑速度和稳定性。

扩容触发条件不能只看QPS，我设置了三个指标，任一个持续30秒超过阈值即触发扩容：实例平均QPS超过单实例健康QPS的70%；实例P99延迟连续超过500毫秒；排队器平均等待时长超过1秒。三个指标覆盖了请求量增长、性能劣化、队列积压三种典型场景，避免单一指标误判。

扩容步长的设计也有讲究。我采用“快上快下”策略：首次扩容增加当前实例数的50%，休息90秒，如果仍然过载，再次扩容30%，依此类推。这样既保证了短时间内把实例数拉上去，又不会因为扩容过快造成资源浪费。缩容则保守很多，连续30分钟实例利用率低于30%才允许缩容，每次缩容不超过当前实例数的20%，并且单次缩容最少保留2个实例兜底。这套策略实测下来的效果是，高峰期扩容响应时间从最初的10分钟压缩到3分钟以内，缩容也不会引发服务质量波动。

3. 关键选型与调度实现

3.1 为什么选择自研调度器而不是开源方案

开源领域其实有KubeDL、KFServing、Seldon Core这些项目，我早期都验证过。KFServing在模型服务生命周期管理上做得不错，但对多版本流量灰度的支持比较弱，扩展起来要改很多内部逻辑；Seldon Core的管线能力适合离线推理场景，在线场景反而显得重。加上我们还需要多租户配额、冷启动预加载池、混合型号GPU适配这些强定制需求，自研调度器是性价比最高的选择。

自研并不意味着从零造轮子。我保留了K8s作为资源底座，自研部分集中在业务调度逻辑上。调度器以Deployment形态部署在控制面，通过K8s Informer机制监听节点资源变化和Pod状态变化，同时通过gRPC接口接收每个节点的资源状态上报，结合这两类数据构建出全局资源视图。这样做既利用了K8s的容器编排能力，又避开了默认调度器对模型业务语义不敏感的缺点。

3.2 核心调度逻辑的落地代码（简化版）

调度引擎核心逻辑我写成了一段简化版本的代码，去掉了一些分支细节，保留了完整决策链路。为了便于理解，我用Python风格展示。

python复制class ModelScheduler:
    def schedule(self, model_id, request_info):
        # 1. 查询当前模型的所有实例状态
        instances = self.instance_registry.list_instances(model_id)
        hot_instances = [ins for ins in instances if ins.status == 'HOT']

        # 2. 优先寻找负载最低的热实例
        if hot_instances:
            candidate = min(hot_instances, key=partial(self.estimate_load, request_info))
            if self.estimate_load(candidate, request_info) < candidate.max_load:
                return RouteDecision(action='ROUTE', instance_id=candidate.instance_id, pod_name=candidate.pod_name)
        # 3. 没有可用的热实例，尝试创建新实例
        target_node = self.find_suitable_node(model_id)
        if target_node:
            self.scaler.create_instance(model_id, target_node)
            return RouteDecision(action='PREPARE', node_name=target_node.node_name)
        # 4. 没有节点资源，交给排队器等待或降级
        return RouteDecision(action='QUEUE')

    def find_suitable_node(self, model_id):
        required_mem = self.model_repo.get_model_required_mem(model_id)
        candidates = []
        for node in self.resource_view.all_nodes():
            if node.free_visible_mem < required_mem:
                continue
            if node.gpu_util > 80:
                continue
            if node.loading_task_num >= 1:
                continue
            if self.has_model_instance_on_node(model_id, node):
                continue  # 避免单点集中
            score = self.node_score(node)
            candidates.append((score, node))
        if not candidates:
            return None
        candidates.sort(key=lambda x: x[0])
        return candidates[0][1]

这段代码看起来不长，但已经体现了调度策略的核心：优先复用热实例，其次找合适节点创建新实例，实在没有资源就排队等待。有一点要说明，真实场景里estimate_load不是简单看请求数，而是结合当前处理中请求数、请求平均处理时长、GPU利用率综合算出的预计负载值，避免因为少量高耗时请求导致误判。

3.3 关键参数的计算与调优思路

调度平台的参数配置是个持续迭代的过程。我挑三个最关键的参数讲一下它们的推导逻辑。

第一个是队列容量和超时时间的设定。排队器是为了缓冲流量，但队列不能无限长，否则用户等待时间超过心理预期，体验更差。我用Little定律做初步估算：队列容量 = 模型平均QPS x 可接受排队时间。假设模型平均QPS是1000，可接受排队时间是2秒，那队列容量就是2000。超时时间则按照“用户可容忍等待时间 - 调度决策耗 - 网络往返预估”推算，一般设置300到500毫秒。超过等待时间的请求直接返回过载提示，不做无意义排队。

第二个是预加载池的缩减判断。预加载池是常驻资源，需要精细控制。我设置了一个冷却时间机制：预加载实例被激活转为正式实例后，超过15分钟未再有扩容需求，就释放50%的预加载实例，保留最低保障数。释放前要检查该模型目前所有实例的平均负载是否低于50%，确保释放操作不会损害服务质量。

第三个是节点资源上报周期。上报太频繁会占用大量网络和控制面CPU，太稀疏则调度决策基于过期数据、误判率高。我最终设置的周期是3秒一轮上报，加上本地缓存和增量更新，控制面资源消耗控制在5%以内。调度决策时最多容忍5秒的时延，超过这个时间就强制刷新资源视图，避免基于陈旧数据做决策。

4. 部署、压测与性能调优实录

4.1 部署形态与资源规划参考

实际的部署形态我按规模和成本分两种方案。小规模场景（10到20个模型、10台GPU节点以内），控制面组件可以部署在3台8C16G的CPU节点上，存储用MySQL+Redis，模型仓库用对象存储，监控用Prometheus+Grafana，这套组合成本低、维护简单。大规模场景（百级模型、50台以上GPU节点），控制面需要拆分，调度引擎和API网关分别独立部署，存储换成TiDB这类分布式数据库，监控升级为VictoriaMetrics，模型仓库加CDN加速节点拉取速度。

特别强调一下，控制面和数据面之间一定要做网络隔离，同时控制面本身要具备高可用。我见过一个团队把调度器单点部署在GPU节点上，GPU节点一宕机，调度器跟着挂，整个平台陷入瘫痪。正确的做法是控制面部署在独立的CPU节点或者容器云环境，并保证至少3副本，通过Leader选举保证同时只有一个调度器在干活。

4.2 压测数据：默认参数和优化后的差距有多大

平台搭建完成后，我组织了一次完整的压测。压测模型选用一个典型的NLP分类模型，单实例支撑500 QPS，模型加载时间约20秒。测试工具用wrk和内部自研压测框架，分4个场景：单模型高并发、多模型混合调度、突刺式流量冲击、冷启动场景模拟。

优化前的默认参数配置下，单模型高并发压测到1200 QPS时，P99延迟开始突破300毫秒，排队数快速上涨。主要原因是指标采集周期过长，调度引擎没能及时感知实例过载，扩容动作慢了一拍。多模型混合调度时资源碎片化严重，新模型找不到连续显存，创建失败率一度高达23%。

优化后的压测结果好了很多。单模型在1500 QPS下P99稳定在120毫秒左右，多模型混合场景的资源创建成功率提升到99%以上，突刺流量冲击测试中，1000 QPS瞬时翻到5000 QPS，平台在2分40秒内完成实例扩容，恢复过程中零请求超时，冷启动预留的预加载池让首个请求延迟控制在800毫秒以内。

调参过程中最关键的三个动作是：缩短资源上报周期从10秒降到3秒；为每个模型单独设置弹性伸缩策略，而不是用全局默认值；把冷启动预加载池从可选项改成必选项。这三个调整带来的收益最大，其他细节调整属于锦上添花。

4.3 灰度发布与回滚的实测案例

平台上线后的第一次模型灰度发布，我选了一个实验性的文本分类模型v2。配置网关规则：v1承接80%流量，v2承接20%流量。刚开始v2实例只有2个，监控指标显示P99延迟从80毫秒涨到250毫秒，算法团队反馈某些类别效果异常。我马上执行一键回滚，把v2流量切回v1，整个回滚过程用了不到10秒。

这次实测暴露了一个问题：灰度期间的监控指标权重需要调优。只看平均延迟会掩盖少量长尾请求的问题，后来我把监控指标改成按分位段统计，重点关注P95和P99，同时在灰度期间引入“错误率拨测”任务，每隔30秒自动向v2实例发送构造样本，一旦错误率超过5%自动暂停灰度。这套机制之后又经历了几次灰度，效果稳定很多，基本杜绝了问题模型长时间影响线上流量的情况。

5. 常见问题与排查技巧实录

5.1 显存碎片化导致的OOM问题

现象：模型实例偶发抖动，重启后不到半小时又OOM，但节点的剩余显存总量看起来足够。

排查过程：我通过nvidia-smi看显存分配，发现节点上被分配出去的显存块非常零散，单块连续显存不足以加载新模型。模型仓库里记录了每个模型需要的显存大小，但调度器只看了节点的总剩余显存，没有考虑显存碎片问题。

解决方案：调度器在找节点时，不再只判断总剩余显存，而是增加一个“最大连续空闲显存”的判断条件。实现方式是让节点Agent执行一段命令获取每个GPU的显存分配表，把最大空闲块大小上报给调度器，调度器要求最大空闲块必须大于等于目标模型所需显存。这个改动上线后，OOM频率大幅下降。

5.2 冷启动击穿与队列堆积雪崩

现象：某个模型流量突然涨到平时10倍，调度器不断创建新实例，但用户反馈请求大面积超时，队列深度持续上涨。

排查过程：打开监控链路，发现请求到达和实例创建成功之间存在巨大的时间差，大量请求在排队器里等待。进一步查实例启动日志，发现新创建的实例都在做模型加载，拉模型文件耗时30秒以上，加载期间实例还不能接流量，导致排队池被占满。

解决方案：接入预加载池机制并设置合理的预热实例数量，从根上解决冷启动耗时问题。同时给排队器增加“饥饿保护”，当排队超过300毫秒时，错误率拨测自动摘除不可用实例，不再让请求继续堆积。另外给模型加载任务增加了并发限制，避免一次性在集群里加载太多模型导致IO带宽耗尽。

5.3 多租户资源抢占问题

现象：多个业务方共用一个集群，A业务方大促流量暴增，把集群资源全部占走，B业务方的模型请求大量失败。

排查过程：排查调度日志发现，调度引擎只按负载和显存决策，完全没有配额概念，资源充足时谁先申请谁先用，B业务方晚了一步，资源被抢完。

解决方案：引入两级配额机制。每个租户在模型仓库中设置资源配额上限，调度器在创建新实例前校验租户已占用资源数是否超过配额，超过则只能复用已有实例，不能创建新实例。同时在触发扩容时，优先扩容配额剩余多且负载高的租户，实现跨租户的公平调度。这个机制上线后，A大促仍然独占资源，但B业务方至少有基础保障的实例数量。

5.4 排查速查表

下表是我在实际运维中沉淀下来的一张速查表，遇到问题可以直接对照排查。

理论上这些坑都能通过架构设计规避，但实际运行时故障发生的组合方式千奇百怪，务必保留好完整的监控链路，否则排障无从下手。

6. 几点经验教训

整个平台从设计到稳定运行，我最大的体会是：模型调度平台本质上是“用控制面的复杂度换数据面的稳定性”。所有复杂逻辑都应该收敛到控制面，让数据面保持简单和可靠。你没听错，这不是一句空话，而是在架构演进中反复验证过的结论。曾经有人提出把调度决策逻辑全部下放到节点Agent上，让每个节点自己决定能不能接收新模型，听起来很美，实际跑起来完全是灾难，Agent版本不一致、决策不统一，最终导致调度疯狂抖动。

另外想提醒的是，调度平台上线初期一定要预留足够的“逃逸通道”。不管是手动一键缩容、路由规则热更新，还是临时禁用某个模型的弹性伸缩，都必须放到控制台上作为基础功能提前实现。生产环境的故障不按剧本走，能让你一键逃生比什么花哨功能都重要。

最后一个小技巧：监控大盘一定要提前做好容量维度的视图。调度平台除了日常的QPS、延迟指标，更要关注显存分配率、节点资源碎片率、模型实例平均利用率这些容量指标。这部分数据跑满3个月后，你就能非常清晰地知道哪些模型该合并、哪些节点该下线、下一步容量规划怎么做。这也是我做完整个平台之后收获最大的数据资产。