从技术角度分析，当前内存市场的供需关系是怎样的？
数据中心的存储架构通常分为三层：第一层是 HBM，第二层是 DRAM，第三层是 NAND。当 前市场出现紧缺，一个主要原因是部分产能被优先分配给了利润更高的 HBM，这挤占了其他 内存产品的产能，导致了连锁性的短缺。
内存需求的增长主要驱动力来自业务侧，随着 Coding Agent、Work Agent 等新产品的推出， 其 Token 消耗量相较于传统应用呈现出十倍、二十倍甚至三十倍的增长。在技术实现上，为 了支持推理过程，需要通过内存机制存储中间数据。这个过程中会采用压缩、显性存储等技 术，因此存储需求的增长与 Token 消耗的增长并非简单的等比关系，而更接近于一种二阶导数的关系，并非直线拉升。
在 AI 应用中，HBM、DRAM 和 NAND 各自扮演什么角色？它们如何协同处理不同时长的 计算任务？
HBM 主要应对高并发的实时处理需求，其占用时长通常较短，可能只有几分钟或一两个小时。 计算过程中，数据会从 HBM 溢出到 DRAM 中，DRAM 的占用时长会稍长一些，可能达到数 小时。最终，需要长期保存的数据会被存放到 NAND 中，因此 NAND 承担的存储压力相对更 大。整个过程是一个数据不断向外层存储溢出的流程，HBM 承载的是并发数，例如百万或千 万级别的并发，但不会被长时间持续占用。
以一个拥有 1 亿用户的产品为例，假设其峰值并发用户数达到 1,000 万。如果每个并发用户 在一天内平均消耗 100 万 Token，而每 100 万 Token 需要 4GB 显存，那么支撑这 1,000 万 并发用户在峰值时刻所需的总显存量为 4,000 万 GB（1,000 万用户 × 4GB/用户）。这个峰 值需求类似于春运期间的运力瓶颈，需要以此为基准来规划 HBM 的配置。若以单颗 HBM 容 量为 100GB 计算，则需要 40 万颗 HBM（4,000 万 GB ÷ 100GB/颗）来满足其峰值需求。 需要注意的是，这 1,000 万并发用户会分布在一天中的不同时段，并非所有需求都集中在同 一瞬间。
考虑到产业界正在进行各类工程化优化以降低 HBM 需求，例如 KV cache 等技术，这些 优化措施在量化上能带来多大程度的 HBM 需求削减？
综合来看，各类工程化优化手段合计能够节约大约 60%的 HBM 需求。主要的优化技术包括 以下几方面：
首先是 Agent Memory 技术。在推理过程中，系统会存储一部分处理结果。当后续遇到相似 或重复的任务时，系统可以直接从存储中调取结果并快速生成，无需重新完整执行一遍，类 似于缓存命中机制。这种方式可以节约大约 35%到 40%的资源。对于简单任务，重复率较高， 节约比例可达 50%至 60%；而对于复杂任务，重复率较低，因此拉低了整体平均值。
其次是选择性存储。系统并不会存储所有用户的每一次操作结果，而是会筛选出其中成功率 最高、运行效果最好、生成质量最优的结果进行存储，丢弃低质量内容。这种择优存储的策 略也能节约 20%到 30%的资源。
最后是 KV cache 优化。在 Agent 场景下，每次任务执行都需要加载上一次的上下文，这与 纯粹的 Chatbot 单次上下文处理不同，其优化逻辑更为复杂。因此，在 Agent 应用中，通过 KV cache 优化能实现的上下文复用率大约在 10%至 15%之间，其节约效果不如在 Chatbot 场景中显著。
目前来看，Agent Memory、选择性存储和 KV cache 是几项最主要且技术上已成熟的优化手 段。
对于像 Kimi 长文本模型这类架构，其 HBM 占用主要在于存储模型权重而非 KV cache， 那么在权重加载方面是否存在共享机制以节约资源？
此类模型虽然在推理时只激活一小部分参数（例如低于 2%），但在加载时仍需要将完整的模 型（如 2.8TB）载入到大量计算卡中。激活部分参数主要节约的是推理过程中的计算量，从 而降低了生成百万级 token 的成本，但并不会节约 KV cache。因为 KV cache 的计算是基于 模型的全部参数，而非仅激活的那部分参数。关于权重共享，这类模型本身就是专家模型架 构，其工作原理就是在推理时根据任务需求，仅加载和激活最有用的那部分专家权重，这本 身就是一种高效的权重利用方式。因此，当不同用户执行任务时，系统会调用相应的专家权 重，这在机制上已经实现了权重的按需共享，避免了为每个用户都加载一套完整的、冗余的 权重。
与简单的 Chatbot 应用相比，是否意味着在更复杂的 Agent 执行场景中，通过优化技术 能节约的资源相对有限？
是的，Agent 场景下的优化空间确实比 Chatbot 要小。Agent 任务，尤其是像 Coding Work Agent 这类应用，每个用户执行的具体任务差异性很大，导致任务的重复比例远低于 ChatGPT等对话式应用。因此，依赖于任务重复性的缓存和复用技术，在 Agent 场景下的节约效果会 打折扣。
其实 Agent 更适合应用于 To B 场景。原因在于 To B 场景的用户和应用场景相对固定，例如 在一家拥有数百或上千名员工的公司内部，同一部门的员工处理的事务具有相似性，这使得 构建高效的 Memory（记忆）系统更为可行。相比之下，To C 场景用户基数庞大，个体用户 的使用场景千差万别，为构建统一有效的 Memory 带来了巨大挑战。从行业发展阶段来看， Agent 这一概念出现至今仅约半年，而 Agent Memory 的构建也才刚刚起步三个月左右，其 在存储技术上的应用尚处于非常初级的阶段，远未达到类似 ChatGPT 那样的高比例应用水平。
从公司层面看，当前的存储资源是否充足？未来的供需趋势？
当前存储资源处于紧缺状态。无论是通过提价还是优化软件算法，其目的都是为了缓解硬件 涨价带来的压力。大厂凭借现有的存储存量，可以支撑业务发展至 2026 年第四季度。然而， 预计到 2027 年第一季度，如果新增的硬件采购未能及时到位，将不得不开始对资源使用进行 控制。
在 AI 应用中，To B 和 To C 业务模式的具体区别是什么？
模型压缩技术的产业现状如何？它们对硬件需求的削减幅度和未来发展空间是怎样的？
模型蒸馏和稀疏化技术分别如何影响推理算力和 HBM 显存的需求？
MOE 架构对 HBM 显存需求是增量还是减量因素？
从算法优化的角度看，未来是否存在颠覆性算法大幅降低 HBM 需求的风险？
新的存储介质，如 CXL、GDDR5 或 3D DRAM，将如何影响 HBM 的发展和应用？
从 AI Agent 任务执行的角度来看，内存和 CPU 哪个更为关键？
从供给侧角度，通过各厂商（如英伟达、AMD）的 GPU/APU 出货量及其单卡的 HBM 配置来测算全球 HBM 总需求，这种算法是否合理？
从需求侧角度预测 AI Agent 应用带来的算力需求时，与 C 端用户和模型训练等上限清晰 的场景相比，Agent 的需求似乎无穷无尽，应如何进行有效的预测？
对于大部分普通白领而言，其工作任务的复杂性有限，并发高峰可能集中在上午 10 点至 11 点等特定时段。基于当前观察，2026 年的并发用户数大概在什么水平？
基于一个用户平均占用 4-5GB HBM 内存的假设，2000 万并发用户将产生约 100 PB 的HBM 需求。这一需求量在整个数据存储领域中处于何种水平？
