执行摘要

• 一句话：MRV2 索引映射微优化，省去类型转换开销
• 推荐动作：本 PR 改动极小，但有两个值得注意的设计点：用 __getitem__ 替代 get 规避无谓分支开销，以及用 np.intp 表达索引的指针语义。适合快速浏览而非精读；如果关注 MRV2 的输入准备路径，可以顺带查看 PR#50532 的更大改动。

功能与动机

PR body 明确说明优化动机：Use __getitem__ rather than get with np.fromiter(map(...)) (~6% faster)、Use np.intp for indexing types (avoids copy/type-conversion every time it's used)、Use torch.int64 for gpu tensor index mapping (same reason)。即降低 ModelRunner V2 每步 prepare_inputs 在构建 num_scheduled_tokens 与 idx_mapping 时的 Python/NumPy 开销，并让索引类型表达指针语义，灵感来自 PR#50532。

实现拆解

1. model_runner.py：映射构建微优化（prepare_inputs）：将 map(num_tokens_per_req.get, req_ids) 改为 map(num_tokens_per_req.__getitem__, req_ids)，避免 dict.get 每次调用引入默认值分支与函数调用开销（body 称约 6% 加速）；同时把 idx_mapping_np 的 dtype 从 np.int32 改为 np.intp，因为该数组只用于索引 req_states，用指针宽度的整数可以避免 NumPy 在后续数组索引与 PyTorch int64 交互时重复做类型转换/拷贝。该变化属于数据契约调整：下游消费 idx_mapping 时拿到的是 64 位索引张量（在 64 位平台上 np.intp 即 64 位）。

2. input_batch.py：dummy 批次索引类型对齐（make_dummy）：将 np.arange(num_reqs, dtype=np.intp) 与 torch.arange(num_reqs, dtype=torch.int64) 同步真实路径的索引宽度，保证占位批与真实批行为一致，避免测试路径出现 dtype 不一致。

3. pcp_manager.py：PCP 本地索引类型对齐（partition_batch）：将 local_to_global_batch_req_idx_np 的 dtype 从 np.int32 改为 np.intp，该数组用于对 global_batch.idx_mapping_np 做花式索引，可避免 NumPy 内部为 int32 索引数组做临时类型提升。

4. 测试与配置配套：无新增测试与配置变更；改动集中在 64 位索引语义一致性，回归风险主要靠 MRV2 的 e2e 测试兜底。

关键文件：

• vllm/v1/worker/gpu/model_runner.py（模块 模型运行器；类别 source；类型 data-contract；符号 prepare_inputs）: MRV2 每步输入准备的核心入口 prepare_inputs，本次将映射构建从 dict.get 切换为 getitem，并将 idx_mapping 的 NumPy dtype 从 int32 改为 np.intp，是数据契约变更点。
• vllm/v1/worker/gpu/input_batch.py（模块 输入批次；类别 source；类型 core-logic；符号 make_dummy）: make_dummy 生成占位批次时需要与真实路径保持相同索引宽度，从 np.int32/torch.int32 改为 np.intp/torch.int64，避免测试占位数据与真实行为失配。
• vllm/v1/worker/gpu/pcp_manager.py（模块 PCP 管理；类别 source；类型 core-logic；符号 partition_batch）: PCP 分批时 local_to_global_batch_req_idx_np 用 np.intp 做花式索引，避免 NumPy 为 int32 索引数组做隐式提升，保证与全局 idx_mapping 类型一致。

关键符号：prepare_inputs, make_dummy, partition_batch

关键源码片段

vllm/v1/worker/gpu/model_runner.py

MRV2 每步输入准备的核心入口 prepare_inputs，本次将映射构建从 dict.get 切换为 getitem，并将 idx_mapping 的 NumPy dtype 从 int32 改为 np.intp，是数据契约变更点。

# ModelRunnerV2.prepare_inputs 中映射构建的核心片段
req_ids = sort_batch_req_ids(num_tokens_per_req, self.decode_query_len)
​
# 用 __getitem__ 替代 dict.get：req_ids 中的 id 必然存在，省去 get 默认值分支
# 与额外函数调用开销，映射构建约快 6%。
numtoks_iter = map(num_tokens_per_req.__getitem__, req_ids)
num_scheduled_tokens = np.fromiter(numtoks_iter, dtype=np.int32, count=num_reqs)
​
# 请求索引映射改用 np.intp：它在 64 位平台即 64 位整数，表达“指针”语义，
# 避免 NumPy 在后续花式索引与 PyTorch int64 张量交互时反复做类型转换拷贝。
idx_mapping_iter = map(self.req_states.req_id_to_index.__getitem__, req_ids)
idx_mapping_np = np.fromiter(idx_mapping_iter, dtype=np.intp, count=num_reqs)
idx_mapping = async_copy_to_gpu(idx_mapping_np, device=self.device)

评论区精华

WoosukKwon 在 review 中提问 When is np.intp different from np.int64?，作者 njhill 回应 It's not really, just the semantic that we are using it as a pointer.。即两者数值等价，选择 np.intp 主要是语义表达——把它当作指针宽度整数使用。讨论简短、无分歧，WoosukKwon 随后批准合并。

• np.intp 与 np.int64 的区别 (question): 两者数值上等价，选择 np.intp 是语义表达：它表示指针宽度的整数，适合索引用途，避免在 NumPy 与 PyTorch 间反复转换。

风险与影响

• 风险：风险点集中在数据类型契约：1）np.intp 在 64 位平台是 64 位、在 32 位平台是 32 位，vLLM 实际运行环境几乎都是 64 位，但任何假设 idx_mapping 固定为 32 位的下游 kernel 或断言（如 cudagraph 相关索引拼接）都可能受影响；2）从 dict.get 改为 __getitem__ 在 req_id 缺失时会抛 KeyError 而非返回默认值，虽然 req_ids 来自调度器保证存在，但行为差异仍在；3）make_dummy 的 torch.arange(..., dtype=torch.int64) 只影响测试/占位批次，若测试期望 int32 可能触发断言。三个文件均无直接单测覆盖，回归主要靠 MRV2 e2e 测试兜底。
• 影响：影响范围限于 vllm/v1/worker/gpu 下的 ModelRunner V2 输入准备路径，每步推理都会执行这些映射构建，因此收益虽小但稳定；对用户完全透明，无 API/CLI 变化。对团队的实质影响是确立了索引相关的 dtype 约定（np.intp 表达指针语义），后续 MRV2 相关代码应保持同一契约。
• 风险标记：核心路径数据类型变更, 缺少测试覆盖

关联脉络

• PR #50931 [ModelRunner v2] Enable decoder token-wise pooling: 同属 ModelRunner V2（MRV2）功能线，都修改了 vllm/v1/worker/gpu/ 下的输入准备与张量映射逻辑，本 PR 的索引优化可视为该系列基础设施层面的打磨。