vllm-project/vllm-ascend

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

Ouverte

#14 147 ouverte le 13 août 2026

Voir sur GitHubGuide contributeur
 (2 commentaires) (0 réaction) (0 personne assignée)C++ (2 048 forks)github user discovery
help wanted

Métriques du dépôt

Stars
 (2 637 étoiles)
Métriques de merge PR
 (Merge moyen 4j 5h) (559 PRs mergées en 30 j)

Description

背景

写侧 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

Guide contributeur

Direction de recherche
Examinez le code de ` store kv tp mismatch` et ` build tp mismatch keys and addrs` dans le module `ascend store`. Suivez le flux d'appels pour confirmer la double requête dans `put` et les boucles imbriquées redondantes. Explorez si les résultats du premier `lookup` peuvent être passés à `put` ou si une option peut sauter la deuxième requête. Pour le chemin de lecture, étudiez comment fusionner les deux boucles en une seule itération. Validez avec les tests existants et ajoutez un test unitaire ciblé.
Stack technique
python
Domaine
backenddistributed systems
Type d'issue
Performance
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GitPythonvLLM basics
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
60