做 AI 应用的人聊基础设施，聊得最多的是算力（GPU 多贵）和模型（选哪家），存储经常是最后才想起来的一环。但真跑起来会发现：AI 应用的存储用法和传统应用差别很大，按老习惯选型，账会在三个地方出问题。
用法一：向量化的「读放大」
传统应用的文件是「写一次读多次」，AI 应用多了一层：文件（PDF/文档）进系统要先做解析和向量化——每个文件入库时触发一串读取（取文件→分块→embedding 回写）。这意味着写入路径上的读请求密度远超传统场景，选型时只看「存储容量单价」不看读写吞吐配额，冷启动批处理时就会撞限流。
实操建议：入库批处理的读取走内网 endpoint（不走公网，吞吐和成本都差一个量级），并给批处理任务配独立的限流通道，别和在线服务抢配额。
用法二：生命周期分层比想象中来得快
AI 应用的文件有很强的「温度」特征：解析完成后的原始文件，访问频率断崖式下跌（向量库接管了检索）；用户上传的临时文件，大概率再也不看。冷数据的归档分层来得比传统应用快得多——上传 7 天后转低频、30 天转归档，这个策略对多数 AI 应用直接成立。
反向提醒：embedding 模型升级时要全量重新处理文件——归档层的文件取回有解冻延迟，升级窗口要提前算上这段。我们吃过这个亏：计划两小时的重索引，解冻就等了半天。
用法三：成本要算「全链路」不是「单单价」
存储单价只是账单的一部分。AI 应用的真实存储成本链：容量 + 请求次数（读写 API 调用费）+ 流量（文件给前端、给批处理）+ 取回（归档解冻）。高频小块读写场景，请求费和流量费反超容量费是常态——盯着容量单价选型，方向就错了。
一个快速自检：拉一个月账单，把四项拆开看占比。容量费占比低于一半的团队，优化空间都在用法侧（合并小对象、内网传输、生命周期），换更便宜的存储反而没用。
结语
AI 时代的基础设施账，存储是最容易被低估的一项——它的用法变了，选型的脑子也得跟着换。三个用法看下来共同的底层逻辑：为访问模式付费，而不是为容量付费。
