Roger-Lv's space

具身智能的数据地基:从传感器带宽到湖仓、清洗、评测与回流闭环 具身智能真正的瓶颈,早已不在模型架构——VLA、Diffusion Policy、世界模型这些路线正在快速收敛——而在于数据基础设施:怎么把物理世界的交互数据高效地采上来、存下来、洗出来、训得动,再让推理结果回流形成飞轮。 国地中心在建设人形机器人训练场时就把问题归结为四点:PB 级多模态数据存不下、真实采集成本高昂、视觉/触觉/力觉/位姿格式各异治理困难、跨域流转受限;中国信通院的测算更直接:若要支撑 55B 参数级具身基座模型,需要约 2.12 万台机器人以 8Hz 控制频率连续工作一年,才能产出千万小时级有效数据,而当前全球可用高质量真实数据仅数十万至百万小时级。 这意味着,那套我们熟悉的大数据技术栈——数据湖表格式、Hadoop/Spark 生态、OLAP 引擎、gRPC/MQTT/WebRTC 通信协议——在具身智能场景里不是"能用",而是刚需。本文尝试把这条链路完整拆开:从一台机器人的传感器带宽算起,到湖仓选型、清洗管线、OLAP 评测、推理回流的闭环架构。 关联阅读:本文是数据基础设...

从一维到多维:图解 Megatron 的 SP / CP / EP 与 Transformer 唯一通信处 本文从一个反直觉的观察出发:一个 Transformer 层里,99% 的计算模块根本不需要跨 GPU 通信,唯一的"全员大会"只有 Attention。理解了这一点,Megatron-LM 那套看似复杂的 6 维并行(TP / SP / PP / DP / CP / EP)就不再是黑魔法,而是一张围绕 Attention 设计的"交通调度图"。 关联阅读:本文讲训练并行维度的拆解;VLA 场景下为何选 FSDP 而非 Megatron 见 为什么 VLA 训练选 FSDP 而不是 Megatron。 一、先看清楚:Transformer 层里到底有什么 把一个标准 Transformer 层展开,数据流是这样的(Pre-LN 结构): 12345678910111213141516171819202122232425262728 层输入 x [batch, seq, d] │ ├─────...

从 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 的阻塞主要发生在数据未准备好、缓冲区满或空、...