首Token延迟降低32.4%！是石科技放出集群调度大招，国产推理再提效

• 允中 发自 凹非寺
• 量子位 | 公众号QbitAI
  

GPU集群里，请求排队和资源闲置，可能同时发生。

2026 CCF全国高性能计算学术大会期间，是石科技发布新品TokenFleet分布式调度框架，把优化重点放在请求路由、跨机房容量协同和混合负载治理上，尝试提高现有算力的有效产出。

如果把推理服务看作一座“国产Token优化工厂”，GPU是生产设备，推理实例是工位，业务请求则是一张张订单。TokenFleet负责的，就是把订单与产能匹配起来。

同一批设备，接到的任务不同、分配方式不同，最终的等待时间与达标产出也会不同。规模化服务，需要把这些生产安排一起考虑。

TokenFleet聚焦集群的有效产出

模型部署完成之后，集群还需要同时应对多种业务。

多个模型共享算力，不同租户有各自的服务等级要求。短对话要及时响应，长文档处理需要更多计算与显存，离线批量任务又有完成期限。服务分布在多个机房时，还要考虑各处的容量能否协同。

简单分流可能让部分实例排起长队，其他位置的容量却没有被及时利用。长请求与批量任务相互挤压，会拖慢实时交互；超时、取消和重复计算，又会消耗资源却未形成合格交付。

TokenFleet在模型质量、服务要求与算力预算一致的条件下，通过提高有效Token产出，降低单位有效产出的成本

TokenPilot在同一模型池内选择实例，FleetMind面向跨机房容量协同，SLOMax负责混合负载的准入、队列治理与容量分配，三项核心技术各有分工。

请求分给谁、任务何时进入队列、机房容量如何协同，最终都要回到同一个指标：成功完成且满足服务要求的有效Token产出。

△图1 TokenFleet三项核心调度技术总览

TokenPilot把缓存收益与排队代价一起算

先看请求选点。一次请求，应该发给哪个实例？

一句短问答和一份长文档，即使都算一次请求，消耗的计算与显存也可能相差很大。只按请求数量分流，很难均衡各个实例的实际工作量。

缓存让这件事多了一层取舍。带着相同长前缀的请求，如果送到保留了相关KV缓存的实例，就有机会复用此前的计算结果，减少Prefill，也就是处理输入内容时的重复计算。

但缓存命中高的实例，也可能排队久。请求都涌向同一处，省下的计算时间就可能消耗在等待上。

TokenPilot在选点时，同时估算缓存复用收益与排队代价。它结合输入规模、输出预算和可复用前缀估计工作量，再综合队列、在途Token、KV缓存压力与预测延迟，筛选并评分候选实例。输出预算是约束条件，并不代表实际输出长度。

调度器据此比较不同实例的预计处理代价，判断复用缓存省下的计算，能否抵消额外等待。

△图2 TokenPilot智能推理路由框架

是石科技提供的GLM5.3调优数据显示，在所测显卡集群与负载条件下，采用预测延迟路由后，P95首Token延迟降低32.4%，P50首Token延迟降低71.3%。

△表1 TokenPilot首Token延迟调优结果。数据来源：是石科技大会演讲材料。改善率按（基线值－优化值）÷基线值计算；延迟下降不直接等于成本下降。

P50反映中位水平，P95反映尾部请求的等待情况。这组数据展示的是所测条件下的响应改善；成本收益仍需结合吞吐与资源占用评估。

FleetMind跨机房也要算清服务容量

把视角从一个模型池拉到多个机房，调度就多了一层容量判断。

有空闲GPU，未必能马上接单。目标模型是否部署、版本是否匹配、服务端点是否就绪，以及网络传输要花多少时间，都会影响分流效果。

FleetMind关注的是实际可用的模型服务容量。在TokenFleet的设计中，它汇聚各机房的模型可用性、实时容量与网络状态，先选择执行机房，再由该机房的本地决策引擎选择具体推理实例。

当热点机房开始排队，系统会评估其他机房是否有同版本模型的就绪端点、是否仍有服务余量，再判断能否承接允许跨地域执行的新请求。

能不能分流，要先满足权限和数据地域约束。值不值得分流，还要综合比较回源时延、排队、计算、缓存与传输成本。

容量协同也有不同的时间尺度：短周期调整新请求的去向，长周期调整模型副本与预热位置，并结合容量预留、负载上限感知和自动回退，减少容量错配。

△图3 FleetMind跨机房执行框架。说明：A地为业务入口，不计入GPU容量池；B地为现有集群，C、D地为扩展机房。

TokenPilot与SLOMax面向现有集群，FleetMind面向后续新增算力机房的扩展。跨机房协同的目标，是让符合业务约束的分散容量承接热点需求，减少容量错配和重复预留。

SLOMax按服务要求安排生产

请求进入同一个集群，交付要求却各不相同。

实时对话关心首Token响应和持续生成速度，长上下文任务更依赖输入处理能力与KV容量，离线批量任务则关注完成期限和吞吐。把它们放进同一套队列，容易产生资源争抢。

长Prefill、KV容量压力和批量负载，都可能挤压交互请求。超时、取消与重复执行，还会让一部分计算无法转化为有效交付。

SLOMax结合输入长度、输出预算、任务类型与租户服务目标识别工作量，再按等级准入、分池排队并协调容量。它需要保障交互容量，控制长短请求的并发与相互干扰。

△图4 SLOMax分类队列与容量反馈框架。说明：效果反馈用于调整容量与准入，框架不预设运行中任务抢占能力。

衡量这套调度效果，TokenFleet把达标产出作为优化目标。

Goodput，即达标输出吞吐，计算的是：完整测试时段内，成功完成且满足约定服务要求的请求所产生的输出Token总量，除以测试时长。不同任务类别需要分别定义达标门槛并报告结果。

系统将达标吞吐、失败、取消与重复执行情况反馈给调度策略，持续调整准入和容量比例。GPU有多忙、总吞吐有多高，都需要与最终的合格交付一起看。

在是石科技给出的GLM5.3收益测算示例中，采用流控协同调度后，总输出吞吐增加约1.5%，达标输出吞吐提高约29.4%，达标比例从约67%升至约86%。

△表2 SLOMax有效Token吞吐收益测算示例。数据来源：是石科技大会演讲材料。本表为收益测算示例；达标比例沿用原文取整值，变化约19个百分点。

这组数值属于收益测算，展示了调度希望改善的产出结构。实际收益仍需结合具体负载与服务门槛验证。

同样规模的总产出，如果能减少超时、取消和重复计算，就有机会交付更多达标Token。SLOMax把这些结果纳入反馈，用于调整后续资源分配。

国产Token优化工厂的效率，还要看调度

TokenFleet把推理服务的优化推进到集群层面。实例性能如何分配给不同请求，多个机房的容量如何参与服务，都需要调度把资源与业务要求接起来。

是石科技（METASTONE）是一家独立第三方全栈算力运营商，不绑定任何特定大模型厂商，为客户提供涵盖硬件、组网、调度、优化与运营的一站式全栈算力交付服务

凭借源自国家级计算中心的丰富经验，其算力集群运行SLA达到99.95%以上。目前，是石科技已纳管超过20000P+的算力资源，运营10多个超智算中心，其中有2个国家级超算中心；团队成员曾荣获3项戈登·贝尔奖，积累了超大规模集群的全栈技术服务经验。

围绕国产Token优化工厂，是石科技以自研自用持续打磨软件能力，希望让通用、高频的推理服务更经济，让国产算力发挥更多能力。

此前发布的Meta-Infer高效推理引擎，着力提升单个推理实例的执行效率。此次TokenFleet则把重点放在集群调度，通过请求分配、容量协同与混合负载治理，组织规模化服务。

让更多业务用得起、用得好Token，既需要硬件提供算力，也需要软件把产能组织起来。

TokenFleet把进一步优化的方向，落在了每一次请求如何被分配、每一份容量如何被使用上。

*本文系量子位获授权刊载，观点仅为原作者所有。