vllm-project/vllm-ascend

背景 MRV2 结构化输出（structured output / grammar）路径中，_apply_grammar_bitmask_kernel 将 grammar bitmask 应用到 logits 上，把被屏蔽位置置为 -inf。Ascend 侧实现位于 vllm_ascend/worker/v2/structured_outputs.py，经 patch/worker/patch_v2/patch_triton.py 替换 vllm-core GPU 版本。 当前实现注释明确指出：上游 GPU 版 BLOCK_SIZE=8192 在 Ascend NPU 上会溢出 UB（Unified Buffer），而缩小 BLOCK_SIZE 又使 grid 不稳定，故保留 BLOCK_SIZE=8192 并以 BLOCK_SIZE_SUB=1024 子分块循环处理。kernel 内已有 # TODO: Optimize the kernel performance with NPU profiling data.。 存在以下可优化点： for sub_offset in tl.range(0, BLOCK_SIZE, BLOCK_SIZE_SUB) 子分块循环是 UB 溢出绕过方案，可结合 NPU UB 容量重新设计分块； bitmask 解包（packed >> arange & 1）与 apply（置 -inf）可融合 / 向量化优化； grid 与 BLOCK_SIZE 选择需 profiling 标定。 任务 优化 _apply_grammar_bitmask_

背景 MRV2 采样路径中，bincount 构建 prompt 的二进制 bitmask（prompt_bin_mask，标记 prompt 中出现过的 token）与输出 token 计数（output_bin_counts），供 apply_penalties 使用。Ascend 侧实现位于 vllm_ascend/worker/v2/sample/penalties.py。 当前实现为 Triton kernel _bincount_kernel，grid (num_tokens, num_blocks)，BLOCK_SIZE=1024。kernel 通过 tl.atomic_or 写 bitmask（token_id // 32 为字索引，token_id % 32 为位），通过 tl.atomic_add 累加 output_bin_counts。两个原子操作在高并发下存在竞争。 存在以下可优化点： atomic_or（bitmask）与 atomic_add（counts）原子操作竞争； BLOCK_SIZE=1024 固定； 每个 token 独立遍历 prompt，重复扫描可合并。 任务 优化 bincount 在 Ascend NPU 上的性能。 路径：vllm_ascend/worker/v2/sample/penalties.py（_bincount_kernel / bincount） 方向：降低原子竞争（分块规约 / 私有副本合并）、BLOCK_SIZE 自适应、减少重复

背景 MRV2 采样路径中，apply_penalties 对 logits 施加 repetition / frequency / presence 惩罚。Ascend 侧实现位于 vllm_ascend/worker/v2/sample/penalties.py，经 patch/worker/patch_v2/patch_triton.py 替换 vllm-core GPU 版本。 当前实现为 Triton kernel _penalties_kernel，grid (num_tokens, num_blocks)，BLOCK_SIZE=4096 分块遍历词表。kernel 内对每个 token 有一段顺序循环 for prev_pos in tl.range(pos) 累加前序 draft token 的 bin count（O(pos) 每程序），再施加三类惩罚。受限于 "NPU 不支持链式 or" 做了 use_penalty = use_penalty or ... 拆分。 存在以下可优化点： for prev_pos in tl.range(pos) 顺序累加 draft token 计数，长序列 / 多 draft token 下串行开销大； BLOCK_SIZE=4096 固定； 早期返回（无惩罚）逻辑可进一步减少无效 launch。 任务 优化 apply_penalties 在 Ascend NPU 上的性能。 路径：vllm_ascend/worker/v2/sample/penalties.py（_penalties_kernel / apply_penal

背景 MRV2（Model Runner V2）采样路径中，compute_token_logprobs 负责对采样 token 计算 log-softmax 概率。Ascend 侧实现位于 vllm_ascend/worker/v2/sample/logprob.py，通过 vllm_ascend/patch/worker/patch_v2/patch_triton.py 替换 vllm-core 的 GPU 版本（vllm/v1/worker/gpu/sample/logprob.py）。 当前实现为 Triton kernel _topk_log_softmax_kernel：每个 request 启动一个 program，以固定 BLOCK_SIZE=12944 分块遍历整个词表，两趟计算（max + sum exp）得到 log-softmax，再 gather 指定 token_ids 的 logprob。配套的 compute_topk_logprobs 中 _ranks_kernel 计算 token rank（遍历词表统计 logits > 选中值的个数）。 存在以下可优化点： BLOCK_SIZE=12944 硬编码，对不同词表大小 / batch shape 非最优； log-softmax 两趟遍历词表，未使用 online softmax 融合； _ranks_kernel 用 int32 累加 (logits > x) 的逐块比较，长词表下开销大； multibuffer=False、grid (batch_size,) 未充分

背景 tests/ut/distributed/ascend_store/ 下已有 test_config_data.py / test_pool_worker.py / test_pool_scheduler.py / test_kv_transfer.py / test_coordinator.py 等，但对高风险路径的覆盖仍不均衡。异常路径、GVA 批量元数据、multi-group 失败恢复、异步 load/save 状态机仍需补强。 待补强路径与期望场景： KVCacheTransferThread.run 线程异常分支：线程内 I/O 异常是否被正确捕获、是否传播到主流程、是否被静默吞掉 _alloc_gvas_for_save / _prepare_load_gvas GVA 元数据批量：批量分配的部分失败回滚、group_block_hashes 边界（空 / 单 / 满） LookupKeyClient.lookup 及 ZMQ lookup server：server 无响应 / 连接断开 / 超长 payload 的编解码异常 layerwise _handle_request 同步等待与失败传播：gate.wait 超时、load 失败后 attention 是否被错误放行、失败标记是否一致 相关代码路径：vllm_ascend/distributed/kv_transfer/kv_pool/ascend_store。 任务 优