过去三年，AI产业的注意力几乎全部集中在GPU算力上。TOPS数字年年翻新，芯片制程不断逼近物理极限。然而，当大模型从数据中心走向手机、PC、机器人和工业传感器，一个更为棘手的矛盾开始浮出水面：限制边缘AI落地的核心瓶颈，从“算得快不快”转向“存得下、搬得动、喂得饱”。

正如Arm全球存储业务负责人John Xavier Lionel在GMIF 2026提出的核心判断：“边缘AI的机遇最终不是一个TOPS问题，而是一个系统设计挑战。”这不是一句口号，而是一个被产业数据反复验证的结构性事实。

Token的“隐性账单”，推理吞吐的天花板

要理解这场存储觉醒，首先需要看清AI推理的真实成本结构。

当一台设备每天执行20次AI交互，每次生成500个输出token，一百万台设备每天将产生100亿个token。按照当前主流商业API定价，如果以每百万token 10美元计算，仅输出token的日成本就达到10万美元，年化运营支出高达3650万美元。这还只是输出端——尚未计入输入token、缓存上下文效应、重试开销、网络传输和编排成本。

数字背后是一个朴素的商业逻辑：当AI使用量从“试用”走向“日常”，token生成就从一次性研发投入变成了一项持续性的运营支出。 而任何持续性支出，都会自动寻找最经济的承接方式。

这正是边缘AI从“技术可能性”变为“经济必然性”的底层驱动力。Arm演示文稿中给出的对比框架清晰地揭示了两种路径的成本差异：纯云端路径需要经过“本地数据→网络传输→云端推理→返回token”四个环节，每个环节都在消耗带宽、延迟和金钱；而边缘优先路径则将数据和模型留在本地，仅在能力不足时才向云端升级。

研究数据支持这一判断。Deloitte的分析显示，采用边缘、云混合策略的组织相比纯云架构可实现15%至30%的总成本节约。更激进的数据来自实际部署，某AI主机方案相比纯云端可降低词元成本80%以上，对工厂质检、门店客服等高频场景，“边侧省词元”已经从概念变成了每月成本表上可直接核对的一栏。

成本之外，还有一个更根本的技术约束在重塑边缘AI的架构逻辑。

大模型推理的瓶颈不在计算，而在内存访问。自回归解码阶段，模型需要逐token生成输出，每生成一个token，都要重新读取全部模型权重和KV缓存。这意味着推理吞吐量本质上由内存带宽决定，而非算力峰值决定。

Arm对此有精准概括，即预填充阶段是计算密集型的，但逐token解码阶段反复访问KV缓存；随着并发用户增加，聚合缓存容量可能先于GPU算力成为限制因素。换句话说，不是GPU不够快，而是内存系统“喂”不上。

这一矛盾在边缘端更加尖锐。边缘设备的DRAM容量通常在4GB到16GB之间，而一个经过量化的10B参数模型，仅权重就需要约1.25GB存储空间（按4-bit量化计算）。加上KV缓存、运行时激活值、RAG检索到的文档嵌入和向量索引，工作集轻松突破边缘设备的内存预算。

一个具体的参照是：Phi Silica本地小语言模型在Windows 11系统中占用超过2.59GB硬盘空间，而Copilot + PC的最低硬件门槛已被推高到16GB内存和256GB存储。“小”模型尚且如此，更大规模的多模态模型对存储系统的压力可想而知。

Arm自身的硬件演进也在回应这一挑战。Ethos-U85 NPU性能较前代提升四倍，支持基于Transformer架构的模型，其架构设计的一个关键取向就是“最小化外部数据移动、将活跃张量保持在计算单元附近”。Armv9边缘AI计算平台搭载的Cortex-A320 CPU与Ethos-U85组合，可支持参数量超过10亿的端侧AI模型，同时集成了指针验证、分支目标识别和内存标记扩展等安全技术。

量化止于边界，存储始为中枢

量化是缓解内存压力的主要手段，但它的作用被广泛误解。

从FP32降至INT4，模型大小最多可缩减至原来的八分之一，10GB的模型可缩减至1.25GB。腾讯混元推出的HY-1.8B-2Bit模型通过2-bit量化实现等效约0.3B参数规模，实际存储占用仅约600MB。这些数字令人振奋，但量化并非没有代价。研究指出，量化LLM面临三个核心挑战：数值敏感度（微小的精度误差可能在注意力机制等敏感组件中被放大）、分布与缩放问题（难以预测的激活值和离群值会让一致性量化变得困难），以及不同层之间的差异。

更关键的是，量化降低的是模型权重的存储需求，却无法消除推理过程中产生的动态数据——KV缓存随序列长度线性增长，RAG检索的向量索引随知识库规模扩大，多轮对话的上下文状态需要持续保留。Arm明确指出：“即使经过量化，服务更大模型在内存层次结构中仍可能消耗数十到数百GB。”

这引出一个重要的认知转变：存储不再是被动的数据仓库，而是AI推理架构中的主动参与者。 在传统的“存储→DRAM→缓存→CPU/NPU→输出”数据路径中，每一步移动都消耗时间和能量。Arm提出的优化方向包括，模型放置（将常用模型保留在本地）、压缩（量化权重和AI资产）、本地检索（仅检索相关RAG上下文）、缓存/暂存（将热AI资产暂存在更快的内存中）。这些策略的共同目标，是在存储层级中实现“每一字节移动都产生最大智能价值”。

边缘AI的终局不是“把所有东西搬到边缘”，而是一个基于经济性和技术约束的工作负载放置问题。

Arm提出的“云—边—端”连续体框架将部署点划分为四个层级：云端（前沿/大型模型、数据中心存储）、边缘基础设施（区域/企业AI、本地存储）、高性能边缘（PC/手机/XR/机器人、LPDDR+UFS/NVMe）、低功耗边缘（工业/摄像头/可穿戴设备、SRAM+Flash）。每个层级有不同的功耗、容量、带宽、延迟、安全和成本约束。

选择哪个层级，取决于工作负载的特征。一个实时的工业视觉质检任务，延迟要求在毫秒级，数据量巨大且敏感，适合在高性能边缘甚至低功耗边缘执行。一个需要复杂推理的科研分析任务，模型规模远超边缘设备的承载能力，则应留在云端。而大多数日常交互——语音助手、本地文档RAG、个人化推荐——介于两者之间，最适合在边缘设备上本地执行，仅在能力不足时向上游升级。

这种“边缘优先、按需升级”的模式已经在实际部署中显示出效果。企业报告称，采用该架构后运营响应速度提升40%，云成本降低30%至50%。

系统协同设计，超越TOPS竞赛

Arm给出的公式值得深思：Compute × Memory × Storage × Data Movement。这不是加法，是乘法。任何一个维度的短板都会将整体系统效能拉低到该维度的水平。

其意义在于否定了“堆算力就能解决边缘AI问题”的线性思维，一个拥有100 TOPS算力但只有4GB DRAM的设备，在运行10B参数模型时，瓶颈不在NPU，而在内存容量；一个拥有充足内存但存储带宽不足的设备，在加载模型和RAG检索时会被I/O拖垮；一个各方面均衡但数据搬运路径冗余的设备，会在功耗和延迟上付出不必要的代价。

Arm的应对策略是系统级的。在硬件层面，从Cortex-M到Cortex-A的CPU谱系覆盖了从微瓦级到数瓦级的功耗范围，Ethos-U85 NPU在128到2048个MAC单元之间灵活扩展，同时保持20%的能效提升。在软件层面，KleidiAI与LiteRT、PyTorch ExecuTorch、ONNX Runtime和阿里巴巴MNN等主流框架深度集成，实现SME2的自动启用，让开发者无需额外工作即可获得AI性能提升。

Arm还将KleidiAI延伸应用到物联网领域，可实现高达70%的性能提升，并帮助超过2000万开发者无缝集成主流AI框架。在Llama.cpp上运行微软Tiny Stories数据集时，KleidiAI为新的Cortex-A320带来高达70%的性能提升。这种“零代码改动”的自动加速机制，是Arm区别于其他边缘AI方案的核心软件竞争力。

在工具层面，Arm AI Portal提供了模型浏览、量化筛选和设备兼容性匹配的能力，降低了从模型到部署的工程摩擦。

这些举措的共同指向是：边缘AI的竞争，正在从单点芯片性能的比拼，转向计算、内存、存储和数据搬运四者协同的系统能力较量。

从数据到Token的转变，表面上是AI输出形态的变化，深层是计算架构重心的迁移。当Token成为衡量AI价值的核心单位，系统的每一个环节，从存储介质的选择，到内存层级的划分，到数据搬运路径的优化，都必须围绕“以最低的系统成本生成最多有用Token”这一目标来重新设计。

今天，Arm本质上在为这场系统重构提供一个框架：不是问“云端还是边缘”，而是问“每个AI工作负载在哪里能最高效地交付”。这个问题的答案，不在某一块芯片的规格表里，而在计算、内存、存储与数据搬运的协同设计之中。