《深入理解 AI Infra》把 DeepSeek 的 DSec 收进第 11 章——作者(bojie)开篇即用亲历对标:当年在微软用 FPGA 加速网络与 Bing 搜索、在华为用 UB 去掉抽象层开销,和今天 DSec 一样,都是"打破旧的抽象边界、实现极致性能";底层逻辑一句:传统操作系统与云要服务大量互不相关的程序,必须通用、必须有足够好的可编程性;而 AI Infra 的负载就是 LLM 与 Agent 用的沙箱,通信模式事先已知——可以协同设计。书仓:github.com/bojieli/ai-inf…
正文的干货是"Agent RL 与传统云计算的五条假设之差"(转述):①负载相关性——云上是大量相互独立的租户、靠统计复用削峰谷;RL 是一个作业一次申请 3.2 万个沙箱、需求高度相关。
②时间结构——云容器按自己节奏跑;沙箱约九成时间在等模型生成、CPU 平均只用 5%——优化目标不是 CPU 成本,而是不让 GPU 空等。③镜像分布——serverless 假设少数热门镜像被大量复用;RL 的镜像数量极大、复用极少。
④威胁模型——云安全防的是外部攻击者;RL 里运行在沙箱中的程序,本身就在被优化去寻找漏洞。⑤抢占感知——DSec 知道哪些 GPU 作业被抢占、可主动暂停对应沙箱,通用容器云做不到。
我的看法:五条对比其实是给 57904 那篇"RSI 地基"配的反向说明书——那边讲 DSec 做了什么,这边讲"为什么通用云做不到";五条里我最看重 ②与④:"九成时间在等生成、CPU 只用 5%"直接改写了成本的定义(省的不是机器小时,是别让 GPU 空等——与"同样聪明更少 token"是同一句话的硬件版);"沙箱里的程序被优化去找漏洞"则把 57835 靶场那句"agent 审计有盲区"反向成立为安全设计:跑的不是不可信代码,是"被激励攻击"的代码——威胁模型因此整个换了人。
而"通信模式事先已知→可协同设计"正是今晚反复出现的协同设计观(全栈自研 57992、四态统一 57904):知道负载形状,才能重新划抽象边界——bojie 三段履历(FPGA、UB、DSec)串起的其实是一条职业线:一辈子都在给"通用"还债、给"专用"开刃。
给读者一句:读 AI Infra 别先背架构图,先读"五条假设之差"——新栈的每个设计,都是对旧假设的逐条反驳。
五条对比、履历与书章安排均为原帖转述(DSec 数字沿 57904 已发口径),书内容以仓库为准。















