Roger-Lv's space

上一篇《高性能网络包处理三板斧：XDP、DPDK 与 AF_XDP》讲的是「三条 kernel bypass 路径怎么选」。这篇落到代码：拿一个真实的 DPDK 开源示例项目 The-DPDK-Examples，把概念、封装层、收发包主循环、三个数据面示例、LRU 实现和哈希基准测试一次性拆透。 但在拆代码之前，得先把 DPDK 里那一堆名词讲清楚——否则代码里每一行都看不懂。所以本文前半部分用拓扑图把概念讲透，后半部分逐文件拆代码。如果你已经熟悉 DPDK，可以直接跳到第五节。 一、为什么需要「内核旁路」 先建立基准：标准 Linux 收一个网络包，要走的路是这样的： 123456789101112131415161718192021222324┌─────────────────────────────────────────────────────────────────┐│ 传统内核网络栈 ││ ...

剖析 infini-agent-framework 的双层中间件:原理、实现与自定义 引言 在构建一个 Agent 应用时,我们几乎一定会遇到这样的需求:在每次 LLM 调用前后打日志、压缩过长的对话历史、给工具调用加一层错误兜底、给 HTTP 请求注入上下文、采集 Prometheus 指标……这些需求有一个共同特征——它们不是业务本身,而是横切在业务调用链路上的通用能力。把它们硬塞进业务代码会让系统迅速腐化,于是"中间件(Middleware)"这种模式应运而生。 infini-agent-framework(以下简称框架)作为一个基于 LangGraph + FastAPI 的 Python Agent 框架,在中间件的设计上做了一个值得细看的选择:它没有另起炉灶造一套自研中间件类型,而是直接复用了 Starlette 与 LangChain 两套成熟的中间件抽象,并在此基础上做了组合与编排。这导致框架内存在两套独立、互不共享类型的中间件系统: 层级 基类来源 作用范围 文件位置 HTTP 中间件 Starlette BaseHTTPMid...

下一代 VPN 协议:WireGuard 完全指南 引言 在 VPN 技术领域,WireGuard 的出现堪称一场革命。当 Linus Torvalds 在 2018 年将 WireGuard 合并到 Linux 内核主线时,他给出了一个极高的评价——“艺术品”(a work of art)。这个仅有约 4000 行代码的极简协议,正在重新定义我们对 VPN 的认知。 什么是 WireGuard? WireGuard 是一个极简、高效且安全的 VPN 协议和实现。与传统的 OpenVPN(超过 10 万行代码)和 IPsec 相比,WireGuard 的设计哲学是简单到易于审计,从而从根本上减少潜在的安全漏洞。 它于 2020 年正式合并到 Linux 内核 5.6 版本中,此后迅速成为 Linux 系统上最受欢迎的 VPN 解决方案之一。 核心原理:Cryptokey Routing WireGuard 最核心的创新在于 Cryptokey Routing(加密密钥路由) 机制。简单来说,它将公钥与内网 IP 地址直接绑定,形成一个映射表。 当 WireGuard 接口收到...

记一次 Cilium VXLAN 全零 MAC 丢包问题的排查与修复 本文所有 IP、MAC、节点名、网卡名均为脱敏后的示意值，仅用于说明网络结构与排查思路，不代表真实生产环境。 背景 某次接到反馈：从公有云上访问某边缘 K8s 集群的推理服务不通。 网络架构上有两条专线（WireGuard 隧道）链路，分别接到集群内两个不同节点： 公有云 VM-1 → WireGuard 隧道-1 → 集群的 edge-gw 节点（一个不在 K8s 集群内的网关节点） ✅ 公有云 VM-2 → WireGuard 隧道-2 → 集群的 master 节点（K8s 控制面节点） ❌ 诡异的是：两条链路打到的后端其实是同一个推理服务 Pod，一条通、一条不通。这种"对称中又不对称"的现象，往往最耗时间——因为它会反复推翻你的假设。 整体拓扑 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626...

网络包迷踪:用 eBPF 工具 pwru 追踪 Linux 内核网络包 引言:当 tcpdump 不够用的时候 想象一下这个场景:你通过 tcpdump 确认数据包已经到达了网卡,但应用就是收不到;你怀疑是 iptables 规则或内核网络栈的某个环节把包丢了,却不知道具体丢在了哪里。Linux 内核网络栈的代码路径极其复杂,从网卡驱动、Netfilter 钩子、路由表、到 TCP/IP 协议栈,中间有数十上百个函数调用。传统工具很难精确定位问题出在哪个环节。 这时候,你就需要一个能"看见"数据包在内核中每一个足迹的工具——pwru。 pwru 是 Packet, Where Are You? 的缩写,顾名思义,它的使命就是帮你回答"我的网络包到底去哪儿了?"这个问题。 pwru 是什么? pwru 是一个基于 eBPF(Extended Berkeley Packet Filter)技术的 Linux 内核网络调试工具。它能够追踪网络包在 Linux 内核网络栈中的完整路径,并提供强大的过滤能力,让开发者和管理员能够精细地观察内核状态,从...

分布式训练核心技术:从 FSDP 到 All-Reduce 算法全景解析 引言 随着大语言模型(LLM)参数规模从亿级跃升至万亿级,单卡训练已成为历史。分布式训练技术成为每一位 AI 从业者的必修课。本文将带你系统性地梳理分布式训练的核心技术栈,从 FSDP 的显存优化,到 DDP 的完整链路,再到底层 Ring-AllReduce 与 ACCL 的算法对决,帮你建立完整的知识图谱。 一、FSDP:大模型训练的显存救星 1.1 什么是 FSDP? Fully Sharded Data Parallel (FSDP) 是 PyTorch 1.11 引入的分布式训练策略,其核心思想源于微软的 ZeRO(Zero Redundancy Optimizer)优化器。与传统 DDP 每个 GPU 保留完整模型副本不同,FSDP 将模型参数、梯度和优化器状态分片存储在所有 GPU 上。 1.2 核心适用场景 场景类型 推荐方案 说明 大模型训练(>500M 参数) FSDP 可降低 4-6 倍峰值显存占用 超大模型(>20B 参数) FSDP / DeepSp...

大模型训练的"三体问题":计算、通信与内存的深度协同 在大模型(LLM)预训练的万卡集群时代,算法架构(如 Transformer、MoE)的进步只是冰山一角。真正决定训练成本与效率的,是底层基础设施(AI Infra)的工程深度。当模型参数突破千亿,硬件算力(FLOPS)与显存带宽(HBM)、网络通信(NVLink/InfiniBand)之间的鸿沟日益扩大,性能瓶颈已从"算法创新"转向了"硬件榨取"。 本文将深入到单次训练迭代(Iteration)的微观尺度,从反向传播的数学本质出发,系统性地拆解计算墙(Kernel 优化)、通信墙(异步流水线)与内存墙(显存管理),并揭示顶级 AI Infra 团队如何通过精细的算子编写与调度策略,将 GPU 的有效算力(MFU)从 50% 拉升至 65% 以上。 一、 大模型训练的"三堵墙" 训练一个千亿参数的大模型,通常涉及数据并行(DP)、张量并行(TP)、流水线并行(PP)等多种并行策略的组合。在这个过程中,模型的前向与反向传播不再是简单的"计...

一个 MCP 沙箱路由调度框架的架构分析 本文分析一个用 Go 实现、面向 MCP(Model Context Protocol)的沙箱路由与调度框架。它把"给 agent 起一个隔离环境跑工具"这件事标准化、规模化、多引擎化。 一、它是什么 一句话:一个面向 MCP 的沙箱路由与调度框架,用 Go 写成,直接基于官方 modelcontextprotocol/go-sdk,把沙箱的创建、路由、调度、生命周期、计量都做成了一套基础设施。 它跟"控制面 Python + 数据面 Go、协议优先的通用沙箱平台"是两种不同路线:本框架全 Go、MCP 原生(直接用官方 SDK),更强调调度(快照+Epoch 的确定性调度)和路由(二层网络高可用网格)。它的"沙箱"抽象本质是一个 http.RoundTripper——工具调用就是 HTTP,没有单独的执行协议。 核心能力: 沙箱路由:按沙箱类型分发、MCP 会话生命周期管理、按下游负载动态调整、二层网络高可用。 沙箱引擎:Echo / FileServer / Git / P...

基于 containerd 与 Firecracker 的 MicroVM 容器技术实践 目录 引言与背景 技术架构全景 前置条件与环境搭建 核心组件深度剖析 工作流程与数据流详解 通信机制:vsock 技术内幕 总结与展望 1. 引言与背景 1.1 容器安全隔离的演进 传统的 Linux 容器(如 runc)依赖 Namespace 和 Cgroups 实现进程级隔离,共享宿主机内核。这种模型在追求轻量和高密度的同时,也带来了潜在的安全风险——恶意容器可能通过内核漏洞影响宿主机或其他容器。 MicroVM 技术的出现为容器安全提供了硬件级别的隔离方案。Firecracker 作为 AWS 开源的高性能 VMM(Virtual Machine Monitor),专为轻量级 MicroVM 设计,可在毫秒级启动时间下提供完整的硬件虚拟化隔离。 1.2 项目背景 firecracker-containerd 项目由 AWS 主导,旨在将 Firecracker 的强大隔离能力与 containerd 的成熟容器管理生态相结合,实现"像管理容器一样管理 MicroVM&...

OpenSandbox 项目学习 项目地址：https://github.com/opensandbox-group/OpenSandbox 官方文档：https://open-sandbox.ai 一、它是什么 一句话：OpenSandbox 是面向 AI 应用的通用沙箱平台（general-purpose sandbox platform），提供多语言 SDK、统一的沙箱协议，以及 Docker / Kubernetes 两套运行时，覆盖 Coding Agent、GUI Agent、Agent 评测、AI 代码执行、RL 训练等场景。 为什么需要它？如今 Agent（尤其 Coding Agent、代码解释器、浏览器自动化、RL 训练）需要在隔离环境里跑不可信代码、装第三方依赖、访问网络、长出进程，甚至要批量起几万实例。直接在宿主机上跑既不安全也不可规模化。OpenSandbox 把「隔离 + 可编程 + 可调度」这三件事标准化了： 隔离：容器级隔离，并可选 gVisor / Kata / Firecracker microVM 强化；网络出入站可策略化。 可编程：统一的...