2026.09.24 | AC | LLM | Jev Impact on Optics, Memory & CPU

摘要

1. Jev 把一次 AI 调用压缩成 Choice、Score 或 Noul：选哪个、打几分、某件事为真的概率是多少。它输出得很少，调用又快又便宜，看起来会直接减少大模型推理和 HBM 消耗；可如果低成本判断催生更多

Agent、更多工具调用和更长任务，服务器、内存、存储与网络又可能迎来新需求。

1. 本篇文章从一个 Agent 任务的完整资源消耗出发，将其拆成慢模型规划、快速判断、工具执行、热状态和持久状态五部分。笔者进一步用 KV Cache 容量公式、三组 HBM

敏感性情景和三档任务留存量，回答三个问题：单任务降耗要被多大的任务量增长抵消？KV Cache 是否真的会迁入 NAND？哪些硬件最先看到 Jev 带来的增量？

1. 结果远比“利好 GPU”或“利好存储”复杂。Jev 改变了计算在系统中的位置，投资机会也会随之迁移。最终判断取决于几个可以持续跟踪的真实数据。

Jev 发布后，市场很快形成了两种相反的硬件解释。

第一种认为，Jev 用小型决策模型替代通用大模型的高频判断，长文本生成减少，KV Cache 随之下降，因此利空 GPU 和 HBM。第二种认为，判断成本下降会触发 Jevons Paradox（杰文斯悖论）：单位智能越便宜，用量越大，最终反而拉动更多算力和存储。两种说法都抓住了一部分事实，也都跳过了中间最重要的一步：一次成功的 Agent 任务究竟消耗了什么资源？

此前的《从Token到Decision：Jev带来的快慢模型分层如何重塑Agent、AI SaaS与端侧芯片》讨论了 Jev 的产品形态、适用场景与商业模式；《一个 Token 的旅程》从 Token 在模型内部的流动解释了 GPU、HBM、光互联与 CPU 的需求。本篇则重点讨论，当 Agent 把“思考”拆成两种速度、把“记忆”移出单一模型上下文，这种模型架构的改进将如何影响硬件需求？

一、Token 仍然重要，但已不足以解释 Agent 的资源消耗单位

聊天时代，一次请求通常围绕一个模型展开。用户输入文本，模型读取上下文，逐 Token 输出回答。计算、显存和价格都可以围绕 Token 估算。

Agent 的工作方式更像一个项目组。前沿模型负责拆任务、制定计划和处理异常；Jev 一类决策模型负责大量边界清楚的判断；代码和工具负责执行；数据库保存任务状态、权限、文件和历史轨迹。一次任务可能只生成几百个可见 Token，却完成几十次判断、工具调用和状态读写。因此，Agent 时代更合适的最小分析单位是“一个成功完成的任务”，可以写成：

单任务资源 = 慢模型规划 + 快模型判断 + 工具执行 + 热状态 + 持久状态

进一步拆成五个变量：

• `kL`：每项任务调用前沿大模型的轮数；
• `mJ`：每项任务调用 Jev 类决策模型的次数；
• `ktool`：代码、浏览器、数据库等工具调用次数；
• `Shot`：任务进行中需要低延迟访问的热状态；
• `Swarm`：任务结束后继续保留、可审计复用的持久状态。

Jev 的直接作用，是用大量便宜的 `mJ` 替代一部分昂贵的 `kL`。但 `ktool`、`Shot` 和 `Swarm` 很可能同步增加。于是，同一项技术会对不同硬件产生相反方向的影响。

图1：一项agent任务消耗的资源路径对比

传统 Agent 经常把工具结果、失败日志和历史动作不断追加到提示词中，再让同一个大模型重新读取。上下文像一个越开越长的会议：每加入一位参与者，都要先听完此前全部发言。Jev 式架构更接近分工明确的公司。前沿模型偶尔召开管理层会议，Jev 快速完成路由、分类、风险评分与是否重试，代码执行确定性动作，外部状态库保存项目资料。大模型不必每轮背诵全部历史，CPU、DRAM、网络和存储却要支撑更多流程。

二、Jev 对 HBM 的第一层影响：减少大模型“背历史”的次数

HBM 是 High Bandwidth Memory（高带宽内存），靠近 GPU，用来放模型权重、当前激活和 KV Cache。KV Cache 可以理解为模型的短期工作记忆：模型已经读过的每个 Token，会留下一组中间结果，后续生成无需从头计算。对采用多查询或分组查询注意力的模型，KV Cache 容量可以近似写成：

KV Cache = 2 × 上下文长度 × 层数 × KV 维度 × 每元素字节数

其中“2”代表 Key 和 Value 两份缓存。用一个纯示意模型计算：80 层、KV 维度 1,024、FP16/BF16 两字节，同一并发会话在 8K、32K、128K 上下文下，KV Cache 约为 2.5GB、10GB 和 40GB。

图2：上下文越长，KV Cache 越像一堵容量墙

这张图解释了 Jev 的价值来源。若路由、是否完成、工具选择和风险判断都由大模型处理，任务每推进一步就可能继续扩展上下文。Jev 把其中部分环节改为一次读取状态、并行返回若干结构化判断，减少长上下文被反复送入前沿模型。但这里需要叠一下buff：

第一，TypeSafe 尚未披露 Jev 的参数量和内部架构，不能说 Jev 自身完全没有 KV Cache。公开资料能支持的结论，是它不生成自由文本、多个问题可并行评估，系统级长解码负担较轻。

第二，切换模型需要额外成本。大模型与 Jev 如果不能共享 KV Cache，状态需要重新编码；前沿模型再次接手时还可能发生 Prefill，即重新读取上下文的预填充计算。

第三，企业需要的不只是容量。即便 HBM 占用下降，频繁调度、模型切换和并发会话也可能降低 GPU 利用率。单看“每次调用少了多少 Token”，容易高估真实节省。

三、HBM 总需求的增减取决于任务量能否越过阈值

Jev 对 HBM 的影响可以拆成一个简单等式：新 HBM 总需求 / 原 HBM 总需求 = 任务量倍数 × 单任务 HBM 资源比

单任务资源比再写成：(1-f)×c + f×r + v

其中，`f` 是被 Jev 卸载的判断比例，`c` 是剩余大模型调用的上下文系数，`r` 是 Jev 判断相对于原大模型判断的资源比，`v` 是验证、切换和上下文重建带来的额外开销。

由于 TypeSafe 没有披露生产负载数据，笔者用三组假设做敏感性分析。保守卸载、基准卸载和深度卸载下，单任务 HBM 资源分别降至原来的 74.5%、39.2%和 23.4%。要让 HBM 总需求重新回到原水平，任务量需分别增长约

1. 34 倍、2.55 倍和 4.28 倍。

图3：HBM总需求的胜负手，是任务量能否跑赢单任务降耗

这给出了一个鲜明判断：Jev 对高端 GPU/HBM 的一阶作用是降低单任务强度，二阶作用才是杰文斯效应。

四、KV Cache 与 NAND 之间，隔着一层“业务状态”

KV Cache 是特定模型、特定层和特定上下文计算出的中间张量。换模型、改权重或改变部分提示词后，它未必还能复用。业务状态则包括任务树、网页元素、文件、代码补丁、权限、工具结果和审计日志，可以跨模型、跨时间复用。

Jev 推动的更可能是“状态外部化”：把模型内的长叙事，改造成系统可读取的结构化状态。数据按照访问速度分层：

图4：Jev推动状态分层，KV Cache不会原样搬进NAND

• HBM：模型权重、当前激活与活跃 KV Cache，微秒级以下访问，带宽最高；
• 主机 DRAM：活跃 Agent 状态、热缓存、部分 KV 主机卸载，容量更大；
• 企业级 SSD：任务轨迹、虚拟机快照、索引和近期文件，需要持久化和高 IOPS；
• 对象存储/HDD：长期日志、历史产物和冷数据，保留时间最长。

因此，Jev 对存储的传导顺序大概率是：主机 DRAM 最直接，企业级 SSD 次之，NAND 容量弹性取决于任务留下的数据量和保留政策。NVIDIA 的 Dynamo 文档已经支持 KV Cache 向 CPU 内存和磁盘分层，但磁盘路径仍需考虑实验成熟度、筛选策略和 SSD 寿命，不能把它视为所有 Agent 的默认架构。

五、NAND 的胜负手是“每项任务留下多少字节”

一次 Choice 输出可能只有几个字节，即使每天调用上亿次，也不会自然形成巨大的容量需求。容量差距来自截图、代码、浏览器轨迹、文件版本、虚拟机快照和训练回流数据。

假设系统每天完成 1,000 万项任务，保留 30 天、保存三份副本，不考虑压缩与去重：

• 每项任务只留 10KB 结构化记录，总容量约 9TB；
• 每项任务留下 1MB 轨迹和文件，总容量约 0.9PB；
• 每项任务留下 100MB 截图、沙箱与快照，总容量约 90PB。

图5：NAND需求取决于每项任务留下多少数据

同样的任务数，对 NAND 的结果可以相差一万倍。由此可见，“Agent 更多”只是必要条件，能够决定 SSD 收入的变量还有：每任务持久化字节、保留天数、副本数、压缩去重率、冷热分层比例、写放大和耐久度要求。

短期内，企业级 SSD 可能先看到 IOPS（每秒输入输出次数）和耐久度需求，容量未必同步爆发。数以亿计的小状态读写会增加元数据、索引和日志压力；只有任务开始保留大量多模态产物和沙箱快照，容量才会明显抬升。那么，哪些终端应用会把10KB记录推向MB乃至GB？

Coding Agent是最容易率先放量的场景。Agent修改代码、安装依赖、编译和运行测试后，企业为了复现错误、回滚版本和审查变更，往往需要保存代码仓库副本、补丁、编译产物、测试日志以及容器快照。一次“是否通过测试”的判断只有几个字节，一项长时编码任务留下的工作现场却可能达到数十MB乃至数GB。

Computer Use和浏览器Agent紧随其后。企业若要求每一步操作可审计，系统需要保留页面截图、DOM状态、下载文件、表格和文档版本。Agent处理财务、法务、采购等高价值流程时，审计要求会把“只保存最终答案”升级为“保存完整操作轨迹”。

网络安全Agent会形成高写入强度。调查越权、攻击或误删事件，需要网络流量、进程变化、凭据调用、文件系统日志和事发时的容器快照。它们兼具高IOPS、长保留期和多副本要求，是企业级SSD较高价值的工作负载。

自动驾驶、机器人和游戏Agent会产生最大的多模态数据。Jev式模型可能只返回转向、减速、跳跃等动作，验证该动作却需要摄像头、雷达、传感器、游戏世界状态和完整Episode。单次决策很小，支撑它的“现场录像”很大。

AI4S和自驱实验室更偏长期价值。显微镜图像、实验视频、分子结构、物理仿真、EDA波形和失败轨迹既要审计，也可能回流下一轮训练。数据一旦从一次性结果变成可复用训练资产，保留时间和副本数都会上升。

这五类场景可以归纳为一句话：NAND需求来自可复现、可审计、可训练的任务现场，Decision本身只占极少字节。因此，Coding Agent、Computer Use和网络安全更可能先带来企业级SSD的IOPS与耐久度需求；物理AI和AI4S规模化后，容量弹性才更明显。

六、网络需求会增加“次数”，未必增加同等幅度的“字节”

传统大模型集群的网络投资，重点是 GPU 之间搬运巨量张量。Jev 式 Agent 增加的是另一类流量：模型路由、工具调用、权限检查、状态读取、数据库访问和人工复核。这些请求通常更小、更碎、更频繁。

因此需要区分两张网：

• Scale-up/Scale-out 训练与推理网络关注大带宽、低延迟的 GPU 互联；
• Agent 控制面与数据中心网络关注 RPC 次数、小包处理、连接管理、安全隔离和服务编排。

Jev 每次输出很小，未必显著增加总传输字节，却可能显著增加每秒请求数和东西向服务调用。受益更直接的环节是 NIC（Network Interface Card，网卡）、DPU（Data Processing Unit，数据处理器）、服务器 CPU 和低延迟交换；光模块能否受益，仍要看前沿模型调用量、集群切分和 GPU 利用率，逻辑弱于“请求次数增加”。这也解释了为什么 CPU 不能被视为 AI 数据中心的配角。GPU 负责高密度矩阵计算，CPU 负责调度、序列化、网络协议、工具进程、沙箱和权限检查。Agent 越像一个持续运行的软件系统，CPU 秒/任务越值得单独计量。

七、硬件投资顺序：先找控制面增量，再等算力反弹

综合单任务强度与总量弹性，Jev 之后的硬件方向可以分成四组：

图6：Jev之后，硬件投资顺序从算力核向状态控制层扩散

1. 服务器 CPU 与主机 DRAM：最直接

更多 Agent 意味着更多并发会话、工具进程、状态机、数据库请求和安全检查。即使大模型 Token 减少，这些工作也不会消失。需要跟踪 CPU 利用率、每任务 CPU 秒、主机内存容量和 Agent 并发数。

服务器CPU对应AMD和Intel。AMD的机会来自EPYC核心数、内存通道和AI服务器CPU份额提升；Intel拥有庞大的服务器安装基础，Agent控制面若提高通用计算利用率，也会改善其数据中心CPU的需求质量。主机DRAM对应Micron、Samsung Electronics和SK hynix，受益逻辑是每台服务器需要容纳更多并发会话、热状态和KV主机卸载。公司能否兑现收入，还取决于云厂商配置比例、平台利用率和采购周期。

2. 企业级 SSD/NAND：有条件受益

任务轨迹、文件、快照和长期记忆若被保留，企业级 SSD 的 IOPS、耐久度和容量都会受益。对应供应商包括Samsung Electronics、Micron、SK hynix/Solidigm、Kioxia和SanDisk。Samsung和Micron同时覆盖DRAM与NAND，能够分享主机内存和企业级SSD两层增量；Solidigm、Kioxia和SanDisk对存储周期的业绩弹性更高。Marvell则提供企业级SSD控制器和数据基础设施芯片，受益点更接近“如何管理这些数据”。验证时应优先看Jev率先带来什么样的终端场景爆发，若 Agent 只保留很小的结构化状态，NAND 弹性会显著低于市场想象。

3. NIC、DPU 与数据中心交换：偏利好

模型与工具被拆成更多服务后，RPC、鉴权、队列和状态同步增加。面向AI数据中心的NIC+DPU综合竞争力，笔者将全球前三排为NVIDIA、Broadcom和AMD Pensando。

• NVIDIA拥有ConnectX/SuperNIC、BlueField DPU、Spectrum-X交换机和DOCA软件，能够把GPU、网卡、DPU和交换机共同优化，是全栈确定性最高的受益者。
• Broadcom的优势来自NetXtreme/Thor系列NIC、Tomahawk交换芯片、SerDes和PHY。它更像面向多家云厂商和设备商供货的底层“军火商”，开放以太网份额提升时受益更直接。
• AMD Pensando补齐了AMD在网络、存储和安全卸载上的能力，已经进入Azure等云环境；若AMD扩大AI服务器和机架级系统份额，Pensando具备随系统放量的期权。

Marvell的OCTEON DPU在电信、边缘网络、安全网关和定制基础设施中积累深厚，综合排名可放在第四；Intel拥有传统NIC基础和E2100 IPU，当前AI网络产品节奏弱于前三。网络受益需要用每任务RPC数、东西向流量和小包处理负载验证，Agent数量本身不足以证明收入增量。

4. 高端 GPU、HBM 与光互联：先降强度，再看总量

Jev 减少部分前沿模型轮次和长上下文，单任务 GPU/HBM 强度承压；任务量跨过 1.3—4.3 倍的情景门槛后，总需求才可能重新增长。GPU对应NVIDIA和AMD；HBM对应SK hynix、Micron和Samsung Electronics。前两类公司的受益程度取决于成功任务量能否跑赢每任务GPU秒下降，HBM厂商还要观察每颗加速器的容量升级能否抵消推理效率提升。

交换与光互联需要再分一层。Broadcom、Marvell和Arista可能受益于服务拆分和东西向流量增加；Coherent、Lumentum等光器件公司更依赖实际传输字节、端口速率和GPU集群扩张。大量小RPC可以提高网络设备负载，却不会 自动创造同等幅度的光带宽需求。

这一组最容易被宏大叙事误导。投资者需要同时观察前沿模型 Token、推理 GPU 利用率、KV Cache 命中率和成功任务量。任何单一指标都无法给出结论。

5. 端侧 NPU、LPDDR 与 UFS：远期期权

自动驾驶、机器人和游戏需要毫秒级本地决策，Jev的产品形态与需求相容。芯片侧可关注Qualcomm、NVIDIA、Mobileye和MediaTek，本地内存与存储仍映射Samsung Electronics、Micron和SK hynix。TypeSafe尚未披露端侧模型规格、功耗和量产计划。现阶段只能保留产业期权，后续持续跟踪。

图7：从硬件环节落到公司，受益顺序与验证条件

八、结论：Jev 降低“思考”的边际成本，也把瓶颈推向系统

Jev 的硬件意义，可以总结为三句话。

第一，单任务层面，它减少前沿大模型承担的高频判断，GPU/HBM 强度先下降。

第二，系统层面，它把更多任务变成可执行的软件流程，CPU、DRAM、I/O、企业级 SSD 和控制面网络承担更多工作。

第三，总量层面，杰文斯效应能否覆盖单任务降耗，要用成功任务数和任务留存字节验证。在本文情景中，HBM 的盈亏平衡门槛约为 1.3—4.3 倍任务量增长；NAND 的容量结果则可以因每任务留存量不同而天壤之别。

笔者更倾向把 Jev 看成 AI 基础设施从“一个大模型包办全部”走向分层计算的早期信号。算力仍然重要，只是新增价值开始向控制面和状态层扩散。未来最有解释力的指标，也将从 Token/day 扩展为：成功任务数 × 每任务计算 × 每任务状态 × 保留时间。

当云厂商开始稳定披露这四组数据，Jev 对硬件的影响才会从架构推演进入财务兑现。

--- 前序文章

1. 《从Token到Decision：Jev带来的快慢模型分层如何重塑Agent、AI SaaS与端侧芯片》：讨论Jev的产品形态、适用场景、计费方式和商业模式，是本篇硬件分析的应用层起点。

《一个Token的旅程（上）：AI算力的真瓶颈，藏在内存墙里》：从Token在模型内部的流动出发，解释GPU、HBM、CPU和光互联的需求，是本篇从Token升级到Decision与成功任务的基础框架。

--- 数据来源与口径说明

1. TypeSafe AI, Introducing System One Models and Jev。用于 Jev 的公开产品形态、结构化输出和并行判断机制。
2. TypeSafe AI Docs,

Introduction；Models。用于上下文限制、接口能力与披露边界。

1. Latent Space, Jev / Diogo Almeida interview。创始人观点，用于理解 KV

Cache、模型路由和系统设计动机；相关表述不等同于已验证性能。

1. NVIDIA, NIM KV Cache Reuse and Host Offloading。用于 KV Cache 复用与主机卸载机制。
2. NVIDIA Dynamo, KV Block Manager。用于

CPU/磁盘分层缓存及 SSD 寿命边界。

1. NVIDIA TensorRT, Work with Transformers。用于 KV

Cache 结构与推理机制。

1. NVIDIA, BlueField Platform；Broadcom, [Thor

Ultra 800G AI Ethernet NIC；AMD, Pensando DPU；Marvell, OCTEON DPU；Intel, IPU E2100。用于NIC/DPU产品与竞争格局映射。

1. 文中 KV Cache 数值、HBM 盈亏平衡和 NAND 容量均为笔者敏感性测算，不代表 TypeSafe 披露、行业预测或任何公司的业绩指引。

风险提示：Jev 的架构、参数量、服务端硬件和生产负载尚未完整披露；第三方应用案例可能受免费额度、早期开发者选择偏差和特定工作流影响；本文为笔者个人观点，只讨论架构方向，不构成个股投资建议，请投资者自担风险。