PR body指出，Ray Actor由Ray的raylet生成，而非通过multiprocessing.spawn，因此SGLANG_NUMA_BIND_V2使用的numactl子进程包装路径（通过numa_utils中的configure_subprocess）从未应用于它们。在默认SGLANG_NUMA_BIND_V2=True时，调度器Actor完全未绑定，导致性能损失。
该PR值得精读，重点关注NUMA绑定在Ray Actor中的实现方式，以及如何复用现有工具函数确保与V1/V2路径的互补性。设计决策展示了在分布式环境中处理进程绑定的优雅方案。
Review中仅有一名审核者（Qiaolin-Yu）批准，无具体评论，表明变更被快速接受，可能因为逻辑清晰且基于现有NUMA工具。
python/sglang/srt/ray/scheduler_actor.py中，从sglang.srt.environ导入envs，从sglang.srt.managers.scheduler导入configure_scheduler_process（替换原configure_scheduler），并从sglang.srt.utils.numa_utils导入get_numa_node_if_available和numa_bind_to_node。SchedulerActor.__init__中，调用configure_scheduler_process后，检查envs.SGLANG_NUMA_BIND_V2.get()，若为True，则通过get_numa_node_if_available获取NUMA节点并调用numa_bind_to_node进行进程内绑定，确保在调度器构造前完成。configure_scheduler调用改为configure_scheduler_process，并传递actual_gpu_id参数。| 文件 | 模块 | 状态 | 重要度 |
|---|---|---|---|
python/sglang/srt/ray/scheduler_actor.py |
Ray 调度器 | modified | 6.83 |
python/sglang/srt/ray/scheduler_actor.py
core-logic
这是唯一修改的文件，实现了 Ray 调度器 Actor 的 NUMA 绑定逻辑，直接影响 Ray 部署下的性能。
from sglang.srt.environ import envs
from sglang.srt.managers.scheduler import Scheduler, configure_scheduler_process
from sglang.srt.utils.numa_utils import (
get_numa_node_if_available,
numa_bind_to_node,
)
# ... 在 configure_scheduler_process 调用后 ...
# Ray actors can't use the numactl subprocess-wrapping approach
# (SGLANG_NUMA_BIND_V2's normal path), so bind in-process via libnuma.
# The V1 path inside configure_scheduler_process already handles
# SGLANG_NUMA_BIND_V2=False.
if envs.SGLANG_NUMA_BIND_V2.get():
numa_node = get_numa_node_if_available(server_args, actual_gpu_id)
if numa_node is not None:
numa_bind_to_node(numa_node) # 执行进程内NUMA绑定
logger.info(
f"[TP{tp_rank}] Bound to NUMA node {numa_node} for GPU {actual_gpu_id}"
)
# 创建调度器，此时权重分配和NCCL初始化将在绑定的NUMA节点上执行
self.scheduler = Scheduler(...)
当前评论区没有形成足够清晰的争议点或结论，后续有更多讨论时会体现在这里。
风险较低：
影响范围：
当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。
PR body指出，Ray Actor由Ray的raylet生成，而非通过multiprocessing.spawn，因此SGLANG_NUMA_BIND_V2使用的numactl子进程包装路径（通过numa_utils中的configure_subprocess）从未应用于它们。在默认SGLANG_NUMA_BIND_V2=True时，调度器Actor完全未绑定，导致性能损失。
python/sglang/srt/ray/scheduler_actor.py中，从sglang.srt.environ导入envs，从sglang.srt.managers.scheduler导入configure_scheduler_process（替换原configure_scheduler），并从sglang.srt.utils.numa_utils导入get_numa_node_if_available和numa_bind_to_node。SchedulerActor.__init__中，调用configure_scheduler_process后，检查envs.SGLANG_NUMA_BIND_V2.get()，若为True，则通过get_numa_node_if_available获取NUMA节点并调用numa_bind_to_node进行进程内绑定，确保在调度器构造前完成。configure_scheduler调用改为configure_scheduler_process，并传递actual_gpu_id参数。关键文件：
python/sglang/srt/ray/scheduler_actor.py（模块 Ray调度器；类别 source；类型 core-logic；符号 SchedulerActor.init）: 这是唯一修改的文件，实现了Ray调度器Actor的NUMA绑定逻辑，直接影响Ray部署下的性能。关键符号：SchedulerActor.init, configure_scheduler_process, get_numa_node_if_available, numa_bind_to_node
python/sglang/srt/ray/scheduler_actor.py这是唯一修改的文件，实现了Ray调度器Actor的NUMA绑定逻辑，直接影响Ray部署下的性能。
from sglang.srt.environ import envs
from sglang.srt.managers.scheduler import Scheduler, configure_scheduler_process
from sglang.srt.utils.numa_utils import (
get_numa_node_if_available,
numa_bind_to_node,
)
# ... 在 configure_scheduler_process 调用后 ...
# Ray actors can't use the numactl subprocess-wrapping approach
# (SGLANG_NUMA_BIND_V2's normal path), so bind in-process via libnuma.
# The V1 path inside configure_scheduler_process already handles
# SGLANG_NUMA_BIND_V2=False.
if envs.SGLANG_NUMA_BIND_V2.get():
numa_node = get_numa_node_if_available(server_args, actual_gpu_id)
if numa_node is not None:
numa_bind_to_node(numa_node) # 执行进程内NUMA绑定
logger.info(
f"[TP{tp_rank}] Bound to NUMA node {numa_node} for GPU {actual_gpu_id}"
)
# 创建调度器，此时权重分配和NCCL初始化将在绑定的NUMA节点上执行
self.scheduler = Scheduler(...)
Review中仅有一名审核者（Qiaolin-Yu）批准，无具体评论，表明变更被快速接受，可能因为逻辑清晰且基于现有NUMA工具。
参与讨论