基于eBPF技术的LLM推理服务全栈可观测性：架构、挑战与实践

文档摘要： 本文系统性阐述了在云原生环境下，利用扩展伯克利包过滤器（eBPF）技术实现大语言模型（LLM）推理服务全栈可观测性的方法与架构。内容涵盖自建千亿参数LLM推理服务在异构硬件（如昇腾910B）与分布式框架（如vLLM, Ray）下面临的挑战，分析了传统可观测性三大支柱（指标、追踪、日志）及新兴性能剖析支柱的不足。文章重点介绍了DeepFlow平台如何通过eBPF实现零代码侵入的全栈指标采集、全链路追踪与混合栈（CPU/GPU）性能剖析，并辅以智能体应用与中国移动的落地案例，验证了该方案在优化GPU利用率、定位推理延迟及适配流式协议等方面的有效性。

关键词： eBPF；LLM推理；可观测性；分布式追踪；GPU性能剖析；DeepFlow；vLLM；云原生；

一、自建LLM推理服务的可观测性挑战

随着千亿参数级开源模型（如DeepSeek）的普及，企业自建大语言模型（LLM）推理服务的需求激增，无论是互联网公司、行业客户还是政企单位，都开始积极搭建自己的模型，这也带动了国产GPU的快速落地。热潮之下，问题也随之浮现。

以往搭建一套推理引擎或服务尚需一定的技术积累，而DeepSeek的出现加速了这一过程，同时也带来了两方面的问题。

1. 硬件异构性与调优复杂度：为应对高端GPU禁运，实践中常采用混合国产卡（如华为昇腾910B），其规格、性能与开发生态（如性能剖析工具链）差异显著。根据微软亚洲研究院（MSRA）对超700个GPU低效案例的分析（报告索引：MSRA-GPU-Eff-2024），低效主要原因包括：内核计算配置不当（>20%）、显存操作延迟（约25%）及文件I/O瓶颈（>10%）。在不同硬件上复用配置将导致严重的GPU利用率低下。
2. 分布式推理与智能体架构的复杂性：千亿参数模型需跨多机多卡进行分布式推理（例如基于ACK部署的DeepSeek-vLLM-Ray架构）。同时，服务日益接入复杂的AI智能体框架，后者需协调模型、工具与记忆系统，形成多层分布式系统，使得故障定界与性能分析极为困难。

在国内的实践中，这一挑战尤为突出。对于大型企业而言，采购时往往面临混合选用不同品牌、不同型号异构卡的复杂情况。如何进行选型、配比，以及后续的参数调优，都成了亟待解决的问题。

那么为何参数调优如此关键？根据微软亚洲研究院（MSRA）于2024年发布的《GPU Efficiency Analysis in LLM Inference》报告（参考编号 MSRA-2024-GPU-Eff）曾对七百多个GPU低效使用案例进行分析，发现低效情况大致可归纳为三类，各占约四分之一。

• 第一类问题：计算GPU内核

在测试集群中使用较小的batch size进行训练或推理，以适应测试环境；但到了生产集群，若未根据不同的硬件条件调整此参数，就可能导致GPU利用率低下——在A硬件上有效的配置，在B硬件上可能需要完全不同。这类因代码配置导致的问题，约占低效案例的20%以上。

• 第二类问题：显存操作

代码中将数据从主机内存复制到HBM显存，或在不同卡之间进行数据拷贝时，可能因未妥善处理阻塞操作而造成不必要的延迟。近期DeepSeek在开源周报中发布的性能剖析数据也致力于优化此类通信与计算的重叠执行，以尽可能提升GPU利用率。这同样是导致GPU低效运转的原因之一。

• 第三类问题：文件读写

在训练任务中，将检查点写入本地磁盘或分布式文件系统时，若I/O性能不足，会对整个训练进程造成瓶颈。

回到千亿参数模型的推理场景。如图（千亿参数LLM推理服务、AI智能体点复杂性）所示，左侧示意在千亿参数规模下，往往不得不采用分布式推理服务。以实现多节点、多卡上千亿参数模型的有效推理。

这还只是相对简单的分布式形态，仅涉及若干进程。右侧则展示了另一个日益常见的场景：推理服务需要接入当前热门的AI智能体体系。Chatbot只是一种简单形态，若考虑完整的AI智能体应用，它还需要与模型、工具以及记忆系统等进行交互。这实际上构成了一个相当复杂的分布式系统。

总的来说，以上所述正是当前推理服务面临的多重挑战。

二、LLM推理服务可观测性的核心支柱及传统方案的局限

谈到可观测性，大家通常都会提及经典的三大支柱：指标、追踪与日志。理论上，将这些数据收集齐全便足以支撑观测需求。

而OTel在2024年将性能剖析数据提升为至关重要的第四大支柱，集齐这些能力似乎就够了？实际上，LLM推理引擎或推理服务更贴近基础设施层，这与通用的分布式应用系统有所不同。当前许多实践也建议在 K8s 容器环境中搭建推理服务，这使得可观测性面临一些差异。

• 指标

例如在指标层面，vLLM与Ray等进程之间在推理时，Token是以流式方式输出的。观测“TTFT”（Time to First Token，首次输出Token的时间）或“TPOT”（Time Per Output Token，每次输出Token的时间）时，不能只关注单一节点，而需要审视全链路的每一个环节，比如K8s中每一张网卡的时迟消耗情况。

• 追踪

在追踪方面，对于K8s基础设施，我们除了要看到每个环节的时延，还需关注基础设施服务（如最基础的DNS，或数据库、向量数据库等）在整个调用链中的状态与性能。

• 性能

除了CPU剖析，更需要与GPU上下文结合；除了主内存的剖析，还需要具备高带宽内存（即显存）的剖析能力。这能帮助我们快速识别推理引擎运行时的OOM（Out of Memory）根源。事实上，在vLLM的GitHub Issue中，时常出现升级新版本或使用某型号卡时引发的显存OOM问题，这也是一个新的挑战。

依靠传统手段可以完美解决这些挑战和问题吗？实际上依靠传统手段无论任何方式，都会存在一定的局限。例如：

• 2.1 推理服务基础设施指标数据

指标通常分为基础设施指标和业务指标。基础设施指标主要指GPU卡的用量、功耗等，这需要由硬件主动暴露。但这里存在一个局限：如果GPU被虚拟化，每个虚拟卡的详细指标受限于硬件本身的暴露能力，很可能无法完整获取。

• 2.2 推理服务业务指标数据

业务指标如果依赖推理引擎自身提供，其完备性可能不足。当前开源的推理引擎众多，未必能为各种模型提供丰富的业务指标。一种常见的变通方案是通过网络网关进行观测。目前许多LLM网关都具备AI Gateway能力，可以在网关侧暴露业务指标。但无论哪种方法都会存在问题：若由业务自身暴露，则需要插入Prometheus SDK进行埋点；若仅在网关处暴露，则观测视角仅限于网关这一个点。

• 2.3 调用连追踪

由于推理服务及其前置的智能体或接入服务构成了一个复杂的分布式应用，构建链路追踪能力就显得非常关键。目前已有不少开源工具，例如基于OpenTelemetry的OpenTracing，以及OpenLIT等，它们支持的能力相近，主要通过Python或JavaScript/TypeScript的插桩库来实现分布式追踪。但现有方案也存在一些不足：其一，通常只能关注单个进程内部的耗时消耗，难以扩展到整个K8s链路上，呈现从基础设施到应用的全路径时延。其二，对多种编程语言的支持仍在逐步完善中。

• 2.4 性能剖析

如图（性能剖析：GPU Profiling、HBM Porfiling）所示，左侧是NVIDIA Nsight提供的性能剖析能力。这是一种较为底层的工具，主要面向系统工程师或GPU工程师进行性能调优，可以深入观察GPU内部处理单元或显存的利用率等情况。但对于上层应用的开发者而言，这类工具缺少CPU上下文信息，存在一定认知隔阂。

以往，推理或训练任务可能只由少数专业工程师负责，他们能够解读左侧的剖析数据。然而当下，越来越多的工程师需要参与推理服务的开发和运维，他们更熟悉且需要的是贴近CPU上下文、能够展示Python函数调用栈的剖析能力——这正是右侧PyTorch Profiler所提供的。且右下角展示的函数调用栈信息，对于在GPU之上进行应用开发的工程师来说更加直观友好。

然而在Python中获取此类调用栈信息，通常需要进行手工打造的精细插桩。例如在训练过程中，可能需要设置等待轮次、预热轮次、激活轮次等。由于性能开销较大，这种插桩需要精巧的设计：一般在测试阶段先运行一次以获取剖析数据，据此进行优化，而后在正式训练或推理前移除这部分代码。

综上所述，传统手段能覆盖指标、追踪、剖析和日志这四大支柱，但在两种场景下仍显不足：第一，随着更多应用工程师需要面对推理服务，工具需要变得更简单易用；第二，在云原生环境中只观测单点，在排查问题时可能忽略某些由基础设施，或者特定型号GPU卡导致的影响。

三、DeepFlow 基于eBPF的全栈可观测性解决方案

如图（为什么使用eBPF：零侵扰、全栈）所示，左侧示意图见于http://eBPF.io官网，其核心优势可概括为“零代码修改”与“全栈观测”。即无需改动应用代码或重启进程，即可获取可观测性数据；并且不仅能获得进程内部的数据，还能覆盖Linux内核乃至整个软件栈的观测信息。

右侧是eBPF在用户态同样具备强大的uprobe能力。尽管常有人说uprobe的开销会比内核态的kprobe更大，但这里有一个关键点：在计算密集型场景中，许多关键操作（如GPU内核函数调用，或基于InfiniBand等高速网络的通信调用）本身开销就已非常大。因其自身开销巨大，在其上附加uprobe所带来的额外资源消耗或时间代价往往微不足道。根据 DeepFlow 的实际测算，额外损耗仅在个位数百分比（例如1%到5%）之间。因此，在右侧所示的这类计算场景中，uprobe是完全可用的，其开销有时甚至低于许多传统插桩方式引入的性能损耗。

• 3.1 DeepFlow 全栈指标采集解决方案

以一个典型场景为例：假设一个Nginx Gateway将负载分发到后端的Serving Pod。如果出现TTFT或TPOT指标的异常波动，而我们无法确定问题是否出在模型服务侧，那么中间K8s基础设施层可能存在的问题点就非常多了。若需要定位一个每小时仅偶发一次的抖动，传统上可能需要在多处抓取tcpdump或分析Nginx访问日志，排查效率很低。

DeepFlow利用eBPF采集所有网络路径的流量与延迟。并对其时延进行计算，就能得到一张全栈路径的指标视图。以时延为例，从客户端进程、eBPF捕获的系统调用、客户端Pod的网卡、到K8s节点的网卡，如果节点还部署在KVM宿主机上，甚至可以延伸到宿主机节点的网卡，整条路径上每一段的时延消耗都能清晰地展现出来。这样就能直接判断问题是否源于基础设施层，避免了在云原生环境中搭建LLM服务平台时常见的定界不清问题。

• 3.2 DeepFlow 全栈全链路追踪解决方案

DeepFlow利用eBPF实现了一种创新性的AutoTracing能力，能够覆盖基础设施网关、K8s网卡、CoreDNS乃至数据库等全链路组件，并能较好地识别Python等非Java语言。特别地，为应对DeepSeek等模型为降低部署成本而采用的磁盘KV Cache创新，DeepFlow方案也能够将相关的文件I/O调用事件关联至追踪链路中，提供存储性能的可观测性。如图（Tracing：实用eBPF实现Disk/OSS KV Cache IO 的追踪）右下角则展示了如何在DeepFlow Agent中配置，使其在采集一次调用时，能关联采集到相应的IO事件。

• DeepFlow 全栈函数级性能剖析解决方案

eBPF 能同时捕获用户态（通过uprobe）与内核态事件，实现：

• Python与C++混合调用栈合并：将vLLM等引擎上层的Python函数调用与底层的C++/CUDA内核调用关联，形成完整的性能火焰图。
• 精准GPU耗时计算：通过分析CUDA内核启动与同步事件，结合CPU侧调用栈，准确计算异步GPU操作的真正耗时，而不仅仅是CPU等待时间。
• 显存（HBM）剖析：可视化显存申请与释放的热点函数，辅助定位内存溢出（OOM）根源。在计算密集型场景中，uprobe带来的性能损耗通常仅为1-5%，是可接受的。

四、DeepFlow 用户实践

• 案例一：DeepFlow智能体的自观测实践

DeepFlow内部部署了一个基于vLLM与Ray构建的AI智能体，用于自动化故障诊断与数据分析。通过eBPF能力，实现了：

• 对该智能体推理服务的GPU内核与显存操作进行无侵入剖析。
• 清晰展示混合编程栈下的性能热点，指导在不同型号硬件上进行参数调优，以适配最佳服务配置。

• 案例二：中国移动的业务指标采集

中国移动利用DeepFlow的WASM插件扩展能力，在不修改业务代码的情况下，成功采集了其私有推理协议下的全栈业务指标（包括TTFT、TPOT、令牌产出率等），并在微服务环境中实现了全链路指标汇聚与分析。

五、结论

基于eBPF的全栈可观测性方案，为复杂、异构的LLM推理服务提供了从应用到底层基础设施的统一观测视角。它克服了传统插桩方法的侵入性局限与观测死角，通过在网络、系统及应用运行时层的无缝关联，显著提升了性能诊断、资源优化与故障定位的效率，是云原生AI基础设施可观测性演进的关键技术路径。