LLM 训练推理优化体系
背景：训练和推理的效率挑战
LLM 训练和推理面临显著效率挑战：
- 训练效率：GPT-4 训练时长约 90-100 天，GPU 数量达数万，但利用率仅 32%-43%，年化故障率 6%-11%。代码层面低效主因包括计算效率、显存拷贝和网络传输问题。
- 推理开销：Llama 8B 模型推理需 1.48TB 显存，推理时延高，GPU 并非越多越好，需持续观测与优化。
- 在线推理服务：复杂分布式服务（如 LLM 应用、APIGW、AuthService 等）需端到端低时延和高稳定性，但排查显存消耗和分布式追踪难度大。
- 消费级 GPU 与 CPU 协同：需在大模型与小模型间实现 GPU 与 CPU 协同，提升效率。
现状：传统解决方案和工具的问题
传统解决方案存在局限：
- GPU 计算：Nvidia Nsight 需重启进程且缺少 CPU Context，PyTorch Profiler 仅支持 PyTorch 且性能影响大。
- RDMA 网络：网卡/交换机指标粒度粗，公有云 RDMA 网络性能黑盒。
- 在线推理服务可观测性：OpenLLMetry 和 OpenLIT 支持语言有限，需修改代码。
方法：eBPF 构建零侵扰可观测性
eBPF 技术优势：
- 全栈可观测性：支持 Socket、File、Perf、Function Call 等事件，实现零代码全栈剖析。
- 业界探索：华为和 Meta 已探索 eBPF 在 Tracing 和 GPU Profiling 中的应用。
- 技术挑战：需合并 Python/C/C++ 栈，实现全栈剖析；需实现 Network-Centric 分布式追踪。
实践：PyTorch 全栈剖析和追踪
DeepFlow 中的 eBPF AutoProfiling：
- Compute Profiling：实现 CPU 和 GPU 火焰图，全栈剖析 Python 业务、vLLM、PyTorch、C/C++ Lib 和 CUDA 函数耗时。
- HBM Profiling：剖析 CUDA 显存申请、实时用量和 Host<->Device 拷贝耗时。
- COMM Profiling：使用 eBPF Hook RDMA API，剖析 RoCEv2 Packet 的丢包率、时延和吞吐。
- Distributed Tracing：支持在线推理服务和端侧 ROS2 推理服务，具备内置和可编程协议识别能力，提取业务属性标签。
探索：Agent 自动优化 ML 代码
利用 LLM Agent 自动优化 ML 代码：
- 全栈函数理解：通过 LLM Agent 快速高效理解全栈函数。
- DeepFlow：实现零侵扰 AI 应用全栈可观测性，包括集合通信、网络性能监控、在线推理服务和分布式追踪，无需修改代码和重启进程。
