拓冰网站定制 
后端人工智能模型推理服务集群管理可观测性【免费下载链接】gpustackA GPU cluster manager for high-performance AI model serving (vLLM, SGLang) and on-demand SSH-accessible GPU instances.项目地址https://gitcode.com/gh_mirrors/gp/gpustack点击查看免费下载GPUStack 的调度器Scheduler是模型部署的核心决策引擎它负责为新模型实例选择最优的 Worker/GPU 放置位置扩容并在副本缩减时决定优先删除哪些现有实例缩容。本文基于官方调度器文档 docs/scheduler.md并结合仓库源码gpustack/scheduler/、gpustack/policies/深入讲解其过滤 评分的两阶段机制、六段 Worker 过滤链、按后端差异化的资源候选评估以及扩容/缩容两套评分链的完整实现。读完本文你将掌握 GPUStack 调度决策的完整链路并学会通过环境变量调整调度策略。调度器概览两大职责与两阶段模型调度器承担两类相互关联的任务扩容Scale Up为新建的模型实例挑选最佳的 Worker/GPU 放置位置缩容Scale Down为现有模型实例排序当副本数减少时优先移除最不偏好的实例。无论哪个方向调度器都遵循同样简洁的两阶段流程过滤Filter找出真正能运行该模型的候选者相当于构建候选清单评分Score为每个候选者打分然后挑选最适合当前目标的一个。从源码看调度器的主体是 gpustack/scheduler/scheduler.py 中的Scheduler类。它通过AsyncUniqueQueue异步队列消费待调度实例start()时以_check_interval 180秒为周期注册IntervalTrigger定时任务做全量扫描同时订阅ModelInstance的CREATED事件做增量触发两者互为兜底。模型实例的状态在调度过程中会依次经历PENDING → ANALYZING → SCHEDULED的流转_evaluate中先将实例置为ANALYZING并写入 Evaluating resource requirements找到候选后由apply_candidate_to_instance置为SCHEDULED并落盘 worker/gpu 信息最终由 Worker 侧上报进入RUNNING。扩容调度Scale-Up1. 基础 Worker 过滤链调度器首先对 Worker 列表做一轮基础过滤这一步主要处理非资源类约束集群、标签、后端兼容性、指定 GPU 与本地路径可用性。过滤链按以下顺序执行与源码 find_candidate 中filters列表的构建顺序一一对应Cluster Filter集群过滤只保留目标集群内的 WorkerGPU Matching FilterGPU 匹配过滤当模型显式指定 GPU 时收窄 Worker 集合Label Matching Filter标签匹配过滤只保留标签满足模型标签选择器的 WorkerStatus Filter状态过滤只保留READY状态的 Workerstatus_filter.py 中逐 worker 比对WorkerStateEnum.READYBackend Framework Filter后端框架过滤剔除加速器或运行时能力与所选后端不匹配的 WorkerLocal Path Filter本地路径过滤仅针对显式指定 GPU 的LOCAL_PATH模型移除配置的模型路径不存在的 Worker。所有过滤器的抽象基类与链式执行逻辑定义在 policies/base.pyWorkerFilterChain.filter()按顺序逐个应用过滤器一旦某轮过滤后 Worker 列表为空则提前终止并聚合所有过滤原因生成诊断消息。只有通过这轮基础过滤的 Worker 才会进入基于资源的候选过滤。注意在 find_candidate 中基础过滤链还会根据情况追加PDModeRuntimeFilterPD 解耦运行时过滤以及可选的GatherFloorFilterMUST_GATHER聚集策略的兜底过滤这些属于多角色/PD 部署场景的扩展普通单角色模型不受影响。2. 基于资源的候选过滤这一阶段同样是过滤但过滤依据从元数据与 Worker 状态换成了资源本身该 Worker 或放置方案能否提供足够的 RAM/VRAM 来运行模型资源需求的估算方式取决于模型类型GGUF 模型使用 GGUF 解析器gguf-parser估算资源需求其他模型类型由对应后端估算例如 vLLM、SGLang、MindIE、VoxBox 等。后端能力不同可用的降级路径也不同vLLM、SGLang、MindIE主要使用基于 GPU 的放置方案此处不使用纯 CPU 或部分 offload 的降级路径GGUF、自定义后端Custom、VoxBox使用 GGUF 解析器估算资源需求支持 GPU offload、部分 offload 或 CPU 执行自定义后端、VoxBox支持 GPU offload 或 CPU 执行。候选者按顺序评估一旦某个策略返回可运行的候选者即停止。总体上调度器依次尝试单 Worker 单 GPU一个 Worker 上的一块 GPU 足以满足模型需求单 Worker 多 GPU单块 GPU 不够时同一 Worker 上的多块 GPU 联合使用跨 Worker 分布式推理后端支持分布式执行时可使用多个 Worker 上的 GPU部分 offload 或 CPU 执行仅当该模型类型与后端支持这些降级模式时使用。这里有几个关键细节资源适配过滤在得到候选的第一个策略处停止分布式候选可以包含主 Worker 之外的从属 Workersubordinate_workers显式 GPU 选择在基础过滤与资源适配过滤两个阶段都会被尊重。源码层面选择哪个资源适配 selector 由 build_candidate_selector 决定它按优先级依次处理纯 CPU 角色 → GPU 实例类型整卡声明InstanceTypeWholeCardSelector→ vGPU 切分VGPUResourceFitSelector→ GGUF 模型GGUFResourceFitSelector→ Ascend MindIE → vLLMOmni 模型除外→ SGLang → 其余走CustomBackendResourceFitSelector。GGUF 的评估逻辑集中在 gguf_resource_fit_selector.py其中定义了Single-Worker Single-GPU Full Offloading、Single-Worker Multi-GPU Full Offloading、Distributed Deployment、Single-Worker Partial Offloading、CPU Offloading等事件动作与文档描述的尝试顺序完全吻合。资源估算过程依赖 scheduler/calculator.py 的calculate_gguf_model_resource_claimGGUF与get_pretrained_config_with_workers其他模型读取预训练配置调度器在_evaluate中还会据此自动补全模型的categoriesLLM/EMBEDDING/RERANKER/IMAGE、distributable与gpus_per_replica等字段。3. 候选评分找到可运行的候选后调度器用一条评分链scorer chain给候选打分并选择总分最高的候选。当前扩容评分链为Placement Scorer放置评分器Model File Locality Scorer模型文件本地性评分器候选总分是所有启用评分器得分之和。评分链的实现见 score_chain.py 的CandidateScoreChain每个评分器独立计算得分后累加total_scores[id(candidate)] candidate.score最终按总分排序。Placement Scorer放置评分器放置评分器在扩容时始终启用源码见 placement_scorer.py它根据模型的placement_strategy字段选择 binpack 或 spread 策略Binpack装箱目标是把尽可能多的模型实例打包进最少的箱子如 Worker/GPU在不超过容量上限的前提下最大化资源利用率、最小化箱子数量。模型实例被放到剩余空间最少的箱子中以最小化每个箱子的剩余容量。Spread分散目标是把多个模型实例尽可能均匀地分布到不同 Worker 上提升系统容错性与负载均衡能力。额外行为对于 GPU 放置VRAM 压力比 RAM 压力权重更重。源码中ResourceWeight的默认值为vram 2.0、ram 1.0即 VRAM 占用率对得分的贡献是 RAM 的两倍对于纯 CPU 放置只考虑 RAM 利用率。从源码结构看spread 策略的得分还会区分当前模型的实例数current与其他模型的实例数others并按 Worker权重 0.85与 GPU权重 0.15两个维度加权计算优先选择当前模型实例数最少的 Worker/GPU。Model File Locality Scorer模型文件本地性评分器该评分器用于把放置偏向于已经拥有所需模型文件且文件处于READY状态的 Worker源码见 model_file_locality_scorer.py。其行为查询已就绪主模型文件的 Worker若配置了投机解码speculative decoding同时查询草稿模型draft model的就绪文件按参与该候选的 Worker 中已拥有这些文件的比例给每个候选打分主模型本地性的权重高于草稿模型本地性。源码中主模型比例权重为 1.0草稿模型比例权重为 0.5最终得分为(main_ratio 0.5 * draft_ratio) / 1.5 * max_score。需要说明的是该评分器在得分上限max_score 0时直接跳过。默认上限由环境变量GPUSTACK_SCHEDULER_SCALE_UP_LOCALITY_MAX_SCORE控制默认 5设置为 0 可关闭本地性偏好。另外从 find_candidate 的代码可以看到当集群声明了拓扑topology且实例属于多角色分组时评分链还会追加TopologyProximityScorer拓扑邻近评分器与PairingAffinityScorer配对亲和评分器前者偏向靠近同组其他角色的 Worker后者偏向与对向角色同机的 Worker——这些是 PD 解耦部署prefill/decode 分离场景的专用扩展普通模型不受影响。4. 最终选择评分完成后调度器选择总分最高的候选将模型实例指派到该放置位置。pick_highest_score_candidate 采用简单的线性扫描比较各候选score字段选中后 apply_candidate_to_instance 会把 worker_id、worker_name、gpu_indexes、gpu_addresses、computed_resource_claim、分布式从属 Worker 等十个字段写入实例行状态置为SCHEDULED并针对 vLLM/MindIE/SGLang 设置distributed_servers.mode INITIALIZE_LATER。缩容调度Scale-Down当期望副本数低于现有模型实例数时控制器会对现有实例排序先删除排名最低的实例。入口在 gpustack/server/controllers.py 的find_scale_down_candidates它调用ModelInstanceScoreChain对实例评分后按分数升序排列sorted(..., reverseFalse)调用方从列表头部开始取len(candidates) - replicas个实例执行删除。缩容使用独立的评分链作用于现有模型实例Status Scorer状态评分器Offload Layer ScorerOffload 层数评分器Placement Scorer放置评分器注意缩容评分链与扩容不同它使用ModelInstanceScoreChain而非CandidateScoreChain后者会对各评分器的分数按总分上限归一化scale_factor total_max_score / sum_max_score。Status Scorer状态评分器状态评分器偏好健康副本使不健康或尚未就绪的副本成为优先删除对象。源码 status_scorer.py 的打分规则为Worker 处于NOT_READY或实例处于ERROR得 0 分WorkerREADY且实例RUNNING得满分max_score默认 100其他中间状态得满分的一半。分数越低越先被删除因此不健康、报错、未就绪的实例会首先成为缩容目标。Offload Layer ScorerOffload 层数评分器对于上报了total_layers与offload_layers的 GGUF 模型该评分器偏好已 offload 更多层的实例源码见 offload_layer_scorer.py完全 offloadtotal_layers offload_layers得满分部分 offload按offload_layers / total_layers比例得分无 offload 层元数据得 0 分。其语义是已把更多层驻留在 GPU 上的实例价值更高缩容时应保留offload 层数少更依赖 CPU的实例先删。Placement Scorer 的缩容模式同一个放置评分器在缩容时被复用但它从移除视角而非放置视角评估现有放置placement_scorer.py 中通过scale_typeScaleTypeEnum.SCALE_DOWN切换。放置仍反映模型的binpack或spread策略但分数被解释为保留偏好binpack 缩容模式下单 GPU 打分把自身 claim 计入可分配资源allocatable.vram vram_claim即评估若删掉该实例会释放多少资源/剩余密度spread 缩容模式同样基于实例分布计数评估。因此放置分数越低的实例越可能被优先移除。默认的缩容放置分上限仅为 1GPUSTACK_SCHEDULER_SCALE_DOWN_PLACEMENT_MAX_SCORE远低于状态评分器的 100说明缩容决策以实例健康状态为主、放置策略为辅。此外若实例属于多角色分组缩容链还会追加PairingRetentionScorer保留与对向角色共置的实例。调度策略相关环境变量调度器各评分器的得分上限即各策略的相对权重可通过环境变量调整默认值定义在 gpustack/envs/init.py环境变量默认值作用GPUSTACK_SCHEDULER_SCALE_UP_PLACEMENT_MAX_SCORE100扩容放置评分器得分上限GPUSTACK_SCHEDULER_SCALE_UP_LOCALITY_MAX_SCORE5扩容模型文件本地性评分器得分上限设为 0 关闭GPUSTACK_SCHEDULER_SCALE_DOWN_STATUS_MAX_SCORE100缩容状态评分器得分上限GPUSTACK_SCHEDULER_SCALE_DOWN_OFFLOAD_MAX_SCORE10缩容 offload 层数评分器得分上限GPUSTACK_SCHEDULER_SCALE_DOWN_PLACEMENT_MAX_SCORE1缩容放置评分器得分上限GPUSTACK_SCHEDULER_SCALE_DOWN_PAIRING_MAX_SCORE20缩容配对保留评分器得分上限GPUSTACK_SCHEDULER_PAIRING_AFFINITY_MAX_SCORE200扩容配对亲和评分器得分上限设为 0 关闭GPUSTACK_SCHEDULER_TOPOLOGY_PROXIMITY_MAX_SCORE150扩容拓扑邻近评分器得分上限GPUSTACK_SCHEDULER_GROUP_PAIR_LOCALITY_WEIGHT1.0分组配对本地性权重GPUSTACK_SCHEDULER_GROUP_FILE_LOCALITY_WEIGHT0.3分组文件本地性权重从默认值可以看出 GPUStack 的调优思路扩容时放置策略100是主导信号文件本地性5是轻量级的加速偏好缩容时实例健康状态100主导、offload 程度10其次、放置策略1仅作微调。这些权重均可按集群特征如是否频繁冷启动下载模型、是否存在异构 GPU进行调整。代码地图从文档到实现如果希望进一步研读调度器实现仓库中以下位置与本文内容直接对应gpustack/scheduler/scheduler.pyScheduler主循环、find_candidate过滤与评分编排、build_candidate_selector、apply_candidate_to_instancegpustack/scheduler/calculator.pyGGUF 与非 GGUF 模型的资源 claim 估算gpustack/policies/base.pyWorkerFilter/WorkerFilterChain、ScheduleCandidatesScorer/ModelInstanceScorer等抽象基类gpustack/policies/worker_filters/六段基础过滤链的逐一实现gpustack/policies/candidate_selectors/按后端分派的资源适配选择器gpustack/policies/scorers/placement、model file locality、status、offload layer 等评分器与评分链gpustack/server/controllers.pyfind_scale_down_candidates缩容评分入口tests/scheduler/ 与 tests/policies/调度器与各过滤/评分策略的测试用例是理解预期行为的可靠参考。小结GPUStack 的调度器以过滤 评分两阶段模型统一了扩容与缩容两种场景扩容时通过六段基础过滤链收缩 Worker 集合再按模型类型与后端能力进行资源适配评估最后以放置策略binpack/spread为主、模型文件本地性为辅完成打分选优缩容时则以实例健康状态为首要依据结合 GGUF offload 层数与放置策略排序升序删除最低分实例。理解这条决策链是排查实例长时间 PENDING、优化异构集群资源利用率、以及调整模型分布策略的前提。赞分享后端人工智能模型推理服务集群管理可观测性【免费下载链接】gpustackA GPU cluster manager for high-performance AI model serving (vLLM, SGLang) and on-demand SSH-accessible GPU instances.项目地址https://gitcode.com/gh_mirrors/gp/gpustack点击查看免费下载相关推荐Volcano Job 弹性扩缩容基于 JobUpdatedEvent 与插件机制的 Scale Up/Down 设计解析Volcano Job 弹性扩缩容基于 JobUpdatedEvent 与插件机制的 Scale Up/Down 设计解析 本文以 Volcano 设计文档云原生后端任务调度批处理ERNIE-Image-Turbo性能优化如何在消费级GPU上高效运行ERNIE Image Turbo性能优化如何在消费级GPU上高效运行 ERNIE Image Turbo是百度ERNIE Image团队开发的开源文本到图像rkt容器调度扩展调度器扩展点与插件开发实例rkt容器调度扩展调度器扩展点与插件开发实例 一、调度器扩展背景与核心价值 在容器编排领域调度策略的灵活性直接影响资源利用率与业务稳定性。rkt作为遵循Ap容器运行时云原生网络上一篇Flutter Admin图表组件全解析数据可视化从未如此简单下一篇终极iOS侧载指南用AltStore轻松安装未签名应用的完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GPUStack 调度器深度解析：模型实例的扩容（Scale-Up）与缩容（Scale-Down）调度机制
后端人工智能模型推理服务集群管理可观测性【免费下载链接】gpustackA GPU cluster manager for high-performance AI model serving (vLLM, SGLang) and on-demand SSH-accessible GPU instances.项目地址https://gitcode.com/gh_mirrors/gp/gpustack点击查看免费下载GPUStack 的调度器Scheduler是模型部署的核心决策引擎它负责为新模型实例选择最优的 Worker/GPU 放置位置扩容并在副本缩减时决定优先删除哪些现有实例缩容。本文基于官方调度器文档 docs/scheduler.md并结合仓库源码gpustack/scheduler/、gpustack/policies/深入讲解其过滤 评分的两阶段机制、六段 Worker 过滤链、按后端差异化的资源候选评估以及扩容/缩容两套评分链的完整实现。读完本文你将掌握 GPUStack 调度决策的完整链路并学会通过环境变量调整调度策略。调度器概览两大职责与两阶段模型调度器承担两类相互关联的任务扩容Scale Up为新建的模型实例挑选最佳的 Worker/GPU 放置位置缩容Scale Down为现有模型实例排序当副本数减少时优先移除最不偏好的实例。无论哪个方向调度器都遵循同样简洁的两阶段流程过滤Filter找出真正能运行该模型的候选者相当于构建候选清单评分Score为每个候选者打分然后挑选最适合当前目标的一个。从源码看调度器的主体是 gpustack/scheduler/scheduler.py 中的Scheduler类。它通过AsyncUniqueQueue异步队列消费待调度实例start()时以_check_interval 180秒为周期注册IntervalTrigger定时任务做全量扫描同时订阅ModelInstance的CREATED事件做增量触发两者互为兜底。模型实例的状态在调度过程中会依次经历PENDING → ANALYZING → SCHEDULED的流转_evaluate中先将实例置为ANALYZING并写入 Evaluating resource requirements找到候选后由apply_candidate_to_instance置为SCHEDULED并落盘 worker/gpu 信息最终由 Worker 侧上报进入RUNNING。扩容调度Scale-Up1. 基础 Worker 过滤链调度器首先对 Worker 列表做一轮基础过滤这一步主要处理非资源类约束集群、标签、后端兼容性、指定 GPU 与本地路径可用性。过滤链按以下顺序执行与源码 find_candidate 中filters列表的构建顺序一一对应Cluster Filter集群过滤只保留目标集群内的 WorkerGPU Matching FilterGPU 匹配过滤当模型显式指定 GPU 时收窄 Worker 集合Label Matching Filter标签匹配过滤只保留标签满足模型标签选择器的 WorkerStatus Filter状态过滤只保留READY状态的 Workerstatus_filter.py 中逐 worker 比对WorkerStateEnum.READYBackend Framework Filter后端框架过滤剔除加速器或运行时能力与所选后端不匹配的 WorkerLocal Path Filter本地路径过滤仅针对显式指定 GPU 的LOCAL_PATH模型移除配置的模型路径不存在的 Worker。所有过滤器的抽象基类与链式执行逻辑定义在 policies/base.pyWorkerFilterChain.filter()按顺序逐个应用过滤器一旦某轮过滤后 Worker 列表为空则提前终止并聚合所有过滤原因生成诊断消息。只有通过这轮基础过滤的 Worker 才会进入基于资源的候选过滤。注意在 find_candidate 中基础过滤链还会根据情况追加PDModeRuntimeFilterPD 解耦运行时过滤以及可选的GatherFloorFilterMUST_GATHER聚集策略的兜底过滤这些属于多角色/PD 部署场景的扩展普通单角色模型不受影响。2. 基于资源的候选过滤这一阶段同样是过滤但过滤依据从元数据与 Worker 状态换成了资源本身该 Worker 或放置方案能否提供足够的 RAM/VRAM 来运行模型资源需求的估算方式取决于模型类型GGUF 模型使用 GGUF 解析器gguf-parser估算资源需求其他模型类型由对应后端估算例如 vLLM、SGLang、MindIE、VoxBox 等。后端能力不同可用的降级路径也不同vLLM、SGLang、MindIE主要使用基于 GPU 的放置方案此处不使用纯 CPU 或部分 offload 的降级路径GGUF、自定义后端Custom、VoxBox使用 GGUF 解析器估算资源需求支持 GPU offload、部分 offload 或 CPU 执行自定义后端、VoxBox支持 GPU offload 或 CPU 执行。候选者按顺序评估一旦某个策略返回可运行的候选者即停止。总体上调度器依次尝试单 Worker 单 GPU一个 Worker 上的一块 GPU 足以满足模型需求单 Worker 多 GPU单块 GPU 不够时同一 Worker 上的多块 GPU 联合使用跨 Worker 分布式推理后端支持分布式执行时可使用多个 Worker 上的 GPU部分 offload 或 CPU 执行仅当该模型类型与后端支持这些降级模式时使用。这里有几个关键细节资源适配过滤在得到候选的第一个策略处停止分布式候选可以包含主 Worker 之外的从属 Workersubordinate_workers显式 GPU 选择在基础过滤与资源适配过滤两个阶段都会被尊重。源码层面选择哪个资源适配 selector 由 build_candidate_selector 决定它按优先级依次处理纯 CPU 角色 → GPU 实例类型整卡声明InstanceTypeWholeCardSelector→ vGPU 切分VGPUResourceFitSelector→ GGUF 模型GGUFResourceFitSelector→ Ascend MindIE → vLLMOmni 模型除外→ SGLang → 其余走CustomBackendResourceFitSelector。GGUF 的评估逻辑集中在 gguf_resource_fit_selector.py其中定义了Single-Worker Single-GPU Full Offloading、Single-Worker Multi-GPU Full Offloading、Distributed Deployment、Single-Worker Partial Offloading、CPU Offloading等事件动作与文档描述的尝试顺序完全吻合。资源估算过程依赖 scheduler/calculator.py 的calculate_gguf_model_resource_claimGGUF与get_pretrained_config_with_workers其他模型读取预训练配置调度器在_evaluate中还会据此自动补全模型的categoriesLLM/EMBEDDING/RERANKER/IMAGE、distributable与gpus_per_replica等字段。3. 候选评分找到可运行的候选后调度器用一条评分链scorer chain给候选打分并选择总分最高的候选。当前扩容评分链为Placement Scorer放置评分器Model File Locality Scorer模型文件本地性评分器候选总分是所有启用评分器得分之和。评分链的实现见 score_chain.py 的CandidateScoreChain每个评分器独立计算得分后累加total_scores[id(candidate)] candidate.score最终按总分排序。Placement Scorer放置评分器放置评分器在扩容时始终启用源码见 placement_scorer.py它根据模型的placement_strategy字段选择 binpack 或 spread 策略Binpack装箱目标是把尽可能多的模型实例打包进最少的箱子如 Worker/GPU在不超过容量上限的前提下最大化资源利用率、最小化箱子数量。模型实例被放到剩余空间最少的箱子中以最小化每个箱子的剩余容量。Spread分散目标是把多个模型实例尽可能均匀地分布到不同 Worker 上提升系统容错性与负载均衡能力。额外行为对于 GPU 放置VRAM 压力比 RAM 压力权重更重。源码中ResourceWeight的默认值为vram 2.0、ram 1.0即 VRAM 占用率对得分的贡献是 RAM 的两倍对于纯 CPU 放置只考虑 RAM 利用率。从源码结构看spread 策略的得分还会区分当前模型的实例数current与其他模型的实例数others并按 Worker权重 0.85与 GPU权重 0.15两个维度加权计算优先选择当前模型实例数最少的 Worker/GPU。Model File Locality Scorer模型文件本地性评分器该评分器用于把放置偏向于已经拥有所需模型文件且文件处于READY状态的 Worker源码见 model_file_locality_scorer.py。其行为查询已就绪主模型文件的 Worker若配置了投机解码speculative decoding同时查询草稿模型draft model的就绪文件按参与该候选的 Worker 中已拥有这些文件的比例给每个候选打分主模型本地性的权重高于草稿模型本地性。源码中主模型比例权重为 1.0草稿模型比例权重为 0.5最终得分为(main_ratio 0.5 * draft_ratio) / 1.5 * max_score。需要说明的是该评分器在得分上限max_score 0时直接跳过。默认上限由环境变量GPUSTACK_SCHEDULER_SCALE_UP_LOCALITY_MAX_SCORE控制默认 5设置为 0 可关闭本地性偏好。另外从 find_candidate 的代码可以看到当集群声明了拓扑topology且实例属于多角色分组时评分链还会追加TopologyProximityScorer拓扑邻近评分器与PairingAffinityScorer配对亲和评分器前者偏向靠近同组其他角色的 Worker后者偏向与对向角色同机的 Worker——这些是 PD 解耦部署prefill/decode 分离场景的专用扩展普通模型不受影响。4. 最终选择评分完成后调度器选择总分最高的候选将模型实例指派到该放置位置。pick_highest_score_candidate 采用简单的线性扫描比较各候选score字段选中后 apply_candidate_to_instance 会把 worker_id、worker_name、gpu_indexes、gpu_addresses、computed_resource_claim、分布式从属 Worker 等十个字段写入实例行状态置为SCHEDULED并针对 vLLM/MindIE/SGLang 设置distributed_servers.mode INITIALIZE_LATER。缩容调度Scale-Down当期望副本数低于现有模型实例数时控制器会对现有实例排序先删除排名最低的实例。入口在 gpustack/server/controllers.py 的find_scale_down_candidates它调用ModelInstanceScoreChain对实例评分后按分数升序排列sorted(..., reverseFalse)调用方从列表头部开始取len(candidates) - replicas个实例执行删除。缩容使用独立的评分链作用于现有模型实例Status Scorer状态评分器Offload Layer ScorerOffload 层数评分器Placement Scorer放置评分器注意缩容评分链与扩容不同它使用ModelInstanceScoreChain而非CandidateScoreChain后者会对各评分器的分数按总分上限归一化scale_factor total_max_score / sum_max_score。Status Scorer状态评分器状态评分器偏好健康副本使不健康或尚未就绪的副本成为优先删除对象。源码 status_scorer.py 的打分规则为Worker 处于NOT_READY或实例处于ERROR得 0 分WorkerREADY且实例RUNNING得满分max_score默认 100其他中间状态得满分的一半。分数越低越先被删除因此不健康、报错、未就绪的实例会首先成为缩容目标。Offload Layer ScorerOffload 层数评分器对于上报了total_layers与offload_layers的 GGUF 模型该评分器偏好已 offload 更多层的实例源码见 offload_layer_scorer.py完全 offloadtotal_layers offload_layers得满分部分 offload按offload_layers / total_layers比例得分无 offload 层元数据得 0 分。其语义是已把更多层驻留在 GPU 上的实例价值更高缩容时应保留offload 层数少更依赖 CPU的实例先删。Placement Scorer 的缩容模式同一个放置评分器在缩容时被复用但它从移除视角而非放置视角评估现有放置placement_scorer.py 中通过scale_typeScaleTypeEnum.SCALE_DOWN切换。放置仍反映模型的binpack或spread策略但分数被解释为保留偏好binpack 缩容模式下单 GPU 打分把自身 claim 计入可分配资源allocatable.vram vram_claim即评估若删掉该实例会释放多少资源/剩余密度spread 缩容模式同样基于实例分布计数评估。因此放置分数越低的实例越可能被优先移除。默认的缩容放置分上限仅为 1GPUSTACK_SCHEDULER_SCALE_DOWN_PLACEMENT_MAX_SCORE远低于状态评分器的 100说明缩容决策以实例健康状态为主、放置策略为辅。此外若实例属于多角色分组缩容链还会追加PairingRetentionScorer保留与对向角色共置的实例。调度策略相关环境变量调度器各评分器的得分上限即各策略的相对权重可通过环境变量调整默认值定义在 gpustack/envs/init.py环境变量默认值作用GPUSTACK_SCHEDULER_SCALE_UP_PLACEMENT_MAX_SCORE100扩容放置评分器得分上限GPUSTACK_SCHEDULER_SCALE_UP_LOCALITY_MAX_SCORE5扩容模型文件本地性评分器得分上限设为 0 关闭GPUSTACK_SCHEDULER_SCALE_DOWN_STATUS_MAX_SCORE100缩容状态评分器得分上限GPUSTACK_SCHEDULER_SCALE_DOWN_OFFLOAD_MAX_SCORE10缩容 offload 层数评分器得分上限GPUSTACK_SCHEDULER_SCALE_DOWN_PLACEMENT_MAX_SCORE1缩容放置评分器得分上限GPUSTACK_SCHEDULER_SCALE_DOWN_PAIRING_MAX_SCORE20缩容配对保留评分器得分上限GPUSTACK_SCHEDULER_PAIRING_AFFINITY_MAX_SCORE200扩容配对亲和评分器得分上限设为 0 关闭GPUSTACK_SCHEDULER_TOPOLOGY_PROXIMITY_MAX_SCORE150扩容拓扑邻近评分器得分上限GPUSTACK_SCHEDULER_GROUP_PAIR_LOCALITY_WEIGHT1.0分组配对本地性权重GPUSTACK_SCHEDULER_GROUP_FILE_LOCALITY_WEIGHT0.3分组文件本地性权重从默认值可以看出 GPUStack 的调优思路扩容时放置策略100是主导信号文件本地性5是轻量级的加速偏好缩容时实例健康状态100主导、offload 程度10其次、放置策略1仅作微调。这些权重均可按集群特征如是否频繁冷启动下载模型、是否存在异构 GPU进行调整。代码地图从文档到实现如果希望进一步研读调度器实现仓库中以下位置与本文内容直接对应gpustack/scheduler/scheduler.pyScheduler主循环、find_candidate过滤与评分编排、build_candidate_selector、apply_candidate_to_instancegpustack/scheduler/calculator.pyGGUF 与非 GGUF 模型的资源 claim 估算gpustack/policies/base.pyWorkerFilter/WorkerFilterChain、ScheduleCandidatesScorer/ModelInstanceScorer等抽象基类gpustack/policies/worker_filters/六段基础过滤链的逐一实现gpustack/policies/candidate_selectors/按后端分派的资源适配选择器gpustack/policies/scorers/placement、model file locality、status、offload layer 等评分器与评分链gpustack/server/controllers.pyfind_scale_down_candidates缩容评分入口tests/scheduler/ 与 tests/policies/调度器与各过滤/评分策略的测试用例是理解预期行为的可靠参考。小结GPUStack 的调度器以过滤 评分两阶段模型统一了扩容与缩容两种场景扩容时通过六段基础过滤链收缩 Worker 集合再按模型类型与后端能力进行资源适配评估最后以放置策略binpack/spread为主、模型文件本地性为辅完成打分选优缩容时则以实例健康状态为首要依据结合 GGUF offload 层数与放置策略排序升序删除最低分实例。理解这条决策链是排查实例长时间 PENDING、优化异构集群资源利用率、以及调整模型分布策略的前提。赞分享后端人工智能模型推理服务集群管理可观测性【免费下载链接】gpustackA GPU cluster manager for high-performance AI model serving (vLLM, SGLang) and on-demand SSH-accessible GPU instances.项目地址https://gitcode.com/gh_mirrors/gp/gpustack点击查看免费下载相关推荐Volcano Job 弹性扩缩容基于 JobUpdatedEvent 与插件机制的 Scale Up/Down 设计解析Volcano Job 弹性扩缩容基于 JobUpdatedEvent 与插件机制的 Scale Up/Down 设计解析 本文以 Volcano 设计文档云原生后端任务调度批处理ERNIE-Image-Turbo性能优化如何在消费级GPU上高效运行ERNIE Image Turbo性能优化如何在消费级GPU上高效运行 ERNIE Image Turbo是百度ERNIE Image团队开发的开源文本到图像rkt容器调度扩展调度器扩展点与插件开发实例rkt容器调度扩展调度器扩展点与插件开发实例 一、调度器扩展背景与核心价值 在容器编排领域调度策略的灵活性直接影响资源利用率与业务稳定性。rkt作为遵循Ap容器运行时云原生网络上一篇Flutter Admin图表组件全解析数据可视化从未如此简单下一篇终极iOS侧载指南用AltStore轻松安装未签名应用的完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考