TBW / DWPD 寿命预算技术探讨
从业务负载反推容量与颗粒档位 —— 一份给存储选型与应用方案工程师的量化方法手册 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0
市场分析人员在判断「这个场景该用多大容量、什么档位颗粒」时，最常做的事是拍脑袋：要么按同行的料号对标，要么拿一颗容量最大的样品去报。这一份文档要把它变成一条可复算的链路。
做法是：先把业务负载翻译成每日写入字节数，再把「寿命目标」翻译成所需容量，最后用厂商标称的 TBW 与颗粒的 P/E 去校验余量。三个算法、五个算例、十个错配案例，构成一条从需求到料号档位的完整推导。
结论： 寿命判断的顺序永远是先算写入、再算容量、最后才看颗粒。 TBW 与 DWPD 只是同一枚硬币的两面（TBW = DWPD × 容量 × 天数）， 真正决定选型的是「每日写入量 × 寿命年数 × 余量系数」这个乘积； 颗粒档位只负责把乘积换算成能被采购到的容量与 P/E 组合。 所有数值均为行业经验区间，以正式 datasheet 与实测为准。
读者路径
- 要做容量档位判断：直接跳第 5~7 章（三个算法）与第 10 章（五个算例），这是本文主干。
- 要理解 TBW / DWPD 口径：读第 1~2 章，弄清「标称」与「实测」差在哪里。
- 要建立负载感觉：读第 3~4 章与附录 B，那里有可直接取用的负载画像参数。
- 要做方案评审：读第 8~9 章（温度、写放大）与第 12 章（三阶段核查清单）。
- 要避免常见错误：读第 11 章的十个错配案例与八个误区。
1. 三个容易混淆的量：P/E、TBW、DWPD
这一章先把三个最常被混着用的量拆清楚。它们的层级不同、单位不同、失效含义也不同——搞混这一步，后面所有容量判断都会偏。
1.1 P/E 是颗粒指标，不是器件指标
P/E（Program / Erase cycle，编程 / 擦除次数）指的是一个 NAND 存储块在被判定为坏块之前，能够承受多少轮擦除-编程循环。它是物理层指标，描述的是「一块 NAND 介质本身能磨多少次」。
关键在于它的层级。P/E 是颗粒（die）级别的指标，同一颗 die 上的所有块共享同一个标称值。一颗 128 Gb 的 TLC 颗粒标称 P/E 3,000 次，意思是「每个块大约能擦写 3,000 次」，而不是「整颗器件总共能擦写 3,000 次」。
| 指标 | 所属层级 | 单位 | 标定主体 | 典型数值（经验区间） | 失效含义 |
|---|---|---|---|---|---|
| P/E | 颗粒 / 块（die 级） | 次（cycles） | 芯片原厂（颗粒规格书） | SLC 1万~10万；TLC 约 1千~3千；QLC 数百 | 该块隧道氧化层损伤累积，判定为坏块 |
| TBW | 器件（成品级） | TB（10¹² 字节） | 器件厂 / 模组厂（成品规格书） | 数十 TB 到数千 TB，随容量线性放大 | 超过保修写入量，厂商不再担保 |
| DWPD | 器件（成品级） | 次/天（盘/天） | 同上，常与 TBW 并列给出 | 0.1 ~ 3 次/天，企业级产品常见 | 同上，只是换一种表述口径 |
把 P/E 直接当成器件寿命是最常见的错误。器件的总可擦写轮次 = 块数 × 每块 P/E，而容量越大块数越多，所以「大容量颗粒的 P/E 数字看起来一样，实际总擦写能力是线性放大的」。反过来，一颗标称 3,000 次 P/E 的 TLC 颗粒，配到 128 Gb 的器件上，最终能写多少要靠 TBW / DWPD 去算，而不是靠 3,000 这个数。
1.2 TBW 是什么：总可写字节数
TBW（Total Bytes Written / Terabytes Written）是器件在保修期内允许写入的数据总量，单位是 TB。它回答的是一个问题：这块存储「一辈子一共能写多少数据」。
TBW 是一个与容量强绑定的量：同一款颗粒、同样的 P/E，容量翻倍则 TBW 也翻倍。这也是为什么 2 TB 盘的 TBW 总是 1 TB 盘的两倍——它们的单位容量寿命其实是一样的。
| 口径 | 含义 | 谁在用 | 对读规格表的影响 |
|---|---|---|---|
| 主机写入量口径 | 只算主机交给器件的字节，不含器件内部写放大 | 最常见、最保守 | TBW 数值看起来偏小 |
| NAND 写入量口径 | 算上器件内部因 GC、均衡产生的额外写入 | 部分大厂与工业级器件 | TBW 数值偏大，换算需再乘 WAF |
| 标称容量口径 | 用标称容量（如 512 GB）而非可用容量参与计算 | 营销口径居多 | 比可用容量口径高 5% ~ 15% |
| 实测口径 | 在实际负载与温度下跑出来的真实可写量 | 大厂内部与第三方测试 | 通常明显低于前三者，见 2.3 |
1.3 DWPD 是什么：每日写次数
DWPD（Drive Writes Per Day，每日写入盘次数）表示保修期内每天可以把整个存储写满几遍。它是「日均负载」的另一种表达方式，天然与业务负载可比，所以企业级与工业级产品几乎都用 DWPD 作为主指标。
换算关系非常简单，这一点务必记牢：
TBW (TB) = DWPD (次/天) × 容量 (TB) × 保修天数 (天)
DWPD = TBW (TB) / 容量 (TB) / 保修天数 (天)
例：容量 1.92 TB，标称 DWPD = 1，保修 5 年
保修天数 = 365 × 5 = 1825 天
TBW = 1 × 1.92 × 1825 = 3504 TB
例：容量 512 GB 消费级盘，标称 TBW = 600 TB，保修 5 年
DWPD = 600 / 0.512 / 1825 约等于 0.64 次/天消费与移动场景的用户不关心每天写几次，只关心「这块盘能用几年」，TBW 配合容量与保修年限可以直接算出年限；企业与工业场景的采购方手里已经有一个日均写入量的预算，DWPD 可以直接和它对比，无需再转换。所以两个指标长期并存，读规格表时两者都要看。
| 场景 | 主用指标 | 典型标称值 | 同容量下换算示例 | 读规格时注意 |
|---|---|---|---|---|
| 消费级 SSD / 存储卡 | TBW + 保修年限 | 数十 ~ 数百 TB | 512 GB / 600 TBW / 5 年 → 0.64 DWPD | TBW 常按营销口径，容量基准多为标称值 |
| 企业级 SSD | DWPD | 1 ~ 3 次/天 | 1.92 TB / 1 DWPD / 5 年 → 3504 TB | 通常同时给 DWPD 与 TBW，两者自洽 |
| 工业级 SSD / 存储卡 | DWPD + TBW | 0.5 ~ 3 次/天 | 256 GB / 1 DWPD / 5 年 → 467 TB | 宽温版常另给降额后的 DWPD |
| eMMC / UFS / SD NAND | TBW 或 P/E | 数十 ~ 数百 TB | 128 GB / 150 TBW / 5 年 → 0.64 DWPD | 小容量器件常直接标 P/E 次数 |
| 车规 eMMC / UFS | P/E + TBW + 温度等级 | 按 AEC-Q100 等级 | 需按车规温度上限重新折算 | 车规料号的 P/E 常按高温标定 |
1.4 三者的换算关系与各自的失效含义
把三者串起来，链路是这样的：
- 颗粒 P/E（芯片厂给）+ 容量（器件厂定） → 推出器件理论总擦写轮次；
- 理论总擦写轮次 × 每轮可写的字节数 → 得到器件标称 TBW；
- TBW 折成日均 → 得到器件标称 DWPD；
- 再乘一个余量系数 k → 得到工程上可承诺的 DWPD。
| 量 | 换算时的角色 | 对应的失效含义 | 失效后会发生什么 |
|---|---|---|---|
| P/E | 提供「每块能磨多少次」这个物理上限 | 材料层面的失效 | 块变坏块，坏块耗尽后器件无法可靠擦写 |
| TBW | 提供「保修期内共能写多少」的商业承诺 | 商务层面的失效 | 写入量超过保修额度，厂商不再担保（数据未必立刻坏） |
| DWPD | 提供「每天能写几个盘」的可比口径 | 与 TBW 同一种失效 | 同上，只是表述不同；它方便直接与业务负载对比 |
NAND 的失效是渐进的：擦写次数上升 → 原始误码率上升 → 纠错负担加重 → 读重试增多 → 纠错兜不住才丢数据。TBW / DWPD 是保修与商务的界线，不是数据的生死线。实际工程里，比 TBW 更早出现的往往是「温度 + 时间」这条线（数据保持期到期），这一点第 8 章会展开。
2. 厂商是怎么标 TBW 的
这一章拆解厂商规格书上的 TBW 数字是怎么来的、为什么各家不一样、以及为什么你实测出来的总是比标称低。
2.1 通用标法：TBW = 容量 × P/E × 单元比特数
绝大多数厂商的 TBW 标定都用同一个骨架。展开写就是：
TBW (TB) 约等于 容量 (Gbit) × P/E (次) × 单元比特数 (bit) / 8 / 1000
↑ TBW ↑ 标称容量 ↑ 颗粒 P/E ↑ SLC=1 / pSLC=1
TLC =3 / QLC =4
简化写法（1 bit 单元时）：
TBW (TB) 约等于 容量 (Gbit) × P/E (次) / 8 / 1000
= 容量 (GB) × P/E (次) / 8
校验：1 GB = 8 Gbit，所以 Gbit 与 GB 之间差 8 倍，除以 8 之后正好抵消。如果直接把 TLC 的 TBW 当成「容量 × P/E / 8」来算，会低估约 3 倍——因为 TLC 一个单元存 3 bit，同一块物理空间能承载 3 倍的字节数。这一项是 TLC 与 QLC 相比，TBW 数字更大的主要原因，它和「P/E 下降」这两个因素方向相反、量级相当，最终才落到 TLC 千次级 P/E 配大容量 TBW 的均衡点上。
| 因子 | 含义 | 取值来源 | 对 TBW 的影响方向 | 经验区间 |
|---|---|---|---|---|
| 容量 | 器件标称容量，单位 Gbit | 器件规格书（注意是 Gbit 还是 GB） | 正向，一次方 | 1 ~ 512 GB（消费级） |
| P/E | 每块可承受的擦写次数 | 颗粒规格书，常见 25 ℃ 标定 | 正向，一次方 | 1 千 ~ 10 万次 |
| 单元比特数 | 每个物理单元存几个 bit | 颗粒类型（SLC/pSLC=1，MLC=2，TLC=3，QLC=4） | 正向，一次方 | 1 ~ 4 |
| / 8 | bit 换成 Byte | 单位换算常量 | 固定衰减 | 常数 |
| / 1000 | GB 换成 TB | 十进制单位约定（部分厂商用 1024） | 固定衰减 | 常数 |
| 余量系数 k | 工程上再打的折扣 | 本文建议，无厂商公开值 | 反向衰减 | 1.5 ~ 2.0 |
2.2 标定口径的差异：容量按标称还是可用、写放大算不算
同样是「1 DWPD / 5 年」的标称，不同厂商背后的假设可能差一倍以上。差异主要来自三处：
| 差异点 | 口径 A | 口径 B | 两者 TBW 比值 | 读规格表时怎么确认 |
|---|---|---|---|---|
| 容量基准 | 标称容量（如 512 GB） | 可用容量（扣掉 OP 与格式化为 480 GB 左右） | 约 1.05 ~ 1.20 | 看规格书是否标注「基于标称容量」 |
| 是否含写放大 | 主机写入量（WAF = 1） | NAND 实际写入量（含 WAF） | 约 1.0 ~ 4.0 | 看是否标注 TBW 的测试方法与负载类型 |
| 是否含温度降额 | 25 ℃ 标定值直接给出 | 按目标工作温度降额后给出 | 约 1.0 ~ 3.0 | 看 P/E 的标定温度与工作温度范围是否一致 |
| 是否含磨损均衡 | 平均块 P/E | 最差块 P/E（更保守） | 约 1.1 ~ 2.0 | 看是否说明是否按最差块标定 |
| 十进制 vs 二进制 | 1 TB = 10¹² 字节 | 1 TB = 2⁴⁰ 字节 | 约 1.10 | 存储行业惯例用十进制，注意区分 |
口径不同的情况下，A 厂 1200 TBW 与 B 厂 800 TBW 完全可能是一回事。正确做法是：先用同一口径换算到 DWPD，再用同一套负载假设折算到你的实际写入量。本文第 6 章的算法 B 就是干这件事的。
2.3 为什么实测通常明显低于标称
把 2.2 的五个口径差异叠上真实世界的损耗，标称与实测之间通常有 3 ~ 8 倍的差距。拆开看：
| 损耗来源 | 典型量级 | 机理 | 能否在算法里提前计入 |
|---|---|---|---|
| 可用容量低于标称 | 5% ~ 20% | OP 预留区、格式化损耗、坏块预留 | 能，用容量系数折算 |
| 写放大 WAF | 1.0 ~ 4.0 倍 | GC 搬移、磨损均衡、映射表更新 | 能，取负载相关的区间值 |
| 温度加速 | 1.0 ~ 3.0 倍 | 高温下擦写损伤与漏电同时加快 | 能，按工作温度取因子 |
| 磨损不均导致的最差块 | 10% ~ 100% | 动态均衡不完美，部分块先到寿命 | 部分能，用余量系数覆盖 |
| 突发写入集中 | 10% ~ 50% | 短时高频写入集中在少数块上 | 部分能，用峰值系数覆盖 |
| 厂商未公开的内部预留 | 不透明 | 映射表、坏块表、日志区占用 | 不能，只能靠余量系数兜 |
凡是标称 TBW / DWPD 的规格，几乎都隐含了「25 ℃、稳态、顺序写、良好磨损均衡」这四个前提。你的实际工况只要有一项偏离，就要打折扣。这也是本文第 5~7 章所有算法都强制引入余量系数 k 的原因——k 不是凑数，它覆盖的就是这张表里所有「不能提前精确计入」的部分。
2.4 读 TBW 规格表的六个必查项
拿到一份规格书，下面六项逐条确认，之后再谈选型：
| # | 必查项 | 在规格书里找什么 | 找不到时的保守处理 |
|---|---|---|---|
| 1 | 容量口径 | 标称容量还是可用容量；OP 预留比例 | 按可用容量 = 标称 × 0.85 估 |
| 2 | TBW / DWPD 的测试口径 | 是否写明 TBW 为主机侧还是 NAND 侧、是否含 WAF | 一律按主机侧（WAF = 1）估 |
| 3 | P/E 标定条件 | 标定温度、负载类型（顺序 / 随机）、是否最差块 | 按 25 ℃、顺序写、平均块估 |
| 4 | 工作温度范围 | 商业级 / 工业级 / 车规，对应的 P/E 是否有降额版本 | 按最高工作温度 + 温度因子估 |
| 5 | 保修年限 | TBW 对应几年保修；不同年限 TBW 是否线性缩放 | 按客户承诺年限重算，不沿用标称 |
| 6 | 单位与十进制口径 | TB 用 10¹² 还是 2⁴⁰；容量标 GB 还是 GiB | 存储业按十进制，营销页常混用 |
这六项填完，你在市场分析里给出的「这个场景该配多大容量」才是可追溯、可复算、可被别人接手的结论。否则一旦客户质疑「为什么你要 128 GB 而不是 64 GB」，你只能重新拍脑袋。
3. 写入模型：把业务负载翻译成字节数
这一章是整条链路的入口。前面所有关于 TBW 的定义与口径，都只是「结果侧」；只有把业务功能逐项翻译成每日写入字节数，才有了计算的起点。
3.1 写入负载的六个基本量
描述一个场景的写入负载，需要六个量。缺任何一个，算出来的容量都会偏：
| 量 | 符号 | 含义 | 单位 | 取值来源 | 缺失的后果 |
|---|---|---|---|---|---|
| 日均写入量 | V_d | 稳态运行下每天写入的数据量（主机侧） | GB/天 | 功能拆解 + 实测流量 | 整体偏大或偏小，后面全错 |
| 写放大系数 | WAF | NAND 侧实际写入 / 主机侧写入 | 倍 | 按访问模式估，见第 9 章 | 低估寿命消耗，可能差 3~4 倍 |
| 留存周期 | T_r | 数据需要保留多少天（滚动覆盖则填覆盖轮次） | 天 | 功能需求书 | 高估所需容量，选型偏大 |
| 重写比例 | r_w | 同一天内被反复覆写的字节占比 | % | 由写入粒度与更新频率决定 | 低估写入量，日志类场景尤甚 |
| 突发系数 | k_b | 峰值写入量 / 日均写入量 | 倍 | 按业务峰谷比估 | 低估长期消耗峰值带来的磨损 |
| 余量系数 | k | 为口径差、温度、磨损不均预留的折扣 | 倍 | 工程经验，建议 1.5 ~ 2.0 | 纸面合格、实际不够用 |
3.2 从功能需求到日均写入：逐项拆解法
不要凭空估日均写入量，按功能逐项累加是唯一可靠的做法。一条负载通常由若干个独立功能构成，每一项各算各的，最后相加：
步骤 1：列出所有产生写入的功能项
例：运行日志、行驶轨迹、OTA 包缓存、配置回写、故障快照
步骤 2：每一项算三个数
单次写入量 S_i （字节）
每天发生次数 n_i （次/天）
每日写入量 V_i = S_i × n_i × r_w,i
步骤 3：日均写入量 V_d = 求和 V_i （GB/天，注意单位统一）
步骤 4：留存校验
所需存储空间 = 求和 (V_i × T_r,i) ≤ 候选容量
注意：只有「不需要滚动覆盖」的功能项才进这个校验| 功能项 | 单次写入量 S_i（经验值） | 日频次 n_i | 留存 T_r | 备注 |
|---|---|---|---|---|
| 运行日志（单条） | 200 B ~ 4 KB | 10 ~ 10,000 条/天 | 7 ~ 30 天，滚动覆盖 | 条长与频次强相关，需实测 |
| 行驶轨迹点 | 32 ~ 128 B/点 | 1 点/秒 ~ 1 点/5 秒 | 通常滚动覆盖 | 长里程场景量级差别大 |
| OTA / 固件缓存 | 1 ~ 32 MB | 0.05 ~ 1 次/天 | 升级前缓存，可清 | 很少发生但单次量大 |
| 配置回写 | 64 ~ 512 B | 1 ~ 50 次/天 | 常驻，不覆盖 | 量小，可忽略 |
| 故障快照 / 黑匣子 | 64 KB ~ 4 MB | 0.01 ~ 10 次/天 | 长期保留 | 事件驱动，均值常被高估 |
| 传感器采样缓存 | 8 ~ 64 B/点 | 1 ~ 100 Hz | 秒级到分钟级 | 可穿戴与 IoT 的主要来源 |
| 拍照 / 视频片段 | 2 ~ 20 MB | 0.1 ~ 20 次/天 | 长期保留 | 对存储容量影响最大 |
| 系统分区更新 | 100 MB ~ 数 GB | 0.01 ~ 0.1 次/天 | 双分区滚动 | 手机 / 平板特有 |
① 漏项：只算了业务日志，忘了「异常时自动抓取的诊断快照」「定时上报的心跳」「配置每次变更都回写整份配置」这类隐性写入，在日志类设备里它们常占到三成以上。② 重项：把「同一天内被覆盖 5 次的日志」当成 5 个功能项各算一遍，实际是重写比例 r_w 的一次性放大，不要重复计入。③ 单位错：MB 与 GB 混用是最常见的算错来源，建议在表格里统一成 GB/天这一列。
3.3 突发写入与稳态写入的分离
寿命是按「累计擦写次数」消耗的，而承受冲击的是「局部磨损」。这两件事必须分开看：
- 稳态写入决定长期容量是否够：按日均写入量 × 天数算，这是 5 年后的总量问题。
- 突发写入决定颗粒会不会提前坏：短时间内集中写入会让部分块被反复擦写，磨损不均导致的局部超载可能比总量更早触发问题。
| 维度 | 稳态写入 | 突发写入 | 在算法里的位置 |
|---|---|---|---|
| 衡量指标 | 日均写入量 V_d（GB/天） | 峰值写入量 V_p（GB/天 或 MB/s） | V_d 进容量与寿命公式，V_p 单独校核 |
| 对应消耗 | 全盘均匀消耗的 TBW | 局部块集中消耗的最差块磨损 | V_p 用突发系数 k_b 折算进余量 |
| 典型场景 | 日志持续追加、后台同步 | 开机自检批量写入、数据导入、OTA | 开机批量写与固件升级最典型 |
| 风险表现 | 寿命按比例消耗，可预测 | 个别块提前到寿命，坏块增加 | 表现为坏块数上升、可用容量下降 |
| 缓解手段 | 选更大容量或更高耐久颗粒 | 分摊写入、避开集中区域、限速 | 固件层做写入平滑与磨损均衡 |
3.4 日历效应：日志类负载按 365 天还是按开机小时
很多场景的设备并不是 7×24 通电。取寿命口径时，必须先回答一个问题：「一天」到底按日历天算，还是按实际开机小时折算？
| 运行模式 | 日均开机小时 | 写入是否集中在开机期 | 日均写入量口径 | 寿命年限折算注意 |
|---|---|---|---|---|
| 7×24 连续运行（服务器、网关） | 24 h | 全天均匀 | V_d 按日历天，n_d = 365 | 直接用日历天，无需折算 |
| 每天固定时段运行（如夜间集中同步） | 4 ~ 12 h | 集中在某几个小时 | V_d / 24 × 开机小时数 | 磨损更集中，突发系数要放大 |
| 间歇运行（每天几小时） | 2 ~ 6 h | 零散分布 | 同上 | 考虑峰值写入带宽是否超规格 |
| 深度休眠待机（可穿戴） | 18 ~ 22 h 佩戴 | 主要在佩戴期 | V_d 按佩戴天 | 取最长连续未充电天数做校验 |
| 一次性使用（无重复充电的行业设备） | 极低 | 只在维护窗口 | V_d 极低，需另按保持期评估 | 寿命瓶颈往往不是 TBW 而是保持期 |
如果产品承诺「5 年质保」，那寿命公式里的年限就用 5 年，不论设备实际上是一天开机 4 小时还是 24 小时。开机小时只影响峰值写入带宽的校核与突发磨损的放大，不影响总量。把「实际开机少」当成「可以少配容量」是典型的错误——客户按自然年算，你按开机小时算，两边对不上。
| 口径 | 定义 | 适用场景 | 会带来的偏差 |
|---|---|---|---|
| 日历天口径 | V_d 按 365 天累计 | 7×24 设备、承诺按自然年 | 基准口径，无偏差 |
| 开机小时折算 | V_d × (开机小时 / 24) | 间歇运行设备 | 总量变小，若误用于选型会导致容量偏小 |
| 峰值折算 | V_p 按最大连续时段累计 | 极端写入集中场景 | 总量变大，若直接用会导致容量偏大 |
| 混合口径 | 总量用日历天，峰值单独校核 | 有峰谷差异的业务 | 推荐做法，两头都不失真 |
4. 负载画像库
这一章给六类典型场景的负载画像。画像的价值在于给出一个可复用的起算区间，避免每个项目都从零拆解。数值均为行业经验区间，实际项目仍需实测校准。
4.1 路由器 / T-BOX 类：日志与配置
这一类的典型特征是：写入量不大但持续不断，写入粒度极小，留存周期短。核心负载是系统日志、运行日志与配置变更回写。
| 子场景 | 日均写入量 V_d | 写入粒度 | 留存周期 | WAF 估计 | 注意 |
|---|---|---|---|---|---|
| 家用路由器（普通负载） | 10 ~ 100 MB/天 | 单条日志 200 B ~ 2 KB | 7 ~ 30 天滚动 | 1.3 ~ 2.0 | 几乎全天在线，但写入量很小 |
| 商用路由器（多协议 / 流量统计） | 100 MB ~ 2 GB/天 | 1 KB ~ 16 KB | 30 ~ 90 天滚动 | 1.5 ~ 2.5 | 会话表与流量统计是主要写入源 |
| T-BOX 车载（基础） | 100 MB ~ 1 GB/天 | 轨迹点 32 ~ 128 B | 30 ~ 90 天 | 1.5 ~ 2.5 | 轨迹点是持续小粒度写入 |
| T-BOX 车载（含行车记录） | 1 ~ 10 GB/天 | 视频片段 2 ~ 32 MB | 长期保留或分段 | 1.8 ~ 3.5 | 视频是大块顺序写，WAF 反而较低 |
| 工业网关（数据采集） | 500 MB ~ 20 GB/天 | 采样块 512 B ~ 8 KB | 30 ~ 365 天 | 1.8 ~ 3.5 | 留存长时对容量影响大 |
4.2 智能手表与可穿戴：日志深度很小
可穿戴设备的写入负载经常被严重高估，因为「传感器一直在采样」听起来很可怕。实际上：
- 采样数据通常不必落盘：绝大多数传感器数据在 MCU 的 RAM 里被算法消费掉，不需要每条都写进 flash。
- 真正落盘的是三类：算法结果与计步汇总（分钟级聚合）、异常事件日志（低频）、配置与固件（很少）。
- 容量瓶颈往往不是日志而是 OTA 镜像与录音缓存：这几项单次量大但发生频率极低。
| 写入项 | 日均写入量（经验区间） | 写入粒度 | 留存 | 说明 |
|---|---|---|---|---|
| 传感器采样原始数据 | 0 ~ 100 MB/天（多数为 0） | 单条 8 ~ 64 B | 不落盘或极短 | 通常在 MCU 内消费，不进 flash |
| 分钟级聚合结果 | 1 ~ 20 MB/天 | 512 B ~ 4 KB | 7 ~ 30 天滚动 | 计步、心率、卡路里等汇总值 |
| 异常事件日志 | 0.1 ~ 10 MB/天 | 256 B ~ 4 KB | 30 天以上 | 跌落、异常心率、低电量等 |
| 系统与协议栈日志 | 0.5 ~ 15 MB/天 | 100 B ~ 1 KB | 7 ~ 14 天滚动 | 蓝牙配对、系统事件、重连原因 |
| OTA 固件镜像缓存 | 0 ~ 100 MB/天（均摊） | 数 MB ~ 数十 MB | 升级前后短时 | 双分区或临时缓存，寿命影响小 |
| 录音 / 短语音片段 | 0 ~ 100 MB/天 | 数百 KB ~ 数 MB | 按业务定 | 有录音功能的机型才需计入 |
把「传感器采样频率 × 传感器数量 × 一天」直接当成 flash 写入量，会高估一到两个数量级。正确做法是先问一句：这些采样数据真的需要持久化吗？绝大多数中间数据只在 RAM 里流转，落盘的只有聚合值与事件。附录 C 的 10.2 算例用一个真实量级的数字说明了这个差距。
4.3 手机与平板：系统分区与用户数据分离
手机与平板的存储负载必须拆成两类完全不同的对象来算，否则容量判断会严重失焦：
| 分区类别 | 写入量特征 | 寿命诉求 | 容量判断依据 | 更换周期影响 |
|---|---|---|---|---|
| 系统分区 | 日志、OTA 双分区、App 数据、缓存回写 | 要求 3 年以上不失效 | 日均写入 × 换机周期 × k | 换机周期 3 ~ 5 年是寿命基准 |
| 用户数据（照片 / 视频 / App） | 写入量极大但对寿命不敏感 | 只要不出坏块即可 | 容量按业务数据量，不按寿命 | 换机即整体淘汰，寿命压力小 |
| 应用沙盒（高频 App） | 小文件频繁覆写，WAF 高 | 局部磨损不均更明显 | 看该 App 的写入频次 | 沙盒频繁重建会造成写放大 |
| 缓存分区 | 写入最频繁，可随时丢弃 | 寿命压力最大 | 按缓存大小与刷新频率估 | 清理不影响数据，但加速磨损 |
| 安全 / 密钥分区 | 写入极低频但要求长期可靠 | 要求 5 ~ 10 年 retention | 容量按体积，写入量几乎不计 | 这一分区的瓶颈是保持期而非 TBW |
对手机与平板，容量档位的第一决定因素是业务数据量与机身厚度，不是寿命。寿命只决定「在同一个容量档位里，该选哪个耐久等级」。例如同样是 256 GB，高端机与入门机的 TBW 需求可能差两倍，但两者的容量选择逻辑是一样的。不要用寿命倒推容量。
4.4 工业与车规：宽温与车规对寿命的影响
工业（-40 ~ 85 ℃）与车规（-40 ~ 85/105 ℃）的差别不只是温度范围，更是「温度降额」这件事被写进了标称值。
| 维度 | 商规（0 ~ 70 ℃） | 工规（-40 ~ 85 ℃） | 车规（-40 ~ 85 / 105 ℃） | 对寿命的影响 |
|---|---|---|---|---|
| P/E 标定温度 | 25 ℃ 标定，不降额 | 高温段需降额或另给版本 | 按高温段标定或双版本 | 高温版 P/E 常降到标称的 50% ~ 80% |
| TBW / DWPD 口径 | 按标称给 | 常同时给常温版与高温版 | 按车规温度口径给 | 同一料号不同温度版本的 TBW 可能差一倍 |
| 数据保持期 | 常给出明确年限 | 需覆盖高温断电存放 | 要求覆盖停驶期高温存放 | 高温保持期可能先于 TBW 到期 |
| 选型注意 | 消费 / 通用设备 | 工业网关、仪表、户外设备 | 车载 T-BOX、仪表、ADAS 记录 | 必须核对工作温度对应的 TBW 版本 |
不少器件在规格书里同时给出商规与工规（或车规）两个 TBW / DWPD 值，差别来自温度降额。选型时务必确认你引用的是哪个温度档位的数值。市场分析里最常见的错误就是拿商规 TBW 去论证车规项目——数字很漂亮，实测一定不达标。
4.5 SSD / 存储卡：高写入负载
这一类的写入量通常是全场景里最高的，而且它本身就是容量档位的消费者——很多「SSD 场景」其实是数据中心、监控录像、AI 训练等垂直应用的写入需求。
| 子场景 | 日均写入量（经验区间） | 写入模式 | 典型 DWPD 需求 | 容量档位量级 |
|---|---|---|---|---|
| 消费级系统盘 | 10 ~ 60 GB/天 | 随机与顺序混合 | 0.1 ~ 0.3 | 512 GB ~ 2 TB |
| 游戏主机 / 高频读写 | 20 ~ 100 GB/天 | 顺序为主，峰值高 | 0.2 ~ 0.5 | 1 ~ 4 TB |
| 监控录像（NVR / 相机） | 100 GB ~ 数 TB/天 | 连续视频流，顺序写 | 1 ~ 3 | 1 ~ 16 TB |
| 数据中心日志 / 缓存盘 | 数百 GB ~ 数 TB/天 | 高强度随机写 | 1 ~ 3（企业级） | 3.84 ~ 30 TB |
| AI 训练数据集盘 | TB 级/天 | 顺序大块写为主 | 0.5 ~ 1（容量优先） | 数十 TB 起 |
| 工业级存储卡（持续记录） | 50 GB ~ 1 TB/天 | 顺序写，稳态要求高 | 1 ~ 3（宽温版） | 64 GB ~ 1 TB |
4.6 画像参数速查表
下面这张表是本章的浓缩版，也是第 10 章算例的参数来源。全部为行业经验区间，用作起算与交叉校验，实际项目请以实测流量与器件规格书为准。
| 场景 | V_d（GB/天） | WAF | T_r（天） | k_b | 推荐 k | 首要制约 |
|---|---|---|---|---|---|---|
| 家用路由器 | 0.01 ~ 0.1 | 1.3 ~ 2.0 | 7 ~ 30 | 1.2 ~ 1.5 | 1.5 | 几乎无，写入量太小 |
| 商用路由器 | 0.1 ~ 2 | 1.5 ~ 2.5 | 30 ~ 90 | 1.5 ~ 2.5 | 1.8 | 留存长度 |
| T-BOX 车载基础 | 0.1 ~ 1 | 1.5 ~ 2.5 | 30 ~ 90 | 1.5 ~ 2.5 | 1.8 | 宽温降额 |
| T-BOX 含记录仪 | 1 ~ 10 | 1.8 ~ 3.5 | 7 ~ 90 | 1.5 ~ 3.0 | 2.0 | 写入量与容量双高 |
| 智能手表 / 可穿戴 | 0.002 ~ 0.02 | 1.3 ~ 2.2 | 7 ~ 30 | 1.2 ~ 1.5 | 1.5 | 容量小，日志深度极浅 |
| 手机 / 平板系统分区 | 0.5 ~ 5 | 1.5 ~ 3.0 | 7 ~ 365 | 1.5 ~ 3.0 | 2.0 | 换机周期与 OTA 双分区 |
| 工业网关 | 0.5 ~ 20 | 1.8 ~ 3.5 | 30 ~ 365 | 1.8 ~ 3.0 | 2.0 | 高温降额加长留存 |
| 监控录像 / NVR | 100 ~ 3000 | 1.2 ~ 2.0 | 7 ~ 30 | 2.0 ~ 5.0 | 1.8 | 写入带宽与稳态掉速 |
| 数据中心日志盘 | 200 ~ 3000 | 2.0 ~ 4.0 | 7 ~ 90 | 1.5 ~ 2.5 | 1.5 | 随机写放大 |
| 工业级存储卡 | 50 ~ 1000 | 1.2 ~ 2.0 | 30 ~ 90 | 2.0 ~ 4.0 | 1.8 | 宽温加稳态带宽 |