2026 年还在用一台 NAS 加几块移动硬盘存素材的团队，基本都会在某一个节点被现实教育一次：盘坏了、素材没了、客户还在催源文件。于是很多人把目光转向 MinIO——开源、S3 兼容、能跑在普通 x86 服务器上，看上去就是"自己搭一个云对象存储"的平替方案。软件本身不难，装起来半小时的事，真正难的是下单服务器那一刻：到底要几块盘？8+3 还是 12+4？出网带宽买固定还是走 95 计费？一台 36 盘位的高密度机器，能不能直接顶一个四节点集群？为什么同样是 200TB 裸容量，有人装完之后只剩 130TB 可用？
这篇不聊 MinIO 怎么装、客户端怎么配，网上教程一堆。这篇只聊花钱的那部分：硬件六个维度怎么拆、纠删码配比怎么算、出网带宽的账怎么记、什么规模自建才真的比直接买云厂商的对象存储便宜、什么地方千万别自己上。
核心结论先看这五条：
1. 买容量先看纠删码后的可用容量，别看裸容量。12+4 配比下 200TB 裸盘只剩 150TB 可用，8+3 只剩 145TB 左右，差的这几十 TB 就是你白掏的钱。下单前先把总数除一遍。
2. 出网带宽才是长期最大成本项。机器和盘的钱是一次性的，出网的钱每个月都在跑。按 95 计费还是按固定带宽买，一年下来的差价可能够再买半台机器。
3. 单盘容量别贪大。20TB 以上的企业级 HDD 坏一块，重建窗口动辄一两天，这段时间你等于少了一层容错，是最危险的时候。
4. 单节点多盘不等于多节点。一个机箱里的 36 块盘，抗得住坏盘，抗不住整机掉电、背板故障、机柜 PDU 跳闸、机房市电事故。
5. 自建和云的分界线，大概在"可用容量几百 TB + 出网持续跑满几百 Mbps"这个量级。低于这个量级，云对象存储按量付费多半更省心；高于它，自建摊薄之后的单位成本会明显更低。
很多人把对象存储理解成"一个能挂载的网盘"，这是最常见也最贵的误会。块存储给你一块裸盘，你来格式化；文件存储给你目录树，能改能追加；对象存储给你的是一个扁平的桶（bucket），里面放一堆带 key 的对象，只能整体读写、不能就地改一半。MinIO 就是后者——它对外说的是 S3 那套 API（PutObject、GetObject、ListObjects），你的应用得按 S3 的方式去写，不是 NFS 挂载上去就能当本地目录用。
这个差别直接决定了硬件选型方向：对象存储的重心是容量密度、出网吞吐、盘故障后的自愈能力，而不是单文件的随机小写延迟。所以你会看到 MinIO 集群大量用 7200 转的企业级近线 HDD，而不是全闪。反过来，如果你真要的是"几十个人同时在NAS上改同一个 PSD 文件"，那该买的是文件存储方案，不是 MinIO。
同样是"自建对象存储"，业务不一样，配置差得非常远，照抄别人的单子基本都要吃亏：
图片/视频素材库——文件大（几十 MB 到几个 GB），读多写少，出网压力集中在下载。这类最吃出网带宽，盘用大容量 HDD 就行，内存可以给得保守一点。
备份归档——写入是持续的大流式写入，几乎不读，除非出事。这类对出网带宽要求最低，对裸容量和单 TB 成本最敏感，是自建最划算的场景之一。
AI 训练样本池——几个 TB 到几百 TB 的小文件（几十 KB 到几 MB 的图片、音频切片），训练时几百个并发同时读。这类最容易被小文件 IOPS 和元数据内存打死，往往需要 SSD/NVMe 做热层，或者干脆把样本打包成大文件再喂进去。
私有云盘 / 内部文件分发——读写都中等，但对访问质量和可用性敏感，跨网访问（电信访问联通、内地访问中国香港节点）体验直接决定用户骂不骂人。这类线路权重最高，BGP 多线几乎是硬要求。
纠删码（Erasure Coding，业内简称 EC）是 MinIO 不用 RAID 也能抗坏盘的核心。它把一个对象切成 N 个数据块，再算出 M 个校验块，一共 N+M 块，分散写到不同的盘（最好在不同的节点）上。只要坏的盘数不超过 M 块，数据就能靠剩下的块算回来，一个对象都不丢。
于是可用容量的算法非常简单：可用容量 = 裸容量 × N ÷ (N+M)。校验块不存真实数据，纯粹是拿来救命的开销。MinIO 里这个参数写成 EC:N 的形式，N 指的是校验盘的数量，比如默认 EC:4 就是"总盘数减 4 块做数据，4 块做校验"；一个纠删码集合（erasure set）里的盘数上限通常是 16，所以 12+4 正好顶到这个上限。
拿 16TB 企业级 HDD 举例，算三种常见配比，差别非常直观：
8+2（10 块盘）：裸容量 160TB，利用率 80%，可用 128TB，最多同时坏 2 块盘。盘数少、省钱，但容错只有 2 块，盘一多风险就上来了。
8+3（11 块盘）：裸容量 176TB，利用率 72.7%，可用约 128TB，最多同时坏 3 块盘。注意这里有个很反直觉的点——8+3 比 8+2 多买了一块盘，可用容量几乎没变，换来的是容错从 2 块提到 3 块。这笔钱买的是重建窗口里的安全感，不是容量。
12+4（16 块盘）：裸容量 256TB，利用率 75%，可用 192TB，最多同时坏 4 块盘。这是目前最主流的配比，容量利用率和容错能力平衡得最好，而且 16 刚好是一个 erasure set 的上限，盘位规划上也好整除。
再看一个真实点的规模：4 节点、每节点 12 块 16TB，总裸容量 768TB，12+4 配比（每节点 3 块校验的逻辑分布到 4 节点），可用容量大概在 500–580TB 区间，具体取决于你实际的条带分布方式。下单前一定要拿这个数去对合同，别拿 768TB 去跟老板汇报。
有人觉得"既然能坏 4 块，那我配 EC:8 岂不是更安全"。理论上容错是提高了，但代价很实在：校验盘越多，容量利用率越低（16 盘里配 8 块校验就是 50% 利用率，直接砍半），而且写入时需要算和写的块更多，CPU 和网络开销都上去了。
真正的容错能力不只看 M，还要看故障域。MinIO 是把条带的数据块和校验块按盘、按节点打散的，如果你只有 1 个节点、16 块盘，那 EC:4 的"坏 4 块盘不丢数据"是真的；但如果是 4 节点、每节点 4 块盘，配 EC:4，那它扛的是"任意坏 4 块盘或者整个 1 个节点挂掉"，实际冗余度更高。这就是为什么多节点比单节点多盘值钱——同样的校验开销，买到的保护范围不一样。
纠删码不是免费的。写入时要把一个对象切成 N 份再算 M 份校验，读取时如果有盘坏了或者数据不一致，还要现场反算——这些都是实打实的 CPU 指令。好消息是：现代 CPU 的 SIMD 指令集（Intel 的 AVX2 / AVX-512）对这类矩阵运算有专门加速，MinIO 底层的纠删码库也做了对应的优化，所以大文件顺序读写场景下，CPU 通常不是瓶颈，网卡和盘先到顶。
经验区间是这样的：大文件（几十 MB 以上）流式写入，单节点跑到万兆网卡跑满（约 1.1 GB/s 量级），中等规格的 CPU 占用通常还有余量；但一旦切到小文件高并发——比如几万个几十 KB 的对象并发 PUT/GET——画风就变了。每个请求都要走一遍 HTTP 解析、签名校验、元数据读写、纠删码切分，进程/协程的上下文切换次数暴涨，CPU 软中断和系统调用占比明显上升，这时候核数比主频更重要。
选型上给个实在的建议：大文件场景，单路或双路中端 CPU（十几到二十几核）就够用；小文件高并发场景，优先堆核数，双路机型会舒服很多。另外别忽略 AES-NI——如果你开了服务端加密（SSE），加解密全靠它，没有硬件加速的 CPU 在小文件场景会明显吃力。至于要不要上旗舰级 CPU，说实话，做对象存储基本没必要，省下来的钱加到内存和出网带宽上收益大得多。
内存这块是自建对象存储最容易被砍错的地方。很多人按"存储机器嘛，给个 32GB 得了"来配，跑起来之后发现问题全出在这。
内存主要吃在三处：元数据缓存（每个对象的 key、版本、大小、修改时间这些索引信息，MinIO 会尽量让它们待在内存里）、并发连接的缓冲区（每个 HTTP 连接、每个在飞的分段上传都要占一部分）、以及纠删码计算时的临时缓冲。
起步建议：单节点 32GB 是最低门槛，64GB 是比较舒服的起点，128GB 适合对象数到千万级或者并发连接常年在几千以上的场景。一个粗略的经验是对象数越多、平均文件越小，内存需求越高——同样是 100TB，存 100 万个 100MB 的视频，和存 2 亿个 500KB 的图片，后者对内存的压力可能是前者的几倍甚至十几倍，因为元数据量差了两个数量级。
还有一点容易被忽略：内存不足不会直接报错，而是表现为延迟莫名其妙变高、ListObjects 越来越慢。因为元数据被打到盘上去了,而 HDD 的随机 IOPS 只有一两百，一卡顿业务侧就是"怎么突然这么慢"。与其事后加内存导致停机，不如一开始就按 64GB 起步配，内存这一项在整机成本里占比本来就不高，是性价比最高的保险。
对象存储的容量主体，现在基本是企业级大容量近线 HDD 的天下：希捷银河 X18/X20/X22 系列（16/18/20/22TB）、西数 Ultrastar DC HC550/HC560/HC570、东芝 MG09/MG10 系列，都是常见的选型。它们的共同点是 7200 转、氦气封装、CMR（传统磁记录）为主、年负载率 550TB/年这个量级、MTBF 标称 250 万小时。
SSD 在这套架构里通常不是拿来堆容量的，而是做热层或缓存层：把最近访问频繁的对象放 SATA/SAS SSD（3.84TB、7.68TB、15.36TB 是常见档位）或者 NVMe U.2（三星 PM9A3、Solidigm D5-P5316/D7-P5620、铠侠 CM6/CD6 这一档），冷数据自动沉降到 HDD 池。全闪存的对象存储当然存在，但那是给 AI 训练样本池、实时日志这种极端 IOPS 场景准备的，单 TB 成本高出一个量级，普通素材库别碰。
有一条红线：别拿消费级/桌面级硬盘做容量池。SMR（叠瓦磁记录）的盘在随机写和重建场景下性能会断崖式下跌，重建时间能拉长到无法接受；桌面盘也没有 TLER/ERC 这类超时控制，动不动就被控制器踢出阵列，导致"盘其实没坏但被判死了"的假故障。
这条要单独拎出来讲，因为它直接决定你会不会丢数据。
一块盘坏了，MinIO 会把缺失的块重算出来，写到备用盘上，这个过程叫重建（heal）。重建的速度主要受限于目标盘的持续写入带宽和集群当时的业务负载，不是一个固定的数。按企业级大容量 HDD 的持续写入通常在 150–250 MB/s 这个量级估算：
16TB 的盘，全盘重建大概在 18–30 小时量级；
20TB 的盘，大概在 24–36 小时量级；
22–24TB 的盘，大概在 30–48 小时量级，如果业务还在正常跑、重建要和业务抢 IO，拖到两三天甚至更长都很常见。
也就是说，你为了降低单 TB 成本买的更大容量的盘，换来的是一次坏盘后长达一两天的脆弱期。这段时间里集群处于"容错额度已经被用掉一块"的状态，8+3 只剩能再坏 2 块，12+4 只剩能再坏 3 块。这时候如果同批次、同型号、同固件、同服役时长的盘里再坏一块——这在现实里一点都不罕见，因为它们的磨损曲线几乎是重合的——风险就实打实了。
怎么平衡？我的建议是：容量池单盘优先选 16TB 或 18TB，别一头扎进 22TB/24TB。更大的盘当然能省盘位和电力，但前提是你要么有足够的节点把条带打散得更宽，要么能接受更长的重建窗口。如果是归档场景、业务几乎不读、重建可以不限速跑，那上大容量盘是划算的；如果是在线素材库，业务白天一直有流量，我更倾向多盘位 + 中等单盘容量。
盘位数不是越多越好，但确实有下限。一个纠删码集合的盘数上限通常是 16，所以单节点 12 盘位、16 盘位、24 盘位（两个 set）、36 盘位（需要整除规划）都是常见选择。要注意 MinIO 要求集群里每个节点的盘配置尽量一致，而且盘的总数最好能被 set 大小整除，不然会剩下一些盘用不上或者被迫降级成较小的 set，白白浪费容量。
扩容上，MinIO 支持加新的 server pool（一组配置相同的节点），但不支持随意往老 pool 里塞一两块盘。这意味着你第一次下单的盘位规划，基本决定了未来两三年的扩容粒度：一次扩一整个 pool（比如再买 4 台同配机器），而不是"加两块盘"。买之前务必想清楚三年后的容量目标，别买个 8 盘位机器用到一半发现扩容只能整机整机加。
IDC 行业里，入网（别人往你服务器上传、也就是你集群的写入方向）通常非常便宜甚至不计，出网（你服务器往外发数据、也就是下载方向）才是按 Mbps 或者按流量实打实收钱的那一头。原因很朴素：运营商之间的结算和骨干网的扩容成本，主要压在流量出口这一侧。
对对象存储来说这个不对称特别致命，因为对象存储的典型动作就是"下载"——用户看图片、拉视频、训练机读样本、分支办公室同步备份，全都是出网。你买一台服务器花三五千一个月，可能出网带宽那一项就要花掉三五千甚至更多。我见过太多团队把预算全砸在盘上，结果机器到位之后发现出网带宽买小了，用户一访问就卡，加带宽的钱比机器还贵。
算一笔具体的账：100 Mbps 出网如果全天跑满，一个月理论出网流量大约是 100 Mbps × 30 天 ≈ 31–32 TB；300 Mbps 跑满就是接近 95 TB；1 Gbps 跑满则是 300 TB 以上。你把这个数字乘以流量单价，就能大致判断"按流量计费"和"按带宽计费"哪个更划算。
固定带宽（峰值计费）：你买一个带宽上限，比如 100 Mbps，不管你用没用满，都按 100 Mbps 收钱。好处是账单可预测、不用担心突发流量爆表；坏处是如果你的业务峰谷很明显（白天高、夜里几乎为零），那你大量时间在为用不到的带宽付钱。
95 计费（月 95 峰值的简称）：服务商每 5 分钟采样一次你的出网带宽，一个月下来拿到几千个采样点，把最高的 5% 的点去掉，用剩下点里最高的那个作为计费带宽。好处是对峰谷明显的业务非常友好——你偶尔冲到 500 Mbps，但只要这种尖峰不超过每月 5% 的时间，就不计入计费；坏处是账单不固定，业务模式一变，下个月的钱可能差很多。
怎么选？给个直接的判断：如果你的出网曲线比较平稳（素材分发、持续的训练读取、常态化备份同步），买固定带宽更简单也更可控；如果曲线是尖峰型的（活动期间爆量、版本发布时集中下载、白天高夜里低），95 计费通常能省下一大截。另外一定要问清楚三件事：出网是独享还是共享、超出部分怎么算、入网收不收钱。这三个问题不问清楚，签完合同才发现的成本最难受。
盘和 CPU 决定你的存储能存多少、跑多快，线路决定的是"用户觉得快不快"。这两件事经常被混为一谈，但它们完全是两回事——你集群内部读写飞快，不代表广州的联通用户打开你服务器上的图片不转圈。
单线（比如纯电信、纯联通）价格最低，同网访问质量很好，但跨网访问就完全看运营商之间的互联互通脸色，晚高峰抖动、丢包都可能出现。适合访问群体高度单一的场景，比如内部备份、只给电信宽带用户用的素材分发。
BGP 多线是主流选择：机房同时接入多家运营商，通过 BGP 协议自动选路，电信用户走电信、联通用户走联通、移动用户走移动，跨网质量明显好于单线。代价是价格通常比单线高一档（经验区间在 20%–50% 上下，具体以咨询为准）。做私有云盘、对外素材库、多分支办公同步的，BGP 基本是硬要求，别省这个钱。
跨境这块要说清楚。中国内地访问中国香港节点的往返时延，通常在 30–80 ms 这个量级；到新加坡通常在 40–100 ms 量级；到美西通常在 150–200 ms 量级；到欧洲通常在 200–300 ms 量级。这些都是"通常"和"量级"，实际值受具体机房、具体运营商、峰值时段影响很大，别拿来做承诺，要准确数据就得自己用 mtr / ping 在目标时段实测。如果业务主体在内地、回源和下载也主要在内地，优先放内地节点；如果是对外分发、或者内地访问需要走 CN2 GIA 这类优质回程线路，再考虑中国香港节点——注意这里说的是中国香港，跨境链路的稳定性和备案要求跟内地节点不是一个玩法，下单前把用途和流量模型讲清楚。
自建对象存储最后一个硬件维度是机房，也是最容易被当成"无所谓"的一项。
磁盘密度决定了你的单 TB 空间成本。常见形态是 4U 36 盘位（3.5 英寸），密度更高还有 4U 60 盘位、甚至 4U 90/106 盘位的高密度存储服务器（用 SAS 扩展器实现）。盘位密度越高，单机柜能塞的容量越大，摊到每 TB 的机柜租金和电力就越低——但反过来，单机故障的影响面也越大，一台 106 盘位的机器挂掉，就是一百多块盘同时离线。密度和故障域是一对矛盾，规模小的时候别上超高密度机型。
电力是长期成本里排第二的（第一是出网带宽）。一台满配 36 块企业级 HDD 的 4U 存储服务器，整机功耗通常在 500–900W 这个量级，启动和重建时瞬时功耗更高。机柜一般按电流（A）或者按 kW 计费，一个 42U 机柜能给你多少安，直接决定你能放几台机器。下单前问清楚：机柜给多少 A、超了怎么算、是不是双路供电。
机架空间要留余量。42U 标准机柜，放 4U 的存储服务器理论上能塞 10 台，但你还得放交换机、PDU、理线，实际能放 8 台左右就不错了。别把柜子塞满，后期加机器、换盘、走线都需要操作空间。
异地副本（站点复制 / 桶复制）是容灾的最后一道保险，但它有个非常现实的代价：写入带宽直接翻倍。你往主站点写 100 Mbps，主站点就要往备站点再同步 100 Mbps，两边加起来是 200 Mbps 的量。而且跨站点的往返时延会直接影响同步延迟，如果两地之间网络抖动，同步积压会让备站点一直落后。做异地副本之前先把带宽预算做进去，别等到账单一出来才发现是双份。
这一条值得单独开一节，因为它是自建对象存储里最贵的认知错误。
一台 36 盘位的机器，配 EC:4，理论上能坏 4 块盘不丢数据——听起来很够用。但这台机器上有大量共享故障域：两个电源（如果是 1+1 冗余还好，单电源就完了）、一块主板、一张 HBA 卡或 SAS 扩展器、一块背板、一张系统盘、一个机柜 PDU、一路市电、一个机房。任何一个环节出问题，36 块盘会同时离线，纠删码一瞬间全部失效。
换成 4 节点、每节点 8 块盘，同样 32 块盘、同样的 EC:4，情况就完全不同了：MinIO 会把条带的数据块和校验块打散到不同节点上，整个一台机器掉线，剩下 3 个节点仍然能算出完整数据，业务不中断，等你把机器修好再加回去，它会自动补齐。这就是多节点真正的价值——它把"坏盘"这个高频小事故和"整机/机柜/机房事故"这个低频大事故，分开处理了。
所以结论很明确：预算有限时，宁可 4 台 8 盘位的机器，也别买 1 台 36 盘位的机器。前者贵一点（多 3 份 CPU、内存、主板、机位），但换来的是扛得住整机故障。MinIO 官方对分布式部署的建议也是 4 节点起步，这不是随便定的数。真要省钱，省在 CPU 和单盘容量上，别省在节点数上。
存储圈有句老话：磁盘阵列不是在你坏盘的时候失败，是在你换盘重建的时候失败。这句话在纠删码里同样成立，甚至更成立——因为纠删码的重建要把大量数据重新算一遍、再分散写到多块盘上，对剩余所有盘都是一次全量读压力。
重建期间会发生几件事：剩余盘的读 IO 被打满，业务延迟明显上升（用户感觉到"怎么今天特别卡"）；重建本身要占网络带宽，如果是跨节点重建，节点间网络也会吃紧；如果盘是同一批次采购的，它们的磨损曲线高度重合，第二块盘在重建期间出问题的概率并不低。这时候 8+3 只剩能再坏 2 块，12+4 只剩能再坏 3 块，一旦跌破阈值，就是真的丢数据。
能做的事其实不多但都很有效：一是采购时分批、分品牌、分批次，别一次性买 36 块同型号同批次的盘；二是给重建限速，MinIO 允许你限制 heal 的速率和并发，宁可重建慢一点，也别把业务打死，更别把所有盘的 IO 同时拉满；三是监控 SMART，重点关注 Reallocated Sectors、Pending Sectors、UDMA CRC Error 这几项，出现趋势性增长就提前换盘，而不是等它彻底挂掉；四是留热备盘，让热备盘自动顶上，把人工介入的时间从"几天"压到"几小时"。
很多人算容量只算"我现在有多少数据"，结果上线半年发现容量掉得远比预期快，问题基本出在这三处。
版本控制（Versioning）：开了版本控制之后，每次覆盖同名对象，旧版本不会被删，而是作为历史版本继续占容量。这对于防误删、防覆盖非常有价值的，但如果你每天往同一个 key 写一个新版本，一年下来就是 365 份历史数据。必须配合生命周期规则，比如"保留最近 30 个版本"或者"非当前版本 90 天后删除"。
生命周期管理（ILM）：这是控制容量增长的核心工具——过期对象自动删除、N 天后沉降到低频/归档层、清理过期删除标记（delete marker）。很多团队开了版本控制却没配生命周期，等于开了一个容量无底洞。另外记得定期清理未完成的分段上传（multipart upload 传了一半失败留下的碎片），这部分数据你看不见、算不到，但实实在在占着空间，MinIO 的控制台和 mc 命令都能扫出来。
小文件的元数据压力：这是最隐蔽的一项。每个对象不管多小，都要占一份元数据。1 亿个 50KB 的对象，实际数据只有 5TB，但元数据量和索引规模会吃掉大量内存，ListObjects 会慢到不能用，HDD 上的随机读 IOPS 会被彻底打死（企业级 HDD 的随机读 IOPS 通常只有一两百这个量级）。应对办法很直接：把小文件打包——AI 训练样本打成 tar 包、Parquet 或者 WebDataset 格式，日志按小时合并成大文件，图片按批次归档成 zip；或者把热数据放 SSD/NVMe 层，让元数据和小对象走闪存。这两种办法通常要一起用。
下面这张表按"从入门到规模化"排了 5 档配置，对应 5 类常见的服务商形态。价格部分分两类：标注"以官网实时价为准"的是官网明示档位，标注"预估"的是按行业公开区间推算的范围，都不是承诺价。
| 配置档位（盘位/CPU/内存） | 裸容量 / 纠删码后可用容量 | 磁盘类型 | 公网带宽与计费 | 价格区间 | 适合谁 |
|---|---|---|---|---|---|
| 入门单节点：4–8 盘位 / 单路 E5 级或同档 / 32–64GB | 64–128TB 裸 / 8+2 后约 51–102TB 可用 | 8–16TB 企业级 HDD，可选 1–2 块 SSD 做缓存 | 30–100 Mbps，固定带宽为主 | ¥999/月档（裸金属 E5-2620，以官网实时价为准）；整机 ¥0.2–0.5万/月（预估，以下单核算为准） | 10 人以内小团队的私有云盘、内部备份，先跑起来验证业务 |
| 主流 4 节点集群：每节点 8–12 盘位 / 双路中端 / 64–128GB | 512–768TB 裸 / 12+4 后约 384–576TB 可用 | 16–18TB 企业级 HDD 为主，每节点 1–2 块 NVMe 做热层 | 100–500 Mbps，固定带宽或 95 计费二选一 | 单节点 ¥3999/月档（E5-2698v4×2，以官网实时价为准）；整机 ¥1.5–3万/月（预估，以下单核算为准） | 图片/视频素材库、中型 AI 团队样本池，最通用的一档 |
| 大容量归档池：36 盘位高密度 / 双路中端 / 64GB | 576–720TB 裸 / 12+4 后约 432–540TB 可用 | 18–22TB 大容量 HDD，写入密集、读取极少 | 30–100 Mbps，入网占比高、出网压力小 | ¥0.8–2万/月（预估，以下单核算为准） | 备份归档、合规留存、磁带替代，对单 TB 成本最敏感 |
| 全闪热层 / 小文件型：8–12 盘位 U.2 / 双路高核数 / 128–256GB | 60–180TB 裸 / 12+4 后约 45–135TB 可用 | NVMe U.2 3.84–15.36TB（PM9A3 / P5620 / CM6 一档） | 500 Mbps–1 Gbps，建议 95 计费 | ¥2–5万/月（预估，以下单核算为准） | 亿级小文件、AI 训练样本池、高并发元数据场景 |
| 中国香港存储型：4–8 盘位 / E3 级或同档 / 32–64GB | 64–128TB 裸 / 8+3 后约 46–93TB 可用 | 16TB 企业级 HDD，兼顾容量与重建窗口 | 50–200 Mbps，CN2 GIA 回内地，跨境回源时延通常在 30–80 ms 量级 | ¥1500–1599/月档（中国香港 E3，以官网实时价为准） | 对外分发、跨境业务素材库、需要免备案对外服务的团队 |
这张表里有几个数字要单独提醒一下：可用容量那一列永远比裸容量少 20%–28%，这是纠删码的固定开销，谁家都一样；价格区间的"整机"口径包含了机器和基础带宽，但不包含超出部分的出网费用，出网是另算的；A 类官网明示档（E5-2620 ¥999、E5-2698v4×2 ¥3999、中国香港 E3 ¥1500/¥1599）都是"起"的口径，实际配置加上盘和带宽之后会高出不少，以官网实时价为准。
这是我给大多数做素材库、私有云盘的团队首推的一档，理由很实在：深圳南山自营机柜，机器是真机不是虚出来的，盘位和内存按你的配比来配，不会出现"买的 12 盘位结果只给了 8 块"这种事。双路 E5-2698v4 这一档官网明示 ¥3999 起（以官网实时价为准），核数足够撑住小文件高并发，内存直接上到 64GB 起步，省得后期停机加。网络是 BGP 多线，华南用户跨网访问质量稳定，出网带宽可以按固定也可以谈 95 计费，账单谈得清楚。真出了硬件故障，7×24 中文工单平均 5 分钟响应，硬件故障 10 分钟自动迁移，不用自己半夜跑机房。自营机柜最快 1 分钟上架，急着上线的项目这一条很救命。
如果你的素材要对外分发、或者业务本身就在境外，中国香港节点是绕不开的选择。一万网络的中国香港 E3 档是 ¥1500/¥1599（以官网实时价为准），配 CN2 GIA 回内地线路，跨境回源时延通常在 30–80 ms 量级（实际以目标时段实测为准）。这一档我建议配 16TB 的盘而不是 20TB 以上——跨境节点的换盘和运维响应时间天然比内地长，重建窗口短一点，风险就小一点。另外出网带宽在这里尤其要算清楚，跨境带宽单价通常高于内地，先按 95 计费跑一个月看曲线，再决定要不要转固定带宽，别一上来就买满。
自建对象存储不是把机器点亮就完事了，后面还有一堆琐碎事。一万网络这边有几项是免费的、值得直接用起来：每日 3 份免费系统盘快照、30 秒回滚（改配置改崩了能秒退）、5–20G 免费 DDoS 防护（对象存储一旦暴露公网，被扫被刷是常态）、免费网站备案协助（内地节点对外服务必备）、以及工程师 1 对 1 部署环境——MinIO 的部署、纠删码参数、系统盘和数据盘分离、监控告警这些，让工程师带着你过一遍，比自己啃文档快得多。深耕 IDC 19 年（成立于 2007 年）的服务商，这类工程经验的密度确实不一样。
这个问题是所有讨论的终点，也是最该算清楚的一笔账。
先说云对象存储的成本结构：存储费 + 出网流量费 + 请求次数费。按行业公开参考区间（各云官网口径不同，以官网实时价为准），标准存储的存储单价通常在 0.1 元/GB/月这个量级，公网出网流量通常在 0.5 元/GB 这个量级。拿这个量级估一下：100TB 标准存储，一个月存储费约 ¥10,000 量级；如果这个月出网了 30TB，出网费约 ¥15,000 量级，合计 ¥25,000/月 量级（预估，以实际账单为准）。看出问题了吗——出网比存储本身还贵。
再说自建的成本结构：一次性硬件投入（或者月租）+ 机柜/托管 + 电力 + 出网带宽 + 运维人力。硬件或者月租是能摊薄的，出网带宽是持续的，运维人力是最容易忽略的一项——自建意味着你得有人会看盘的健康、会处理重建、会调参数，这份人力成本在中小团队里往往是隐性的。
分界线可以这么划：
云更划算的情况：可用容量在几十 TB 以内；月出网流量在几 TB 以内；业务还在验证期、规模不确定；流量曲线尖峰极其极端（一年就爆两次，每次几个小时）；团队没有专职运维；需要多地就近加速和 CDN 配合。这些情况下老老实实买云对象存储，别折腾。
自建更划算的情况：可用容量到了几百 TB 量级并且还在稳定增长；月出网流量到了几十 TB 甚至上百 TB、并且曲线比较平稳；数据是长期留存型的（备份归档、素材沉淀、样本池），不是用完就删；团队有能扛事的技术人手。这时候自建的单位成本优势会非常明显——因为你把最贵的那一项（出网流量按 GB 计费）换成了固定带宽按 Mbps 计费，跑得越满越划算。
不划算也不该自建的情况：为了"数据在自己手里更安全"而自建，但没人做备份、没做异地副本、没监控——这是把风险从云厂商转移到了自己的盲区；以及规模明明只有几 TB，却为了"自主可控"买一台机器放着，那台机器的钱够在云上存好几年。
为什么坑：销售报给你的永远是裸容量。你以为买了 200TB，装完 MinIO 配 12+4 只剩 150TB，配 8+3 只剩 145TB，凭空少了四分之一。更糟的是，很多人按"我需要 200TB"去下单，结果只买了 200TB 裸盘，业务上线两个月就满了，扩容只能整机整机加。
怎么避：先定可用容量目标，再反推裸容量。公式是：裸容量 = 目标可用容量 ÷ (N/(N+M))。需要 150TB 可用、走 12+4，那就要买 200TB 裸。下单前让服务商在配置单上写明"裸容量 XX TB，EC 配比 X+Y，可用容量约 XX TB"，白纸黑字。
为什么坑：22TB、24TB 的盘单 TB 成本确实更低，但坏一块之后的重建窗口会拉到 30–48 小时甚至更长。这段时间你少了一层容错，而且最怕的恰恰是同批次盘连续出问题。
怎么避：在线业务优先 16TB/18TB；归档场景（几乎不读、重建可以不限速）再考虑 20TB 以上。采购时分批次、分品牌，别一次买齐同型号同批次。同时配好热备盘、给 heal 限速，把重建对业务的冲击压下来。
为什么坑：纠删码解决的是"硬件坏了还能读"，不是"数据被删了还能找回"。误删、误覆盖、应用 bug 写坏了数据、勒索软件加密，这些纠删码全都会忠实地、高效地复制到每一块盘上。不少团队开开心心配了 EC:4，结果一次 rm -rf 或者一次错误的生命周期规则，数据说没就没。
怎么避：纠删码之上必须再叠一层：版本控制 + 生命周期保留策略（防误删误覆盖）、异地站点复制（防机房级事故）、定期离线/异介质备份（防逻辑损坏）。记住一句：纠删码是高可用的手段，备份是数据安全的手段，两件事。
为什么坑：出网是自建对象存储唯一一项"每天都花钱、且随业务增长而增长"的成本。机器买小了可以加盘，出网买小了就是用户卡；按流量计费的话，一次被刷、一次活动爆量，账单可能直接翻倍。而很多人在预算阶段只算了机器和盘的钱。
怎么避：下单前先估算月出网流量（用日活 × 人均下载量 × 30 天粗算，至少估个量级），然后同时问服务商要三种报价：固定带宽、95 计费、按流量，三个数摆一起对比。上线后先跑一个月看曲线，再决定要不要调整计费方式。另外务必加防盗链和速率限制，别让你的出网带宽给别人做嫁衣。
为什么坑：HDD 的随机读 IOPS 通常只有一两百这个量级。几十 KB 的小文件一旦上量到千万、亿级，ListObjects 会慢到无法使用，读取延迟会飙到业务不能接受，元数据还会吃光内存导致整体变慢。很多人跑测试用大文件，一切正常，上线之后真实数据全是小文件，直接崩。
怎么避：先统计你真实数据的平均文件大小和对象总数，再决定要不要上 SSD/NVMe 热层。AI 训练样本优先打包成 tar / Parquet / WebDataset，日志按小时合并，图片按批次归档。内存按对象数给而不是按容量给——对象数多的，内存直接上到 128GB 甚至更高。
为什么坑：做异地复制的时候，很多人只算了一边的带宽。实际上每一次写入都要在站点之间再传一份，出网/入网压力是双份的，跨站点时延还会造成同步积压。等到账单一出来才发现预算不够，只能把副本关掉——那就等于白做了。
怎么避：规划阶段就把异地同步的带宽按"主站点写入峰值 × 2"来算，并且明确两地之间的链路质量和时延区间（跨境的话通常在几十到几百 ms 量级，以实测为准）。如果带宽预算吃紧，可以用异步复制 + 错峰同步（夜间限速同步）来削峰，或者只对核心桶做复制，冷数据不复制。
严格说一台也能跑，单节点多盘、配纠删码，抗坏盘能力是有的。但我不推荐——单节点的共享故障域太多，整机掉电、主板故障、背板故障一来就全挂。真要上生产，按 4 节点起步规划，每节点 8–12 块盘。预算确实紧张的话，折衷方案是 2 节点先跑，但要清楚这只是过渡，而且两节点的容错能力比四节点弱很多，同时务必把异地备份先做好。等业务量上来，再加一组同配的 pool 扩上去。
盘位多、追求容量利用率，选 12+4（75% 利用率，容错 4 块）；盘位少、想省钱，选 8+3（72.7% 利用率，容错 3 块）。两者利用率其实差不太多，真正的区别是容错盘数和条带宽度——12+4 能同时扛 4 块盘，重建时也更容易把负载摊开。还有一个硬约束：一个纠删码集合的盘数上限通常是 16，所以 12+4 已经是顶格配置，再多校验块就得改别的规划方式。规模在几百 TB 以上的，直接上 12+4 更省心。
看场景。在线业务（素材库、私有云盘、训练样本池）我更倾向 16TB 或 18TB：单盘重建窗口在 18–30 小时量级，业务还能接受，实在不行限速跑一天也就完了。20TB 以上的盘，重建窗口会拉到 30–48 小时甚至更长，这段时间你等于少了一层容错，风险是实打实的。归档场景（几乎不读、可以不限速重建）那就大胆上大容量盘，单 TB 成本和机柜占用都能省下来。另外不管选哪种，别一次性买同型号同批次的盘，分两批买，磨损曲线错开一点。
看出网曲线的形状。曲线平稳（素材分发、常态化训练读取、持续备份同步），固定带宽更简单，账单可预测，也不怕突发。曲线尖峰明显（活动爆量、版本发布集中下载、白天高夜里低），95 计费通常能省一大截——它会把每月最高的 5% 采样点剔掉，偶尔冲高不算钱。实操上我建议：先按 95 计费跑一个月，看真实曲线长什么样，再决定要不要转固定。另外一定要问清楚独享还是共享、超出部分怎么算、入网收不收钱。
能跑，但我不建议。原因有两个：一是故障域，36 块盘在一台机器上，整机一挂全挂，纠删码瞬间失效；二是扩容粒度，MinIO 是按 server pool 扩的，你后面加机器得加一整组同配节点，而不是往老机器里塞盘，所以先买一台高密度的机器，后面扩容会很别扭。如果预算确实只够一台，那就把它当"验证环境"用，业务数据同时在别处留一份备份，等预算到位直接上 4 节点。
需要，而且这是最容易想当然的地方。纠删码防的是"盘坏了读不出来"，不防"数据被删了、被覆盖了、被加密了"。这三件事纠删码会原样复制到每一块盘上。所以自建之后至少要做三层：开版本控制并配生命周期保留策略，防误删误覆盖；做异地站点复制，防机房级事故；定期做一份异介质或者离线的冷备份，防逻辑损坏和勒索。别觉得"我自己掌控硬件就很安全"——真正的风险从来不在硬件那头。
粗略的经验分界是：可用容量到几百 TB 量级、并且月出网流量到几十 TB 往上，自建的单位成本优势才开始明显。原因是云对象存储最贵的那一项是出网流量（按 GB 计，行业公开参考通常在 0.5 元/GB 量级，以各云官网实时价为准），而自建把这项换成了固定带宽按 Mbps 计，跑得越满越划算。反过来，如果你只有几十 TB、每月出网几 TB，或者业务规模还不确定、团队没有运维人手，那老老实实买云对象存储更省事也更便宜。拿不准就把两边三年的总账都算一遍再决定。
如果这篇只能记住一句话，那就记住这句：自建 MinIO 的钱，大头不在机器和盘上，在出网带宽和重建窗口上。机器是一次性的，盘是摊薄的，出网是每个月都来的账单，而重建窗口则是你平时看不见、出事时最要命的东西。
我的立场也很明确：几十 TB 规模的团队，别折腾，直接买云对象存储，把精力花在业务上；几百 TB 且出网持续跑满的团队，自建确实划算，但请务必按 4 节点起步、按 12+4 规划、按 16–18TB 选盘、把出网带宽的账算在最前面。至于那种"为了自主可控"但既不做备份、也不做异地副本、也没监控的自建，比用云危险得多——至少云厂商那边有专业的人在盯着盘。
硬件这头，找一家能把配比、盘位、带宽、线路讲清楚的服务商，比单纯比价重要得多。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快 1 分钟上架，BGP 多线加 CN2 GIA，7×24 中文工单平均 5 分钟响应、硬件故障 10 分钟自动迁移、每日 3 份免费快照 30 秒回滚、5–20G 免费 DDoS 防护、免费备案协助，这些是官网明示的服务，能用上的尽量用上。配置怎么配、带宽怎么买，建议直接把你的可用容量目标、平均文件大小、月出网量级这三个数报给工程师，让对方按你的真实模型出方案，比照着别人的配置单抄靠谱得多。
本文涉及的配置建议、容量算法与行业参考区间，整理自公开技术文档与行业通行实践；一万网络相关的产品、价格与服务说明，可查阅官网 https://www.idc10000.net/ 的服务器租用、裸金属服务器、中国香港服务器等产品页，以及官网明示的价目与服务承诺页面。文中标注"预估"的价格均为按行业公开区间推算的参考范围，不构成报价承诺；标注"以官网实时价为准"的官网明示档位可能随活动与配置变动。具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
