Altman说你在浪费DRAM:AI内存瓶颈的真相

Altman批DRAM浪费,揭示AI推理竞争从算力转向内存效率。
文章从Hacker News上一则关于「Sam Altman认为你在浪费DRAM」的简短讨论出发,指出AI行业的关注焦点正从训练算力转向推理阶段的内存效率。文章解释了内存墙的成因——DRAM带宽增速远慢于算力增长,使内存成为推理规模化的新瓶颈;并归纳了DRAM浪费的四类常见来源:过度分配、KV Cache失控、CPU-GPU数据搬运冗余以及框架默认配置保守。在商业层面,模型能力趋同使推理成本成为差异化竞争的关键,能用更少内存支撑更高并发者将在定价上占优。开发者应对之道包括先建立内存可观测性、采用内存分级与请求级配额、以及针对性调优推理框架参数。文章同时提醒原始素材信息有限,分析属方向性解读,需结合实际度量数据判断。
当Altman开始操心你的内存
在Hacker News上,一条标题为「Sam Altman Thinks You're Wasting DRAM」的帖子引发了讨论。帖子本身只有16个点和18条评论,但这句话背后的潜台词值得深挖:OpenAI的掌门人正在把注意力从算力转向内存,而绝大多数开发者对DRAM的使用方式,可能比想象中更低效。
这不是一句随口调侃。当大模型推理成本成为AI应用落地的核心矛盾时,内存的分配、复用和回收策略,直接决定了单位token的成本。Altman的「浪费」指控,指向的是一整套沿袭自传统软件开发的资源管理惯性。
为什么DRAM成了新的战场
算力焦虑之后,内存墙浮现
过去两年,行业讨论的焦点集中在GPU短缺和训练算力上。但推理场景的规模化,把另一个瓶颈推到了台前:内存带宽和容量。模型参数、KV Cache、中间激活值都要占用DRAM,而DRAM的带宽增长远慢于算力增长,这就是经典的「内存墙」。
在这种结构下,浪费DRAM不只是多花点电费的问题,它直接压低了并发数、拉长了响应时间。一个显存/内存管理不当的推理服务,可能在同样的硬件上只能跑出别人一半的吞吐。
内存墙(Memory Wall) 是计算机体系结构中的经典概念,指处理器算力的增长速度长期快于内存带宽与延迟的改善速度,导致系统性能受限于数据搬运而非计算本身。在大模型推理中,这一矛盾尤为突出:GPU的浮点算力每两年翻倍,而HBM/DRAM带宽的增速明显滞后。结果是,推理的瓶颈常常不是矩阵乘法算不动,而是权重、KV Cache和激活值在内存与计算单元之间的搬运跟不上。业界常用「算术强度」(每字节内存访问能完成多少次运算)来衡量一个负载是否受内存带宽约束,大模型自回归解码阶段的算术强度很低,因此是典型的内存带宽敏感型负载。
「浪费」可能藏在这些地方
从工程视角看,DRAM浪费通常不是显式的内存泄漏,而是几个隐蔽的习惯:
- 过度分配:为峰值负载预留内存,但峰值极少出现,空闲内存无法被其他任务复用。
- 缓存失控:KV Cache不做分级或淘汰策略,长上下文请求把内存吃满。
- 数据搬运冗余:在CPU和GPU之间反复拷贝,或者在不必要的地方保留多份副本。
- 框架默认值:很多推理框架的默认配置偏保守,开发者不做调优就直接上线。
这些做法在单机测试时看不出来,一旦进入生产环境的多租户场景,浪费会被放大。
KV Cache 是大模型自回归生成中的关键机制:为避免每生成一个新token都重新计算此前所有token的Key和Value,推理系统会把历史token的K/V张量缓存下来复用。它把计算复杂度从随序列长度平方增长降为线性,但代价是显存/内存占用随批次大小、序列长度、层数和注意力头数线性膨胀。长上下文、高并发场景下,KV Cache往往成为最大的内存消耗项,也是「缓存失控」的根源。业界因此发展出PagedAttention(分页管理KV Cache,减少碎片)、KV Cache量化、前缀共享和分层卸载等技术,核心思路都是把这份缓存当作需要精细调度的稀缺资源而非无限量的附属品。
Altman的视角:成本结构决定竞争格局
这条HN帖子之所以有讨论价值,在于它反映了OpenAI这类公司对成本结构的敏感度。模型能力趋同的趋势下,推理成本成了差异化竞争的关键变量。谁能用更少的DRAM支撑更高的并发,谁就能在定价上更从容。
对开发者而言,这意味着「能跑通」不再是标准,「跑得省」才是。Altman的批评可以理解为一种提醒:AI应用的性能优化,正在从算法层下沉到系统层,内存管理是其中绕不开的一环。
不过也要承认,这只是一条简短的HN讨论,Altman具体在什么语境下说这句话、针对的是哪类使用者,原始素材并没有给出更多细节。把它当作一个方向性信号,比当作具体的技术指导更合适。
开发者可以做什么
先测量,再优化
内存优化的第一步是建立可观测性。追踪每个请求的峰值内存占用、KV Cache的命中率、内存分配的频率,才能定位真正的浪费点。没有度量数据的优化,往往是凭感觉调参。
把内存当作稀缺资源来设计
在架构层面,可以考虑内存分级(热数据放显存、温数据放DRAM、冷数据落盘)、请求级的内存配额、以及更激进的缓存淘汰策略。这些思路在数据库和CDN领域已经成熟,迁移到AI推理服务上同样适用。
内存分级(Memory Tiering) 的思路源于存储层次结构:把访问频率高、延迟敏感的数据放在带宽最高但容量最小的介质(如GPU显存/HBM),把次热数据放在容量更大但带宽较低的DRAM,冷数据则下沉到SSD或远端存储。AI推理中的典型做法是把活跃请求的KV Cache留在显存、把暂时挂起的请求KV Cache换出到主机内存、把长期不活跃的会话落盘,从而在有限显存下支撑更高并发。这与操作系统虚拟内存的换页、数据库的缓冲池管理在原理上一脉相承,难点在于换入换出的调度策略和由此引入的延迟抖动,需要结合请求的SLA做权衡。
关注框架的调优空间
主流推理框架通常提供了批量大小、缓存策略、量化精度等配置项。默认配置面向通用场景,生产环境需要针对性调整。这部分工作不性感,但收益直接体现在成本表上。
编辑观点
「Altman说你在浪费DRAM」这个标题的传播力,来自它戳中了一个被忽视的盲区。AI工程社区花了大量精力讨论模型选型和Prompt技巧,却较少严肃对待系统层的资源效率。内存管理的回归,说明这个行业正在从「能不能做」进入「划不划算」的阶段。对个体开发者来说,这既是压力,也是建立技术壁垒的机会。
需要提醒的是,本条素材信息密度有限,HN讨论的具体内容未在原始输入中展开,本文的分析更多是基于标题本身的方向性解读,读者应结合自身系统的实际度量数据做判断。
相关推荐

Claude Code v2.1.316 更新解析:企业级网关与多项稳定性修复
Claude Code v2.1.316 发布:新增企业网关池化组预算、分层策略模式、子智能体 effort 控制,修复 Shell、网络与会话恢复等数十项问题,并弃用 Opus 4.8 fast 模式。

17世纪英国洪水与末日恐慌:天气史新解
基于Hacker News讨论的'17世纪英国洪水与不祥预感',解读极端天气如何被赋予神意与政治预兆意义,并探讨天气史对当代气候传播与灾害舆情的启示。

合理使用制度为何对AI时代人人有益
从Hacker News讨论出发,解析合理使用(Fair Use)原则在AI训练与内容创作中的法律逻辑、争议焦点及其对创作者与技术生态的双重影响。