端侧AI加速落地背后：存储如何重构终端算力

深度解析 | 端侧AI加速落地，存储如何重构终端算力？

最近半年我一直在折腾端侧AI推理，把几个主流的大语言模型压到手机和边缘盒子上去跑。调优过程里发现一个很反直觉的现象：真正卡住推理速度的，往往不是NPU算力不够，而是存储子系统在拖后腿。模型权重从闪存搬到内存、再从内存喂给计算单元，每一层搬运都在消耗时间、功耗和带宽，而这些开销在GPU服务器上不明显，在端侧却会被放大得很厉害。

这篇文章想聊清楚一件事：端侧AI要加速落地，存储是怎么变成关键变量的。我会从实际碰到的瓶颈出发，拆解模型加载、推理访存、介质选型、分层调度这几个环节，讲一讲存储如何重构本就有限的终端算力预算。适合正在做端侧模型部署的算法工程师、嵌入式开发，以及想理解端侧AI成本结构的产品经理阅读。

1. 算力叙事之外，端侧推理的隐形瓶颈在数据搬运

1.1 为什么模型变大的速度快过算力升级

过去几年，端侧NPU的TOPS数字涨得很快。单看峰值算力，很多移动芯片已经能跑百TOPS级别，理论上足够支撑几十亿参数模型的推理。可实际部署时你会发现，模型推理帧率远达不到理论值。问题不在于计算单元算不过来，而在于数据在存储层次之间搬运的速度，远远跟不上计算单元的消费速度。

这里有个核心概念叫算术强度（arithmetic intensity），也就是每次数据访问能支撑多少次计算。大模型推理的权重复用度其实并不高，尤其在小batch场景下，每个权重数据被读取后可能只参与一两次运算就丢弃。端侧为了省内存往往用batch为1的方式推理，权重要从存储里反复读取，模型的访存需求就会暴涨。

我做过一次粗算：一个70亿参数的模型，如果按INT8量化，权重约7GB。推理每条token大概要走一遍全部权重，也就是7GB的数据搬运。假设端侧存储带宽是50GB/s，仅权重搬运就需要140毫秒。而实际上端侧设备很少能达到这个带宽，瓶颈就藏在这里。算力再高，数据喂不进去，加速就无从谈起。

1.2 访存墙与功耗墙：端侧场景为什么更吃亏

服务器场景计算密度高、带宽资源充裕，访存墙问题可以通过大规模并行和高速互连来缓解。端侧设备则完全不同，功耗上限决定了频率不能拉高，内存通道数量受限，闪存接口带宽也在一个相对保守的范围。算力与带宽的比例关系在端侧被严重放大，这是底层的物理约束。

同时，功耗墙上存储也扮演了重要角色。很多人以为NPU计算单元才是功耗大头，实际测试发现，从DDR读取权重的能耗往往不比MAC运算低多少。以某个端侧推理实验为例，单纯搬运权重数据消耗的平均功耗能占到整机推理功耗的三到四成。这就是“数据搬运不是免费的”最直接的体现。

换句话说，端侧AI加速不只是在算力芯片上下功夫，存储子系统的容量、带宽、功耗、寿命四个维度共同决定了实际可用算力。这也是我这里说的“存储重构终端算力”的含义——通过优化数据的存放位置、读取路径和搬运策略，可以把有限的计算资源真正释放出来。

2. 拆开端侧AI的存储链路：从冷启动到稳态推理的三个阶段

要理解存储怎么影响端侧AI，不能只看某一个环节，我习惯把它拆成三个阶段：冷启动加载、推理访存、长期反复读写。每个阶段的瓶颈完全不同，优化方向和手段也各不一样。

2.1 阶段一：模型体积落地，容量是入场券

端侧模型第一步是要把权重从非易失存储（通常是UFS或eMMC类闪存）搬到内存里。这个阶段的核心痛点是容量。模型文件动辄数GB，而端侧内存既要给系统UI、常规App留空间，又要给推理运行时和大小的KV Cache预留buffer，可用空间非常紧张。

容量不足直接影响模型选择。我在一块8GB内存的测试板上跑7B模型，光权重就占了7GB，内存几乎耗尽，系统频繁触发回收机制，推理偶尔被杀死。换成4B模型后权重降到4GB左右，再配合量化才勉强稳定。这里建议实际部署前先用cat /proc/meminfo之类的工具排查可用内存水位，尤其要看Cached和MemFree两个指标，避免模型加载后引发系统级抖动。

闪存本身的速度也会影响冷启动耗时。我实测过从UFS 3.1和UFS 4.0分别加载同样体积的模型，后者能缩短约三分之一的总加载时间。对于客服机器人类应用，冷启动时间直接影响用户第一体验，这个差距不能忽略。

2.2 阶段二：KV Cache与中间激活，带宽是加速器

进入稳态推理后，每次token生成都需要处理两部分数据：一是模型权重，二是对话历史累积的KV Cache。KV Cache是中间激活值的缓存，长度随对话增长而线性膨胀，访问频率极高，是推理访存的主力之一。

KV Cache对容量和带宽都提出了要求。假设上下文长度是4096，层数是32，隐藏维度是4096，按每个key/value矩阵各占一份计算，再乘上精度字节数和batch大小，仅KV Cache占用就有好几GB。这个数字还只是中等上下文场景，实际部署长上下文模型时会更大，内存预算经常被它占去大头。

KV Cache的访问模式也和权重不同。权重是一次性读取顺序流过，KV Cache则是按位置索引随机访问，缓存命中率对推理延迟的影响非常直接。如果KV Cache被挤到Swap分区，推理延迟会急剧恶化，我试过在内存不足时强制开Swap跑模型，结果每条token的生成时间直接翻了几倍。这个阶段优化的核心是提高随机访问带宽和命中率，通常要考虑KV Cache的内存固定分配，避免被操作系统换出。

2.3 阶段三：权重反复读取，寿命与QoS的持久战

持续推理意味着同一个模型权重会在存储层次里被反复读取成千上万次。对这些权重来说，闪存只负责首次加载，后续主要靠DDR或SRAM缓存。但端侧内存紧张时，系统可能把部分不活跃页写回闪存，从而触发频繁换入换出，这会对闪存寿命产生额外压力。

闪存寿命要考虑Program/Erase周期和写入放大两个指标。用户可能在手机上更新模型文件，每次部署新版本都会重写数GB数据，如果闪存的预留空间（over-provisioning）不足，写入放大系数升高，会加速介质老化。某些低端边缘盒子使用的eMMC写入寿命低于UFS，长时间反复跑在线推理更新尤其明显。

QoS方面同样和存储相关。推理任务如果遭遇闪存GC（垃圾回收）的写阻塞，延迟可能瞬间飙升到几百毫秒，产生肉眼可见的卡顿。曾有开发者专门跑到某个设备上看实时日志，发现推理延迟尾部增长基本都集中在两类事件上，一是闪存后台任务抢带宽，二是其他应用IO突发干扰。优化思路是把模型权重、系统数据和用户数据放到不同的存储分区或物理介质上，IO调度上尽量做隔离。

3. 存储介质选型：别把所有闪存都当成一回事

端侧设备的存储介质的种类通常比PC更复杂：内存有LPDDR4x、LPDDR5、LPDDR5X，非易失存储有eMMC、UFS、SD卡级别的低速介质，未来还可能看到MRAM、ReRAM这类新非易失内存。介质选型直接决定了模型能不能跑、跑多快、寿命能撑多久。

3.1 三种主流介质的真实边界

我先给一张自己整理的对比表，方便你快速定位每种介质的定位：

注意：以上带宽是我在测试环境测得的中位数据，不同厂商、不同固件版本会略有差异。选型时建议以实际板级测试为准。

UFS和LPDDR的分工非常清晰：UFS管持久化和冷启动加载，LPDDR管运行时数据。许多端侧AI优化方案会把部分中等热度的权重常驻在UFS里、按需流式加载到LPDDR，而不是一次性全部装入。这种方式对UFS的顺序读带宽提出了更高要求，UFS 4.0的高带宽就显得更重要了。

3.2 接口协议与队列深度：真实带宽不是标称值

很多人只看接口标称带宽，实际跑起来却发现数据远低于预期。原因在于真实带宽是排队延迟、块大小、并发队列深度共同作用的结果。UFS和eMMC都是命令队列模型，区别是UFS支持比较深的队列，连续小块的随机读能力明显强于eMMC，这在大模型权重分块加载时很关键。

举例来说，模型权重通常以文件形式存放，而文件系统会把它拆成多个块。如果文件碎片化严重，读取时要不断跳转寻址，随机性能就成为瓶颈。同样的UFS 3.1芯片，顺序读可以到1500MB/s，但纯随机4KB读可能只有几百MB/s。量化模型权重建议用连续大文件保存，并且提前做文件系统碎片整理，能显著提升加载速度。

我曾在一个部署任务里把权重打成一个大.safetensors文件，顺序加载时间比原来几十个小文件的方式缩短了一半以上。这背后是文件系统读策略的差异，线性预读在大文件上效率极高，碎片化则会让预读彻底失效。

3.3 从介质角度看模型部署的分层适配

选介质的同时也是在给模型选择存储层级。我的经验是三层划分比较实用：

• 热层：常驻LPDDR的权重和KV Cache，延迟最低，功耗最敏感；
• 温层：UFS中的模型主文件，按需加载到热层，要求高顺序读带宽；
• 冷层：eMMC或SD卡中的备份模型、历史日志、静态数据，容量优先，速度次之。

热层容量毕竟有限。假如某设备只有6GB可用内存，7B模型无法整载，就可以考虑把前几层Transformer块的权重放在UFS里，推理时异步预取到LPDDR。这个“分块驻留”策略我在测试板上跑通过，延迟略有上升，但总算能在低端设备上载入大模型。关键是让存储的带宽和延迟特性匹配上模型的实际访存模式。

4. 重构终端算力的分层存储策略，我实测过的几条路径

聊完介质，再说实际怎么优化。以下几条路径都是我在开发板、手机上实际验证过的方案，供你参考时直接套用，比只谈理论实用得多。

4.1 分层放置：热权重驻留、冷权重流式加载

我在一个8GB设备上部署14B量化模型（约8GB权重）时，一次性加载会直接爆内存。后来采取分段预热策略：启动时先加载模型前几层的权重和嵌入表，后几层权重留在UFS里，推理过程中用预取队列提前把即将用到的层搬到内存。

预取逻辑的关键是“超前量”。推理引擎逐层执行Transformer块，权重使用顺序是确定的，只要在当前层计算的同时预取下一层权重，就能把UFS读取延迟隐藏在计算后面。实测中我对一个扇区大小做对齐后，流式加载带来的停顿基本可以忽略，单token延迟只增加了不到百分之八，但内存峰值需求下降了百分之四十多。

如果你也在做类似尝试，建议把预取队列深度设成两层到三层，太浅容易被UFS的调度抖动打穿，太深又会导致内存里堆积过多临时块。这个参数往往需要结合具体闪存的队列延迟来调，直接抄别的项目的设置不一定合适。

4.2 模型文件与数据区的IO隔离

文件碎片和并发IO对推理延迟的影响，比很多人想象的大。有一次我在设备上跑稳定推理时，同时开启了一个下载任务，结果推理速度掉了一半多。排查后发现，下载任务写入的位置和模型文件分区完全重叠，闪存一边服务随机读请求一边处理写入，GC被频繁触发，排队时间直线拉长。

之后我把模型文件放在一个独立分区，同时调整内核IO调度策略，把推理进程的IO优先级调到最高。再跑同样的下载场景，推理速度掉幅控制在百分之五以内。这个优化成本极低，效果却非常明显，特别适合做端侧AI产品化的场景。

如果你不想动分区，还可以在部署阶段把模型权重提前缓存到全内存的tmpfs里。这样推理过程完全不经过闪存，代价是模型加载时间变长，适合对启动时间不敏感但推理延迟要求高的场景。

4.3 量化、稀疏化带来的存储红利不止是容量

量化对存储的贡献通常被简单理解成“模型变小了，内存省了”，实际上它对带宽和功耗的帮助同样显著。权重从FP16降到INT8，每次读取的数据量减半，带宽占用和搬运能耗自然同步减少。我实测一个视觉模型从FP16换到INT8后，帧率提升了约15%，其中算力提升之外的带宽收益占了一多半。

稀疏化对存储布局的影响更有趣。权重稀疏化之后，可以直接用稀疏格式（比如CSR或bitmask压缩）存储，跳过零值块可以节省带宽。但要注意，稀疏格式在存储里往往不再连续，随机读取更多，对闪存反而可能不友好。我的建议是：如果目标是改善存储带宽效率，优先看量化；如果目标是压缩闪存容量，再考虑稀疏化。

运行时如果动能关闭权重缓存，可以借助Linux的mlock把关键页面锁定在内存里。我发现很多系统自带的核心控件都会在内存压力时收缩缓存，推理页面被换出的概率远高于预期。用mlock能有效避免这类抖动，但记得预留足够内存，否则反过来造成系统OOM。

4.4 碎片化管理：别让系统把推理性能悄悄吃掉

文件系统碎片是端侧AI最容易忽视的隐性杀手。闪存本身是随机读友好的，但文件系统映射碎片却会破坏预读机制。我用fio测过一次碎片化前后UFS的顺序读吞吐，从正常情况的1400MB/s掉到了不足900MB/s，差距接近三分之一。

处理方案按场景分两类：如果设备有root权限，可以在部署前执行一次干净的镜像写入，保证模型文件在闪存上是连续大块；如果设备不可控，建议在应用层将模型文件看作是“只读大文件”，并通过顺序流式读取的方式编码，尽量避免大量seek。部分文件系统提供了固定预读窗口，可以利用它将碎片影响降到最低。

5. 从硬件协同看存储为算力松绑的下一步

端侧AI的存储优化不会停留在软件补丁层面，硬件层面的协同设计会越来越重要。目前看到几个值得关注的方向，对存储介质和接口协议的演进影响很深。

5.1 混合介质与扩展内存的边界

LPDDR容量和成本始终有限，但推理场景对容量的需求又很大。未来端侧设备可能会走向混合介质方案：把性能要求极高的KV Cache放在LPDDR或SRAM附近，把大体积权重放在带宽接近内存、但成本更低的介质上。这种分层混合本质上是在算力与预算之间做更细的权衡。

CXL类扩展内存技术在高性能计算领域已经很成熟，在端侧设备上因为功耗封装等原因尚难落地，但思路是相通的：通过更高效的地址映射和缓存一致性协议，让多样存储介质协同为计算单元服务。未来端侧如果出现类似“可扩展统一内存”，存储对算力的重构效应会更明显。

5.2 软件侧与介质侧需要同时转向数据流水线思维

很多优化方案到今天还在用“把模型装进内存”的静态思维，但端侧AI长期运行的场景更适合“数据流水线”思维：权重按需流动、KV Cache动态分配、存储层级间自动迁移热度。这个思路对推理引擎、文件系统和介质固件都提出了新要求。

例如，推理引擎可以主动向存储层暴露访问模式，而不是把存储当成普通块设备。媒体侧（尤指UFS/FW调度器）可以配合预取提示做相应调整。这套软硬协同方案在业内已有雏形，主控芯片已经能执行简单的IO优先级策略，未来如果能感知到推理的层切换时序，就能提前做GC和预取规划，把尾延迟降到更低。

这个方向给我的直觉是：端侧AI的下一轮性能提升，未必全部来自算力芯片的制程红利，存储与计算的协同优化会释放出很大空间。谁能把数据流水线设计得更顺滑，谁就能在相同硬件条件下跑出更高的真实推理吞吐。

最后再分享一点个人经验：调试端侧AI性能时，别急着调模型和算子，先看存储层的带宽分布与IO占用率。我在很多项目里发现，花一个下午优化访存模式，收益常常比花一周调参与量化更直接。存储看似不起眼，却经常是端侧AI落地时真正决定成败的环节。