如果只看规格表，2026年的UFS仍然是一条熟悉的技术升级曲线：UFS 4.1之后是UFS 5.0，带宽继续提升，随机性能进一步提高，端侧AI也在提出更复杂的数据访问需求。

但FAST 2026上，SK hynix、Google与首尔大学联合发表的一项部署研究，透露出另一条更值得行业关注的变化。研究团队并没有只更换一颗更快的NAND或调整Controller Firmware，而是同时改动Device Firmware、SCSI/UFS Driver、Linux Block Layer、F2FS以及Android Framework，并在商用智能手机上完成实机验证。结果显示，在碎片化条件下，ZUFS持续写入吞吐超过传统UFS两倍，测试中的游戏加载时间缩短约14%。[1]

真正值得注意的并不是“14%”这个数字本身，而是这部分应用级收益并非来自某一个单点器件参数，而是来自整条存储栈的协同。高端UFS竞争的分析单位，正在从单颗器件扩展到软件—硬件共同构成的系统。

图1：UFS竞争边界正在从协议、器件系统，继续扩展到跨层协同 制图：存储阿翁哥

一、ZUFS真正改变的，不是“更快”，而是Host与Storage的责任边界

传统UFS是一种高度成熟的Managed Flash架构。Host主要提交逻辑读写请求，L2P Mapping、Garbage Collection、Wear Leveling、ECC以及NAND介质管理等复杂工作，主要由Controller和Firmware在Device内部完成。

这种抽象非常成功：它把NAND复杂性隐藏在标准接口之后，使手机SoC、操作系统和OEM不必理解每一种NAND的内部几何结构，也让供应商更容易在统一协议下进行替换和认证。

但随着容量和工作负载复杂度提升，把绝大多数Flash管理复杂性封装在Device内部的方式开始面临新的成本约束。FAST 2026论文指出，大容量传统UFS需要维护庞大的细粒度L2P映射，而Device内部SRAM不可能无限增加。ZUFS通过固定Zone与顺序写入语义，让Host参与数据放置约束、Zone选择与写入组织，从而降低Device侧映射压力。[1] 需要强调的是，这并不是把整个FTL交给Host，更不是把UFS变成Host-managed raw NAND；ECC、Wear Leveling以及大量介质管理职责仍然留在Device侧。

所以ZUFS不是传统UFS的简单加强版。它本质上是一种架构Trade-off：用更高的Host/Software协同复杂度，换取更低的Device映射与GC压力，以及更可控的长期性能。

二、真正的变化在Android：UFS要跑得更好，软件栈必须一起改

这也是FAST 2026最有产业意义的一点。研究团队识别出的难题并不只在Flash本身，还包括多Open Zone竞争有限SRAM、端到端Write Ordering、Clock Gating引发的I/O Requeue，以及大Zone带来的Garbage Collection前台停顿。

为了解决这些问题，优化跨过了Device Firmware、SCSI/UFS Driver、Block Layer、F2FS和Android Framework。论文给出的结论很明确：ZUFS的完整潜力需要整个移动存储栈协同设计才能释放，[1] 这不是某一个Firmware Feature或单点硬件升级可以替代的。

图2：Cross-layer Co-optimization：真正的优化边界已经不再停在UFS封装内部 制图：存储阿翁哥

Android软件栈的重要性也不是偶然。Android官方文档显示，从Android 13开始，Userspace只使用GKI内置文件系统；F2FS属于Google Android Kernel团队持续支持和频繁维护的生产文件系统之一。[3] 这意味着，一项新的存储能力如果要真正成为可规模部署的Android能力，最终不仅要进入Memory器件，还必须与公共Kernel、文件系统和Android平台协同。

这也解释了为什么Google参与ZUFS研究具有结构性意义：存储优化已经开始触及移动操作系统的公共基础设施。不过，这只能证明公共软件栈已经进入创新路径，并不能据此推断ZUFS或某一种跨层方案已经成为Android生态的通用能力。

三、但必须踩刹车：ZUFS是方向性样本，不是整个UFS未来的唯一答案

如果因为这篇论文就得出“未来手机都会采用ZUFS”，会把一个有价值的方向性样本写成技术炒作。论文证明的是跨层协同可以在真实设备上产生收益，并不等于它已经证明了未来市场的唯一技术路线。

首先，ZUFS把部分复杂性从Device扩展到Host与软件栈，本身就带来开发、验证和维护成本。低容量、低负载或成本高度敏感的手机，未必值得为这套协同付费。其次，收益高度依赖Workload；长期碎片化、随机访问和AI负载复杂的设备更容易体现价值，而简单顺序访问场景未必获得相同收益。最终是否采用，还取决于容量、工作负载、软件成熟度、Qualification成本以及功耗与热设计等多重约束。

更现实的市场结果可能是分层：普通UFS继续承担高度标准化的大规模市场，而ZUFS及类似跨层方案首先集中在高容量、旗舰AI手机和特定OEM平台。SK hynix已于2025年完成ZUFS 4.1客户Qualification并进入量产供货，这证明它已经跨出实验室，但还不能据此推断整个Android生态会迅速全面迁移。[2]

四、最容易写错的一点：跨层协同并不必然导致Vendor Lock-in

直觉上，OEM围绕某一颗UFS做得越深，替换供应商就越难。这个方向有一定道理，但如果直接写成“跨层协同会锁死供应商”，并不严谨，因为标准化、开源和私有调优会同时作用于供应商切换成本。

一方面，ZUFS并不是某一家Memory厂的私有概念；相关Zone语义已经进入标准体系，F2FS与Linux/Android公共代码也在吸收针对Zone UFS的能力。Android公共Kernel文档已经出现由vivo工程师贡献的blkzone_alloc_policy，用于控制传统区域和顺序Zone的写入优先级；相关说明明确提到当前使用的是传统UFS与Zone UFS混合方案。[4][5]

另一方面，当JEDEC语义、Linux Block层、F2FS和Android GKI逐渐标准化后，一部分过去需要单独定制的能力可能更容易跨供应商复用。真正可能形成壁垒的，不是“Zone”这个标准本身，而是标准之上的Vendor-specific Firmware行为、Telemetry、Workload Tuning、Power/Thermal参数以及量产平台经验。

图3：跨层协同的两股力量：公共标准降低替换成本，私有优化增加重新验证成本 制图：存储阿翁哥

五、真正的产业问题开始浮现：谁掌握整台手机的“存储优化权”？

一旦优化走出芯片，产业竞争就不再只是Memory厂之间的事情。跨层优化至少涉及三方：存储供应商（Memory Supplier）、OS/Android Platform以及Smartphone OEM。本文所说的“存储优化权”，并不是独家控制权，而是谁能够持续定义优化目标、获得真实工作负载反馈、决定调优策略、完成跨层验证，并把经验固化为下一代平台可复用规则的能力。

存储供应商掌握NAND特性、Controller、Firmware、GC、Telemetry和Device行为；Android平台掌握Kernel、Block Layer、F2FS和Framework公共能力；OEM则最了解真实用户Workload、整机Power/Thermal、应用体验、Qualification以及多供应商策略。三方拥有的不是同一种知识，也因此拥有不同的优化杠杆。

图4：UFS跨层时代的核心问题：优化知识最终沉淀在Memory厂、Android平台还是OEM？ 制图：存储阿翁哥

这三方谁掌握更多可复用的跨层优化知识，谁就可能获得更多产品定义能力。存储供应商如果主导整套联合调优，可能提高客户对其Firmware和器件行为的依赖；Google如果把优化能力推入公共Android/GKI/F2FS，则可能把个别厂商的创新转化为行业公共能力；OEM如果掌握Workload、Kernel和验证体系，则可能反过来要求多个Memory供应商适配同一套平台。

因此，高端UFS下一阶段真正值得追踪的，不只是“谁的协议更新”，而是谁能持续影响数据怎么放、GC什么时候做、Firmware如何响应、Power怎样调，以及不同Workload如何被识别和分类。这里争夺的本质，是跨层优化知识能否沉淀为可复用的平台资产。

六、跨层协同可能产生相反的供应链结果：关键在优化知识归属

如果是Supplier-led Co-optimization，Memory厂商主导Firmware、Telemetry和平台联合调试，OEM为了保留最佳性能会更依赖供应商经验；当替换供应商需要重新调参与系统回归时，Optimization Friction就可能上升。

但如果是OEM-led Co-optimization，情况可能相反。OEM自己掌握Workload、Kernel、F2FS、Validation和Zone策略，就可以要求Samsung、SK hynix、Micron或其他UFS供应商共同适配自己的平台。此时跨层知识更多沉淀在OEM，反而可能提升Multi-source能力和采购议价权。

图5：同一种Cross-layer Optimization，可以导向两种完全不同的供应链结果 制图：存储阿翁哥

所以不能简单写成“跨层协同会让Memory厂更强”。真正关键的是Optimization Knowledge归属谁，以及哪些能力被标准化、哪些能力仍然私有。Supplier-led路径可能提高替换摩擦，OEM-led路径可能提高多供能力；如果Google/Linux等公共平台把通用能力持续标准化，部分厂商特有优势还可能被公共化。

七、中国UFS真正的机会，不是复制Google，而是把分散能力组织起来

公开证据已经出现一个值得追踪的中国样本：vivo工程师向F2FS/Linux提交了针对Zone UFS的写入分配策略，而且补丁明确描述传统UFS和Zone UFS混合使用的实际场景。[4] 这至少说明，国内手机OEM的工程能力已经可以进入文件系统与Storage Behavior这一层，而不只是采购和验证存储器件。

但一个补丁不能证明中国OEM已经形成完整的跨层优化体系。真正的产业能力，需要把OEM、SoC、Controller/UFS厂商、Firmware、Kernel/F2FS以及真实AI Workload组织到同一个量产平台，并让优化经验能够跨机型、跨代际复用。

因此，中国UFS下一阶段更值得争取的机会，可能不是再多做一颗“更便宜的Controller”，而是把分散的工程能力组织成联合优化体系。中国未必需要复制Google + SK hynix模式，更可能出现OEM-led Co-optimization：手机品牌作为平台中心，把SoC、UFS供应商、Controller、Firmware、Kernel/F2FS和AI Workload拉到同一套验证与调优框架中。

当然，目前还不能说这一闭环已经形成。真正需要观察的是：国内OEM是否把Zone、Telemetry、Latency等能力持续推入量产平台；国产UFS供应商是否能参与这种联合开发；同一套OEM优化框架能否支持多家供应商；以及这些能力能否从单个机型沉淀为下一代平台复用的工程资产。在这些证据出现之前，“OEM-led中国路径”仍然应被视为可验证的产业推演，而不是既成事实。

八、AI会把“优化权”问题放大，因为带宽本身已经不够解释体验

Samsung对UFS 5.0的官方定义已经显示，高端移动存储正在从单纯追求顺序带宽，转向更复杂的Edge AI场景。其资料给出的最高带宽为10.8GB/s，并强调随机读取最高可达UFS 4.1的5倍，以应对大量、分散、实时的数据访问。[6] 这类厂商规格首先代表产品设计方向，不能直接等同于任意手机上的应用体验。

Micron则已经在UFS 4.1产品上引入Zoned UFS与Intelligent Latency Tracker：前者通过把相似I/O特征的数据组织到Zone中改善读写效率，后者同时观察系统端和存储设备端的I/O延迟，帮助OEM分析真正影响体验的异常。[7] 这同样说明，厂商正在把差异化从峰值带宽延伸到数据组织、延迟可观测性和系统调优。

因此，未来高端移动存储可能同时需要两类能力：UFS 5.0继续提高“路有多宽”，Cross-layer Optimization则解决“数据如何更聪明地走这条路”。前者提高性能上限，后者决定这些性能在真实Workload下能兑现多少。

九、对贸易商和方案商而言，“同一颗UFS”也需要重新定义

这场变化最终一定会落到交易。过去做UFS，确认Brand、Part Number、Capacity、Protocol、NAND、Date Code和Price，基本可以完成大部分交易判断。未来高端产品还要增加一层Platform Context：它在什么SoC与软件栈上被验证、哪些高级能力已经打开、在什么Workload下才有价值。

一颗支持ZUFS或其他高级Feature的UFS，并不意味着放到任何一台手机都能获得相同性能收益。SoC、Android版本、Kernel/Driver、F2FS参数、Firmware Revision和OEM Qualification都可能影响最终表现。对方案商而言，“支持某Feature”和“该Feature已经在目标平台兑现收益”必须严格区分。

因此，未来的替代关系可能从“Part A可以替Part B”，变成“Part A在Platform X + Firmware Y + Android/Kernel Z条件下，可以替Part B”。Qualification / Alternative Matrix会进一步从Component-level升级到Platform-level。对贸易商和方案商来说，报价与替代判断也应开始同时记录平台、Firmware、认证阶段、真实Workload收益以及无法通过认证时的第二出口。

十、未来12-24个月，判断这条趋势是否真正成立，我会看六个信号

结语｜UFS下一场战争，可能是“谁定义优化”

过去UFS产业的责任边界相对清晰：Memory厂把NAND、Controller和Firmware做好，OEM通过标准接口采购、认证和导入。今天，这条边界开始出现松动，因为越来越多性能收益需要在Device之外完成。

ZUFS并没有证明传统UFS要被淘汰，也没有证明所有跨层协同都会制造供应商锁定。它已经证明的，是在高容量、复杂Workload和AI场景下，单纯把芯片做得更快未必能够兑现全部系统收益；Device Firmware、Driver、Kernel、F2FS和Android Framework可能共同决定最终的Storage Behavior。

当这种协同成为性能来源时，产品定义能力也可能随之重新分配。需要继续验证的，不是“某一方一定赢”，而是跨层优化知识最终被谁掌握、哪些能力被公共标准吸收、哪些能力仍然留在厂商与OEM的私有工程体系中。

如果这套知识更多沉淀在Memory厂，供应商可能获得更强的平台黏性；如果沉淀在Google/Linux等公共软件栈，先进能力会更快标准化；如果沉淀在OEM，跨层协同甚至可能成为提高二供能力和采购议价权的新工具。现实中，这三种力量更可能长期并存，而不是由单一一方完全控制。

因此，UFS真正正在进入的，可能不是简单的5.0时代，也不是单纯的ZUFS时代，而是一个“跨层协同开始成为系统性能变量”的产业阶段。下一场UFS竞争真正值得看的，不是哪一家率先把顺序速度再提高1GB/s，而是谁既懂NAND，也懂整台手机，并能把这种理解转化为公共标准、平台经验和可复制的量产能力。

资料来源、事实层与判断边界

1. USENIX FAST 2026：Jungae Kim等，《Unleashing Zoned UFS: Cross-Layer Optimizations for Next-Generation Mobile Storage》。研究由SK hynix、Google、首尔大学联合完成，覆盖Device Firmware、SCSI/UFS Driver、Block Layer、F2FS和Android Framework，并在商用智能手机上进行部署评估。

2. SK hynix Newsroom，2025-09-10：公司宣布ZUFS 4.1完成客户Qualification，并于2025年7月启动量产和供货。

3. Android Open Source Project，Android Kernel File System Support，更新于2026-06：Android 13起Userspace仅使用GKI内置文件系统，F2FS属于Android Kernel团队持续重点支持的文件系统。

4. Linux Kernel Mailing List / Openwall，2024-07-09：vivo工程师提交基于Zone UFS的F2FS写入优先级补丁，并明确描述传统UFS与Zone UFS混合使用场景。

5. Android common kernel Documentation/ABI：blkzone_alloc_policy条目由vivo工程师维护，描述Zone UFS中Sequential Zone和Conventional Zone的写入策略。

6. Samsung Semiconductor，UFS 5.0产品资料：最高10.8GB/s带宽、相较UFS 4.1最高5倍随机读取，面向Edge AI大量分散数据实时访问。

7. Micron，G9 UFS 4.1移动存储资料：Zoned UFS通过按I/O特征组织数据改善效率，Intelligent Latency Tracker同时监控系统与存储设备侧I/O延迟。

作者简介

存储阿翁哥（邹进华），存储芯片贸易从业者、产业研究作者，长期跟踪NAND／DRAM wafer、BGA、DDR／LPDDR、eMMC／UFS与SSD供应链。

编辑说明：FAST 2026实机研究、SK hynix量产信息、Android/F2FS文档、vivo相关补丁以及Samsung、Micron公开产品资料属于事实层；“存储优化权”“Optimization Friction”以及Supplier-led、OEM-led、Platform-led三类路径属于本文提出的产业分析框架。后续仍需用多OEM量产、多供应商可替换性、平台验证成本、应用级收益与订单留存继续检验。