Inference on Atomage's Blog

Split QKV + RMSNorm + RoPE 融合算子

Tue, 26 May 2026 09:50:58 +0800

源代码: vllm-ascend/vllm_ascend/ops/triton/linearnorm/split_qkv_rmsnorm_rope.py

背景#

问题：内存墙#

LLM 推理（尤其是 decode 阶段）是典型的 memory-bound 场景。每一次算子调用都是一次「从 Global Memory 搬数据到片上 → 计算 → 搬回 Global Memory」的循环。如果不融合，Split QKV → RMSNorm → RoPE 这三个步骤各自独立执行：

非融合流程:
  hidden_states ──[load]──> Split Q,K,V ──[store]──> q_in, k_in, v_in
  q_in ──[load]──> RMSNorm ──[store]──> q_normed
  k_in ──[load]──> RMSNorm ──[store]──> k_normed
  q_normed ──[load]──> RoPE ──[store]──> q_out
  k_normed ──[load]──> RoPE ──[store]──> k_out

每一次 load/store 都是一次 GM ↔ UB 的数据搬运。数据在总线上反复进出，但实际的计算量（几个乘加 + 一个开方）极小——这就是 memory-bandwidth bottleneck。

vLLM 分布式通信

Tue, 28 Apr 2026 11:03:49 +0800

class WorkerProc:
    """Wrapper that runs one Worker in a separate process."""

    READY_STR = "READY"
    rpc_broadcast_mq: MessageQueue | None
    worker_response_mq: MessageQueue | None
	@instrument(span_name="Worker init")
    def __init__(...):
	    self.rank = rank
        wrapper = WorkerWrapperBase(rpc_rank=local_rank, global_rank=rank)
        ...
        wrapper.init_worker(all_kwargs)
        self.worker = wrapper
        ...
        self.worker.init_device()
	    if envs.VLLM_ELASTIC_EP_SCALE_UP_LAUNCH:
            self.worker.elastic_ep_execute("load_model")
        else:
            self.worker.load_model()
        。。

Worker `init_device`#

worker的init_device函数负责初始化设备的相关信息

根据当前worker的rank找到它所属的device，将它绑到指定的卡上，以及清空该device的显存，获取该device的显存大小等
对当前的worker做分布式环境初始化，也就是初始化当前worker的各种进程组（如模型并行、流水线并行、数据并行等）
构造当前worker的GPUModelRunner对象。维护着模型权重分片，还维护模型运行过程中所需要的一些数据结构，比如kv cache等，负责模型权重的加载(load_model)，以及实际的推理执行过程等逻辑。

@instrument(span_name="Init device")
def init_device(self):
	if self.device_config.device_type == "cuda":
		...
		# Ray 会设置 NCCL_ASYNC_ERROR_HANDLING，但这个环境变量会导致 CUDA graph
		# 构建时出现异常。CUDA graph 需要同步执行，而该变量会引入异步错误处理，
		# 两者可能引起冲突。
		os.environ.pop("NCCL_ASYNC_ERROR_HANDLING", None)
		...
		# - Ray/external_launcher 场景：这些分布式执行器自己管理GPU映射
        # - 多节点场景(nnodes_within_dp > 1)：每个节点有独立的GPU集合，映射逻辑不同
        # - Ray作为DP后端：Ray的resource pool处理GPU分配
		if (
                parallel_config.distributed_executor_backend
                not in ("ray", "external_launcher")
                and parallel_config.data_parallel_backend != "ray"
                and parallel_config.nnodes_within_dp == 1 # 单节点场景
            ):
            # local DP rank 表示在当前节点内的数据并行编号，而 global rank 可能
            # 跨节点。在单节点场景下，GPU映射只看节点内的local rank。
            dp_local_rank = self.parallel_config.data_parallel_rank_local
            if dp_local_rank is None:
                dp_local_rank = self.parallel_config.data_parallel_index
            # DP副本 0 (dp_local_rank=0)
            # original_local_rank=0 → GPU 0 + 0×2 = GPU 0
            # original_local_rank=0 → GPU 0 + 1×2 = GPU 2 ← 偏移
            # 偏移是为了计算出实际的rank信息，后续用来初始化device
            self.local_rank += dp_local_rank * tp_pp_world_size
            。。
            
		self.device = torch.device(f"cuda:{self.local_rank}")
		# PyTorch的设备API演进：从 torch.cuda.set_device() 到
        # torch.accelerator.set_device_index()。 后续可以不用再手动指定，
		torch.accelerator.set_device_index(self.device)
		...
		# 初始化分布式推理所需的所有环境，包括通信组信息
		# 优先于内存快照处理逻辑，NCCL在初始化会分配内部缓存区，提前初始化用于保证显存计算的准确性
		init_worker_distributed_environment(
			self.vllm_config,
			self.rank,
			self.distributed_init_method,
			self.local_rank,
			current_platform.dist_backend,
		)
		# 1. gc.collect() 回收Python层的垃圾对象，释放可能的GPU引用
        # 2. empty_cache() 释放PyTorch缓存的显存（包括NCCL缓冲区）
        # 得到一个"干净"的显存状态，作为基准线
        gc.collect()
        torch.accelerator.empty_cache()
        # 用于后续计算 KV cache 可用显存。
        # init_snapshot 记录当前可用显存，request_memory 根据模型配置
        # 计算需要预留的 KV cache 大小。
        self.init_snapshot = init_snapshot = MemorySnapshot(device=self.device)
        self.requested_memory = request_memory(init_snapshot, self.cache_config)
    
	# 最后初始化modelrunner，需要依赖设备、分布式通信环境，同时通过快照可以计算出可以分配的kv cache显存大小
	if self.use_v2_model_runner:
		...
		self.model_runner: GPUModelRunner = GPUModelRunnerV2(  # type: ignore
			self.vllm_config, self.device
		)
	else:
		...
		self.model_runner = GPUModelRunnerV1(self.vllm_config, self.device)
	...

`init_worker_distributed_environment`#

负责初始化分布式推理所需的所有环境组件

TorchInductor Pattern Matcher

Mon, 27 Apr 2026 21:37:50 +0800

PyTorch FX 图#

PyTorch FX 是用于捕获、分析和转换 PyTorch 计算图。FX 图是一种静态表示，它记录了 PyTorch 代码的执行流程。用户通过将模型表示为FX图，可以更轻松地进行各种转换，例如图优化，量化，算子融合等。

FX 图的核心组件包括：

torch.fx.Graph：计算图的容器
torch.fx.Node：图中的节点，表示计算操作，如函数调用、方法调用等
torch.fx.GraphModule：由图构建的可执行模块

graph TD
    subgraph FX_Graph
        A["Placeholder Node"] --> B["CallFunction Node"]
        B --> C["CallMethod Node"]
        C --> D["Output Node"]
        E["Module Node"] --> B
    end
    subgraph Components
        F["torch.fx.Graph"] --> FX_Graph
        G["torch.fx.Node"] --> A
        G --> B
        G --> C
        G --> D
        H["torch.fx.GraphModule"] --> F
    end
    style FX_Graph stroke:#333,stroke-width:2px
    style Components stroke:#333,stroke-width:2px

FX Symbolic Tracing#

FX 图的生成过程称为"符号追踪"（Symbolic Tracing），主要步骤包括：

追踪：使用 torch.fx.symbolic_trace() 对 PyTorch 函数或模块进行追踪
捕获：捕获函数执行过程中的所有操作，构建计算图
表示：将计算图表示为 Graph 对象，其中包含一系列 Node 对象
转换：对捕获的图进行分析和转换
执行：将转换后的图包装为 GraphModule，可像普通 PyTorch 模块一样执行

import torch


# Simple module for demonstration
class MyModule(torch.nn.Module):
    def __init__(self) -> None:
        super().__init__()
        self.param = torch.nn.Parameter(torch.rand(3, 4))
        self.linear = torch.nn.Linear(4, 5)

    def forward(self, x):
        return self.linear(x + self.param).clamp(min=0.0, max=1.0)


module = MyModule()

from torch.fx import symbolic_trace

# Symbolic tracing frontend - captures the semantics of the module
symbolic_traced: torch.fx.GraphModule = symbolic_trace(module)

# High-level intermediate representation (IR) - Graph representation
# 由一个列表组成 代表函数输入、调用点（函数、方法、 或 torch.nn.Module 实例），以及返回值。
print(symbolic_traced.graph)
"""
graph():
    %x : [num_users=1] = placeholder[target=x]
    %param : [num_users=1] = get_attr[target=param]
    %add : [num_users=1] = call_function[target=operator.add](args = (%x, %param), kwargs = {})
    %linear : [num_users=1] = call_module[target=linear](args = (%add,), kwargs = {})
    %clamp : [num_users=1] = call_method[target=clamp](args = (%linear,), kwargs = {min: 0.0, max: 1.0})
    return clamp
"""

# Code generation - valid Python code
# 使 FX 成为 Python 到 Python（或 模块到模块）转换工具包。对于每个 Graph IR，我们可以 创建与图语义匹配的有效 Python 代码。
print(symbolic_traced.code)
"""
def forward(self, x):
    param = self.param
    add = x + param;  x = param = None
    linear = self.linear(add);  add = None
    clamp = linear.clamp(min = 0.0, max = 1.0);  linear = None
    return clamp
"""

FX 图的特点

vllm DP (Data Parallel)

Sun, 28 Dec 2025 21:15:37 +0800

DP基本概念#

DP在推理场景下的核心思想，在多个 GPU/节点上完整复制同一个模型权重，每个副本独立处理不同的请求或批次，从而近似线性提升吞吐。与训练中的 DP 需要梯度聚合不同，推理 DP 没有参数同步，通信负担主要来自调度、路由、指标与可选的缓存协同。

具体来说

每个 GPU/设备都拥有模型的完整副本
输入数据被分割成多个批次，通过负载均衡分配给不同设备
各设备独立进行前向推理
每个设备产生各自批次的输出结果

在DP部署方式下由于单卡的计算效率基本保持不变，因此吞吐提升近似是线性：理论上2 张卡就是 2 倍吞吐，4 张卡就是 4 倍，以此类推。

在大规模部署DP的时候，由于整体可支持的吞吐翻倍，API服务器需要面临成倍的压力，因此API服务器（Tokenize等预处理）可能会成为系统瓶颈。vllm可以使用--api-server-count命令行选项来扩展，最终暴露给用户的是一个Endpoint，在内部实现API服务器的扩展。

vllm 异步调度解析

Tue, 09 Dec 2025 11:51:25 +0800

在vllm初始版本中只有一个同步调度策略，在该策略下GPU资源会在调度过程中形成空泡，造成GPU资源的浪费。vllm在v0.10.0版本后提供异步调度策略，并且在后续的迭代中不断加入对于其他特性（例如异步场景下的投机解码）的支持。原始PR内容可查看#19970 Implement Async Scheduling ，当前代码分析基于main branch(735284ed)。

EngineCore处理处理Step逻辑：

def _process_engine_step(self) -> bool:
    """Called only when there are unfinished local requests."""

    # Step the engine core.
    outputs, model_executed = self.step_fn()
    # Put EngineCoreOutputs into the output queue.
    for output in outputs.items() if outputs else ():
        self.output_queue.put_nowait(output)
    # Post-step hook.
    self.post_step(model_executed)

    return model_executed

同步调度策略#

def step(self) -> tuple[dict[int, EngineCoreOutputs], bool]:
  if not self.scheduler.has_requests():
      return {}, False
  
  scheduler_output = self.scheduler.schedule()
  # 通过FutureWrapper进行异步包装（复用异步调度的部分逻辑， 在同步调度逻辑里面会等待结果返回）
  # 
  future = self.model_executor.execute_model(scheduler_output, non_block=True)
  # 用于支持结构化输出等
  grammar_output = self.scheduler.get_grammar_bitmask(scheduler_output)
  with self.log_error_detail(scheduler_output):
	  # 同步
      model_output = future.result()
      if model_output is None:
          model_output = self.model_executor.sample_tokens(grammar_output)

  # 处理整个过程中abort的请求
  self._process_aborts_queue()
  engine_core_outputs = self.scheduler.update_from_output(
      scheduler_output, model_output
  )
  return engine_core_outputs, scheduler_output.total_num_scheduled_tokens > 0

同步调度步骤：