eBPF 加速 LLM 推理调度：从内核级可观测到动态 Batch 决策的全栈实践

引言：被忽视的推理调度黑盒

LLM 在线推理服务（vLLM、TGI、TensorRT-LLM）的 SLA 核心矛盾在于：GPU 算力利用率与长尾 TTFT（Time To First Token）之间存在天然的互斥关系。当你在 tracing 面板上看到 prefill 阶段的一个请求突然从 80ms 飙升到 800ms 时，APM 给出的答案往往是 "GPU busy"——但这无助于定位是 Kernel Launch Queue 排队、HBM 带宽饱和，还是 NCCL AllReduce 的环形阻塞。

传统可观测方案在这个场景下暴露了三个盲区：

1. GPU 内核排队深度不可见：nvidia-smi 只报告整体利用率，无法区分 "计算饱和" 和 "Kernel Launch 阻塞"
2. PCIe 与 NCCL 通信延迟无掩体：推理服务中 Prefill/Decode 分离架构对 RDMA RoCE 链路的 P99 延迟极度敏感，但传统工具只能从 netem 层面猜测
3. 用户态推理框架内部状态不透明：vLLM 的 Continuous Batching 队列深度、PagedAttention 的块分配失败率，对基础设施层而言是暗箱

eBPF 恰好能在不修改推理框架源码的前提下，以纳秒级精度为这条全栈链路提供端到端的可观测性，并进一步驱动调度决策。

第一层：全栈探针——零侵入的推理链路透视

一个完整的 LLM 推理请求跨越了以下层级：

[HTTP/gRPC Server] → [Tokenizer] → [Scheduler] → [Model Executor] → [GPU Kernel]
     ↑                                                             ↓
  entrypoint                                              cuLaunchKernel*()
     ↑                                                             ↓
  accept4()                                    [NCCL AllReduce via RDMA/RoCE]

eBPF 可以通过不同类型的探针逐层采集关键指标：

1.1 syscall 层：入口请求与 TTFT 测量

// bpf_program.c - 跟踪 accept4 + write 计算 TTFT
SEC("tracepoint/syscalls/sys_enter_accept4")
int trace_accept4(struct trace_event_raw_sys_enter *ctx) {
    u64 ts = bpf_ktime_get_ns();
    u32 pid = bpf_get_current_pid_tgid() >> 32;

    // 只追踪 inference-server 进程 (vLLM/TGI)
    char comm[16];
    bpf_get_current_comm(&comm, sizeof(comm));
    if (comm[0] != 'v' && comm[0] != 't') // vLLM / TGI
        return 0;

    u64 key = (u64)pid << 32 | PT_REGS_PARM1(ctx); // pid + client_fd
    bpf_map_update_elem(&accept_ts, &key, &ts, BPF_ANY);
    return 0;
}

SEC("tracepoint/syscalls/sys_exit_write")
int trace_write(struct trace_event_raw_sys_exit *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u64 key = (u64)pid << 32 | PT_REGS_PARM1(ctx);

    u64 *start = bpf_map_lookup_elem(&accept_ts, &key);
    if (!start) return 0;

    u64 delta_us = (bpf_ktime_get_ns() - *start) / 1000;
    // 通过 perf buffer 提交给用户态调度器
    struct ttft_event ev = {.pid = pid, .latency_us = delta_us};
    bpf_perf_event_output(ctx, &ttft_events, BPF_F_CURRENT_CPU, &ev, sizeof(ev));
    bpf_map_delete_elem(&accept_ts, &key);
    return 0;
}

这段代码的巧妙之处在于：它通过 pid + client_fd 的复合键精确匹配一个请求从 TCP accept 到首 token 返回的完整生命周期，避免了多线程环境下请求交叉导致的测量污染。

1.2 uprobe：vLLM Scheduler 内部状态曝光

vLLM 的 Scheduler 对象承载了推理调度的核心状态——waiting 队列、running 队列、swapped 序列。使用 uprobe 挂载到 Scheduler.schedule() 可以无侵入地采集：

// 通过 /proc/{pid}/maps 解析 libpython 中 vllm.engine.async_llm_engine 的符号偏移
// 实际部署中用 BCC 的 symbol resolution 自动化此过程

SEC("uretprobe/vllm_schedule")
int trace_schedule(struct pt_regs *ctx) {
    struct sched_snapshot snap = {};

    // 从寄存器/栈中读取 Scheduler 对象的内部字段
    u64 sched_obj = PT_REGS_PARM1(ctx); // this 指针
    bpf_probe_read_user(&snap.waiting_len, sizeof(u32),
                       (void *)(sched_obj + VLLM_SCHED_WAITING_OFFSET));
    bpf_probe_read_user(&snap.running_len, sizeof(u32),
                       (void *)(sched_obj + VLLM_SCHED_RUNNING_OFFSET));
    bpf_probe_read_user(&snap.num_free_blocks, sizeof(u64),
                       (void *)(sched_obj + VLLM_SCHED_FREE_BLOCKS_OFFSET));

    snap.ts = bpf_ktime_get_ns();
    bpf_perf_event_output(ctx, &sched_events, BPF_F_CURRENT_CPU, &snap, sizeof(snap));
    return 0;
}

注意：vLLM 的 C++ 扩展层（如 vllm._C）符号在 PyTorch 的 torch.library 自定义 op 注册表中会保留完整 symbol，这比直接 parse ELF 更稳定。实际部署时我会用 bpftrace -lv 'uprobe:/proc/{pid}/root/vllm/_C*.so:*' 一次性枚举所有候选挂载点。

1.3 kprobe：GPU Kernel Launch Queue 深度

当推理服务以 CUDA Graph Replay 或常规 cuLaunchKernel 模式运行时，GPU 端的 Kernel Launch Queue 深度直接决定了 P99 延迟：

// 追踪 NVIDIA 内核模块中的 ioctl(NV_ESC_QUEUE_IOCTL)
// 通过 nvidia.ko 的 krace 注入点获取提交队列深度
SEC("kprobe/nv_kchannel_ioctl_submit")
int trace_gpu_submit(struct pt_regs *ctx) {
    u32 submit_depth = PT_REGS_PARM3(ctx); // 第三个参数即 submit queue 当前深度
    u64 gpu_ts = bpf_ktime_get_ns();

    struct gpu_submit_event ev = {
        .submit_depth = submit_depth,
        .ts = gpu_ts,
    };
    bpf_perf_event_output(ctx, &gpu_submit_events, BPF_F_CURRENT_CPU, &ev, sizeof(ev));
    return 0;
}

通过这个指标，延迟尖峰的根因判定逻辑变得清晰：

第二层：调度决策——从指标到行动

有了可观测层提供的实时数据流，调度器可以做两件事：

2.1 Adaptive Max Batch Size

传统 vLLM 配置中 max_num_seqs 是静态值。基于 eBPF 输入的动态策略如下：

# scheduler_agent.py - 部署为 sidecar，通过 Unix socket 与 vLLM 通信
import bcc
import struct
import threading
import json

class EBPFSchedulerAgent:
    def __init__(self, pid):
        self.bpf = bcc.SRC_FILE
        self.pid = pid
        self.ttft_window = []  # sliding window for P99 estimation
        self.current_max_seqs = 32

    def handle_sched_snapshot(self, cpu, data, size):
        ev = self.bpf["sched_events"].event(data)
        # 综合判断逻辑
        memory_pressure = 1.0 - (ev.num_free_blocks / self.total_blocks)
        queue_saturation = ev.running_len / self.current_max_seqs

        if memory_pressure > 0.85:
            # KV Cache 即将耗尽：立即阻断新请求进入 running 队列
            self.send_control(vllm_ctrl_socket, {"action": "throttle", "value": 0})
        elif queue_saturation > 0.95 and ttft_p99 > 500:
            # GPU 过载且延迟恶化：降低并发
            self.current_max_seqs = max(8, self.current_max_seqs - 4)
            self.update_vllm_limit(self.current_max_seqs)
        elif queue_saturation < 0.5 and memory_pressure < 0.3:
            # 资源闲置：逐步放开并发
            self.current_max_seqs = min(64, self.current_max_seqs + 2)
            self.update_vllm_limit(self.current_max_seqs)

    def run(self):
        self.bpf["sched_events"].open_perf_buffer(self.handle_sched_snapshot, page_cnt=256)
        while True:
            self.bpf.perf_buffer_poll(timeout=50)

这个调度器的核心思想是将 GPU "算力利用率" 这个宏观指标拆解为三个正交维度——KV Cache 内存压力、排队饱和度、实测延迟——然后进行联合决策，避免了只看 GPU 利用率导致的 "利用率虚高但延迟爆炸" 问题。

2.2 Prefill/Decode 分离架构下的链路级 QoS

在 Disaggregated Prefill/Decode 架构（vLLM v0.6+ 版本主推）中，Prefill 节点将 KV Cache 通过 RDMA 传输到 Decode 节点。这个过程中 RoCE 链路的质量直接决定了 Decode 节点的输入等待时间：

// 追踪 mlx5 网卡驱动的 roce 数据包发送
SEC("kprobe/mlx5e_xmit")
int trace_roce_xmit(struct pt_regs *ctx) {
    // 识别 KV Cache 传输的大包（>1MB）
    u16 pkt_len = PT_REGS_PARM4(ctx);
    if (pkt_len < 1024 * 1024) return 0; // 小控制包不过滤

    struct kv_transfer_event ev = {
        .direction = 0, // TX
        .size = pkt_len,
        .ts = bpf_ktime_get_ns(),
    };
    bpf_perf_event_output(ctx, &kv_transfer_events, BPF_F_CURRENT_CPU, &ev, sizeof(ev));
    return 0;
}

eBPF 能够区分 "Prefill→Decode 的 KV Cache 传输" 和 "常规的 gRPC 请求流量"，为 RDMA 网卡的 DCQCN 拥塞控制参数调优提供精确的 per-flow 延迟分布——这在传统 RoCE 监控工具中几乎无法实现。

第三层：一个可运行的最小化的 Demo

下面给出一个可在任何 Linux 主机上运行的最小 eBPF + Python 推理调度原型。

环境要求

• Linux Kernel 5.8+（Ring Buffer 支持）
• BCC 工具链：apt install bpfcc-tools linux-headers-$(uname -r)
• Python 3.9+ 与 bcc 库

完整 Agent 代码

保存为 infer_agent.py：

#!/usr/bin/env python3
"""
EBPF-Powered LLM Inference Scheduler Agent
与 vLLM 实例在同一 host 上作为 sidecar 运行，通过 Unix socket 通信
"""
from bcc import BPF, USDT
import ctypes as ct
import time
import socket
import json
import os
import threading

# ========== eBPF 探针 ========== ============
bpf_text = """
#include <uapi/linux/ptrace.h>
#include <linux/sched.h>

struct ttft_event {
    u64 ts_us;
    u32 pid;
    u32 fd;
    u64 latency_us; // TTFT in microseconds
    char comm[TASK_COMM_LEN];
};

BPF_HASH(accept_map, u64, u64); // pid|fd -> accept_ts
BPF_PERF_OUTPUT(ttft_events);

// 追踪 accept4 入口
int trace_accept(struct pt_regs *ctx, int sockfd, struct sockaddr *addr, 
                 int *addrlen, int flags) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    char comm[TASK_COMM_LEN];
    bpf_get_current_comm(&comm, sizeof(comm));

    // 过滤非推理服务进程（按进程名前缀匹配）
    if (comm[0] == 'p' && comm[1] == 'y') {  // python (vLLM 通常为 python 进程)
        u64 key = ((u64)pid << 32) | (u32)sockfd;
        u64 ts = bpf_ktime_get_ns();
        accept_map.update(&key, &ts);
    }
    return 0;
}

// 追踪 write 出口 -> 首 token 写出
int trace_write(struct pt_regs *ctx, int fd, const void *buf, size_t count) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u64 key = ((u64)pid << 32) | (u32)fd;

    u64 *tsp = accept_map.lookup(&key);
    if (!tsp) return 0;

    u64 now = bpf_ktime_get_ns();
    u64 delta_us = (now - *tsp) / 1000;

    struct ttft_event ev = {};
    ev.ts_us = now / 1000;
    ev.pid = pid;
    ev.fd = fd;
    ev.latency_us = delta_us;
    bpf_get_current_comm(&ev.comm, sizeof(ev.comm));
    ttft_events.perf_submit(ctx, &ev, sizeof(ev));

    accept_map.delete(&key);
    return 0;
}

// 追踪 read -> 捕获请求体长度分布
BPF_HISTOGRAM(req_size_hist, u64);
int trace_read(struct pt_regs *ctx, int fd, void *buf, size_t count) {
    u64 log_size = bpf_log2l(count);
    req_size_hist.increment(log_size);
    return 0;
}
"""

class TtftEvent(ct.Structure):
    _fields_ = [
        ("ts_us", ct.c_ulonglong),
        ("pid", ct.c_uint),
        ("fd", ct.c_uint),
        ("latency_us", ct.c_ulonglong),
        ("comm", ct.c_char * 16),
    ]

class InferenceAgent:
    def __init__(self, target_pid=None):
        self.bpf = BPF(text=bpf_text)
        self.target_pid = target_pid
        self.ttft_window = []
        self.decision_lock = threading.Lock()

        # 挂载 kprobe/kretprobe
        self.bpf.attach_kprobe(event="sys_accept4", fn_name="trace_accept")
        self.bpf.attach_kretprobe(event="sys_write", fn_name="trace_write", retprobe=False)
        # 对于 glibc 的 write wrapper，也挂载 kretprobe 做 fallback
        try:
            self.bpf.attach_uprobe(name="c", sym="write", fn_name="trace_write")
        except Exception:
            pass

        # 打开 Ring Buffer
        self.bpf["ttft_events"].open_perf_buffer(self._handle_ttft, page_cnt=128)

        self.running = True

    def _handle_ttft(self, cpu, data, size):
        ev = ct.cast(data, ct.POINTER(TtftEvent)).contents
        self.ttft_window.append(ev.latency_us)
        # 只保留最近 1000 个样本
        if len(self.ttft_window) > 1000:
            self.ttft_window = self.ttft_window[-1000:]

        # 实时打印慢请求告警
        if ev.latency_us > 500_000:  # > 500ms
            print(f"[ALERT] Slow TTFT: {ev.latency_us/1000:.1f}ms on fd={ev.fd}, "
                  f"comm={ev.comm.decode('utf-8', 'replace')}")

    def get_p99_ttft(self):
        if not self.ttft_window:
            return 0
        sorted_t = sorted(self.ttft_window)
        idx = int(len(sorted_t) * 0.99)
        return sorted_t[idx]

    def make_scheduling_decision(self):
        """返回对 vLLM 调度器的建议调整"""
        p99 = self.get_p99_ttft()
        if p99 > 300_000:
            return {"action": "reduce_max_seqs", "delta": -4, "reason": f"P99 TTFT={p99/1000:.0f}ms"}
        elif p99 < 50_000 and len(self.ttft_window) > 100:
            return {"action": "increase_max_seqs", "delta": +2, "reason": f"P99 TTFT healthy={p99/1000:.0f}ms"}
        return {"action": "hold"}

    def dump_req_histogram(self):
        """打印请求体大小分布"""
        print("\n=== Request Size Distribution (log2 scale) ===")
        self.bpf["req_size_hist"].print_log2_hist("bytes")

    def poll_loop(self):
        print(f"[Agent] eBPF probes attached. Monitoring TTFT in real-time...")
        print(f"[Agent] P99 decision polling every 2s")
        while self.running:
            try:
                self.bpf.perf_buffer_poll(timeout=100)
                # 每 2s 做一次调度决策
                if int(time.time()) % 2 == 0:
                    decision = self.make_scheduling_decision()
                    if decision["action"] != "hold":
                        print(f"[DECISION] {decision}")
            except KeyboardInterrupt:
                self.running = False
        print("[Agent] Shutting down...")
        self.dump_req_histogram()

if __name__ == "__main__":
    import argparse
    parser = argparse.ArgumentParser()
    args = parser.parse_args()

    agent = InferenceAgent()
    agent.poll_loop()

运行方式

# 在 vLLM 所在 host 上以 root 权限运行
sudo python3 infer_agent.py

# 预期输出：
# [Agent] eBPF probes attached. Monitoring TTFT in real-time...
# [DECISION] {'action': 'reduce_max_seqs', 'delta': -4, 'reason': 'P99 TTFT=342ms'}
# [DECISION] {'action': 'increase_max_seqs', 'delta': 2, 'reason': 'P99 TTFT healthy=28ms'}
#
# === Request Size Distribution (log2 scale) ===
#      bytes    : count     distribution
#        2    : 0        |                                        |
# ...
#     512    : 1423     |****************************************|
#    1024    : 856      |************************                |
#    2048    : 234      |*******                                  |

实战效果与调优经验

在 7B/13B 模型 + A100-80GB 的生产环境中验证，引入 eBPF 驱动的动态调度后：

关键发现：

1. 不是越低越好：一味降低 max_num_seqs 会让 TTFT P99 好看但 GPU 利用率暴跌。动态策略的核心是"在延迟红线内最大化吞吐"
2. KV Cache 分配器的碎片化是隐形杀手：当 P99 突升但 GPU 利用率正常时，十有八九是 PagedAttention 的块分配出现了外部碎片，此时应该触发 block eviction 而非降低并发
3. GC 停顿不容忽视：Python 层 vLLM scheduler 在请求量大时会出现 GC 停顿（可达 50-100ms），这在 eBPF 视角表现为 accept→write 之间的 syscall 空窗期异常拉长，用 free_allocating 方式定点优化更有效

总结：观测驱动调度的范式转移

LLM 推理服务的调度优化正在从"人工经验调参"走向"观测驱动决策"。eBPF 在这一范式中的价值可概括为三点：

• 全栈打通：从 syscall accept 到 cuLaunchKernel 再到底层 RoCE 数据包，eBPF 是唯一能在单一名义栈上全部覆盖的技术
• 零侵入部署：不需要修改 vLLM/TGI/LL.M 源码，不需要 sidecar 注入 ISTIO envoy，不需要改 Kubernetes 容器镜像
• 毫秒级决策闭环：较传统 Prometheus→Grafana→人工干预的分钟级闭环，eBPF + 本地决策者可将响应时间压缩到 1-2 个调度周期

下一步值得探索的方向是将 eBPF 采集的 per-request 延迟特征作为输入，配合 PID 控制器或简单的 RL 策略网络做更精细的 KV Cache 预分配与 Prefill/Decode 流量调度。

本文完整 Demo 代码可在 https://github.com/yebinbing/ebpf-inference-ops 获取。eBPF 探针适用于 Kernel 5.8+ + glibc 2.31+ 环境。