vllm-project/vllm-ascend

[Contribution] 任务 #8:[Perf/Investigation] 量化 layerwise recv 队头阻塞并评估依赖感知调度

Aperta

#14.149 aperta il 13 ago 2026

 (4 commenti) (0 reazioni) (0 assegnatari)C++ (2090 fork)github user discovery
help wanted

Metriche repository

Star
 (2677 stelle)
Metriche merge PR
 (Merge medio 4g 5h) (559 PR mergiate in 30 g)

Descrizione

背景

layerwise recv thread 使用单 FIFO 队列串行处理任务。队头任务可能等待共享 buffer 的 save owner 或 attention boundary;等待期间后续任务无法被检查,具备 head-of-line blocking 的结构性条件。但静态代码不能证明后续任务会更早 ready,也不能证明改变调度一定改善 TTFT 或吞吐。

GVA 路径的依赖链包含 save CPU event、save NPU event、attention gate 的 CPU record wait 和 gate NPU event;key-based 路径的依赖链不同。必须先把 host 等待、NPU 同步、backend 提交和完成拆开测量,再决定是否修改调度。

相关代码路径:vllm_ascend/distributed/kv_transfer/kv_pool/ascend_store

调查任务

  1. 增加可关闭的时间线/profiler 标记,并为每个 task 记录稳定关联 id、request/layer/group、入队、出队、各依赖满足、backend 提交和完成时间。
  2. 至少拆分以下阶段,不得合并为笼统的 gate waitsave-owner wait
    • queue wait:enqueue 到 dequeue;
    • save CPU event wait;
    • save NPU event synchronize(仅适用路径);
    • gate record/condition wait;
    • gate NPU event synchronize;
    • metadata/address build;
    • backend submit;
    • backend/NPU transfer completion。
  3. 显式检测并统计真正的 HOL 事件:队头依赖未满足期间,队列中至少一个后续任务已满足其全部依赖。仅有队头等待、但后续任务也未 ready,不计为可调度优化机会。
  4. 覆盖默认和显式 prefetch 深度、不同 layerwise_num_shared_buffers、有/无 buffer reuse、independent layer、单/多请求和不同并发;分别报告 GVA 与仍被支持的 key-based 路径。
  5. 同时记录 TTFT、吞吐、p50/p95/p99 queue/HOL/依赖等待、峰值 NPU/host 内存、in-flight task/metadata、lease/backend 队列深度,以及包含 attention 与 transfer 的 NPU 时间线。
  6. 根据证据比较 FIFO、dependency-aware ready queue、按 gate 分组等方案。只有观察到稳定 HOL 事件且候选方案的收益超过重复运行噪声时才进入实现;否则提交“不建议修改调度”的调查结论。

实现约束(仅在决定优化时适用)

  • 不能绕过 attention boundary;不能在 save CPU/NPU event 完成前复用共享 buffer。
  • 必须保留每层 load/save completion event、lease 生命周期、request_queue.task_done()、异常传播和 shutdown 语义。
  • 同一 buffer owner 链和同一请求内存在真实数据依赖的任务不得乱序;无依赖任务才可越过未就绪队头。
  • profiler/时间线关闭时不得在热路径保留高频字符串格式化、NPU 同步或无界内存记录。

验收标准

  • 给出可复现配置、原始时间线和阶段定义;任一总等待都能由拆分阶段解释,不混淆 host condition 与 NPU event synchronize。
  • 报告 HOL 事件数量、持续时间及“后续任务已 ready”的直接证据,而不是只报告队列长度。
  • 明确区分 layerwise_num_shared_buffers 的分配影响与 layerwise_prefetch_layers 的 in-flight 调度影响。
  • 若没有稳定优化机会:报告覆盖的负结果、原因和保留 FIFO 的建议,即完成本任务。
  • 若实施优化:增加纯 CPU/fake event 的确定性顺序与依赖单测、异常/shutdown 测试和 NPU 性能对比;至少 3 次独立重复运行,收益应超过运行噪声,且精度、TTFT 尾延迟、吞吐和峰值内存均无未解释回归。

交付件

  • profiler/时间线补丁、字段说明、复现脚本或命令和原始测量数据。
  • FIFO 与候选调度方案评估报告,包含采用/不采用结论。
  • 如实施优化,交付 PR、单测、NPU 正确性结果、改动前后性能数据和回退开关。

环境约定

  • vllm-ascend:最新 main
  • 硬件:Ascend NPU(注明型号 + 卡数 + TP/CP/PP 配置)
  • 关联任务池:#9079
  • 验收人:@赵鹏博

任务周期

  • 发布:2026-08-12
  • 回收:2026-10-31

Guida contributor