Roger-Lv's space

一句话结论：agentgateway 的对外说法是「一个进程统一 HTTP/gRPC、LLM、MCP、A2A」。但逐文件读完 v1.7.0 的实现后，我认为它真正值得学的有两点，都不在营销词里：一是它清楚自己不该做什么（推理端点选择委托给 EPP、语义缓存委托给 vSR），二是它把 Agent 的会话与身份当成一等公民（会话状态塞进自包含加密令牌、身份栈深到 SPIFFE 和 ID-JAG）。至于「AI 原生」，代码层面的含义比宣传语具体得多。 这篇文章基于对本地仓库（git describe = v1.7.0-71-g134897e1）的逐文件核对写成。凡是能验的我都验了，验不了的会明确标注来源。文末单列一节讲宣传与实现对不上的地方——这不是挑刺，而是因为一个正在快速迭代的项目，官方口径与实际行为的差距本身就是选型时要评估的风险项。 一、问题背景：传统网关为什么接不住 Agent 流量 传统 API 网关（Envoy、Kong、Nginx）的底层假设是短生命周期、无状态、一问一答。这套模型在微服务时代运转良好，但 Agent 流量有三个地方对不上： MCP 是有状态的长会...

一句话结论：这门课不教学生训大模型，教学生在大模型训练系统里做工程判断——用一个 4—8 卡的小集群，完整走一遍万卡规模下的工程决策链，并且每一步都要留下可复核的证据。 最近受老师邀请，给北大本科生排一门面向大模型 Infra 的课，方向偏训练。从零设计到成稿改了几轮，中间被问得最多的是「32 学时塞得下吗」「算力从哪来」这两个问题。这篇文章把整套设计摊开讲，包括 16 周结构、大作业形态、以及几个我认为值得复用的具体做法，希望能给准备开同类课的老师省点事。 一、定位：本科阶段教不了「训大模型」，但教得了「做工程判断」 第一个要回答的问题是：本科生不可能真的训一个千亿模型，那这门课到底教什么？ 我的答案是——教决策链，不教规模。一次大规模训练里真正难的从来不是「按下启动键」，而是一连串判断： 这个模型在这几张卡上，显存够不够？不够的话该切什么？ 切完之后通信代价是多少？瓶颈在计算、通信还是显存？ 换个框架、换个并行度，结论会不会变？ 训练挂了，怎么知道是数据、通信、存储还是代码的问题？ 这些判断的形状在小集群和万卡集群上是同一套，只是量级不同。所以课程把「规模」当作可控...

从 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），让训练任务里的仿真环境和真机环境能用同一套声明式抽象描述。 "具身"这个定语给沙盒基...