WEKA 与 Backblaze 合作将 AI 数据置于两个存储层级

WEKA 与 Backblaze 的合作将 AI 数据分布在两个存储层级中，挑战了“所有有价值的数据集都应放在昂贵高速基础设施上”的观点。

根据 9 月 9 日宣布的合作，WEKA NeuralMesh 负责处理靠近加速计算资源、对性能敏感的工作负载。Backblaze B2 则保留规模更大的数据集、检查点、输出结果及其他不需要立即高速访问的资产。

这种划分听起来很简单，却瞄准了一个日益昂贵的问题。AI 团队希望存储速度足以让 GPU 持续工作，同时又不必将每个保存的产物都维护在同一高性能层级上。

这一安排也对全闪存存储策略和高度捆绑的超大规模云服务形成压力。独立厂商如今希望提供一种由专业化性能层与容量层构成的替代方案。

据 B2 certification 称，两家公司已使用 B2 测试 WEKA 的 Snap-to-Object 功能。不过，完整认证仍在进行中，因此生产环境验证仍是核心问题。

WEKA 与 Backblaze 的合作究竟改变了什么

这项合作让 Backblaze B2 成为经过测试的容量存储目的地，用于承接在 WEKA NeuralMesh 工作流中流转的数据。

两家公司并未主张由 B2 取代 WEKA 的高性能存储。相反，每个平台都在 AI 数据生命周期中获得了明确定位。

NeuralMesh 仍负责为对性能敏感的训练、检查点保存、推理和加速计算提供活跃数据服务。B2 则为仍具价值、但不需要相同访问特征的数据提供对象存储。

对象存储将数据作为带有元数据的对象进行管理，而不是将其呈现为传统文件或磁盘块。这种设计适合保存大型数据集合，但其行为方式不同于邻近 GPU 的高性能存储。

预期工作流从 B2 中的原始非结构化材料开始。训练集、媒体库和源文件可一直保留在那里，直到活跃工作负载需要它们。

随后，团队可通过 NeuralMesh 使选定数据可供其计算环境附近的处理任务使用。一次运行结束后，检查点和输出结果可返回 B2 进行保留或日后复用。

检查点会记录模型在训练期间的状态，使工作能够恢复，而无需重新启动整个运行过程。保留多个检查点有助于恢复、比较、测试和治理。

这一生命周期之所以重要，是因为 AI 项目很少只使用一次数据。一个数据集可以支持训练、评估、微调、再训练，以及之后对模型行为的调查。

保存的推理输出也可以成为分析或未来产品工作的输入。在即时处理后删除一切能够减少存储需求，但也会牺牲这种持续价值。

storage analysis 将该架构描述为：热数据位于 WEKA，较冷数据位于 B2。这一简写概括了数据放置策略，不过真实工作负载包含的温度层级不止两种。

某些资产在整个项目期间都需要即时访问。另一些资产可能数周处于非活跃状态，随后却因再训练、回滚或审计而突然重新启用。

WEKA B2 集成试图让这些迁移变得可重复。集成、容量规划、调优和测试均属于双方联合工作的一部分，而非完全留给每位客户自行完成的任务。

这一资质认定是合作的主要卖点之一。一个团队在处理任何有用的模型数据前，存储集成就可能消耗大量工程时间。

工程师必须确定网络路径、吞吐量要求、恢复行为、身份验证、保留策略和故障处理方式。他们还必须衡量数据能够多快返回性能层。

仅有可用接口并不能解决这些问题。当数据集、并发任务和恢复需求扩大时，生产就绪程度取决于行为是否可预测。

因此，这项公告改变的不只是兼容性列表。它为客户提供了一种建议的运行模式，用于将活跃 AI 数据与保留资产分离。

这种模式并非 WEKA 或 Backblaze 独有。它的重要性来自两家专业供应商将其产品验证为一个组合系统。

这为不希望由单一供应商控制计算、高性能存储、容量存储和数据迁移的团队提供了更清晰的选择。同时，它也增加了一个客户必须监控的集成边界。

合作的承诺正建立在这种平衡之上。专业化可以改善基础设施经济性，但前提是数据迁移不会成为下一个瓶颈。

为什么 AI 存储正分化为活跃层与保留层

AI 基础设施正迫使买方区分：哪些数据用于当前计算，哪些数据仅需保持可用。

GPU 集群依赖稳定的数据输入流。如果存储无法足够快地提供数据，昂贵的计算资源就会等待，而不是处理工作。

这一要求有利于靠近加速计算资源的高性能系统。这类系统注重延迟、并行访问、吞吐量，以及在高要求工作负载下的可预测行为。

然而，在任何时刻，AI 组织全部数据资产中只有一部分服务于活跃任务。其余部分包括源材料、此前的检查点、旧版模型、生成的输出和归档实验。

将每项资产都放在最快层级，相当于将保留需求视作活跃计算。这简化了数据放置决策，却将高端基础设施用于非活跃数据。

另一极端同样不可行。将所有信息置于面向容量的对象存储中，可能让活跃任务等待数据暂存、传输或检索。

WEKA 与 Backblaze 的合作通过明确的专业化分工来应对这一冲突。NeuralMesh 专注于需要即时性能的数据，而 B2 承载规模更大的保留数据集合。

这是一项机制决策，而不只是供应商关系。它假定，当数据会随着其运营角色变化而改变存放位置时，AI 存储才能发挥最佳效果。

同一数据集可以经历多种角色。原始材料起初作为保留容量存在，随后成为活跃训练输入，之后又作为版本化资产返回。

检查点也遵循类似路径。它们在活跃训练期间被写入，但大多数并不需要永久驻留在 GPU 集群旁。

团队可能保留检查点，因为后续模型版本的表现可能更差。他们也可能需要证据来说明，哪些数据和模型状态产生了某个结果。

推理还会产生另一类保留信息流。输出可支持评估、面向用户的功能、质量审查和未来训练周期。

这些数据集合会不断增长，因为 AI 开发具有迭代性。团队会重复运行、修改参数、比较模型，并保留未来可能再次相关的分支。

Backblaze 和 WEKA 表示，数据集和检查点正朝着 EB 级规模增长。这是企业声明，并不意味着每位客户都以该规模运行。

不过，即使对于较小部署，这一趋势仍然可信。当组织保留更多版本并使用更丰富的媒体时，数据积累速度会更快。

视频、音频、科学图像和其他多模态输入远大于普通文本记录。其衍生产物可能令总体存储消耗成倍增加。

因此，双层模型反映了基础设施采购中更广泛的转变。买方越来越多地询问哪些数据值得获得闪存性能，而不是询问所有 AI 数据是否都应置于闪存中。

竞争对手也在提出相同的架构论点。VDURA 和 Wasabi 宣布了一种面向 AI 工厂和高性能计算环境的类似方案。

其 VDURA tiering 将活跃数据保留在 GPU 附近，同时将较旧产物迁移至兼容 S3 的对象存储。这种相似性表明，市场正趋向于按生命周期放置数据。

S3 兼容性意味着服务实现了以 Amazon 对象存储 API 为模型的接口。它能够简化集成，但兼容服务在行为和功能上仍可能存在差异。

WEKA 还在 2026 年初宣布与 Scality 开展对象层合作。该安排将 NeuralMesh 与可由客户在受控环境中部署的企业对象存储相结合。

Scality object tier 表明，Backblaze 并非 WEKA 对保留数据的唯一答案。相反，WEKA 似乎正围绕其性能层构建多种容量选择。

这一策略为买方提供了部署选择，但也加剧了对象存储提供商之间的竞争。当现有替代方案已经存在时，Backblaze 必须证明其服务为何应部署在 NeuralMesh 之后。

其机遇来自将 B2 作为云服务运营。客户无需自行部署和管理另一套存储集群，便可增加保留容量。

代价则是对网络连接和服务可用性的依赖。托管容量层能够减少运维工作，同时将部分工作流移出本地性能环境。

由此产生的买方决策不再只是闪存与磁盘之间的选择。它还涉及位置、控制权、恢复速度、互操作性、数据治理和运维责任。

WEKA B2 集成如何迁移及恢复数据

Snap-to-Object 提供了技术桥梁，但恢复行为比复制数据这一行为本身更重要。

WEKA 的 Snap-to-Object 功能可将完整的文件系统快照（包括数据和元数据）导出到对象存储。快照代表文件系统某一时点的一致性视图。

首次导出会发送完整快照。后续操作可以采用增量方式，即传输变更，而不是再次执行完整复制。

根据 WEKA 对 Snap-to-Object 的说明，导出的数据采用内部格式。用户无法像浏览普通 B2 对象集合那样浏览这些数据。

这种区别会影响预期。该功能旨在通过 NeuralMesh 进行恢复，而不是供任何兼容 S3 的应用程序直接检查。

在 WEKA 与 Backblaze 的合作中，Snap-to-Object 已完成与 B2 的测试。团队可以保留检查点或推理数据，并通过容量层恢复它们。

这一机制支持多种实际场景。训练团队在发现后续运行不稳定后，可以回到较早的检查点。

另一团队可以保留已完成的实验状态，而无需将每个版本都放在活跃层。研究人员之后可将选定快照恢复到适当的 NeuralMesh 环境中。

公司也可以在灾难恢复期间使用保留快照。对象副本将可恢复状态与原始工作负载运行所在的性能集群分离。

其价值不只取决于导出是否成功。团队还需要了解快照需要多长时间、增量数据变化量有多大，以及在压力下恢复的表现。

不同工作负载的恢复目标不同。被放弃的实验或许可以容忍缓慢恢复，而中断的生产流水线可能需要更快恢复运行。

网络容量也会成为这项计算的一部分。即使两个系统都正常运行，在 B2 与 NeuralMesh 之间移动大型数据集仍可能耗费时间。

物理距离同样重要。性能集群与其对象存储层需要具备合适的连接能力，尤其是在团队预计会频繁进行数据暂存或恢复时。

这也是为什么“冷数据”可能具有误导性。一些留存数据可能毫无预警地变得紧急且具有运营价值，架构必须能够应对这种转变。

两家公司表示，该集成包括容量规划和调优。买方应询问这些测试覆盖了哪些工作负载配置，以及结果基于哪些网络假设。

他们还应确定自身的访问模式是否与测试场景相符。大型顺序传输与大量小对象或频繁的并发恢复，其行为并不相同。

元数据规模的重要性可能不亚于总容量。包含数十亿个小文件的集合，与包含较少大型媒体对象的集合，面临不同挑战。

检查点频率带来了另一项变量。频繁快照可提升恢复粒度，但也会增加变更跟踪、传输活动和保留版本数量。

保留策略决定这些版本的保存时长。治理团队可能要求长期保存，而工程团队则可能倾向于积极删除过时状态。

WEKA B2 集成无法替客户选择这些策略。它能够提供一条经过验证的路径，让这些策略在其上运行。

安全控制同样需要关注。团队必须在两个环境中管理凭证、加密、访问边界、删除保护和审计记录。

Backblaze 已宣布，自 2026 年 9 月 14 日起，新的 B2 上传将默认启用服务器端加密。静态加密很重要，但它不能替代身份或生命周期控制。

组织仍需限制哪些人可以恢复、覆盖、保留或删除 AI 资产。训练数据可能包含专有、个人或受监管的信息。

模型检查点也应得到类似保护。它们可能凝聚了大量知识产权，有时还会暴露有关底层训练的信息。

因此，双层设计扩展了控制平面。管理员必须了解每项操作由哪个平台负责，以及事件如何呈现在各类日志中。

故障测试应覆盖中断传输、部分恢复、凭证过期、网络不可用和容量限制。正常条件下的成功演示只能构成部分证据。

团队还应验证 NeuralMesh 版本变更时会发生什么。快照兼容性和恢复流程需要能够经受软件升级和基础设施更换。

这一机制具有可信度，因为 Snap-to-Object 已是明确的 NeuralMesh 功能。尚未获得公开证明的是，它在各种生产环境中与 B2 配合时的表现。

真正的对手是全闪存默认方案

这项合作最直接挑战的是这样一种假设：AI 基础设施应将每一项有价值的资产都保留在高性能闪存中。

对于需要低延迟和高并行吞吐的工作负载，闪存仍然必不可少。争议在于，究竟有多少数据值得长期驻留其中。

全闪存方案减少了层级之间的数据移动。数据始终靠近计算资源，运营人员也可避免一部分暂存、恢复和集成工作。

这种简化具有运营价值。当数据与计算之间的平台和网络路径更少时，性能故障会更容易排查。

然而，随着团队保留更多检查点、数据集、模型版本和输出，容量会不断增长。最快的存储层可能成为昂贵的留存位置。

WEKA 与 Backblaze 的合作提出了另一种答案：将闪存保留给活跃工作，同时把非活跃资产转移至基于磁盘的云对象存储。

Backblaze 已将这一容量论点与 neocloud 市场联系起来。Neocloud 在最大规模超大规模云平台之外提供以 GPU 为重点的云服务。

6 月，Backblaze 宣布达成一项为期五年、容量达数 EB 的协议，为 CoreWeave AI Object Storage 中基于 HDD 的存储层提供支持。其 CoreWeave 协议为该公司面向 AI 的容量存储提供了重要案例。

这一合作关系并不能验证独立的 NeuralMesh 集成。它确实表明，Backblaze 正在寻求大型 AI 基础设施运营商，而非仅将 B2 视为通用云存储。

WEKA 带来了已在采购专业性能基础设施的客户资源。Backblaze 则获得了一条进入这些部署的渠道，而无需替代性能层。

WEKA 获得了一个独立的托管容量选项。这可以强化其论点：NeuralMesh 适用于混合及多供应商架构。

更广泛的竞争格局包括超大规模云厂商的存储服务、独立对象云、本地部署对象平台，以及销售更广泛集成数据系统的供应商。

超大规模云厂商可以在同一云中连接存储、计算、网络、身份和管理服务。其优势在于覆盖庞大服务组合的集成能力。

独立供应商则以可移植性和专业化进行回应。当技术或业务需求足以支持这种分离时，客户可以将计算和存储部署在不同提供商处。

这种方式可以降低对单一云的依赖，但不会自动消除锁定。以 WEKA 内部格式存储的快照，恢复时仍依赖 NeuralMesh。

这对买方而言是一个重要区别。将数据存储在兼容 S3 的服务中，并不能保证每个存储的资产在原始应用之外仍可被直接使用。

通常存储在 B2 中的原始训练对象，可通过对象 API 保持可移植性。Snap-to-Object 导出则采用与 WEKA 绑定的不同恢复模型。

因此，该架构实现了提供商分离，但并非完全的软件独立性。买方应区分基础设施可移植性与应用层数据可移植性。

Scality 提供了另一种竞争形式。它为 NeuralMesh 用户提供可在企业自主管理基础设施中运行的对象存储层。

Backblaze 提供的是托管云目标位置。这些选项分别适合对数据驻留、管理、网络和采购有不同要求的场景。

Wasabi 与 VDURA 的合作建立了独立性能与容量专家之间更直接的配对。这一组合在验证该模式的同时，也在争夺相同买方。

VAST Data 围绕统一数据平台采取了更广泛的策略，并在 AI 云基础设施领域占据重要地位。其策略给较窄范围的合作施加压力，要求其证明运营简洁性。

公有云既有厂商还可通过生命周期策略和集成式高性能文件服务作出回应。当客户已在同一云中运行计算资源时，其规模优势使其难以被取代。

WEKA 与 Backblaze 的合作并未终结这些比较。它为买方提供了另一种可用于基准对比的架构。

其最有力的适用场景似乎是：留存 AI 数据的增长速度远快于活跃工作集。当几乎所有数据都保持性能敏感时，这种分离的吸引力就会下降。

工作负载的可预测性也会影响结果。知道哪些资产将变得活跃的团队，可以在任务开始前对其进行暂存。

不可预测的工作负载会带来更严苛的要求。对旧数据集的突然访问，可能暴露出在规划阶段看似可接受的检索延迟。

全闪存存储通过维持更多高端容量，将这一特定风险降至最低。分层存储则接受数据移动和恢复工作，以改善资源分配。

这才是核心竞争。它并非声称某一种介质在所有场景中都胜出，而是关于延迟应优先保障在哪里的决策。

认证仍在进行中，这一保留条件至关重要

已公布的架构经过测试，但其公开证据仍比两家公司所暗示的生产就绪程度更为有限。

Backblaze 和 WEKA 表示，客户可以联系任一公司开始合作。它们还称，面向 NeuralMesh 的 B2 认证仍在进行中。

这些表述形成了一项重要区别：经过测试的集成，可以在正式认证流程完成前支持早期合作项目。

买方应询问“进行中”对支持义务意味着什么。他们需要知道哪些配置符合联合故障排查条件，哪些仍可能发生变化。

合格架构应明确受支持的 NeuralMesh 版本、B2 功能、网络模式、认证方法和建议的容量比例。

它还应说明边界。客户需要了解哪些配置超出测试范围，以及跨越两个系统的问题应由谁负责。

此次公告未附带公开基准测试。两家公司没有公布传输吞吐量、恢复时间、支持的对象数量，或并发工作负载下的性能。

这一缺失并不表明性能薄弱。它意味着读者无法仅凭公告独立地将该集成与替代方案进行比较。

WEKA 对微秒级访问的主张适用于性能层，不一定适用于从 B2 移动数据。两个系统服务于不同的访问需求。

同样，关于 EB 级数据集的表述描述的是问题规模的上限。它们并不能证明某个特定部署将如何扩展。

客户应根据自身的对象大小、变更速率、网络位置和恢复目标索取测量结果。通用吞吐量数据仍需进行本地验证。

认证还应涵盖故障语义。即使传输或服务发生中断，已完成的快照也必须保持一致性。

运营人员需要看到导出、增量变更和恢复的明确状态。他们应能够在依赖这些操作前识别不完整的操作。

数据生命周期策略带来了另一项不确定性。该集成必须与 B2 保留设置、删除控制、加密和组织治理要求共存。

两家公司的公告强调留存的数据集和输出，但这些类别可能包含受监管的信息。存储位置和访问历史可能成为审计要求。

Backblaze 自身的 AI 存储战略指出了围绕面向 AI 客户的监管、可用性、安全性、集中度和竞争风险。

该文件还强调了 Backblaze 对 AI 模型构建者和 neocloud 平台的战略兴趣。WEKA 合作关系符合既定增长方向，而非孤立的产品实验。

战略一致性仍不能保证采用。客户必须判断，另一项外部容量服务是否足以改善其架构，从而值得为之改变运营方式。

现有 WEKA 用户可能已经拥有对象存储层。迁移留存数据或增加第二个目标位置，需要带来明确的弹性、位置或管理收益。

新客户则面临更广泛的设计选择。他们可以采用这一配对架构，选择另一种 NeuralMesh 对象存储层，或选用集成式竞争方案。

认证可以降低感知风险，但客户案例更为重要。最有说服力的证据将来自具名的生产环境用户，他们能够进行可重复的恢复操作。

这些用户应代表不止一种工作负载。媒体流水线、模型训练、科学计算和推理服务会产生不同的对象与检查点模式。

证据还应覆盖时间维度。在初始部署阶段运行正常的系统，随着快照、命名空间和保留版本不断累积，可能会遇到扩展性问题。

支持协调也是一项实际考量。多供应商系统可能造成延误，因为各供应商起初都可能怀疑问题出在对方组件上。

成熟的合作关系应提供清晰的升级路径和共享的诊断流程。否则，预先测试或许能节省安装时间，却未必能缩短事件处理时间。

该集成方案的价值还取决于可预测的检索能力。每当数据需要回流用于训练或恢复时，容量型存储就会成为活跃工作流的一部分。

团队应在集群利用率较高的时期测试恢复。单独运行时表现良好的恢复操作，可能会与活跃工作负载争夺网络和存储资源。

他们应衡量数据达到可用状态的总耗时，而非仅关注对象传输速度。数据重新水化、元数据处理、挂载、验证和作业重启都会影响恢复过程。

谨慎的结论很直接：该架构遵循合理的生命周期模型，但认证和生产环境案例仍需证明其运营成熟度。

三个信号将表明这项合作是否奏效

认证范围、客户采用情况以及可衡量的恢复表现，将决定这是否会成为基础设施，还是仅停留在联盟公告层面。

第一个信号是 NeuralMesh 完成 B2 认证。两家公司应公布支持的版本、配置、部署前提以及联合支持的边界。

详细的认证将强化这项合作的核心承诺。这将表明客户获得的是可重复实施的设计，而不仅是两款产品之间的通用兼容性。

范围狭窄的认证则会削弱这一承诺。如果支持仅覆盖有限配置，许多买家仍需投入大量工程工作和验证。

第二个信号是具名的生产环境采用案例。客户案例应说明哪些资产存放在 B2，哪些保留在 NeuralMesh，以及数据移动的频率。

有价值的案例应展示工作负载规模，而非依赖含糊的标签。它们应描述检查点频率、保留数据增长、恢复模式和运营归属。

现有 NeuralMesh 客户的采用，将表明 B2 能在既有对象存储选择之外带来价值。新的联合客户则将说明，这一组合会影响基础设施选型。

单一试点项目提供的证据有限。多个不同工作负载类型的部署案例，能让更广泛的生命周期论点更具说服力。

第三个信号是在真实条件下的恢复性能。这项合作需要证明，保留数据能够在可接受的运营时间窗口内重新变为活跃数据。

该证据应涵盖完整的恢复路径，而不仅是传输速率。买家需要了解，一个检查点需要多长时间才能被实际工作负载使用。

稳定一致的结果将强化双层存储模型。这将表明，将非活跃数据从闪存中迁出，并不会在日后造成不可接受的延迟。

不可预测的恢复表现将使全闪存或集成更紧密的替代方案更具优势。它会在关键时刻将低成本保留转化为运营不确定性。

竞争对手的反应会提供额外背景，但并非主要检验标准。Scality、Wasabi、超大规模云服务商和统一平台供应商已支持相互竞争的数据放置策略。

决定性的问题属于客户：他们能否在不增加恢复风险或工程开销的情况下，减轻高性能容量的压力？

评估 WEKA 与 Backblaze 合作关系的基础设施团队，应从具有代表性的数据集和真实的检查点计划开始。在迁移关键保留工作流之前，他们应测试故障和恢复过程。

他们还应记录哪些数据必须快速回流，哪些可以等待。这一分类决定了两层存储是带来效率，还是仅仅增加数据移动。

这项合作值得关注，因为它将 AI 存储增长转化为数据放置决策。其成功将取决于认证能否将这一决策转化为可靠的日常运营。