vllm-project/vllm-ascend

[Contribution] 任务 #6：[Perf] TP mismatch 路径重复查询

Offen

#14.147 geöffnet am 13.08.2026

Auf GitHub ansehenContributor Guide
 (2 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C++ (2.048 Forks)github user discovery
help wanted

Repository-Metriken

Stars
 (2.637 Sterne)
PR-Merge-Metriken
 (Durchschn. Merge 4T 5h) (559 gemergte PRs in 30 T)

Beschreibung

背景

写侧 TP mismatch 路径在 _store_kv_tp_mismatch 中先 lookup() 查已有缓存以过滤 missing keys，过滤后再对 missing keys 调用 put——但 put 内部会再次查询 store 是否已存在同一 key，导致同一批 keys 被 lookup 查询两次。读侧 _build_tp_mismatch_keys_and_addrs 用双重循环构建 keys/addrs，外层按 block、内层按并行维度，存在可合并的冗余遍历。仅 TP mismatch 场景触发。

相关代码：_store_kv_tp_mismatch（写侧先 lookup 再 put，put 内二次查询）、_build_tp_mismatch_keys_and_addrs（读侧双重循环）。

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

任务

消除 TP mismatch 路径的二次查询与冗余遍历。

  • 范围：仅 TP mismatch 场景的读 / 写路径
  • 目标：同一批 keys 在单次 save/load 流程内只查一次，读侧循环合并

验收标准

1. 功能正确性

  • TP mismatch 场景输出与改动前一致
  • 现有单测全绿

2. 性能验证

  • TP mismatch 场景下 lookup/put 调用次数下降
  • 端到端延迟对比

3. 交付件

  • PR + 设计说明 + 性能数据 + 单测

环境约定

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

重点关注

  • "直接覆盖"语义需确认各 backend（mooncake / memcache）行为一致

任务周期

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

Contributor Guide

Research-Richtung
Untersuchen Sie den Code in ` store kv tp mismatch` und ` build tp mismatch keys and addrs` im Modul `ascend store`. Verfolgen Sie den Aufruffluss, um die doppelte Abfrage innerhalb von `put` und die redundanten verschachtelten Schleifen zu bestätigen. Erkunden Sie, ob die Ergebnisse des ersten `lookup` an `put` übergeben werden können oder ob eine Option hinzugefügt werden kann, um die zweite Abfrage zu überspringen. Untersuchen Sie für den Lesepfad, wie die beiden Schleifen zu einer einzigen Iteration zusammengeführt werden können. Validieren Sie mit vorhandenen Tests und fügen Sie einen gezielten Unit Test hinzu.
Tech Stack
python
Domain
backenddistributed systems
Issue Type
Performance
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
GitPythonvLLM basics
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
60