1. 端侧AI存储到底在解决什么问题1.1 从云端推理到端侧推理的存储逻辑转变过去两年做大模型推理绝大多数方案都是把模型放在云端终端只负责发请求、收结果。这个模式在演示阶段很美好一旦落到真实产品里问题就暴露了网络延迟不可控、用户隐私数据要出端、推理成本随调用量线性上涨。于是行业里越来越多团队开始把推理能力往端侧搬这就是端侧AI的核心驱动力。但端侧AI不是简单把模型文件拷到手机或车机上就完事了。它带来的第一个硬骨头就是存储。云端推理时模型权重放在服务器的大容量内存和高速固态盘里带宽和容量都不是瓶颈。端侧设备完全不同手机、平板、车机、IoT模组的存储空间有限闪存读写寿命有限功耗预算更是卡得死死的。模型动辄几个GB甚至十几个GB怎么放、怎么读、怎么在有限的内存里跑起来全是存储要回答的问题。江波龙这次在端侧AI存储上的进展本质上就是在回答这个问题。它不是一个单纯的“容量更大”的故事而是围绕端侧AI推理的实际数据流重新设计了存储介质的角色。我理解这件事的价值需要先搞清楚端侧AI推理时数据到底怎么流动。1.2 端侧AI推理的存储数据流拆解一个典型的端侧大模型推理过程数据流大致是这样的模型权重文件存放在闪存里推理启动时部分权重被加载到内存计算过程中KV Cache不断增长中间激活值在内存和缓存之间来回搬运最终输出结果。这里面有几个关键存储环节模型权重的存放介质通常是UFS或eMMC闪存容量从几GB到几十GB不等。权重是只读的但读取速度直接决定模型加载时间。KV Cache的存放位置这是推理过程中动态增长的部分对话越长占用越大。放在内存里最快但内存有限放到闪存里容量够但读写延迟高。中间激活值的搬运层与层之间的计算结果需要在内存和计算单元之间流转这部分对带宽敏感。用户数据的持久化聊天记录、个性化配置、RAG知识库的向量索引这些需要可靠存储。端侧AI存储要解决的核心矛盾就是闪存的容量和成本优势与内存的速度优势之间怎么平衡。江波龙的思路从公开信息和我对存储行业的理解来看是在UFS这个介质上做文章让闪存更接近内存的使用体验。1.3 为什么是UFS而不是eMMC这里必须解释一个关键选型。端侧设备常见的闪存有两种eMMC和UFS。eMMC是半双工读写不能同时进行命令队列是单队列并发能力弱。UFS是全双工支持多命令队列读写可以并行理论带宽是eMMC的好几倍。对于端侧AI推理来说模型加载时需要连续读取大量权重数据推理过程中又可能同时发生KV Cache的写入和权重的读取。eMMC的半双工特性在这里会成为瓶颈读写互相等待推理延迟抖动会很明显。UFS的全双工和多队列特性天然更适合这种混合读写负载。江波龙在UFS上的积累让它有能力针对端侧AI的场景做定制化优化。这不是简单地把UFS颗粒卖给客户而是从控制器固件、读写调度策略、温度管理等多个层面去适配AI推理的负载特征。注意选UFS还是eMMC不能只看带宽数字。端侧AI场景下读写混合负载的延迟稳定性比峰值带宽更重要。eMMC在纯顺序读场景下可能够用但一旦出现读写交织体验会断崖式下降。2. 江波龙端侧AI存储方案的核心技术点2.1 UFS在端侧AI中的角色重新定义传统UFS的定位是“高速大容量存储”主要服务于拍照、录像、应用安装这些场景。这些场景的特点是写入突发性强读取相对随机对延迟的容忍度较高。端侧AI推理的负载特征完全不同模型加载是超大块顺序读KV Cache是持续的小块随机写权重读取和Cache写入可能同时发生。江波龙方案的核心思路我判断是让UFS控制器具备一定的“负载感知”能力。具体来说可能包括几个层面的优化读写优先级动态调整当检测到模型加载的大块顺序读时临时提升读请求优先级减少推理启动等待时间。写缓存策略优化KV Cache的写入是持续的小块写如果每次都直接落盘闪存的写放大和延迟都会很难看。合理的做法是在控制器内部做写合并攒够一定量再写入闪存页。温度感知的调度端侧设备散热条件差UFS在高速读写时发热明显。如果温度过高触发降频推理延迟会突然飙升。江波龙在固件层面做温度预判和调度调整避免推理过程中出现性能断崖。这些优化听起来像是常规的存储固件工作但难点在于要针对AI推理的负载特征做精细调参。通用UFS固件不会为MoE架构的专家切换、KV Cache的增长模式做专门优化这就是定制化的价值所在。2.2 MoE架构对存储提出的特殊要求热词里出现了MoE架构这不是偶然的。MoE混合专家架构在端侧AI里越来越受关注因为它能在不显著增加计算量的前提下扩大模型参数量。但MoE对存储的挑战和稠密模型完全不同。稠密模型推理时每一层所有参数都要参与计算权重读取是确定性的、可预测的。MoE模型每次推理只激活部分专家哪些专家被激活取决于输入内容。这意味着权重读取模式是动态的、不可完全预测的。如果专家权重分散存储在闪存的不同位置每次专家切换都可能触发随机读取延迟会很难看。江波龙的方案如果要在MoE场景下站住脚必须在存储布局上做文章。我推测可能的做法包括专家权重的聚簇存储把经常被同时激活的专家权重放在闪存相邻的物理块里减少随机读取的寻址开销。专家权重的预加载策略根据历史推理记录预测下一轮可能激活的专家提前把权重从闪存读到内存缓存里。专家切换的流水线化在计算当前专家时后台异步加载下一个可能用到的专家权重把加载延迟藏到计算时间里。这些策略的实现需要存储控制器和推理引擎之间有某种程度的协同。江波龙作为存储厂商可能需要和AI芯片厂商或推理框架团队合作才能把这件事做透。2.3 端侧AI存储的容量与带宽平衡端侧设备的存储容量是有限的。一个7B参数的模型FP16精度下大约14GBINT8量化后约7GBINT4量化后约3.5GB。加上KV Cache、系统占用、用户数据128GB存储的手机跑端侧大模型空间并不宽裕。江波龙方案在容量上的考量我理解不是单纯堆容量而是提高“有效容量”。什么叫有效容量就是实际能用于AI推理的存储空间。这涉及到几个方面模型压缩与存储效率支持更高效的量化格式存储减少权重占用的同时不显著损失精度。KV Cache的分级存储把不常用的历史KV Cache从内存换出到闪存腾出内存给当前推理用。这需要闪存读写足够快换入换出不成为瓶颈。存储空间的动态分配AI推理、系统运行、用户数据之间的空间分配不是固定的可以根据使用场景动态调整。带宽方面UFS 3.1的理论带宽是2.9GB/sUFS 4.0翻倍到5.8GB/s。但理论带宽和实际推理能用的带宽是两回事。江波龙方案如果能在实际混合读写负载下保持较高的有效带宽对推理体验的提升会比峰值带宽数字更有意义。3. 端侧AI存储的实操部署与调优3.1 模型文件在UFS上的布局策略如果你正在做端侧AI部署模型文件怎么在UFS上摆放直接影响加载速度和推理稳定性。我踩过的坑是直接把模型文件当成普通文件拷贝到文件系统里结果加载时读取速度远低于UFS的理论带宽。原因在于文件系统的块分配策略。普通文件写入时文件系统可能把文件分散到不连续的物理块上读取时需要频繁寻址。对于几GB的模型文件这种碎片化会显著拖慢顺序读取速度。比较稳妥的做法是预留连续空间在分区阶段为模型文件预留连续的物理块区域避免运行时碎片化。使用直接I/O加载模型时绕过文件系统缓存直接读闪存减少一次内存拷贝。大块读取把读取请求的块大小调到UFS控制器的优化值通常是128KB或256KB太小会增加命令开销太大可能超出控制器缓存。# 查看UFS设备的基本信息 cat /sys/class/scsi_device/*/device/model cat /sys/block/sda/queue/optimal_io_size cat /sys/block/sda/queue/read_ahead_kb # 调整预读大小对模型加载这种顺序读场景有帮助 echo 2048 /sys/block/sda/queue/read_ahead_kb提示read_ahead_kb不是越大越好。设得太大随机读场景下会浪费带宽做无用预读。模型加载是顺序读可以设大一些如果同一设备上还有大量随机读写需要折中。3.2 KV Cache的存储分级实践KV Cache是端侧AI推理里最吃内存的部分。以7B模型为例FP16精度下每个token的KV Cache大约占用1MB左右取决于层数和隐藏维度。对话长度到2000 token时KV Cache就占用2GB内存。手机内存本来就不宽裕这部分压力很大。把KV Cache换出到UFS是必然选择但怎么换有讲究。我实测下来这几种策略各有适用场景策略做法优点缺点全量换出每轮对话结束把KV Cache全部写入UFS内存占用最低换入换出延迟高对话响应慢滑动窗口只保留最近N个token的KV Cache在内存内存占用可控长对话需要重新计算历史KV分层换出浅层KV Cache留内存深层换出平衡延迟和内存实现复杂度高压缩换出KV Cache量化后写入UFS减少存储带宽压力量化损失影响精度江波龙方案如果要在KV Cache上做优化我判断会从UFS的写入放大和延迟稳定性入手。KV Cache的写入是持续的小块写如果每次写都触发闪存页编程写放大和延迟都会很难看。合理的做法是在控制器内部做写聚合攒够一个闪存页再写入。3.3 MoE专家权重的加载优化MoE架构在端侧部署时专家权重的加载是最大的存储挑战。假设一个MoE模型有8个专家每次推理激活2个专家权重总量可能占模型总参数的70%以上。如果每次专家切换都要从UFS读取权重延迟会非常明显。我试过几种优化思路效果差异很大专家权重常驻内存把最常用的专家权重固定在内存里不参与换出。适合专家激活分布比较集中的场景。专家权重预取根据当前层的激活模式预测下一层可能激活的专家提前从UFS读取。需要推理引擎和存储层有接口。专家权重压缩存储在UFS里以压缩格式存储专家权重加载时解压。节省存储带宽但增加计算开销。# 伪代码专家权重预取的简单实现思路 class ExpertPrefetcher: def __init__(self, ufs_reader, num_experts): self.ufs_reader ufs_reader self.expert_usage [0] * num_experts self.prefetch_queue [] def record_activation(self, expert_id): self.expert_usage[expert_id] 1 def predict_next_experts(self, current_layer, top_k2): # 基于历史激活频率预测实际可以用更复杂的模型 sorted_experts sorted( range(len(self.expert_usage)), keylambda x: self.expert_usage[x], reverseTrue ) return sorted_experts[:top_k] def prefetch(self, expert_ids): for eid in expert_ids: if eid not in self.prefetch_queue: self.ufs_reader.async_read(eid) self.prefetch_queue.append(eid)注意预取不是免费的。预取错了会浪费UFS带宽预取对了才能藏住延迟。在专家激活分布比较均匀的场景下预取的命中率可能很低这时候不如不做预取把带宽留给确定性的读取。4. 端侧AI存储的常见问题与排查4.1 推理延迟忽高忽低的排查思路端侧AI推理最让人头疼的问题就是延迟不稳定。同样的模型、同样的输入有时候响应很快有时候卡顿明显。存储往往是罪魁祸首但容易被忽略。我整理了一个排查清单按优先级排序检查UFS温度温度过高触发降频是延迟抖动的常见原因。用cat /sys/class/thermal/thermal_zone*/temp查看温度如果接近阈值需要优化散热或降低读写强度。检查后台写入系统更新、日志写入、相册同步等后台任务会抢占UFS带宽。推理时如果后台在大量写入读请求会被拖慢。检查存储碎片长期使用的设备模型文件可能已经碎片化。重新整理存储或预留连续空间可以改善。检查读写交织如果KV Cache写入和权重读取同时发生UFS控制器需要在读写之间切换切换开销会导致延迟抖动。调整推理调度把读写错开可能有效。# 查看UFS读写统计 cat /sys/block/sda/stat # 字段含义读完成次数 读合并次数 读扇区数 读耗时(ms) 写完成次数 写合并次数 写扇区数 写耗时(ms) # 查看I/O调度器 cat /sys/block/sda/queue/scheduler # 端侧AI场景建议用none或mq-deadline减少调度开销4.2 模型加载失败的存储侧原因模型加载失败不一定是模型文件本身的问题存储侧的原因也很常见。我遇到过几次排查过程记录如下文件系统错误突然断电或异常卸载可能导致文件系统损坏模型文件读取时校验失败。用fsck检查修复。存储空间不足加载模型时需要临时空间做解压或格式转换空间不够会失败。预留至少模型大小20%的额外空间。UFS命令超时高负载下UFS命令可能超时导致读取失败。检查内核日志dmesg | grep ufs看是否有超时记录。权限问题模型文件权限设置不当推理进程没有读取权限。检查文件属主和权限位。4.3 端侧AI存储选型速查表场景推荐介质关键参数注意事项7B以下模型单次推理UFS 3.1顺序读1.5GB/s预留连续空间避免碎片7B-13B模型多轮对话UFS 4.0顺序读3GB/s随机读写延迟100usKV Cache分级存储控制内存占用MoE模型专家数4UFS 4.0 内存缓存随机读延迟50us专家权重聚簇存储预取策略调优多模型切换场景UFS 4.0容量256GB模型文件分区隔离避免互相干扰极端散热受限场景UFS 3.1降频使用温度70度主动限速避免触发硬件降频5. 端侧AI存储的后续演进方向5.1 存储与计算的进一步融合现在端侧AI的存储和计算还是相对分离的权重存在UFS里计算在SoC里数据通过总线搬运。这个模式的问题是搬运本身消耗时间和功耗。后续的一个方向是让存储介质具备一定的计算能力比如在UFS控制器里做简单的权重解压或格式转换减少搬到计算单元的数据量。这个方向行业里叫“存内计算”或“近存计算”目前还在早期阶段。江波龙作为存储厂商如果在控制器层面开放一些可编程能力让AI推理框架可以把部分预处理逻辑下推到存储端会是一个有意思的差异化点。5.2 端侧AI存储的标准化需求现在端侧AI存储的优化方案各家做各家的推理框架和存储之间没有标准接口。这导致存储厂商的优化很难被上层框架充分利用框架的调度策略也难以下达到存储层。如果行业能形成一套端侧AI存储的接口标准比如定义KV Cache换出换入的语义、专家权重预取的提示接口、存储负载状态的查询接口存储和推理的协同会顺畅很多。江波龙如果在标准制定上有所参与对它在这个领域的长期位置会有帮助。5.3 从手机到更多端侧形态端侧AI不只在手机里。车机、机器人、工业设备、智能家居中控都有端侧推理的需求。不同形态对存储的要求差异很大车机要求宽温、高可靠机器人要求低功耗、抗振动工业设备要求长寿命、数据保持能力强。江波龙在存储介质上的积累如果能针对不同端侧形态做定制化市场空间会比手机更大。我在实际项目里接触过车机端的AI推理需求温度范围从-40度到85度普通消费级UFS根本扛不住必须用宽温颗粒。这类场景的存储选型和手机完全是两个逻辑。提示端侧AI存储选型时先明确设备的工作环境温度和寿命要求再去看性能和容量。消费级颗粒在极端温度下数据保持能力会大幅下降不要为了省成本忽略这一点。5.4 存储寿命与AI推理负载的匹配闪存有写入寿命限制TLC颗粒通常几百到上千次擦写循环。端侧AI推理的写入主要来自KV Cache和日志如果每天写入量很大存储寿命会是个问题。我粗略算过一笔账假设KV Cache每天写入10GB128GB的UFS写入放大系数2.0每天实际写入闪存20GB。TLC颗粒1000次擦写循环总写入寿命128GB×1000128TB。每天20GB可以用约17年。看起来够用但如果写入放大控制不好或者设备寿命要求10年以上余量就不大了。江波龙方案如果在写入放大控制上有优化对端侧AI设备的长期可靠性会有实际价值。这个点普通用户感知不到但设备厂商和运营商很在意。5.5 端侧AI存储的测试与验证方法最后分享一些端侧AI存储的测试经验。存储厂商给的datasheet参数是理想条件下的实际端侧AI负载下的表现需要自己测。我常用的测试方法顺序读测试用dd或fio做128KB块大小的顺序读测模型加载速度。混合读写测试用fio模拟KV Cache写入和权重读取同时发生的场景测延迟分布而不是平均延迟。温度循环测试在高温和低温下分别跑推理负载看性能衰减和恢复情况。长期写入测试连续写入几天看写入速度是否下降判断垃圾回收策略是否合理。# fio混合读写测试示例 fio --namemixed --rwrandrw --rwmixread70 --bs4k \ --size1G --numjobs4 --runtime300 \ --time_based --group_reporting \ --latency_percentiles99.99这个测试模拟70%读30%写的混合负载4KB块大小4个并发任务。重点看99.99分位的延迟而不是平均值。端侧AI推理对尾延迟敏感平均延迟好看但尾延迟高用户体验照样差。我在实际项目里发现很多UFS在混合读写下的尾延迟比顺序读差一个数量级。江波龙如果在这个指标上有优势对端侧AI推理的流畅度会有明显帮助。选型时不要只看顺序读带宽混合读写尾延迟才是端侧AI的真实瓶颈。