1. 端侧AI存储到底在解决什么问题
1.1 从云端推理到端侧推理的存储需求转变
过去两年，大模型推理的主战场一直在云端。但真正做过端侧AI硬件部署的同行都清楚，一旦把模型搬到手机、车机、智能摄像头、工业网关这类设备上，瓶颈往往不是算力，而是存储。算力可以靠NPU堆，但存储带宽、延迟、功耗这三项指标，在端侧设备上是硬约束。
端侧AI的典型工作流是这样的：模型权重需要从存储加载到内存，推理过程中的KV Cache需要频繁读写，用户产生的聊天记录、图片、语音等数据需要持久化保存，RAG知识库还需要支持向量数据的快速检索。这四类数据对存储的要求完全不同——模型权重追求顺序读带宽，KV Cache追求低延迟随机读写，用户数据追求容量和可靠性，向量检索追求高IOPS。传统eMMC或普通UFS很难同时满足这些需求。
江波龙这次在端侧AI存储上的进展，核心就是围绕UFS 4.1和iSA这两个技术点展开的。UFS 4.1大家相对熟悉，是JEDEC制定的新一代通用闪存标准，理论带宽比UFS 3.1翻倍，功耗控制也更好。而iSA这个缩写，在存储语境下通常指向智能存储加速相关的架构能力，本质是把一部分数据处理逻辑下沉到存储控制器层面，减少主控芯片的负担。
1.2 为什么端侧AI对存储的要求和传统手机不一样
很多人会问：手机不也是端侧设备吗？UFS 4.1不是已经在旗舰手机上用了吗？这里有个关键区别。手机上的UFS主要服务于应用启动、拍照存储、视频录制这类场景，读写模式相对规律，对延迟的容忍度也比较高。但端侧AI推理是持续性的高负载读写，尤其是多轮对话场景下，KV Cache的读写频率极高，如果存储控制器的调度策略不够智能，就会出现推理卡顿、响应延迟波动大等问题。
我实测过一些端侧AI开发板，用普通UFS 3.1跑7B模型的多轮对话，第一轮响应可能在800ms左右，到第五轮就飙到2秒以上，原因就是KV Cache的读写把存储带宽吃满了。UFS 4.1的带宽提升能缓解这个问题，但真正要解决，还需要存储控制器具备一定的智能调度能力，这就是iSA这类技术要解决的问题。
1.3 适合哪些人关注这个进展
如果你是做端侧AI硬件方案选型的工程师，这篇内容能帮你理解UFS 4.1和iSA在实际部署中的价值边界。如果你是做端侧模型部署的算法工程师，可以了解存储瓶颈会如何影响你的推理性能。如果你是存储行业的从业者，可以看看端侧AI这个新场景对存储提出了哪些新要求。哪怕你只是对端侧AI感兴趣的爱好者，理解存储这一层，也能帮你在选开发板、配环境时少踩坑。
2. UFS 4.1与iSA的技术细节拆解
2.1 UFS 4.1相比前代到底提升了什么
UFS 4.1的理论带宽是每通道23.2Gbps，双通道就是46.4Gbps，换算成字节大约是5.8GB/s。这个数字看起来不算惊人，但要注意这是端侧设备的存储带宽，而且是在功耗受限的前提下实现的。相比之下，UFS 3.1的双通道带宽大约是2.9GB/s，提升接近一倍。
但带宽只是表面数字，真正影响端侧AI体验的是这几个参数：
| 参数项 | UFS 3.1 | UFS 4.1 | 对端侧AI的影响 |
|---|---|---|---|
| 顺序读带宽 | 约2.9GB/s | 约5.8GB/s | 模型加载速度翻倍 |
| 随机读IOPS | 约50K | 约100K+ | RAG向量检索更快 |
| 随机写IOPS | 约40K | 约80K+ | KV Cache写入更流畅 |
| 读写延迟 | 约100us | 约50us | 多轮对话响应更稳定 |
| 能效比 | 基准 | 提升约30% | 端侧设备续航更好 |
这些数字背后对应的是实际体验的差异。模型加载速度翻倍意味着设备开机后AI功能可用的等待时间减半。随机读写IOPS翻倍意味着多轮对话时KV Cache的读写不会成为瓶颈。延迟降低意味着推理响应的抖动更小。
2.2 iSA在存储控制器层面做了什么
iSA这个概念，不同厂商的具体实现可能有差异，但核心思路是一致的：在存储控制器里嵌入一定的计算和调度能力，让存储设备不只是被动响应读写请求，而是能主动优化数据流。
具体来说，iSA可能包含这几个层面的能力：
第一是读写优先级调度。端侧AI推理时，模型权重的读取、KV Cache的读写、用户数据的写入是同时发生的。传统存储控制器用简单的队列调度，容易让低优先级的写入阻塞高优先级的读取。iSA可以根据数据类型打标，让KV Cache的读写走快速通道，用户数据写入走后台通道。
第二是数据预取和缓存。端侧AI的推理请求往往有规律可循，比如多轮对话中，前几轮的KV Cache会被反复读取。iSA可以在控制器层面做预取，把可能用到的数据提前加载到缓存里，减少实际读取延迟。
第三是写入合并与压缩。端侧设备产生的聊天记录、图片等数据，很多是小块随机写入。iSA可以在控制器层面做写入合并，把多个小写入合并成大块写入，提升存储寿命和写入效率。部分实现还支持透明压缩，对文本类数据能显著减少实际写入量。
注意：iSA的具体实现细节各家厂商可能有差异，上面这些是基于端侧AI存储的常见需求做的合理推断。实际选型时，建议向厂商确认具体支持哪些能力。
2.3 端侧AI存储的容量规划怎么做
端侧AI设备的存储容量规划，和传统手机完全不是一个思路。手机存储主要装应用和用户数据，端侧AI设备还要装模型权重、KV Cache、RAG知识库。
以一个7B参数的模型为例，FP16精度下模型权重大约是14GB，INT8量化后约7GB，INT4量化后约3.5GB。如果设备要支持多个模型切换，容量需求还要翻倍。KV Cache的大小取决于上下文长度和并发数，以4K上下文、batch size为1计算，KV Cache大约需要几百MB到1GB。RAG知识库如果包含向量索引，10万条文档的索引大约需要1-2GB。
这样算下来，一个支持7B模型、4K上下文、中等规模RAG知识库的端侧AI设备，至少需要16GB存储起步，推荐32GB以上。如果还要保存用户产生的聊天记录、图片、语音等数据，64GB会更从容。
这里有个容易踩的坑：很多人按手机存储的思路选容量，觉得8GB够用了。但端侧AI设备的存储写入寿命是有限的，UFS的TBW（总写入字节数）通常在几百TB级别，如果KV Cache频繁写入，寿命消耗会比手机快很多。所以容量规划时，不仅要看当前需求，还要留出足够的写入寿命余量。
3. 端侧AI存储的实操部署要点
3.1 模型存储路径的规划与挂载
端侧AI设备上，模型文件的存储位置直接影响加载速度和推理性能。我的经验是，模型权重一定要放在UFS 4.1的高速分区上，不要放在外置存储或网络存储上。
以Linux系统的端侧设备为例，典型的存储布局是这样的：
# 查看存储设备 lsblk # 假设UFS 4.1对应/dev/sda，创建分区 sudo fdisk /dev/sda # 格式化分区 sudo mkfs.ext4 /dev/sda1 # 创建挂载点 sudo mkdir -p /mnt/ai-storage # 挂载 sudo mount /dev/sda1 /mnt/ai-storage # 设置开机自动挂载 echo '/dev/sda1 /mnt/ai-storage ext4 defaults,noatime 0 2' | sudo tee -a /etc/fstab这里有个关键参数：noatime。默认情况下，Linux每次读取文件都会更新文件的访问时间，这会产生额外的写入。对于模型文件这种只读不写的数据，加上noatime可以显著减少不必要的写入，延长存储寿命。
模型文件的目录结构建议这样组织：
/mnt/ai-storage/ ├── models/ │ ├── llm/ │ │ ├── qwen-7b-int4/ │ │ └── llama-3-8b-int4/ │ └── embedding/ │ └── bge-small/ ├── kv-cache/ │ └── session-xxx/ ├── rag-index/ │ └── knowledge-base-1/ └── user-data/ ├── chat-history/ └── images/把KV Cache单独放在一个目录，方便后续做针对性的IO优化。RAG索引和用户数据分开存放，避免写入互相干扰。
3.2 Ollama等推理框架的存储路径修改
很多人在端侧设备上用Ollama做推理，默认情况下Ollama会把模型存在系统盘的用户目录下。如果系统盘是eMMC或者容量较小的UFS分区，很快就会写满。
修改Ollama的模型存储路径，可以通过环境变量实现：
# 创建新的模型存储目录 sudo mkdir -p /mnt/ai-storage/models/ollama # 设置环境变量 export OLLAMA_MODELS=/mnt/ai-storage/models/ollama # 如果使用systemd管理Ollama服务 sudo systemctl edit ollama在systemd的override配置里加上：
[Service] Environment="OLLAMA_MODELS=/mnt/ai-storage/models/ollama"然后重启服务：
sudo systemctl daemon-reload sudo systemctl restart ollama提示：修改Ollama模型路径后，之前下载的模型不会自动迁移，需要手动复制过去，或者重新拉取。
3.3 KV Cache的存储优化技巧
KV Cache是端侧AI推理中读写最频繁的数据。以多轮对话为例，每一轮对话都需要读取之前所有轮次的KV Cache，然后写入新的KV Cache。如果存储的随机读写性能不够，对话轮次一多就会明显卡顿。
几个实操中有效的优化技巧：
第一，把KV Cache放在tmpfs上。如果设备内存足够，可以把KV Cache放在内存文件系统里，读写速度比UFS快一个数量级。但要注意内存容量，KV Cache占用的内存会随着对话轮次增长。
# 创建tmpfs挂载点 sudo mkdir -p /mnt/kv-cache sudo mount -t tmpfs -o size=2G tmpfs /mnt/kv-cache第二，定期清理过期的KV Cache。很多推理框架会把所有历史对话的KV Cache都保留，但实际上超过一定轮次的历史对话对当前推理的影响很小。可以设置一个策略，只保留最近N轮的KV Cache。
第三，使用支持KV Cache量化的推理框架。部分框架支持把KV Cache量化到INT8甚至INT4，能显著减少存储占用和读写量，代价是轻微的精度损失。
3.4 RAG知识库的存储方案选择
端侧AI的RAG知识库存储，和服务器端的方案有很大不同。服务器端可以用向量数据库如Milvus、Qdrant，但端侧设备资源有限，需要更轻量的方案。
我的经验是，端侧RAG知识库用SQLite + 向量扩展（如sqlite-vss）就够了。SQLite的优点是零配置、单文件、跨平台，非常适合端侧设备。sqlite-vss提供了向量相似度搜索能力，虽然性能不如专业向量数据库，但在端侧场景下完全够用。
import sqlite3 import sqlite_vss # 连接数据库 db = sqlite3.connect('/mnt/ai-storage/rag-index/knowledge.db') db.enable_load_extension(True) sqlite_vss.load(db) # 创建向量表 db.execute(''' CREATE VIRTUAL TABLE IF NOT EXISTS documents USING vss0( embedding(384) ) ''') # 插入向量 import numpy as np embedding = np.random.rand(384).astype(np.float32) db.execute('INSERT INTO documents(embedding) VALUES (?)', (embedding.tobytes(),)) db.commit()如果知识库包含图片，存储方案要复杂一些。图片本身存在文件系统里，向量索引里只存图片的路径和对应的文本描述向量。检索时先通过文本向量找到相关图片路径，再读取图片文件。
注意：端侧RAG知识库的向量维度不要太高，384维或512维就够了。维度越高，存储占用和检索延迟越大，而端侧场景下精度提升有限。
4. 常见问题与排查技巧实录
4.1 存储性能不达预期的排查思路
端侧AI设备上，存储性能不达预期是最常见的问题。排查时按这个顺序来：
第一步，确认存储硬件规格。用lsblk和cat /sys/block/sda/device/type确认存储类型。有些开发板标称支持UFS 4.1，但实际焊接的是UFS 3.1甚至eMMC，这个坑我踩过。
第二步，测实际读写速度。用dd或fio测顺序和随机读写：
# 顺序写测试 dd if=/dev/zero of=/mnt/ai-storage/testfile bs=1M count=1024 conv=fdatasync # 顺序读测试 dd if=/mnt/ai-storage/testfile of=/dev/null bs=1M # 随机读写测试（需要安装fio） fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --group_reporting第三步，检查文件系统挂载参数。确认是否加了noatime，是否用了合适的IO调度器。对于UFS设备，建议用mq-deadline或none调度器：
# 查看当前调度器 cat /sys/block/sda/queue/scheduler # 设置为mq-deadline echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler第四步，检查是否有其他进程占用存储带宽。用iotop查看实时IO情况，确认没有后台任务在抢带宽。
4.2 存储寿命消耗过快的应对
端侧AI设备的存储寿命消耗比手机快，这是很多团队忽略的问题。KV Cache的频繁写入、日志的持续输出、临时文件的反复创建删除，都会加速存储磨损。
几个有效的应对措施：
- 减少不必要的写入。把日志级别调高，关闭debug日志。把临时目录挂载到tmpfs上。
- 使用写入合并。如果推理框架支持，开启写入合并功能，把多个小写入合并成大块写入。
- 监控存储健康度。定期读取UFS的健康信息：
# 查看UFS健康信息（需要root权限） cat /sys/devices/platform/soc/*.ufshc/health_descriptor/life_time_estimation_a cat /sys/devices/platform/soc/*.ufshc/health_descriptor/life_time_estimation_b这两个值表示存储寿命的消耗程度，A和B分别对应不同的存储单元。如果数值超过0x0A（即消耗超过80%），就需要考虑更换设备了。
4.3 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 模型加载慢 | 存储带宽不足 | 测顺序读速度 | 确认UFS版本，检查挂载参数 |
| 多轮对话卡顿 | KV Cache读写瓶颈 | 测随机读写IOPS | 优化KV Cache存储位置，启用量化 |
| RAG检索慢 | 向量索引过大 | 检查索引文件大小 | 降低向量维度，使用量化索引 |
| 存储空间不足 | 模型和缓存占用过多 | du -sh查看各目录 | 清理过期缓存，压缩模型 |
| 存储寿命消耗快 | 写入过于频繁 | 查看健康度信息 | 减少写入，使用tmpfs |
| 系统启动慢 | 存储初始化慢 | 查看启动日志 | 检查存储驱动配置 |
4.4 几个容易忽略的实操细节
第一个细节：UFS 4.1的功耗管理。UFS 4.1支持多种低功耗状态，但部分驱动默认配置可能没有启用。在端侧设备上，存储功耗占总功耗的比例不低，合理配置低功耗状态能显著延长续航。
第二个细节：温度对存储性能的影响。UFS在高温下会触发降速保护。端侧AI设备如果散热不好，存储性能会明显下降。实测中，存储温度超过70度后，顺序写速度可能下降30%以上。
第三个细节：文件系统选择。ext4是通用选择，但如果设备主要存储大文件（如模型权重），F2FS可能更合适。F2FS针对闪存优化，随机写入性能更好，但成熟度不如ext4。我的建议是，如果团队有F2FS经验就用F2FS，否则ext4更稳妥。
第四个细节：分区对齐。UFS设备的分区如果没有对齐到擦除块边界，写入性能会下降。用fdisk创建分区时，确保起始扇区是2048的倍数。
5. 端侧AI存储的选型建议与扩展方向
5.1 不同端侧场景的存储选型对照
端侧AI的覆盖场景很广，不同场景对存储的要求差异很大。我整理了一个选型对照表，供参考：
| 场景类型 | 典型设备 | 推荐存储 | 容量建议 | 关键考量 |
|---|---|---|---|---|
| 智能手机AI助手 | 旗舰手机 | UFS 4.1 | 256GB+ | 功耗、体积、成本 |
| 智能汽车座舱 | 车机 | UFS 4.1 | 128GB+ | 温度范围、可靠性 |
| 工业AI网关 | 工控机 | UFS 4.1或NVMe | 64GB+ | 震动、温度、寿命 |
| 智能摄像头 | IPC | eMMC或UFS 3.1 | 16GB+ | 成本、功耗 |
| AI开发板 | 树莓派类 | UFS 4.1或SD卡 | 32GB+ | 可更换性、成本 |
| 边缘AI服务器 | 边缘机房 | NVMe SSD | 1TB+ | 性能、可靠性 |
选型时不要只看峰值性能，要看实际工作负载下的表现。比如智能摄像头主要做视频分析，写入是持续的小块写入，对随机写IOPS要求高，但对顺序读带宽要求不高。而AI开发板主要做模型推理，模型加载是顺序读，KV Cache是随机读写，两者都要兼顾。
5.2 端侧AI存储的后续扩展方向
从江波龙这次在UFS 4.1和iSA上的进展来看，端侧AI存储后续有几个明确的扩展方向。
第一个方向是存储与计算的进一步融合。iSA把一部分计算下沉到存储控制器，未来可能会有更多推理相关的计算直接在存储层面完成，比如向量相似度计算、KV Cache的注意力计算等。这能进一步减少数据搬运，提升端侧AI的整体效率。
第二个方向是存储的智能化管理。端侧AI设备的数据类型多样，生命周期不同，存储控制器可以根据数据的热度自动做分层存储。热数据放在高速缓存，冷数据迁移到低速存储，对上层应用透明。
第三个方向是多设备存储协同。家庭场景下，多个端侧AI设备可能需要共享知识库和用户数据。存储层面需要支持分布式协同，让设备之间能高效同步数据，同时保证隐私和安全。
5.3 给端侧AI开发者的几条实用建议
如果你正在做端侧AI相关的开发，这几条建议可能帮你少走弯路。
第一，存储选型要留余量。不要按当前需求刚好选容量，至少留50%的余量。端侧AI的数据增长往往超出预期，尤其是用户数据。
第二，尽早做存储性能测试。不要等系统集成完了才发现存储是瓶颈。在方案选型阶段就用fio做基准测试，确认实际性能符合预期。
第三，关注存储的功耗表现。端侧设备的续航是核心竞争力，存储功耗容易被忽略。选型时不仅要看性能参数，还要看功耗曲线。
第四，做好存储健康监控。端侧设备部署后，存储健康度是重要的运维指标。建议在系统里集成存储健康监控，定期上报寿命消耗、温度、错误计数等数据。
第五，不要忽视固件更新。存储控制器的固件更新可能带来性能提升和bug修复。选型时确认厂商是否提供固件更新支持，以及更新方式是否方便。
我在实际部署端侧AI设备的过程中，最大的体会是：存储这一层看起来简单，但真正影响体验的往往是这些细节。UFS 4.1和iSA带来的提升是实实在在的，但要用好这些能力，需要在系统设计、驱动配置、应用优化各个层面都做对。希望这篇内容能帮你在端侧AI存储的选型和部署上少踩一些坑。
