Roger-Lv's space

从 LLM 到具身：注意力架构、VLA/世界模型与云 Infra 的全景调研 一句话导览：本文沿三条主线展开——(1) LLM 侧注意力与 MoE 架构的最新演进（MLA、FlashAttention-3、Ring/Ulysses、线性注意力、MoE）；(2) 具身侧 VLA 与世界模型的代表架构（RT-2、OpenVLA、π0.7、GR00T N1/N1.5、RDT-1B、Genie 3/4、DreamerV3、UniSim）；(3) 从训练 Infra（混合并行、RLHF 流水线）到推理 Infra（vLLM/SGLang）以及具身特有 Infra（遥操作数据飞轮、sim2real、边缘部署、3D/空间存储、RL rollout）的全链路挑战。文末给出面向未来 12 个月的技术选型判断。 一、LLM 侧注意力架构：从"算得快"到"装得下" 1.1 注意力机制演进的三条主线 Transformer 注意力架构在过去两年沿着三条相对独立的路线并行演进： 第一条是算子层优化——以 FlashAttention 系列为代表，核心问题是如何...

从 O(n²) 到 O(n)：线性注意力、稀疏注意力与混合注意力的技术演进 一句话结论：三种机制都是对标准 Transformer 中 O(n2)O(n^2)O(n2) 复杂度的 Softmax 全注意力瓶颈的改进方案——线性注意力通过核函数分解把复杂度降到 O(n)O(n)O(n)；稀疏注意力通过结构化掩码只计算部分 token 对的交互，复杂度降至 O(n)O(n)O(n) 或 O(nlog⁡n)O(n\log n)O(nlogn)；混合注意力则将不同注意力范式（或 Mamba/SSM）分层组合，在效率与精度之间取得平衡。 自 2017 年 Transformer 问世以来，注意力机制的核心公式几乎没有变过：每个 token 要与序列中所有其他 token 计算相似度，再加权聚合 value。这一设计赋予了模型强大的全局建模能力，但代价是计算量与序列长度的平方成正比。当上下文从 2K 扩展到 128K、再到 1M，O(n2)O(n^2)O(n2) 成为了绕不开的墙。过去五年，学术界与工业界从三个不同方向突破这堵墙，本文将逐一拆解其数学原理、典型实现与工程取舍。 一、问题...

Super-agent 设计探索：从架构理念到 dsh-superagent 原型实现 2026 年 10 月 31 日，DeepSeek Harness 团队发布了一篇架构文章《Super-agent 设计探索：迈向更自主的 Agent 系统》（英文标题 Exploring Super-agent Design: Towards a More Autonomous Agent System），同日以 MIT 协议开源了配套原型 dsh-superagent-prototype。 文章本身写得相当克制——开篇就声明「并非对 DeepSeek Harness 现有产品功能的介绍」，而是一篇面向工程实践的架构思路探讨；开源原型也反复强调「只是一种为了验证技术路线而提供的原型，并非 DeepSeek 的正式产品」，并且明确说明**「文中讨论的部分设计属于未来方向，本原型未实现」**。 但这两份材料放在一起读，价值反而更大。文章给出的是「为什么这么设计」的判断，原型给出的是「设计落到代码里长什么样」的答案。 很多在文章里只有一两句话带过的判断，在原型里对应着一整套数据结构、状态机和失败恢...

Kubernetes 控制器与调度器源码解剖：从控制循环到自研调度框架 Kubernetes 有两个"看起来不难、写起来全是坑"的地方：控制器的调谐循环，和调度器的插件框架。 前者难在并发——你面对的是一个最终一致的分布式缓存，写操作和缓存可见性之间有延迟，稍不留神就会重复创建 Pod；后者难在契约——十几个扩展点、几十个插件、三种队列状态，要理解"为什么这个 Pod 现在不能被调度"得同时看懂队列、缓存和抢占。 本文的读法是从基础设施往上层走：先看 client-go 那套事件流水线（Reflector → DeltaFIFO → Indexer → Workqueue），再用 Deployment 和 ReplicaSet 两个内置控制器把控制循环串起来；然后拆 kube-scheduler 的调度周期与框架契约；最后落到自研调度器 Sky-Scheduler——看它在 kube-scheduler 的框架之外，为什么选择了另一套 Session / Action / Statement 模型。 代码基线：Kubernetes v1....

containerd Snapshotter 接口深度解析：懒加载镜像方案的技术基石 在《容器镜像加速全景指南》中我们反复提到一个结论：Nydus / eStargz / SOCI 等懒加载方案之所以能在 containerd 生态落地，根本原因是 containerd 把"文件系统准备"抽象成了一个可插拔接口，并且这个接口的契约里留了一个"关键的后门"——它只要求返回有效的挂载配置，并不要求层数据已经下载到本地。 本文把这个抽象彻底拆开讲透。理解了它，你就理解了所有 remote snapshotter 方案的设计原理。 一、问题域：从 blob 到 rootfs 之间缺失的一环 先看 containerd 内部从 pull 到 run 的完整数据流： 1234567891011121314151617┌──────────────┐ pull ┌───────────────┐│ Registry │ ────────► │ Content Store │ ← 第一站：内容寻址 blob 存储│ (OCI 镜像)...

容器镜像加速全景指南：构建、缓存、懒加载与分发优化 容器启动慢，76% 的时间花在"拉镜像"上，而拉下来的数据平均只有 6.4% 会被真正读到。这组来自 AWS 的测量数据，揭示了容器启动优化最核心的矛盾：我们在为"用不到的数据"付出高昂的时间成本。 这篇文章从底层概念讲起，沿着"构建期瘦身 → 本地缓存复用 → 按需懒加载 → 网络分发加速"的完整链路，系统拆解容器快速启动与镜像快速拉取的所有主流方案。 第一部分：先补齐底层概念——镜像到底是个什么东西 要理解所有加速方案，必须先理解容器镜像的物理本质。这一部分是后面所有内容的地基。 1.1 容器 = Namespace + Cgroups + Rootfs Linux 容器本质上并不神秘，它是三个内核机制的组合： Namespace（如 mount、pid、net、uts）给进程一个"隔离的视野"——容器内看到的文件系统、进程列表、网络栈都是独立的； Cgroups 限制进程能用的 CPU、内存等资源额度； Rootfs（根文件系统）则是容...

mmap 能映射什么：一张全景图 引言 mmap 本质上是一种**"把任意字节序列对象映射进进程虚拟地址空间"的通用机制**——它的作用域取决于 fd 指向什么。 fd 可以是普通文件、tmpfs 文件、字符设备、GPU 节点、VFIO 组，甚至完全不要 fd（MAP_ANONYMOUS）。内核为每次 mmap 创建一个 vm_area_struct（VMA），并绑定对应的文件操作表 f_op->mmap。 所以真正决定"能不能映射、映射出来是什么"的，从来不是 mmap 这个系统调用本身，而是 fd 背后的 file_operations 实现。 123456789mmap(addr, len, prot, flags, fd, offset) │ ├─ 无 fd ──────────────► 匿名内存（零页 + COW） └─ 有 fd │ ├─ 通用路径 do_mmap() → 新建 VMA └─ f_op->mmap(fil...

Agent 沙盒基础设施实践：从 DSec 与 AgentENV 看调度层的选型与落地 引言 随着 Agentic RL 训练规模的爆发，如何为成千上万个并行 Agent 提供隔离、可复用、可快速调度的沙盒执行环境，已经成为基础设施团队绕不开的课题。 团队调度侧近期的工作重心正是这个方向——目标是对齐 DeepSeek 的 DSec 论文（arXiv:2609.22978）所描述的"调度层支持 FnCall、Container、VM 等多级运行时应对异构工作负载"的能力。目前我们的路径是：镜像分发加速在做，运行时已经落成了一套四模板形态（见 §3.12），网络和内核隔离在规划中。 平台的形态是：控制面统一编排云上 GPU 训练集群与边缘侧的机器人、传感器、摄像头，从 RL/LLM 训练一路打通到边缘部署。边缘侧通过 Kubernetes Device Plugin 把机械臂、摄像头暴露成可调度资源（资源名形如 rlinf.io/device-franka），让训练任务里的仿真环境和真机环境能用同一套声明式抽象描述。 "具身"这个定语给沙盒基...

具身智能训练存储与数据管线:JuiceFS + Lance 深度实践 具身智能的存储问题,难点不在"存得下",而在"读得随机、写得突发、流得动"——一段双臂叠衣 episode 里藏着 3 路 30Hz 相机视频、100Hz 关节状态、未来 50 步的 action chunk,训练时 DataLoader 要从数万条 episode 里随机抽 timestep 并把这几路异频流对齐成同一行。 招商局狮岩 AI Lab 的实测给出了量化答案:用 Lance 把长视频切成 GOP 尺度 blob 后,随机读吞吐相对 LeRobot 提升 1.7–6×、存储降低 42%;而地瓜机器人的集群数据则验证了另一端:JuiceFS 多云 + 分布式缓存把训练任务启动从 20 分钟压到 3 分钟、缓存命中率从 45% 提到 92%。本文把这两套栈拼成具身训练的完整存储底座。 一、具身训练的 I/O 画像:与 LLM/CV 根本不是一回事 先明确负载形态,后面所有选型推理都从这里出发。 具身数据的最小单元是 episode,不是 token,也不是单张图...

Queue Quota 深度解析:从 Volcano 三级模型到 MiniMax 级 AI 集群的调度治理实践 Queue Quota 的本质一句话就能说清:它是队列级别的资源记账单元,声明"这个队列能用多少资源、必须保多少资源、最多借多少资源、愿意借出多少资源"——区别于 namespace 级的 ResourceQuota,它的作用域是队列而不是命名空间,并且支持跨队列的借用与回收。 而 MiniMax 这类大模型公司的实际做法,是基于 Volcano 二次开发批调度器,把 Quota 建模从单纯的 CPU/内存扩展到 GPU 卡数、卡型、NVLink 域、IB 域、CPU 沙盒等多个维度,队列树直接对齐业务组织结构,配合夜间潮汐复用把 ETTR(有效训练时间比例)做到 97% 这个业界最高档位。 以下分两个层面展开:先把 Queue Quota 的理论语义讲透,再切到一线调度器研发的真实工作。 一、Queue Quota 的完整语义 1.1 为什么不能只用 ResourceQuota 原生 Kubernetes 的 ResourceQuota 工作在 ...