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 周结构、大作业形态、以及几个我认为值得复用的具体做法，希望能给准备开同类课的老师省点事。 一、定位：本科阶段教不了「训大模型」，但教得了「做工程判断」 第一个要回答的问题是：本科生不可能真的训一个千亿模型，那这门课到底教什么？ 我的答案是——教决策链，不教规模。一次大规模训练里真正难的从来不是「按下启动键」，而是一连串判断： 这个模型在这几张卡上，显存够不够？不够的话该切什么？ 切完之后通信代价是多少？瓶颈在计算、通信还是显存？ 换个框架、换个并行度，结论会不会变？ 训练挂了，怎么知道是数据、通信、存储还是代码的问题？ 这些判断的形状在小集群和万卡集群上是同一套，只是量级不同。所以课程把「规模」当作可控...

一句话结论：Volcano 的 backfill 常被误解成「防止任务被遗忘的兜底机制」。但即使完全去掉它，BestEffort 任务在下一个调度周期依然会被重新评估，不会永久滞留。它真正的价值是：在同一个 Session 内、用一条轻量无干扰的路径，把集群的碎片化空闲资源即刻消化掉，同时保护主调度流程不被拖慢。这是一次工程优化，不是正确性必需品。 本文沿「问题 → 设计 → 源码 → 对比」四条线索展开。所有源码结论基于 Volcano master 分支的 pkg/scheduler/actions/backfill/backfill.go（229 行）逐行核对，核对时间 2026-11-04。 一、背景：BestEffort 的「轻」既是优势也是困境 BestEffort 任务的定义很简单：不声明任何资源请求（CPU / Memory request 为空）。它单任务即可独立运行，不依赖其他任务协同就位，也不需要集群做任何复杂预留。 这种「轻」在调度器里却常常变成劣势： Volcano 的主流程（enqueue → allocate）优先处理的是声明了资源请求、需要...

一句话结论：控制面决定「能不能跑」，数据面决定「跑多快」。K8s 的功夫全在控制面——把 Pod 调度起来、把副本数维持住；而大模型训练真正的痛点，是 GPU 之间、机器之间的数据流动快不快、堵不堵。kubectl get pods 全绿但 MFU 上不去，是典型的控制面看不见的数据面问题。 本文基于 B 站视频《K8s 很熟，为什么月薪卡在三万？大模型 AI Infra 第一讲：从控制面走到数据面》的内容框架整理，其中的技术细节我对照 NVIDIA 官方文档（nvidia-smi 拓扑定义、NCCL 环境变量文档）与相关论文做了核实与补全。核对过程中发现原稿有四处需要更正的地方，已在文中标注。 一、为什么 K8s 玩得溜，月薪却卡在三万 很多云原生工程师 K8s 炉火纯青：写 YAML、调 Deployment、写 Operator、排 Pod 故障、扩缩集群，整套控制面技术一气呵成，但薪资天花板死死卡在三万上下。而那些看起来「只是会跑 nccl-tests」的 AI Infra 同事，年薪轻松翻倍。 差距不在于会不会写 YAML，而在于是否看懂了 K8s 之下的数据面。...

一句话结论：具身智能公司的仿真主力沙盒应当是「裸金属容器 + K8s GPU 调度」，而不是 DSec / AgentENV 那套 Firecracker microVM 层。只有轻量 Agent 工具调用和不可信代码执行才下沉到 microVM。这不是对多级运行时架构的否定，而是该框架在具身场景下的正确映射——仿真吃的是 NVIDIA 专有计算栈，而虚拟化层的 GPU 转发方案恰恰覆盖不到这里。 这篇是 Agent 沙盒基础设施实践：从 DSec 与 AgentENV 看调度层的选型与落地 的延伸。那篇里有一节（§3.5）讲具身仿真的 GPU 路线，结论是「虚拟化不是默认选项」；本文把那个结论展开成一份完整的选型依据——为什么 microVM 接不住仿真、虚拟化 GPU 的四条路径各自能到哪、以及三层负载该怎么分别匹配。 一、为什么这不是一个「通用沙盒」问题 讨论的对象是一类典型的具身智能公司：自研端到端具身大模型，部署轮式双臂仿人机器人与高自由度灵巧手，自建数据工厂沉淀了数万小时多模态具身数据集，机器人已规模化进入真实家庭。 这个形态决定了基础设施要同时承载三类性质完全...

从 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 镜像)...