尧图网页设计 
刚开始做昇思大模型推理服务的时候我栽得最狠的一次就是在“升级模型版本”。当时想法很简单新模型推理代码写好直接把服务停了换权重再启动。结果呢服务中断了将近十分钟线上积压的推理请求全部超时下游业务报警电话被打爆。那一刻我就意识到在大模型推理系统里模型能跑起来只是第一步真正难的是让整个服务在部署、扩容、升级、保活、下线这条链路上长期稳定地运转。昇思大模型推理系统的生命周期管理说白了就是把“实例从生到死”的每个环节都定义清楚、控制到位配套一套清晰的架构和可靠的代码逻辑。这篇文章我不会只讲概念会把我在昇思推理服务上实际用的流程拆解、架构分层、核心状态机代码和线上踩坑记录都摆出来。适合正在做模型推理平台、部署大模型服务或者想把现有推理服务做得更稳的工程师阅读。内容会有一点密度但可以直接拿去做参考。1. 昇思大模型推理系统生命周期管理管什么先理清边界1.1 从模型发布到实例回收生命周期有哪几个阶段我习惯把昇思大模型推理系统中的一个服务实例看作一个独立的“推理工作进程”。在分布式架构里这类进程不会只启动一次就一直活着。它要经历构建、注册、调度、运行、更新、下线等多个阶段而且每个阶段都不能跳过。具体可以分为构建阶段从模型仓库拉取昇思模型文件加载权重初始化昇思MindSpore执行上下文编译计算图。这个过程可能耗时几十秒到几分钟不等。注册阶段实例启动后把自己注册到控制面上报IP、端口、模型版本、显存占用、负载能力等信息让调度器知道“这个实例可以接流量了”。运行阶段实例对外提供推理服务包括请求接收、预处理、模型推理、后处理、结果返回并持续上报心跳和监控指标。更新升级阶段模型版本迭代或推理逻辑变更需要对新实例进行预热、灰度发布、流量切换确认稳定后再回收旧实例。下线回收阶段实例因缩容、故障、升级完毕等原因被回收。需要先摘除流量再等待在途请求结束最后释放显存和临时文件。只跑通“运行阶段”不算生命周期管理。昇思推理系统的生命周期管理核心在于把这几个阶段之间的状态转换做成可观测、可控制、可回滚的流程。比如“构建完成”不代表“可以接收流量”必须显式进入“就绪”状态才算数。同理“缩容”不代表直接kill进程而是先排空在途请求再优雅退出。边界先定清楚后面所有代码逻辑才有依据。1.2 大模型推理场景下的管理难点不是Web应用那种生命周期做过普通微服务开发的同事经常会有一套现成的生命周期管理思路。服务启动时注册到注册中心调用健康检查接口判断存活下线时反注册Kubernetes里靠探针搞就绪和存活。这套思路搬到昇思大模型推理系统里一开始好像也说得通但实际跑下来会发现有几个明显差异。第一大模型实例启动极其昂贵。加载一个动辄几十GB的权重文件到显存还要做图编译和算子优化冷启动阶段通常要几十秒甚至几分钟。如果就绪探针判断得太粗很可能实例还没真正准备好Scheduler就把请求分给它了结果就是大量请求排队等待拖垮整个Batch调度。第二大模型推理是有状态的。这里的“状态”不是业务状态而是显存里的KV Cache、权重参数、推理引擎上下文。这些状态不能像普通无状态服务那样随便复制和销毁。缩容任何一个实例都可能把一部分已经缓存的模型上下文丢掉导致后续请求又要重新做prefill时延瞬间飙升。第三扩容要受物理资源硬约束。昇思推理服务通常跑在GPU或昇腾AI处理器上单个实例占用一整块或大半块设备显存。扩容不是多拉几个容器那么简单需要先在设备上腾出显存、加载权重这和普通Web容器“秒级拉起”完全不是一个量级。所以昇思推理系统的生命周期管理需要一套更重的流程实例加载、预热、就绪确认、排空、优雅销毁每一步都要有明确的状态和操作接口。直接套用普通服务管理方式后面会不断出问题。1.3 生命周期管理的关键指标和优化目标理清生命周期阶段之后工程上还需要落地可量化的指标。没有指标就谈不上管理和优化。我在实际项目中主要关注三组指标生命周期阶段核心指标主要风险启动预热预热耗时、加载成功率、显存分配峰值加载慢导致扩容不及时加载失败导致部署中断注册就绪就绪比例、心跳成功率未就绪实例被调度请求异常堆积运行服务QPS、推理时延、Batch利用率、设备利用率负载不均、Bad Batcher、长尾请求阻塞扩容缩容扩缩容耗时、冷却期次数、缩容失败率扩容抖动、缩容误杀在途请求更新发布灰度批次大小、发布回滚耗时、错误率新旧版本共存导致显存超卖优雅下线排空耗时、残留在途请求数、释放失败率请求被硬杀、显存无法回收这套指标不只是用来做监控大屏更重要的是驱动调度器的控制策略。比如扩容不是因为QPS瞬时升高就立刻扩而是结合单实例处理能力、排队长度、设备空闲情况做综合决策。在后文讲代码实现时很多判断逻辑都会引用这里的指标维度。2. 昇思大模型推理系统的整体架构与控制链路2.1 逻辑架构分层入口到模型实例谁在管谁昇思大模型推理系统的整体架构我会分成五个逻辑层来说。这样聊生命周期管理时能清楚知道每个模块到底在哪一层、扮演什么角色。最上面是接入层负责接收外部推理请求做路由和负载均衡。接入层不关心具体是哪个模型实例在处理请求只根据路由规则、权重大小把请求转发给后面的数据面实例。它是最先感知到流量变化的组件也是生命周期切换时流量摘除的执行者。接入层下面是控制面。控制面是整个生命周期管理的大脑通常包含实例注册中心、调度器、配置中心和状态管理器。它知道当前所有实例分别处于什么状态哪个实例刚启动、哪个实例可以接流量、哪个实例准备下线。调度器会结合监控数据做扩缩容决策并把决策下发到具体的实例池。再往下是数据面。数据面由一组昇思推理实例组成。每个实例内部加载了对应的模型权重提供HTTP或gRPC推理接口。实例启动后主动向控制面注册持续上报心跳。它们才是真正执行模型推理的地方也是生命周期管理对象的实体。侧面还有存储面和监控面。存储面用来管理昇思模型文件、版本清单、部署配置负责解决“版本从哪里来、被谁依赖、何时不可变”的问题。监控面则持续采集指标比如实例的显存占用、推理时延、QPS、队列深度并把数据喂给控制面的调度器做决策。从控制链路来看数据面永远是被管理方控制面不会直接入侵式地杀死数据面进程而是通过状态指令比如“置为DRAINING”“触发缩容”“切换版本”推动实例自己完成优雅动作。这样的分层能避免控制面和数据面耦合过深。刚开始我做的时候总是直接按进程管理思路去处理实例后来重建了这套分层才真正把生命周期从“运维命令”变成了“系统能力”。2.2 生命周期管理模块在分布式架构中的位置昇思推理服务实例通常不止一台设备一个实例而是一个由几十个实例组成的实例组。在这种分布式架构下注册中心和调度器必须和处理推理的数据面分离否则控制链路和数据链路会互相抢占资源。一个常见的错误是让某个推理实例兼任注册中心结果这个实例一扩缩容或升级全系统调度就出问题。我们可以把实例看作一个持续汇报状态的Agent每个实例做的事情很简单启动后上报自己的能力运行中定期汇报健康状态接到下线指令后配合摘流和退出。而控制面中的调度器则更像整个系统的架构设计师它不直接参与推理但决定哪个实例活着、哪个实例应该退休、哪个实例需要被拉起。控制面和数据面之间通过一套明确的状态协议交互。这套协议通常包含注册请求、心跳请求、状态变更请求、下线通知。心跳要做得细致除了简单说“我还活着”最好能携带当前排队长度、显存余量、最近一次推理耗时。调度器根据这些信息判断是扩容还是缩容是保持版本稳定还是触发灰度发布。设计上要注意控制面的接口一定要幂等。比如同一个实例重复注册注册中心要能覆盖旧记录而不是报错同一个下线通知被发了两次实例不能因为第二次重复通知就再走一遍销毁流程。这些细节在分布式架构里看着不起眼实际运行中非常容易出现。2.3 中心化调度与自注册昇思推理场景里我为什么这么选生命周期管理的架构路线主要有两种极端一是彻底的中心化调度由控制面维护全量实例信息调度器主动下发启动、停止命令二是自注册模式实例自己上报自己、自己决定退不退控制面只做轻量记录。我在昇思推理系统里最终采用了“中心化调度为主自注册为辅”的混合路线。原因是昇思大模型推理实例的生命周期动作太重比如加载一个模型需要几分钟调度器必须有能力在全局视角下判断“当前是否值得再拉起一个实例”。如果完全靠实例自注册缺乏全局队列和资源视图很容易在流量高峰时出现多个实例同时冷启动导致设备显存超分或推理Batcher资源被抢占。自注册的“为辅”体现在实例启动后主动上报状态。实例上报的IP、版本、资源能力等信息是注册中心的主要数据来源。调度器不会去猜某个设备上是否已经运行了实例而是等待实例上报后再加入调度池。同时调度器保留对实例的强制下线能力。这个能力是为了防止实例异常失去响应时不会永远占用资源。运维上可以用一条管理命令强制回收但平时大部分情况下都让实例走优雅下线流程。还有一个关键点是模型和实例的解耦。昇思模型文件不建议直接放在实例本地磁盘上反复改动而应该以版本形式集中存储。实例每次启动都从模型仓库拉取指定版本生成不可变的模型快照。这样生命周期管理在升级时实际上管理的是“某个版本的实例池”替换为“另一个版本的实例池”而不是在同一个实例上做原地代码变更。这也是我能做好灰度发布的基础。3. 核心流程逐段拆解预热、扩容、发布、优雅下线3.1 模型预热流程为什么权重加载完成不等于就绪在昇思推理系统里“实例启动”和“实例就绪”之间隔着一整个准备阶段。很多刚开始做部署的同事会拿Kubernetes的存活探针逻辑来套进程起来了就认为Pod Ready结果大量请求打到还在加载模型的实例上直接导致推理超时。后来我改了判断标准只有实例完成权重加载、执行图编译、算子融合、显存分配和预热推理之后才能被判定为Ready。具体来说一个昇思大模型实例从进程启动到Ready通常会经历几个阶段。第一步是进程启动读取配置文件建立日志和监控上下文。第二步是从模型仓库拉取对应版本的MindSpore模型权重文件。模型文件可能很大这一步会有磁盘I/O和网络传输开销。第三步是加载模型到昇思MindSpore运行时创建推理图设置运行设备。这里有个容易忽略的点如果不先安排好显存池和KV Cache空间后续推理到一半可能OOM。所以生命周期管理中要把“显存预分配”作为一个显式阶段来处理而不是等运行时自己按需分配。第四步是跑一次微型验证请求或冷启动推理确认图执行链路没有报错。有的推理引擎还支持compile后导出优化图这个过程会更久。等上面几步全部通过实例才应该把自己标记为Ready然后向注册中心发送就绪信号。在架构设计上这一步通常由控制面根据实例上报的“状态字段”判断。状态字段在Ready之前不允许被调度器选为路由目标。我在3.1最开始说的那次停机事故就是因为预热流程没有做状态控制进程一起来就被接入层认为是健康实例请求打进来全卡在权重加载上。这个坑只要在生命周期管理的状态设计里堵住后面就不会再犯。3.2 容量决策与实例调度扩缩容怎么触发更稳大模型推理实例不像普通API服务随便拉一个进程就完事。昇思推理实例每增加一个就要额外占用加载时间、显存和设备带宽。所以扩缩容的触发条件不能只看“当前CPU到了80%”这种粗糙指标。我在线上使用的决策维度有四个请求排队长度、单实例平均推理时延、实例池的Batch利用率、设备显存余量。举个例子。假设当前每一台昇思推理实例的单卡极限吞吐是每秒200个推理请求线上QPS到了400同时排队中的请求数超过了模型单实例可承受的Batch上限。这时候调度器就可以计算出目标实例数。最朴素的计算公式是目标实例数 ceil(当前QPS / 单实例预期吞吐)但这里有一个“预期吞吐”的坑。如果单实例还在预热阶段它的吞吐能力没有完全发挥出来用静态标称值去估扩容出来的实例可能在几分钟内都是空的。所以我在计算时还会把排队延迟和Batch制式的利用率一起纳入评估。排队延迟超过100ms且Batch利用率在80%以上才认为有扩容诉求而不是瞬时抖动就扩容。缩容比扩容更需要克制。一个正在处理Batch推理的实例如果因为缩容信号而被强行销毁当前批次的几十个请求会全部失败。因此缩容前必须先让实例进入DRAINING状态停止接收新请求然后等待在途请求处理完毕。等待时间最好是可配置的我一般设置为30秒。超过等待时间仍然没有处理完的请求要记录日志后再做强制清理。强制下线不能做得太频繁否则会导致请求成功率持续波动。还有一点是关于冷却期的设计。调度器做了一次扩缩容之后即使指标仍然触达阈值也不能在几秒内连续执行第二次变更。因为实例启动需要时间负载和容量之间是延迟关系没有冷却期的调度器会“追尾”刚决定扩容容量还没上来又连续扩容几次等实例全部Ready后流量已经回落资源白白浪费。冷却期通常要和实例预热时间挂钩。昇思大模型推理实例的预热时间可能是两三分钟那冷却期就不能低于1分钟否则很容易抖动。3.3 版本更新与灰度发布切流与回滚到底怎么操作模型版本升级大概是生命周期管理里最需要谨慎对待的环节。拿昇思MindSpore Serving这种系统来说一个服务实例背后绑定的是明确的模型版本。如果直接在旧实例上覆盖模型文件再重启一方面要承受较长中断时间另一方面新版如果存在问题很难快速回滚到旧版因为旧版的权重文件可能已经被覆盖了。我采用的方案是把版本和实例组绑定。每个模型版本对应至少一个独立的实例组。发布的时候并不直接改动已经在运行的旧实例组而是先按新版本拉起一个新的实例组等新实例组全部预热完成、报告Ready之后再通过接入层的流量权重把请求逐步从旧实例组切到新实例组。整个过程中旧实例组始终在线一旦新版本出现异常只需要把流量权重切回去即可。灰度发布时有一个我不能省掉的步骤新版本实例组在接收真实流量前必须跑一批模拟请求做基准校验。只跑到Ready状态还不够因为Ready只能说明模型能推理不代表推理结果和预期一致。昇思模型一般不会在版本号上发生变化后又提供完全一致的输出但我们需要确认时延、显存占用这些关键指标不超过预期。我通常在灰度流程里增加一个“Canary验证”阶段放5%的真实流量过去观察错误率和时延分布最后再决定是否放大到100%。发布过程中资源成本会短暂上升因为新旧两套实例组同时在跑。这一点要在调度器的容量模型里预留出来。如果一个实例池的显存资源已经被旧版本占掉80%那就不应该这时候再启动新版本实例组否则设备显存会直接超分。我一般会在发布前检查总资源余量确认有足够空间再进入发布流程否则会把发布任务挂起等缩容或资源回收完成后再继续。3.4 优雅下线摘流、排空与资源回收一个都不能少实例下线是生命周期管理里最容易被低估的一步。很多人觉得下线不就是把进程杀掉吗但在昇思大模型推理系统里这个动作包含了好几层逻辑。直接杀进程会让正在处理的推理请求丢失同时显存里的模型上下文来不及清理临时文件也可能残留长此以往会越积越多。优雅下线的第一步是把实例的状态从Ready改成DRAINING。这个状态变更要同步给注册中心和接入层。接入层在拿到状态后会停止向该实例分配新的请求但保留已经进入实例队列的请求继续处理。第二步是给实例一个排空时间窗口让在途请求能够自然结束。我的做法是实例在收到下线指令后启动一个计时器计时器到期之前自己主动对请求处理循环做屏障确保不会再有新的子任务被拉起。等请求数归零之后再通知调度器已经完成排空。第三步才是真正的资源释放包括关闭昇思推理上下文、释放显存、删除临时文件、关闭监听端口。资源释放完成后实例才真正退出。实际中“从DRAINING到真正退出”经常卡在某个请求上。比如有一个长尾推理请求处理了很长时间排空时间窗口已经过了但进程还挂在等结果返回。遇到这种情况我们不能无限等待。我的策略是排空时间窗口结束后强制中断在途请求并记录上下文信息包括请求ID、模型版本、当前阶段。这样虽然会丢失极少数请求但能保证实例不会变成一个永远退不掉的僵尸。要准确知道某个请求是否还在处理中需要在代码里维护一个活跃请求计数器。后文的代码示例会专门展示这个逻辑。4. 生命周期管理的代码实现状态机、注册与优雅下线4.1 用状态机建模实例生命周期要把生命周期管理落在代码上首先要定义清楚状态。为昇思大模型推理实例建模状态机时我不建议用一堆散落的布尔变量表示“是否初始化、是否在排空”这样很容易出现状态组合错误。用枚举加状态迁移校验会更清晰。from enum import Enum from dataclasses import dataclass, field import threading import time import logging logger logging.getLogger(inference-lifecycle) class InstanceState(str, Enum): INITIALIZING initializing READY ready DRAINING draining STOPPED stopped ERROR error # 合法状态迁移表 ALLOWED_TRANSITIONS { InstanceState.INITIALIZING: {InstanceState.READY, InstanceState.ERROR, InstanceState.STOPPED}, InstanceState.READY: {InstanceState.DRAINING, InstanceState.STOPPED, InstanceState.ERROR}, InstanceState.DRAINING: {InstanceState.STOPPED, InstanceState.ERROR, InstanceState.READY}, InstanceState.STOPPED: set(), InstanceState.ERROR: {InstanceState.INITIALIZING, InstanceState.STOPPED}, } dataclass class Instance: instance_id: str model_version: str address: str state: InstanceState InstanceState.INITIALIZING active_requests: int 0 _lock: threading.Lock field(default_factorythreading.Lock) def transition_to(self, target: InstanceState) - bool: 状态迁移统一入口。非法迁移会被拒绝 避免代码里随手把 DRAINING 改回 READY 造成不可预期行为。 with self._lock: if target not in ALLOWED_TRANSITIONS[self.state]: logger.warning( invalid transition %s - %s on instance %s, self.state, target, self.instance_id ) return False old_state self.state self.state target logger.info( instance %s state %s - %s, self.instance_id, old_state, target ) return True这个状态机是所有生命周期管理逻辑的基石。注意我把DRAINING也允许切回READY听起来有点反常但实际有用流量异常时先摘流如果发现实例本身没有故障再把流量恢复可以避免因误判导致不必要的重启。4.2 实例注册与心跳续约逻辑注册中心不能只靠启动时上报一次。昇思大模型推理实例在长时间运行过程中可能因为显存分配不稳定、网络链路变化导致实际可用性和控制面记录不一致。所以我在代码里加了心跳续约逻辑每个实例启动后定期向注册中心上报状态和健康信息。下面的代码是一个模拟的心跳上报线程实际项目中会把HTTP调用替换成gRPC或服务端接口。关键在于使用独立线程不让心跳逻辑阻塞推理主流程。import requests import threading class InstanceHeartbeat: 实例心跳线程。每 10 秒上报一次状态。 如果注册中心连续多次没有收到心跳就会把实例标记为不健康 从而避免把请求调度到一个已经卡死的实例上。 def __init__(self, instance: Instance, registry_url: str): self.instance instance self.registry_url registry_url.rstrip(/) self._stop_event threading.Event() def _report_once(self): payload { instance_id: self.instance.instance_id, model_version: self.instance.model_version, address: self.instance.address, state: self.instance.state.value, active_requests: self.instance.active_requests, timestamp: int(time.time()), } try: response requests.post( f{self.registry_url}/heartbeat, jsonpayload, timeout3, ) if response.status_code ! 200: logger.warning(heartbeat failed: %s, response.text) except Exception as exc: logger.warning(heartbeat request error: %s, exc) def start(self): def run(): while not self._stop_event.is_set(): self._report_once() self._stop_event.wait(10) threading.Thread(targetrun, daemonTrue).start() def stop(self): self._stop_event.set()这里有一个很容易被忽略的问题active_requests字段。注册中心看到的不只是实例存活状态还要知道它当前有多少请求在处理。当调度器想做下线决策时这个字段非常关键。如果实例自己说active_requests已经归零控制面就可以放心让它退如果说还有几百个在途请求即便进程活着调度器也要谨慎处理不能贸然把它从实例池里摘掉。4.3 优雅断流与排空实现基于并发请求计数实例要优雅下线必须能感知到“当前还有多少请求在处理”。我在代码里用一个活跃请求计数器来追踪。每次请求进入core推理模块时计数器加一请求完成时减一。当实例收到DRAINING指令后设置一个排空标志阻止新的请求进入然后等待计数器归零。import time from contextlib import contextmanager class RequestTracker: 请求追踪器。正常接收新请求时 state READY 一旦进入排空流程禁止新请求进入同时等待活跃请求数归零。 def __init__(self, instance: Instance): self.instance instance self._draining False contextmanager def handle_request(self, request_id: str): # 如果实例正在排空拒绝新请求进入 if self._draining: raise RuntimeError(instance is draining, reject new request) with self.instance._lock: self.instance.active_requests 1 try: yield finally: with self.instance._lock: self.instance.active_requests - 1 def start_drain(self): self._draining True self.instance.transition_to(InstanceState.DRAINING) logger.info(drain started, active_requests%d, self.instance.active_requests) def wait_for_drain(self, timeout_seconds: int 30) - bool: deadline time.time() timeout_seconds while time.time() deadline: with self.instance._lock: if self.instance.active_requests 0: return True time.sleep(0.5) return False def force_stop(self): self.instance.transition_to(InstanceState.STOPPED) logger.warning(force stop after drain timeout)这个实现的精巧之处在于contextmanager。推理主流程只要用with tracker.handle_request(...)包住就不用关心后续的下线逻辑。等到要下线的时候实例只需要调用start_drain和wait_for_drain就能确保在途请求先结束。实际线上服务里我还在wait_for_drain返回False时把instance.active_requests的数值记录到日志。这些记录是排查“为什么下线卡死”的第一手证据。4.4 调度器中的生命周期状态决策和配置示例调度器要做两件事决定目标实例数以及决定哪些实例可以被选为路由目标。前者根据容量指标和冷却期控制后者根据实例上报的状态过滤。没有把状态过滤做死的调度器会在实例还在初始化时就把流量打过去造成大量超时。调度器维护的实例列表通常来自注册中心汇总。我给出的配置示例参考了YAML管理方式service: name: qwen_resnet_or_llm_serve model: mindspore-llm-v3 version: 20250601_001 replica_limits: min_replicas: 2 max_replicas: 8 scale_policy: cool_down_seconds: 60 queue_depth_threshold: 50 avg_latency_p95_threshold_ms: 300 gpu_idle_memory_threshold_gb: 20 lifecycle: prewarm_timeout_seconds: 300 drain_timeout_seconds: 30 force_kill_after_timeout: true调度器根据这个配置生成决策。选择路由目标时只会选择stateREADY的实例。当某个实例状态是DRAINING时即使它还在处理请求也绝不会被新流量命中。状态过滤放在调度最前端和容量计算解耦。这样做的好处是无论容量算法怎么调参都不会影响“不让未就绪实例接流量”这条底线。调度器本身并不执行“杀掉进程”的动作它只是把目标实例数和新状态通过接口下发给实例管理模块。比如要缩容调度器向某实例发送“drain”指令实例自行决定如何优雅退出。这种模式在微服务架构里也常用迁移到昇思大模型推理场景后唯一的区别是状态管理的粒度更细、动作更重。5. 线上常见问题和排查技巧实录5.1 实例一直处于INITIALIZING请求却开始打进来了有一次线上扩容调度器判断QPS上涨拉起一个新的昇思推理实例。由于模型权重很大加载过程持续了两分多钟。但接入层没有等我自定义的就绪状态上报而是根据端口探测成功就把新实例纳入了负载均衡池。结果请求打过去后实例还在执行图编译每个请求都在阻塞等待导致这批请求全部超时。排查时我先看了注册中心的心跳记录确认实例确实没有上报Ready状态。接着看接入层的服务发现逻辑发现它只探测TCP端口没有读取生命周期状态。修复方案也很明确接入层的健康检查必须与生命周期状态联动只有stateREADY的实例才能出现在后端节点列表里。另外在调度器里也加了保护即使接入层漏了控制面也不会把非READY实例的地址下发给网关。5.2 缩容把正在推理的实例杀掉了另一次事故发生在半夜流量低谷。调度器检测到某个实例的空闲率很高就触发了缩容。旧脚本写得很粗暴直接向实例进程发送SIGKILL结果把一批正在处理的长请求全部中断下游调用方疯狂重试反而把流量又打起来了。这个问题本质上是缩容没有走生命周期管理里的排空流程。后来我把下线动作统一改为先摘流量再发drain指令实例在RequestTracker里等待活跃请求归零。只有两种情况允许强制结束一是活跃请求数已经归零但进程没有退出二是排空等待超过配置的30秒时间窗口。这个兜底逻辑避免了一台实例卡死永远占着显存的问题。所以配置force_kill_after_timeout: true是有必要的关键在于这个timeout必须给足尤其大模型长请求可能需要处理几十秒只等5秒是不够的。5.3 升级后显存暴涨回滚也救不回来有一次发布新版本大模型旧实例组在线新实例组开始拉取新权重。由于新版本模型输入的max_batch或context长度配置比旧版本大很多加上新旧两个实例组同时存在设备显存被直接占满。我在监控上看到显存使用曲线直接到顶回滚指令发出去之后新实例组里的进程卡在OOM边缘动弹不得。回滚救不回来是因为资源已经被占满了调度器想缩容新实例但注册中心里新实例还是INITIALIZING或ERROR状态容错逻辑没处理好。后来我在版本发布前强制加了一步“资源余量检查”如果当前设备显存空闲小于新版本所需空余量则直接拒绝发布任务。同时把新旧实例组的总资源占用纳入调度器视图避免发布期间超卖。另一个教训是模型版本的max_seq_len、KV Cache策略应该和权重文件一起打包不能只换权重不换配置否则升级动作本身就会因为显存配置错误而失控。5.4 模型加载阶段与请求并发互相干扰大模型推理实例在加载权重时会占用设备的大量带宽和内存通道。如果这时候同机的其他实例还在高并发处理推理请求加载速度会变得极慢甚至出现加载超时。我在实际运行中见过两个实例在同昇腾设备上一个在做模型编译一个在持续推理前者的加载时间比常态多了三倍。处理办法是引入全局的“加载互斥”策略。一个设备上同一时刻只允许一个实例进入权重加载或编译阶段。这需要在调度器层面分配实例时检查设备状态。如果已有实例处于INITIALIZING并占用设备新的扩容请求会排队等待而不是一窝蜂全塞上去。另外初始化阶段可以降低实例对设备带宽的占用优先级比如限制加载线程数减少对正常推理请求的影响。5.5 线上生命周期问题速查表症状可能原因快速排查方式长期修复方向请求偶发超时错误率上升未就绪实例被调度查看注册中心实例状态分布确认是否有非READY实例在服务列表接入层健康检查与状态机联动缩容后大量请求失败直接kill实例未走排空检查实例日志是否有SIGKILL记录统一走DRAINING超时机制发布期间显存暴涨新旧实例组共存无资源余量检查查看设备显存曲线发布节点发布前强制资源余量确认实例无法成功回滚新进程OOM调度器无法管理查看新实例状态是否ERROR或STOPPED支持强制回收和资源清理加载耗时增长同设备并发加载/推理抢占带宽检查设备活跃任务列表全局加载互斥和线程限制心跳正常但推理卡死进程内死锁或显存碎片抓取线程栈观察活跃请求计数完善进程级健康探针和自动重启真正把昇思大模型推理系统的生命周期管理做扎实绝不是写几个状态枚举和下线脚本就够了。它需要把“实例是什么、何时能服务、何时不能服务、怎么退出”这个闭环通过架构分层和代码逻辑固定下来。我栽过几次跟头之后最大的体会是不要迷信“先启动起来再说”很多线上故障都源于状态没有理清。你花在设计状态机和排空流程上的时间远比之后抢救事故的时间少得多。另一个很实用的建议是一开始就为每个实例的日志打上instance_id和model_version这样从注册、扩缩容到下线所有问题都能快速关联到具体实例进程排查效率会高非常多。希望这套流程和代码能给你在做昇思推理系统时提供一个可以落地的起点。 昇思大模型推理服务生命周期管理：从状态机到优雅下线实践
刚开始做昇思大模型推理服务的时候我栽得最狠的一次就是在“升级模型版本”。当时想法很简单新模型推理代码写好直接把服务停了换权重再启动。结果呢服务中断了将近十分钟线上积压的推理请求全部超时下游业务报警电话被打爆。那一刻我就意识到在大模型推理系统里模型能跑起来只是第一步真正难的是让整个服务在部署、扩容、升级、保活、下线这条链路上长期稳定地运转。昇思大模型推理系统的生命周期管理说白了就是把“实例从生到死”的每个环节都定义清楚、控制到位配套一套清晰的架构和可靠的代码逻辑。这篇文章我不会只讲概念会把我在昇思推理服务上实际用的流程拆解、架构分层、核心状态机代码和线上踩坑记录都摆出来。适合正在做模型推理平台、部署大模型服务或者想把现有推理服务做得更稳的工程师阅读。内容会有一点密度但可以直接拿去做参考。1. 昇思大模型推理系统生命周期管理管什么先理清边界1.1 从模型发布到实例回收生命周期有哪几个阶段我习惯把昇思大模型推理系统中的一个服务实例看作一个独立的“推理工作进程”。在分布式架构里这类进程不会只启动一次就一直活着。它要经历构建、注册、调度、运行、更新、下线等多个阶段而且每个阶段都不能跳过。具体可以分为构建阶段从模型仓库拉取昇思模型文件加载权重初始化昇思MindSpore执行上下文编译计算图。这个过程可能耗时几十秒到几分钟不等。注册阶段实例启动后把自己注册到控制面上报IP、端口、模型版本、显存占用、负载能力等信息让调度器知道“这个实例可以接流量了”。运行阶段实例对外提供推理服务包括请求接收、预处理、模型推理、后处理、结果返回并持续上报心跳和监控指标。更新升级阶段模型版本迭代或推理逻辑变更需要对新实例进行预热、灰度发布、流量切换确认稳定后再回收旧实例。下线回收阶段实例因缩容、故障、升级完毕等原因被回收。需要先摘除流量再等待在途请求结束最后释放显存和临时文件。只跑通“运行阶段”不算生命周期管理。昇思推理系统的生命周期管理核心在于把这几个阶段之间的状态转换做成可观测、可控制、可回滚的流程。比如“构建完成”不代表“可以接收流量”必须显式进入“就绪”状态才算数。同理“缩容”不代表直接kill进程而是先排空在途请求再优雅退出。边界先定清楚后面所有代码逻辑才有依据。1.2 大模型推理场景下的管理难点不是Web应用那种生命周期做过普通微服务开发的同事经常会有一套现成的生命周期管理思路。服务启动时注册到注册中心调用健康检查接口判断存活下线时反注册Kubernetes里靠探针搞就绪和存活。这套思路搬到昇思大模型推理系统里一开始好像也说得通但实际跑下来会发现有几个明显差异。第一大模型实例启动极其昂贵。加载一个动辄几十GB的权重文件到显存还要做图编译和算子优化冷启动阶段通常要几十秒甚至几分钟。如果就绪探针判断得太粗很可能实例还没真正准备好Scheduler就把请求分给它了结果就是大量请求排队等待拖垮整个Batch调度。第二大模型推理是有状态的。这里的“状态”不是业务状态而是显存里的KV Cache、权重参数、推理引擎上下文。这些状态不能像普通无状态服务那样随便复制和销毁。缩容任何一个实例都可能把一部分已经缓存的模型上下文丢掉导致后续请求又要重新做prefill时延瞬间飙升。第三扩容要受物理资源硬约束。昇思推理服务通常跑在GPU或昇腾AI处理器上单个实例占用一整块或大半块设备显存。扩容不是多拉几个容器那么简单需要先在设备上腾出显存、加载权重这和普通Web容器“秒级拉起”完全不是一个量级。所以昇思推理系统的生命周期管理需要一套更重的流程实例加载、预热、就绪确认、排空、优雅销毁每一步都要有明确的状态和操作接口。直接套用普通服务管理方式后面会不断出问题。1.3 生命周期管理的关键指标和优化目标理清生命周期阶段之后工程上还需要落地可量化的指标。没有指标就谈不上管理和优化。我在实际项目中主要关注三组指标生命周期阶段核心指标主要风险启动预热预热耗时、加载成功率、显存分配峰值加载慢导致扩容不及时加载失败导致部署中断注册就绪就绪比例、心跳成功率未就绪实例被调度请求异常堆积运行服务QPS、推理时延、Batch利用率、设备利用率负载不均、Bad Batcher、长尾请求阻塞扩容缩容扩缩容耗时、冷却期次数、缩容失败率扩容抖动、缩容误杀在途请求更新发布灰度批次大小、发布回滚耗时、错误率新旧版本共存导致显存超卖优雅下线排空耗时、残留在途请求数、释放失败率请求被硬杀、显存无法回收这套指标不只是用来做监控大屏更重要的是驱动调度器的控制策略。比如扩容不是因为QPS瞬时升高就立刻扩而是结合单实例处理能力、排队长度、设备空闲情况做综合决策。在后文讲代码实现时很多判断逻辑都会引用这里的指标维度。2. 昇思大模型推理系统的整体架构与控制链路2.1 逻辑架构分层入口到模型实例谁在管谁昇思大模型推理系统的整体架构我会分成五个逻辑层来说。这样聊生命周期管理时能清楚知道每个模块到底在哪一层、扮演什么角色。最上面是接入层负责接收外部推理请求做路由和负载均衡。接入层不关心具体是哪个模型实例在处理请求只根据路由规则、权重大小把请求转发给后面的数据面实例。它是最先感知到流量变化的组件也是生命周期切换时流量摘除的执行者。接入层下面是控制面。控制面是整个生命周期管理的大脑通常包含实例注册中心、调度器、配置中心和状态管理器。它知道当前所有实例分别处于什么状态哪个实例刚启动、哪个实例可以接流量、哪个实例准备下线。调度器会结合监控数据做扩缩容决策并把决策下发到具体的实例池。再往下是数据面。数据面由一组昇思推理实例组成。每个实例内部加载了对应的模型权重提供HTTP或gRPC推理接口。实例启动后主动向控制面注册持续上报心跳。它们才是真正执行模型推理的地方也是生命周期管理对象的实体。侧面还有存储面和监控面。存储面用来管理昇思模型文件、版本清单、部署配置负责解决“版本从哪里来、被谁依赖、何时不可变”的问题。监控面则持续采集指标比如实例的显存占用、推理时延、QPS、队列深度并把数据喂给控制面的调度器做决策。从控制链路来看数据面永远是被管理方控制面不会直接入侵式地杀死数据面进程而是通过状态指令比如“置为DRAINING”“触发缩容”“切换版本”推动实例自己完成优雅动作。这样的分层能避免控制面和数据面耦合过深。刚开始我做的时候总是直接按进程管理思路去处理实例后来重建了这套分层才真正把生命周期从“运维命令”变成了“系统能力”。2.2 生命周期管理模块在分布式架构中的位置昇思推理服务实例通常不止一台设备一个实例而是一个由几十个实例组成的实例组。在这种分布式架构下注册中心和调度器必须和处理推理的数据面分离否则控制链路和数据链路会互相抢占资源。一个常见的错误是让某个推理实例兼任注册中心结果这个实例一扩缩容或升级全系统调度就出问题。我们可以把实例看作一个持续汇报状态的Agent每个实例做的事情很简单启动后上报自己的能力运行中定期汇报健康状态接到下线指令后配合摘流和退出。而控制面中的调度器则更像整个系统的架构设计师它不直接参与推理但决定哪个实例活着、哪个实例应该退休、哪个实例需要被拉起。控制面和数据面之间通过一套明确的状态协议交互。这套协议通常包含注册请求、心跳请求、状态变更请求、下线通知。心跳要做得细致除了简单说“我还活着”最好能携带当前排队长度、显存余量、最近一次推理耗时。调度器根据这些信息判断是扩容还是缩容是保持版本稳定还是触发灰度发布。设计上要注意控制面的接口一定要幂等。比如同一个实例重复注册注册中心要能覆盖旧记录而不是报错同一个下线通知被发了两次实例不能因为第二次重复通知就再走一遍销毁流程。这些细节在分布式架构里看着不起眼实际运行中非常容易出现。2.3 中心化调度与自注册昇思推理场景里我为什么这么选生命周期管理的架构路线主要有两种极端一是彻底的中心化调度由控制面维护全量实例信息调度器主动下发启动、停止命令二是自注册模式实例自己上报自己、自己决定退不退控制面只做轻量记录。我在昇思推理系统里最终采用了“中心化调度为主自注册为辅”的混合路线。原因是昇思大模型推理实例的生命周期动作太重比如加载一个模型需要几分钟调度器必须有能力在全局视角下判断“当前是否值得再拉起一个实例”。如果完全靠实例自注册缺乏全局队列和资源视图很容易在流量高峰时出现多个实例同时冷启动导致设备显存超分或推理Batcher资源被抢占。自注册的“为辅”体现在实例启动后主动上报状态。实例上报的IP、版本、资源能力等信息是注册中心的主要数据来源。调度器不会去猜某个设备上是否已经运行了实例而是等待实例上报后再加入调度池。同时调度器保留对实例的强制下线能力。这个能力是为了防止实例异常失去响应时不会永远占用资源。运维上可以用一条管理命令强制回收但平时大部分情况下都让实例走优雅下线流程。还有一个关键点是模型和实例的解耦。昇思模型文件不建议直接放在实例本地磁盘上反复改动而应该以版本形式集中存储。实例每次启动都从模型仓库拉取指定版本生成不可变的模型快照。这样生命周期管理在升级时实际上管理的是“某个版本的实例池”替换为“另一个版本的实例池”而不是在同一个实例上做原地代码变更。这也是我能做好灰度发布的基础。3. 核心流程逐段拆解预热、扩容、发布、优雅下线3.1 模型预热流程为什么权重加载完成不等于就绪在昇思推理系统里“实例启动”和“实例就绪”之间隔着一整个准备阶段。很多刚开始做部署的同事会拿Kubernetes的存活探针逻辑来套进程起来了就认为Pod Ready结果大量请求打到还在加载模型的实例上直接导致推理超时。后来我改了判断标准只有实例完成权重加载、执行图编译、算子融合、显存分配和预热推理之后才能被判定为Ready。具体来说一个昇思大模型实例从进程启动到Ready通常会经历几个阶段。第一步是进程启动读取配置文件建立日志和监控上下文。第二步是从模型仓库拉取对应版本的MindSpore模型权重文件。模型文件可能很大这一步会有磁盘I/O和网络传输开销。第三步是加载模型到昇思MindSpore运行时创建推理图设置运行设备。这里有个容易忽略的点如果不先安排好显存池和KV Cache空间后续推理到一半可能OOM。所以生命周期管理中要把“显存预分配”作为一个显式阶段来处理而不是等运行时自己按需分配。第四步是跑一次微型验证请求或冷启动推理确认图执行链路没有报错。有的推理引擎还支持compile后导出优化图这个过程会更久。等上面几步全部通过实例才应该把自己标记为Ready然后向注册中心发送就绪信号。在架构设计上这一步通常由控制面根据实例上报的“状态字段”判断。状态字段在Ready之前不允许被调度器选为路由目标。我在3.1最开始说的那次停机事故就是因为预热流程没有做状态控制进程一起来就被接入层认为是健康实例请求打进来全卡在权重加载上。这个坑只要在生命周期管理的状态设计里堵住后面就不会再犯。3.2 容量决策与实例调度扩缩容怎么触发更稳大模型推理实例不像普通API服务随便拉一个进程就完事。昇思推理实例每增加一个就要额外占用加载时间、显存和设备带宽。所以扩缩容的触发条件不能只看“当前CPU到了80%”这种粗糙指标。我在线上使用的决策维度有四个请求排队长度、单实例平均推理时延、实例池的Batch利用率、设备显存余量。举个例子。假设当前每一台昇思推理实例的单卡极限吞吐是每秒200个推理请求线上QPS到了400同时排队中的请求数超过了模型单实例可承受的Batch上限。这时候调度器就可以计算出目标实例数。最朴素的计算公式是目标实例数 ceil(当前QPS / 单实例预期吞吐)但这里有一个“预期吞吐”的坑。如果单实例还在预热阶段它的吞吐能力没有完全发挥出来用静态标称值去估扩容出来的实例可能在几分钟内都是空的。所以我在计算时还会把排队延迟和Batch制式的利用率一起纳入评估。排队延迟超过100ms且Batch利用率在80%以上才认为有扩容诉求而不是瞬时抖动就扩容。缩容比扩容更需要克制。一个正在处理Batch推理的实例如果因为缩容信号而被强行销毁当前批次的几十个请求会全部失败。因此缩容前必须先让实例进入DRAINING状态停止接收新请求然后等待在途请求处理完毕。等待时间最好是可配置的我一般设置为30秒。超过等待时间仍然没有处理完的请求要记录日志后再做强制清理。强制下线不能做得太频繁否则会导致请求成功率持续波动。还有一点是关于冷却期的设计。调度器做了一次扩缩容之后即使指标仍然触达阈值也不能在几秒内连续执行第二次变更。因为实例启动需要时间负载和容量之间是延迟关系没有冷却期的调度器会“追尾”刚决定扩容容量还没上来又连续扩容几次等实例全部Ready后流量已经回落资源白白浪费。冷却期通常要和实例预热时间挂钩。昇思大模型推理实例的预热时间可能是两三分钟那冷却期就不能低于1分钟否则很容易抖动。3.3 版本更新与灰度发布切流与回滚到底怎么操作模型版本升级大概是生命周期管理里最需要谨慎对待的环节。拿昇思MindSpore Serving这种系统来说一个服务实例背后绑定的是明确的模型版本。如果直接在旧实例上覆盖模型文件再重启一方面要承受较长中断时间另一方面新版如果存在问题很难快速回滚到旧版因为旧版的权重文件可能已经被覆盖了。我采用的方案是把版本和实例组绑定。每个模型版本对应至少一个独立的实例组。发布的时候并不直接改动已经在运行的旧实例组而是先按新版本拉起一个新的实例组等新实例组全部预热完成、报告Ready之后再通过接入层的流量权重把请求逐步从旧实例组切到新实例组。整个过程中旧实例组始终在线一旦新版本出现异常只需要把流量权重切回去即可。灰度发布时有一个我不能省掉的步骤新版本实例组在接收真实流量前必须跑一批模拟请求做基准校验。只跑到Ready状态还不够因为Ready只能说明模型能推理不代表推理结果和预期一致。昇思模型一般不会在版本号上发生变化后又提供完全一致的输出但我们需要确认时延、显存占用这些关键指标不超过预期。我通常在灰度流程里增加一个“Canary验证”阶段放5%的真实流量过去观察错误率和时延分布最后再决定是否放大到100%。发布过程中资源成本会短暂上升因为新旧两套实例组同时在跑。这一点要在调度器的容量模型里预留出来。如果一个实例池的显存资源已经被旧版本占掉80%那就不应该这时候再启动新版本实例组否则设备显存会直接超分。我一般会在发布前检查总资源余量确认有足够空间再进入发布流程否则会把发布任务挂起等缩容或资源回收完成后再继续。3.4 优雅下线摘流、排空与资源回收一个都不能少实例下线是生命周期管理里最容易被低估的一步。很多人觉得下线不就是把进程杀掉吗但在昇思大模型推理系统里这个动作包含了好几层逻辑。直接杀进程会让正在处理的推理请求丢失同时显存里的模型上下文来不及清理临时文件也可能残留长此以往会越积越多。优雅下线的第一步是把实例的状态从Ready改成DRAINING。这个状态变更要同步给注册中心和接入层。接入层在拿到状态后会停止向该实例分配新的请求但保留已经进入实例队列的请求继续处理。第二步是给实例一个排空时间窗口让在途请求能够自然结束。我的做法是实例在收到下线指令后启动一个计时器计时器到期之前自己主动对请求处理循环做屏障确保不会再有新的子任务被拉起。等请求数归零之后再通知调度器已经完成排空。第三步才是真正的资源释放包括关闭昇思推理上下文、释放显存、删除临时文件、关闭监听端口。资源释放完成后实例才真正退出。实际中“从DRAINING到真正退出”经常卡在某个请求上。比如有一个长尾推理请求处理了很长时间排空时间窗口已经过了但进程还挂在等结果返回。遇到这种情况我们不能无限等待。我的策略是排空时间窗口结束后强制中断在途请求并记录上下文信息包括请求ID、模型版本、当前阶段。这样虽然会丢失极少数请求但能保证实例不会变成一个永远退不掉的僵尸。要准确知道某个请求是否还在处理中需要在代码里维护一个活跃请求计数器。后文的代码示例会专门展示这个逻辑。4. 生命周期管理的代码实现状态机、注册与优雅下线4.1 用状态机建模实例生命周期要把生命周期管理落在代码上首先要定义清楚状态。为昇思大模型推理实例建模状态机时我不建议用一堆散落的布尔变量表示“是否初始化、是否在排空”这样很容易出现状态组合错误。用枚举加状态迁移校验会更清晰。from enum import Enum from dataclasses import dataclass, field import threading import time import logging logger logging.getLogger(inference-lifecycle) class InstanceState(str, Enum): INITIALIZING initializing READY ready DRAINING draining STOPPED stopped ERROR error # 合法状态迁移表 ALLOWED_TRANSITIONS { InstanceState.INITIALIZING: {InstanceState.READY, InstanceState.ERROR, InstanceState.STOPPED}, InstanceState.READY: {InstanceState.DRAINING, InstanceState.STOPPED, InstanceState.ERROR}, InstanceState.DRAINING: {InstanceState.STOPPED, InstanceState.ERROR, InstanceState.READY}, InstanceState.STOPPED: set(), InstanceState.ERROR: {InstanceState.INITIALIZING, InstanceState.STOPPED}, } dataclass class Instance: instance_id: str model_version: str address: str state: InstanceState InstanceState.INITIALIZING active_requests: int 0 _lock: threading.Lock field(default_factorythreading.Lock) def transition_to(self, target: InstanceState) - bool: 状态迁移统一入口。非法迁移会被拒绝 避免代码里随手把 DRAINING 改回 READY 造成不可预期行为。 with self._lock: if target not in ALLOWED_TRANSITIONS[self.state]: logger.warning( invalid transition %s - %s on instance %s, self.state, target, self.instance_id ) return False old_state self.state self.state target logger.info( instance %s state %s - %s, self.instance_id, old_state, target ) return True这个状态机是所有生命周期管理逻辑的基石。注意我把DRAINING也允许切回READY听起来有点反常但实际有用流量异常时先摘流如果发现实例本身没有故障再把流量恢复可以避免因误判导致不必要的重启。4.2 实例注册与心跳续约逻辑注册中心不能只靠启动时上报一次。昇思大模型推理实例在长时间运行过程中可能因为显存分配不稳定、网络链路变化导致实际可用性和控制面记录不一致。所以我在代码里加了心跳续约逻辑每个实例启动后定期向注册中心上报状态和健康信息。下面的代码是一个模拟的心跳上报线程实际项目中会把HTTP调用替换成gRPC或服务端接口。关键在于使用独立线程不让心跳逻辑阻塞推理主流程。import requests import threading class InstanceHeartbeat: 实例心跳线程。每 10 秒上报一次状态。 如果注册中心连续多次没有收到心跳就会把实例标记为不健康 从而避免把请求调度到一个已经卡死的实例上。 def __init__(self, instance: Instance, registry_url: str): self.instance instance self.registry_url registry_url.rstrip(/) self._stop_event threading.Event() def _report_once(self): payload { instance_id: self.instance.instance_id, model_version: self.instance.model_version, address: self.instance.address, state: self.instance.state.value, active_requests: self.instance.active_requests, timestamp: int(time.time()), } try: response requests.post( f{self.registry_url}/heartbeat, jsonpayload, timeout3, ) if response.status_code ! 200: logger.warning(heartbeat failed: %s, response.text) except Exception as exc: logger.warning(heartbeat request error: %s, exc) def start(self): def run(): while not self._stop_event.is_set(): self._report_once() self._stop_event.wait(10) threading.Thread(targetrun, daemonTrue).start() def stop(self): self._stop_event.set()这里有一个很容易被忽略的问题active_requests字段。注册中心看到的不只是实例存活状态还要知道它当前有多少请求在处理。当调度器想做下线决策时这个字段非常关键。如果实例自己说active_requests已经归零控制面就可以放心让它退如果说还有几百个在途请求即便进程活着调度器也要谨慎处理不能贸然把它从实例池里摘掉。4.3 优雅断流与排空实现基于并发请求计数实例要优雅下线必须能感知到“当前还有多少请求在处理”。我在代码里用一个活跃请求计数器来追踪。每次请求进入core推理模块时计数器加一请求完成时减一。当实例收到DRAINING指令后设置一个排空标志阻止新的请求进入然后等待计数器归零。import time from contextlib import contextmanager class RequestTracker: 请求追踪器。正常接收新请求时 state READY 一旦进入排空流程禁止新请求进入同时等待活跃请求数归零。 def __init__(self, instance: Instance): self.instance instance self._draining False contextmanager def handle_request(self, request_id: str): # 如果实例正在排空拒绝新请求进入 if self._draining: raise RuntimeError(instance is draining, reject new request) with self.instance._lock: self.instance.active_requests 1 try: yield finally: with self.instance._lock: self.instance.active_requests - 1 def start_drain(self): self._draining True self.instance.transition_to(InstanceState.DRAINING) logger.info(drain started, active_requests%d, self.instance.active_requests) def wait_for_drain(self, timeout_seconds: int 30) - bool: deadline time.time() timeout_seconds while time.time() deadline: with self.instance._lock: if self.instance.active_requests 0: return True time.sleep(0.5) return False def force_stop(self): self.instance.transition_to(InstanceState.STOPPED) logger.warning(force stop after drain timeout)这个实现的精巧之处在于contextmanager。推理主流程只要用with tracker.handle_request(...)包住就不用关心后续的下线逻辑。等到要下线的时候实例只需要调用start_drain和wait_for_drain就能确保在途请求先结束。实际线上服务里我还在wait_for_drain返回False时把instance.active_requests的数值记录到日志。这些记录是排查“为什么下线卡死”的第一手证据。4.4 调度器中的生命周期状态决策和配置示例调度器要做两件事决定目标实例数以及决定哪些实例可以被选为路由目标。前者根据容量指标和冷却期控制后者根据实例上报的状态过滤。没有把状态过滤做死的调度器会在实例还在初始化时就把流量打过去造成大量超时。调度器维护的实例列表通常来自注册中心汇总。我给出的配置示例参考了YAML管理方式service: name: qwen_resnet_or_llm_serve model: mindspore-llm-v3 version: 20250601_001 replica_limits: min_replicas: 2 max_replicas: 8 scale_policy: cool_down_seconds: 60 queue_depth_threshold: 50 avg_latency_p95_threshold_ms: 300 gpu_idle_memory_threshold_gb: 20 lifecycle: prewarm_timeout_seconds: 300 drain_timeout_seconds: 30 force_kill_after_timeout: true调度器根据这个配置生成决策。选择路由目标时只会选择stateREADY的实例。当某个实例状态是DRAINING时即使它还在处理请求也绝不会被新流量命中。状态过滤放在调度最前端和容量计算解耦。这样做的好处是无论容量算法怎么调参都不会影响“不让未就绪实例接流量”这条底线。调度器本身并不执行“杀掉进程”的动作它只是把目标实例数和新状态通过接口下发给实例管理模块。比如要缩容调度器向某实例发送“drain”指令实例自行决定如何优雅退出。这种模式在微服务架构里也常用迁移到昇思大模型推理场景后唯一的区别是状态管理的粒度更细、动作更重。5. 线上常见问题和排查技巧实录5.1 实例一直处于INITIALIZING请求却开始打进来了有一次线上扩容调度器判断QPS上涨拉起一个新的昇思推理实例。由于模型权重很大加载过程持续了两分多钟。但接入层没有等我自定义的就绪状态上报而是根据端口探测成功就把新实例纳入了负载均衡池。结果请求打过去后实例还在执行图编译每个请求都在阻塞等待导致这批请求全部超时。排查时我先看了注册中心的心跳记录确认实例确实没有上报Ready状态。接着看接入层的服务发现逻辑发现它只探测TCP端口没有读取生命周期状态。修复方案也很明确接入层的健康检查必须与生命周期状态联动只有stateREADY的实例才能出现在后端节点列表里。另外在调度器里也加了保护即使接入层漏了控制面也不会把非READY实例的地址下发给网关。5.2 缩容把正在推理的实例杀掉了另一次事故发生在半夜流量低谷。调度器检测到某个实例的空闲率很高就触发了缩容。旧脚本写得很粗暴直接向实例进程发送SIGKILL结果把一批正在处理的长请求全部中断下游调用方疯狂重试反而把流量又打起来了。这个问题本质上是缩容没有走生命周期管理里的排空流程。后来我把下线动作统一改为先摘流量再发drain指令实例在RequestTracker里等待活跃请求归零。只有两种情况允许强制结束一是活跃请求数已经归零但进程没有退出二是排空等待超过配置的30秒时间窗口。这个兜底逻辑避免了一台实例卡死永远占着显存的问题。所以配置force_kill_after_timeout: true是有必要的关键在于这个timeout必须给足尤其大模型长请求可能需要处理几十秒只等5秒是不够的。5.3 升级后显存暴涨回滚也救不回来有一次发布新版本大模型旧实例组在线新实例组开始拉取新权重。由于新版本模型输入的max_batch或context长度配置比旧版本大很多加上新旧两个实例组同时存在设备显存被直接占满。我在监控上看到显存使用曲线直接到顶回滚指令发出去之后新实例组里的进程卡在OOM边缘动弹不得。回滚救不回来是因为资源已经被占满了调度器想缩容新实例但注册中心里新实例还是INITIALIZING或ERROR状态容错逻辑没处理好。后来我在版本发布前强制加了一步“资源余量检查”如果当前设备显存空闲小于新版本所需空余量则直接拒绝发布任务。同时把新旧实例组的总资源占用纳入调度器视图避免发布期间超卖。另一个教训是模型版本的max_seq_len、KV Cache策略应该和权重文件一起打包不能只换权重不换配置否则升级动作本身就会因为显存配置错误而失控。5.4 模型加载阶段与请求并发互相干扰大模型推理实例在加载权重时会占用设备的大量带宽和内存通道。如果这时候同机的其他实例还在高并发处理推理请求加载速度会变得极慢甚至出现加载超时。我在实际运行中见过两个实例在同昇腾设备上一个在做模型编译一个在持续推理前者的加载时间比常态多了三倍。处理办法是引入全局的“加载互斥”策略。一个设备上同一时刻只允许一个实例进入权重加载或编译阶段。这需要在调度器层面分配实例时检查设备状态。如果已有实例处于INITIALIZING并占用设备新的扩容请求会排队等待而不是一窝蜂全塞上去。另外初始化阶段可以降低实例对设备带宽的占用优先级比如限制加载线程数减少对正常推理请求的影响。5.5 线上生命周期问题速查表症状可能原因快速排查方式长期修复方向请求偶发超时错误率上升未就绪实例被调度查看注册中心实例状态分布确认是否有非READY实例在服务列表接入层健康检查与状态机联动缩容后大量请求失败直接kill实例未走排空检查实例日志是否有SIGKILL记录统一走DRAINING超时机制发布期间显存暴涨新旧实例组共存无资源余量检查查看设备显存曲线发布节点发布前强制资源余量确认实例无法成功回滚新进程OOM调度器无法管理查看新实例状态是否ERROR或STOPPED支持强制回收和资源清理加载耗时增长同设备并发加载/推理抢占带宽检查设备活跃任务列表全局加载互斥和线程限制心跳正常但推理卡死进程内死锁或显存碎片抓取线程栈观察活跃请求计数完善进程级健康探针和自动重启真正把昇思大模型推理系统的生命周期管理做扎实绝不是写几个状态枚举和下线脚本就够了。它需要把“实例是什么、何时能服务、何时不能服务、怎么退出”这个闭环通过架构分层和代码逻辑固定下来。我栽过几次跟头之后最大的体会是不要迷信“先启动起来再说”很多线上故障都源于状态没有理清。你花在设计状态机和排空流程上的时间远比之后抢救事故的时间少得多。另一个很实用的建议是一开始就为每个实例的日志打上instance_id和model_version这样从注册、扩缩容到下线所有问题都能快速关联到具体实例进程排查效率会高非常多。希望这套流程和代码能给你在做昇思推理系统时提供一个可以落地的起点。