摘要

NVIDIA的Dynamo论点是：Agent inference必须作为数据中心级系统优化，而不是一组彼此独立的模型副本。 Dynamo位于vLLM、SGLang和TensorRT-LLM之上，统筹感知KV cache的扩缩容、prefill与decode解耦，以及横向扩展调度。收益来自多台机器之间的规模经济。
核心约束是质量、成本和延迟构成的三方前沿，优化单位是完整的Agent工作流，而不只是模型本身。 更多推理、重试、工具调用和多轮上下文可以提升质量，但也会消耗更多token、拉长延迟。因此，运营方会先确定所需模型和SLA，再测试并行度与部署配置，找到“满足全部约束的最低成本版本”。
将prefill与decode分离，既能立即提升效率，也为专用硬件铺路。 对足够长的序列而言，prefill通常受算力约束；decode通常受内存带宽约束，二者混合时，长prefill步骤可能阻塞token生成。Dynamo将二者放入可独立扩缩容的资源池；从DGX Spark与Mac协同实验，到已经公布的Rubin CPX，都显示出推理集群日益异构化的趋势。
模型架构正变得与推理硬件和预期上下文不可分割。 Kimi K2的设计者减少attention heads、增加更稀疏的experts，在保持激活expert数量不变的同时降低attention计算量。讨论将其概括为硬件—模型—上下文—代码协同设计。DeepSeek的MLA被引用为例：它将约128,000-token上下文压缩到约8 GB，而同精度下、规模相近的Llama 405B上下文估计需要40–80 GB。
Agents把一次模型调用变成由模型、缓存、工具和子Agent组成的结构化系统。 “system as model”可能在一次API响应背后隐藏许多专用模型。一位参与者预计，到年底前会出现能够连贯运行超过24小时的Agent，但当前讨论中的生产环境自主运行时间更接近20–45分钟；另一位参与者预计，效率会先改善，运行时间才会进一步无差别拉长。
提出的安全规则非常直接：通常只能让Agent获得文件访问、互联网访问和任意代码执行三项能力中的两项。 NVIDIA内部团队正努力让更多员工试用Codex、Claude Code和OpenClaw，同时保留明确的执行控制点；Brev的隔离云VM则是在企业网络之外运行高风险Agent的一种方案。
Brev正成为NVIDIA面向开发者的桥梁，把本地硬件连接到云GPU和一键式软件部署。 它最初的洞察是：页面上最醒目的应该是“A100”，而不是把它埋在云实例代码里；Launchables把同一逻辑延伸到了软件部署。DGX Spark已可在早期体验中注册到Brev，并从笔记本电脑远程使用，“就像任何其他云节点一样”，把家用设备变成“一座小型数据中心”。
NVIDIA的执行文化，将“光速”式截止日期与对初期可能价值为零的市场进行长期投资结合起来。 “SOL”要求先找出物理意义上的下限，再把组织约束逐层加回来；但稳定性和安全性仍是实际输入，而不是“先把一切做出来，坏了再说”的借口。在规模化场景中，硬件经济性可能极其惊人：讨论称，在一条比较曲线的大部分区间里，GB200 NVL72的单token服务成本约为Hopper的1/35。

精读

1. Brev把GPU供给变成了开发者产品

Nader Khalil最初对Brev的设想非常克制：接入多个GPU来源，把开发者能够SSH进入其中一台机器所需的时间压到最低。云平台控制台把用户请求的“A100”埋在晦涩的实例代码和多页表单里；Brev则让GPU类型成为页面上最醒目的对象。
就连动态GPU卡片也体现了这套产品理念。Nader在Figma中设计卡片，再通过修改React里的SVG样式手工实现动画效果——这项“工匠式”工作最初让身为小股东的swyx有所质疑，但他后来认为，这正体现了Brev贯穿始终的细致。
那个令人难忘的GTC展台，同样把这一思路用于传播。由于最后一个展位位于遥远角落，Brev搭起足够高的冲浪板和棕榈树，让它们高过邻近展台的墙；这个展位因此脱颖而出，也被NVIDIA团队记住。
Launchables把供给能力延伸为GPU软件的一键部署。NVIDIA收购Brev后，Nader表示，决定性契合在于“产品的灵魂是一致的”：Brev获得了更多资源，却没有放弃让GPU访问更简单的目标；brev.nvidia.com也变成主持人所称的“GPU首页”。

2. DGX Spark暴露出GPU性能与可用性之间日益扩大的鸿沟

新用户群包括可能从未使用过GPU的OpenClaw开发者。Nader更大的判断是，AI正在创造“一个技术素养更高的社会”；但用户扩张也迫使NVIDIA建立多层新的开发者体验。
他第一次参加DGX Spark相关会议时，很快明确了问题所在。有人提出的首个用途是购买两台设备、组建Kubernetes集群；Nader回应说，真正的第一步应该是让SSH连接毫不费力，因为Kubernetes用户“更有忍受痛苦的倾向”，而只想运行Agent的用户并非如此。
NVIDIA Sync封装了SSH连接；Brev的早期体验集成则允许用户注册一台Spark，把它留在家中，再像访问任何其他Brev节点一样，从咖啡馆远程接入。家庭系统由此变成一座“预配置数据中心”，Brev通过同一个界面连接本地与云端算力。

3. “光速”把交付日期压缩到物理极限

Nader最喜欢的NVIDIA运营经验是“SOL”：在接受三周预估之前，先问清楚究竟有什么物理因素让三周变得不可避免。“光速以某个速度运行，所以如果某件事比它更慢，你就知道中间有东西挡住了。”
他的笔记本电脑类比让这一原则变得具体。如果通常交付需要5天，SOL就是有人直接走进Best Buy、立刻买下一台机器；只有在这之后，团队才应该把更大规模采购的实际约束加回来。
一位主持人的反驳值得保留：当团队需要稳定性和计划时，持续要求SOL可能会变得令人厌烦。Nader表示认同：对于CES，Spark远程注册可能达到早期体验阶段，并出现在Jensen的主题演讲中；但网络和安全问题尚未解决，因此不能把它当成已完成的产品。
这个词本身也来自硬件：加速器有理论上的全速上限，随后才是实际能够达到的比例，例如模型FLOPS利用率。因此，SOL并不意味着可以忽视维护；它定义的是“我们能达到的最低目标”，然后对每一个增量组件重复这一过程。

4. NVIDIA把组织流动性视为研究优势

Kyle大学毕业后加入NVIDIA，从自动驾驶目标检测转向GPU加速推荐系统，随后又进入图神经网络领域。推荐系统正成为信息流爆炸时代的常驻基础设施，而图网络则让他能够表示人与人、人与物品以及概念之间的关系。
NVIDIA鼓励员工追随兴趣：有人提出一项倡议后，可以给组织中更高层、可能对此感兴趣的人发邮件，请求参与其中。与之配套的规则是，“动量是唯一的权威”——先做出具体东西，让同事试用，再用已经展示出的进展吸引支持。
沟通方式也同样松散。邮件线程可能变成60人的“mosh pit”，但它们能够保留工作上下文，让重要讨论重新浮现，随时加入收件人，并在工作分叉时拆成新的线程。
Kyle描述了NVIDIA愿意投资“零亿美元业务”的做法：某个领域今天可能没有收入，但理解未来市场仍然重要。当主持人指出汽车显然不是一个零亿美元市场时，讨论进一步澄清，这里的含义是：内部组织不需要立刻产生收入，也能为重要研究提供正当性。

5. Dynamo把数据中心变成推理引擎

Kyle最终从相反方向回到了推荐系统：Amazon Ads介绍了用Dynamo进行生成式推荐的做法，这意味着5年前他正在做的事情，正被LLM推理“取代”。这种汇合说明，推理为何已经从小众系统议题走向高速公路广告牌。
vLLM、SGLang和TensorRT-LLM等单体引擎，主要优化的是模型的一份副本或一个副本实例。Dynamo位于它们之上，是一个模块化、数据中心级的推理运行时，负责协调横向扩展，并利用KV cache最大化、解耦等共享系统机会。
横向扩展最终会撞上硬件和算法边界。在多数DGX H100系统中，最快的NVLink域覆盖8块GPU；超过这一范围后，通信就会转向InfiniBand。Kyle估计，NVLink单向带宽约为500 GB/s，InfiniBand约为50 GB/s，同时提醒具体数字取决于硬件代际。
因此，横向扩展不可避免，但简单复制模型副本会浪费性能。Dynamo的核心判断是：机器集合中存在独特的缓存状态和不断变化的工作负载，应该把它们作为一个推理系统统一调度，而不是视为可互换的盒子。

6. 质量、成本和延迟定义每种部署的可行前沿

Kyle把推理可行性归结为3条轴线：工作流能否以足够高的质量完成任务，所有多轮调用能否以足够低的成本完成服务，以及能否满足延迟SLA？Dynamo提供了在这条“帕累托曲面”上移动的旋钮，但无法消除取舍。
工作流如今与基础模型同等重要。更小的模型如果配合更多测试时扩展、重试、工具或更强的harness，可能达到更大模型的质量，但也会消耗更多调用次数和token；更快的模型变体与可调节的思考预算，则把这一交换关系直接暴露出来。
模型和SLA确定后，运营方会测试tensor parallel规模及其他常见配置，寻找成本最低的可行系统。不存在通用配方：expert数量、稀疏度、服务布局和工作负载分布，往往来自大量试错，而不是理论上唯一正确的答案。
主持人举出的“再试一次”例子，体现了需求侧的压力。一篇被引用的论文据称发现，让模型看到失败尝试并再次作答，成功率大约可以翻倍。自蒸馏或强化学习还能更深入地利用过去的失败；因此，更好的推理可能意味着有意为多次尝试付费，而不是要求一次调用就做到完美。

7. Prefill与decode解耦，消除了隐藏的调度冲突

传统推理引擎在prefill与decode之间交替：prefill读取prompt并生成KV cache，decode则利用该缓存生成输出token。由于调度按步骤推进，一次很长的prefill操作可能阻止引擎启动下一步decode，损害交互式生成体验。
两个阶段对硬件的压力也不同。当输入足够长时，prefill通常受算力约束，因为它要完整遍历权重，并承担二次复杂度的attention计算；decode则反复读取线性规模的内存，通常受内存带宽限制。
解耦会把两个阶段分配到独立的worker资源池，消除二者在步骤上的同步干扰，并让每个资源池使用适合自身的配置。讨论指出，这一思路在Dynamo之前就已出现在学术研究中，而Dynamo是最早把它作为系统原语支持的框架之一。
硬件层面的影响已经显现。Exo Labs展示了在DGX Spark上执行算力密集型prefill、在Mac上执行decode的方案；NVIDIA则公布了面向prefill的专用加速器Rubin CPX。参与者拒绝猜测未来是否会利用即将到来的Groq技术实现极高速decode。

8. Grove让Prefill与decode容量能够独立移动

静态配对效率不高，因为工作负载不会保持固定的prefill-to-decode比例。突然涌入大量超长prompt，会令prefill需求急升；输出长度、上下文和请求结构的变化，则会形成另一条decode扩容曲线。
Dynamo包含一个名为Grove的Kubernetes组件，用于表示这种多阶段、多节点部署。讨论将其与LeaderWorkerSet对比：后者适合许多分布式任务，但当配对阶段需要动态变化的比例，而不是固定的副本形态时，就会遇到困难。
Dynamo能够估算工作负载需要多少prefill和decode worker，再将调度机制暴露出来，在现有基础设施上实现这种布局。Decode的扩展同时取决于交互两端：输出越多，生成步骤越多；累积上下文越长，每一步执行的工作也越多。

9. Kimi K2显示，架构正在变成硬件资源分配决策

讨论中最清晰的协同设计案例是Kimi K2。它被描述为采用类似DeepSeek的思路，使用MLA，但对组件进行不同扩展：设计者增加expert数量，同时保持激活expert数量不变，让混合变得更稀疏；与此同时减少attention heads，以降低attention工作量。
这种取舍是在重新分配资源，而不只是简单缩小模型：更多expert会消耗额外内存容量，较少的attention heads则降低仍会随上下文呈二次增长的计算量。因此，预期工作负载和目标硬件会影响架构究竟购买哪一种容量。
swyx的框架是，近期实验室正在超越单一的“稀疏比例”。设计者可以调整总expert数与激活expert数、attention head数量以及attention层数；更广泛的问题被称为“硬件—模型—上下文—代码协同设计”，因为短上下文与长上下文工作负载偏好的架构取舍不同。
Nemotron被列为另一个协同设计样本：混合状态空间模型受益于大量后训练，而NVIDIA则分层发布模型、数据集和配方。ServiceNow用该数据集训练自己的模型，体现了让其他人复用训练产物或训练流程的目标。

10. Harness正成为训练模型的一部分

Agent harness产生的上下文应被视为模型系统的一部分，并在可能的情况下在训练阶段被“内化”。如果部署始终使用某种固定结构和工具词汇，那么针对该环境训练，应该能够提升最终质量。
一位主持人的反驳是，广泛通用的模型必须接入多种harness、搜索工具和名称不同的函数。讨论承认了其中的摩擦：用户可能必须模仿原始工具接口，撤销部分工具特定的后训练，或围绕自己的harness重新训练——“真的很烦人”。
更乐观的终点是，模型无需专门重新训练就能理解新工具；但当前局限并未被描述为AGI，而是一个“非常愚蠢的‘学习我的工具’”问题。Bash被描述为一种通用harness。
更广泛地说，“system as model”意味着一次模型调用可能隐藏着许多模型和组件协同工作。Dynamo及其他NVIDIA库，目标就是帮助管理这层复杂性。

11. 上下文增长可能依赖不连续的“解锁”

一位主持人直接质疑了行业的上下文发展轨迹：前沿模型已经在约1,000,000个token附近徘徊了大约两年，从1,000,000走向2,000,000，并不能合理推导出100,000,000。“这行不通”是对当前扩展律斜率的怀疑性解读。
回应借用了Leopold Aschenbrenner提出的“解锁”概念：科学或架构上的发现，能够释放此前被卡住的数量级。DeepSeek称原生多token预测改善了训练稳定性，这是一个较小的例子；新的attention机制则可能更大幅度改变服务可行性。
MLA提供了一个数字样本。讨论估计，DeepSeek约128,000-token的上下文——通过RoPE扩展后可能达到256,000——只需约8 GB；而同等精度下，规模相近的Llama 405B上下文此前大约需要40–80 GB。
一个推测性的“解锁”方案是：先在本地把彼此无关的文档切成独立区块进行prefill，再通过完整序列上的全局attention执行decode。这样或许能消除prefill的全局二次复杂度，但这一想法明确仍不确定：尚未有人展示过，也“可能是一个陷阱”，最终只会失败。

12. NVIDIA的Agent推广让安全成为架构问题

NVIDIA已经大规模部署Codex，使用者达到“数万人”，员工也在使用Cursor和Claude Code等工具。有用的工具会通过公司松散的邮件网络“像野火一样”传播，有时Jensen会要求团队立即让它们在全公司范围内运行。
内部Outlook CLI成为一位参与者的验证案例。Codex被要求总结每封邮件、标记升级事项、把可能需要回复的邮件移入文件夹，并归档其他所有邮件；工具运行成功后，它被发给约500名同事，其他人也获得了安装帮助。
提出的安全规则是，Agent拥有3项强大能力：文件访问、互联网访问和任意代码执行；“你确实应该只允许Agent获得这3项能力中的两项”。三项能力同时开放，会扩大恶意注入或非预期数据移动的路径。
NVIDIA的安全团队被描述为进取型团队，因为它试图在启用技术的同时定义执行控制点。对于OpenClaw，内部指导是先在与企业网络隔离的Brev云VM中运行，同时公司继续完善更强的控制措施。

13. CLI正成为企业软件面向Agent的原生接口

NVIDIA正在把Outlook、SAP等业务应用变成命令行工具，并希望将相关工作开源，甚至推动成立“Open CLI Foundation”。开发者工具的新规则已不再只是“让文档能够被LLM访问”；每个工具都应提供强大的CLI支持。
最好的框架来自一段历史反转：计算最初始于shell，随后图形界面让机器更能理解人类；如今LLM正在操作这些界面，而软件“已经不再对机器友好”。给Agent一个终端，等于恢复了一个简洁、可组合的控制面。
讨论列举了使用CLI的几个理由：可移植性、本地性、可发现性，以及预训练数据中大量存在的命令行示例。讨论还指出，CLI能够预先定义允许的网络调用和漏洞边界，而不是让模型临时编写任意Python请求。
NVIDIA已经把这一模式用于推理工程。Agent可以请求算力、启动Dynamo实验、测试配置，并返回帕累托前沿上的点；有一个Agent曾“完全一次性解决”一个配置问题，而此前这需要专家手工进行多轮迭代实验。

14. Agent系统制造出永不满足的算力需求，但需求并不均匀

本地Agent暴露出行为与算力经济学之间的不匹配。一位参与者的全天候Agent即使收到关闭指令，仍让Runpod实例保持运行，把45分钟的人类时间当成几分钟的Agent时间；一台本地双GPU服务器因此变成了“一台小暖炉”。
本地硬件提供控制力，却不具备数据中心经济性。讨论提到，一块约8,000美元、配备96 GB显存的Blackwell RTX PRO 6000可以作为有能力的本地选项，但集中式规模能够实现大规模expert parallelism等优化；在引用曲线的大部分区间里，GB200 NVL72的单token成本约为Hopper的1/35。
讨论更大的主题仍是“system as model”：一次看似简单的API调用，背后可能编排着许多模型、组件和子Agent。NVIDIA的DGX Spark模型路由器会在本地模型与基础模型之间做选择，把非此即彼的决定替换为“所有可用选项中的最佳组合”。
对运行时间的预期仍存在分歧。一位参与者预计，到年底前会出现能够连贯运行超过24小时的Agent，而讨论中的生产环境自主运行时间约为20–45分钟。另一位参与者认为，取舍取决于领域：消费者可能不想等待20分钟的响应，但GPU kernel、医疗和生物研究可能值得更长运行时间；效率或许会先提升，系统运行时间才会再次拉长。

AI 如何改变战争｜Palantir 首席技术官市场概述2026年3月10日