Roger-Lv's space

从 LLM Infra 到具身智能 Infra:仿真集群、VLA 训练栈与数据管线全景解析 写给一位即将从大模型 Infra 转向具身智能 Infra 的工程师,也写给所有关注这个方向的人。 引言:一次心智模型的切换 过去三年做大模型 Infra 的人,心智模型基本是稳定的:海量文本 token 进、GPU 集群算、ckpt 出、推理服务化。但具身智能完全不同——它训练的不是"下一个 token",而是"机器人在物理世界里的下一步动作";它的数据不是从互联网爬来的,而是真机遥操作、仿真合成、人类视频多源混合出来的;它的基础设施不仅要支撑训练,还要支撑大规模并行仿真和真机数据回流这两个 LLM 时代从未存在过的环节。 如果你从 LLM Infra 背景切入这个领域,大约 60-70% 的工程经验可以直接平移,剩下 30-40% 需要新建心智模型。本文拆解其中三个最核心的新模块:仿真集群的算力形态、VLA 训练栈的真实结构、以及数据管线的工程全貌。 一、仿真集群:GPU 上的"平行世界" 1.1 它到底是什么 具身智能训...

为什么 VLA 训练选 FSDP 而不是 Megatron:四个约束同时成立 本文是 从 LLM Infra 到具身智能 Infra:仿真集群、VLA 训练栈与数据管线全景解析 的姊妹篇——那篇给出了"VLA 训练用 FSDP 而非 Megatron"的结论,这篇把背后的逻辑彻底拆透。 核心原因一句话:VLA 模型的参数规模(1B-34B)刚好落在 FSDP 的"甜点区",加上它基于 HuggingFace 生态的异构多模态结构让 Megatron 类框架难以适配,而科研社区主导的开源生态天然偏向 PyTorch 原生方案。下面把逻辑拆开讲。 一、先看 VLA 训练的真实规模和场景 VLA 训练的参数量和你熟悉的 LLM 预训练完全不是一个量级: 场景 参数规模 典型硬件 训练方式 VLA 预训练 7B(OpenVLA)/ 3B(π0) 64 张 A100 × 15 天 全量 VLA 微调(主流场景) 7B 单节点 8 张 A100 LoRA 或全量 VLA-RL 后训练 7B 单节点到多节点 FSDP 管理 ...

一次 create_sandbox 调用背后:Agent Sandbox 的控制面、数据面与句柄机制详解 当 LLM Agent 需要执行一段自己生成的代码时,它会向隔离沙箱平台发起一个请求:“给我一个沙箱”。这个请求背后发生了什么?沙箱是怎么被分配的?后续的命令又是如何找到正确的沙箱的? 这是 Agent 基础设施中最容易被一笔带过、却最值得拆解的一环。本文以 Kubernetes SIG 的 Agent Sandbox 项目(kubernetes-sigs/agent-sandbox)为样本,把一次完整的沙箱生命周期——从 create_sandbox 到 terminate——拆到协议层面。 核心结论先行:领养沙箱和操作沙箱走的是两条完全不同的通道。 create_sandbox 触发的是控制面流程(K8s API 上的 Claim/adopt,一次性的);后续 commands.run()、files.write() 走的是数据面流程(HTTP 请求经网关/Router 打到具体的沙箱 Pod,每次操作都走一遍)。而把这两条通道缝在一起的,是 SDK 返回的那个"...

DRA 拓扑感知调度:从 ResourceSlice 到 NUMA/PCIe 对齐 DRA(Dynamic Resource Allocation)已经原生支持拓扑感知调度,而且这是它的核心设计目标之一——通过 ResourceSlice 暴露设备拓扑信息,配合 ResourceClaim 中的约束(constraint)让调度器在 Pod 绑定前就完成 NUMA / PCIe 级别的拓扑对齐。本文从实现机制、版本演进、使用示例和当前局限几个维度展开说明。 本文是 深入解析 K8s GPU 复用:从通用方案到 HAMi 异构架构全解 的深入篇——那篇讲 HAMi 怎么用 DRA 做异构 GPU 分配,这篇专讲 DRA 本身的拓扑感知能力。 一、实现机制:拓扑如何参与调度决策 DRA 的拓扑感知能力建立在 KEP-4381(DRA Structured Parameters) 引入的结构化参数模型之上,核心链路分三层: 123456789101112131415161718192021222324 ┌─────────────────────────...

协议优先的沙箱执行框架:OpenSandbox 架构拆解 先给一句话定位:阿里 OpenSandbox 是一个"协议优先"的开源沙箱执行框架——它自己不做隔离(隔离委托给 Docker/Kata/gVisor/Firecracker),而是用一套 OpenAPI 规范统一了"沙箱生命周期"和"沙箱内执行"两层接口,用注入到每个容器里的 Go 守护进程完成有状态的代码执行,再用 Pool/BatchSandbox 两级 CRD 在 Kubernetes 上把批量创建做到了 O(1) 复杂度。 需要先澄清一个容易混淆的点:市面上叫"OpenSandbox"的有两个东西——开源项目 OpenSandbox(GitHub opensandbox-group/OpenSandbox,Apache 2.0,2026 年初发布,两天破 3800 星)和阿里云上的托管服务 Agent Sandbox(商业产品,MicroVM 隔离 + 每分钟 15K 沙箱弹性)。本文以前者为主线,后者在结尾对比。 关联阅读:本文讲...

从冯·诺依曼到 Agent 沙箱:虚拟化隔离技术栈的一次完整拆解 LLM Agent 正在把一个老问题重新推到台前:当代码由模型生成、且不可信时,你把它放在哪里执行? 容器的隔离撑不住对抗性负载;传统虚拟机又太重,扛不住每秒几十次的沙箱创建。于是一批沉寂多年的技术突然变得炙手可热——Firecracker、gVisor、Kata Containers、microVM。这些名词经常混在一起出现,但它们分处不同层次、解决不同问题。要真正理解它们的取舍,需要从最底层讲起:从冯·诺依曼架构的"核心与外围",一路讲到 Agent infra 的选型决策。 本文分四部分:先梳理虚拟化技术栈的分层关系,再深入 QEMU 的设备模型理解"外围设备"的本质,然后分析性能差异的根源,最后落到 Agent 沙箱的实战选型。 一、技术栈全景:谁在谁的上面 先用一句话给所有主角定位: KVM 是 Linux 内核提供的硬件虚拟化基础设施;QEMU 是基于 KVM 的传统全功能虚拟机监视器;Firecracker 是基于 KVM、专为 Serverless 设计的...

深入解析 K8s GPU 复用:从通用方案到 HAMi 异构架构全解 在云原生 AI 时代,GPU 作为算力核心资产,其高昂的成本与常常不到 40% 的实际利用率,让"显卡复用"成为企业降本增效的必答题。本文将全景解析当前主流的 GPU 复用方案,并深度剖析国产开源项目 HAMi 如何通过底层 Hook 技术与云原生调度,实现多厂商异构 GPU 的精细化隔离。 一、 GPU 复用全景:8 大主流方案对比 当前主流的显卡复用方案可按技术层次划分为五大类,不同路线在隔离强度、性能损耗、硬件门槛和部署复杂度上呈现明显的梯度差异:从硬到软,灵活性递增、隔离性递减。 方案 技术层次 隔离级别 性能损耗 硬件门槛 典型场景 MIG 硬件分区 物理硬隔离 几乎无 仅 A100/A30/H100 等 多租户推理、确定 QoS NVIDIA vGPU 驱动/Hypervisor 级 驱动级硬隔离 较低 VGX 系列卡 + IOMMU VDI、图形桌面云、虚机推理 SR-IOV PCIe 硬件虚拟化 硬件级 极低 Ampere 及以后数据中心卡 HPC/A...

深入理解 Go Channel:何时阻塞?何时引发 Panic? 本文将深入探讨 Go 语言中 Channel 的底层行为机制,梳理在不同状态下发送、接收和关闭操作的阻塞与 Panic 场景,帮助你彻底避开并发编程中的死锁与崩溃陷阱。 在 Go 语言的并发编程中,有一句名言:“不要通过共享内存来通信,而应通过通信来共享内存”。作为这一哲学的核心载体,Channel(通道)是我们日常开发中最常用的并发原语。 然而,Channel 的使用并非毫无门槛。如果不清楚它在不同状态下的行为,极易写出导致死锁或 Panic 崩溃的代码。今天,我们就来彻底盘清楚:Go 的 Channel 到底在什么时候阻塞?什么时候报错? 一、 什么是阻塞?什么是报错? 在开始前,我们需要明确两个概念: 阻塞:当前 Goroutine 被挂起,暂停执行,等待条件满足后继续运行。如果条件永远不满足,就会导致死锁。 报错:程序发生严重错误,触发 panic,如果未被 recover 捕获,整个程序会崩溃退出。 二、 Channel 在什么时候会阻塞? Channel 的阻塞主要发生在数据未准备好、缓冲区满或空、...

一个集群,多个调度器:Kubernetes 多调度器共存实践指南 “我们集群里已经有 kube-scheduler 了,还能再装一个 Volcano 吗?会不会打架?”——这是 AI Infra 团队在做调度器选型时最常被问到的第一个问题。答案是:可以,而且这正是 Kubernetes 的设计初衷之一。但"装上就能用"和"用对"之间,隔着一整篇本文要讲的内容。 一、为什么这个问题重要 大模型时代的集群里,工作负载的分裂前所未有:在线服务要打散、要低延迟;训练任务要 Gang 调度、要拓扑聚拢;推理服务要 SLO 感知、要弹性伸缩。没有任何一个调度器能同时把这些语义做到极致,于是"多调度器共存"从边缘玩法变成了生产标配——华为云 CCE 的"kube-scheduler 管在线 + Volcano 管训练"双轨架构就是典型代表。 Kubernetes 从设计之初就考虑了这个需求:每个 Pod 通过 schedulerName 字段指定由谁来调度,各调度器通过 watch API Server 只处理与...

Kafka 设计原理全览:从分布式日志到高可用 引言 Kafka 最初由 LinkedIn 开发,后捐给 Apache 基金会,如今已是流式数据事实标准。它能在一台普通服务器上跑到 10 万级消息/秒的吞吐,同时保证消息的持久化与高可用——这背后不是玄学,而是一套围绕"分布式日志"的精巧设计。 本文以"分布式日志"为内核,系统梳理 Kafka 的架构与核心原理,目标是读完一篇就建立完整的心智模型。参考了腾讯云开发者社区《Kafka 设计原理全览》及若干资料,综合整理。 一、Kafka 是什么:不止是消息队列 Kafka 是一个分布式流处理平台,有三重身份: 消息系统:生产者发消息、消费者收消息,提供解耦、削峰、异步、系统恢复等能力,还支持顺序保证和回溯消费。 存储系统:消息以日志形式持久化到磁盘,配合多副本实现高可靠的冗余存储。 流处理平台:提供完整的流处理类库(Kafka Streams),可在消息之上做转换、聚合、连接。 为什么用它做消息队列?核心价值:解耦(上下游不直接耦合)、削峰(峰值流量暂存管道、下游按自己速度消费)、可扩展...