每个成功的AI项目迟早都会遇到一个经典的问题：你把所有数据放在哪里？
我们的客户以一种非常独特的方式达到了这一点。 四个AI生成模型每隔几秒钟就会生成一个75兆字节（MiB）的结果文件，全天候运行。 随着时间的推移，他们本地的平台开始出现问题：阵列过热、备份时间窗口不稳定，添加更多服务器也无法继续扩展。
客户已经在使用 Akamai 来交付内容，因此将 AI 生成的内容集中到Akamai 对象存储中是下一步的自然选择。 它将流量保持在熟悉的网络中，最大限度地减少了出口流量，并使这些文件能够为下游用户提供服务。
这个问题很简单：Akamai 对象存储服务能否轻松应对当前和未来模型扩展时的海量数据需求？
为了给出一个可信的答案，我制作了一个小型的演示程序并对其进行了测试。 在本文中，我将介绍 AI 数据处理模式、测试环境设置以及这些结果对客户的意义。
如您所在的企业也在考虑采购云服务或进行云迁移，
点击链接了解 AkamaiLinode 解决方案，现在申请试用可得高达 5000 美元专属额度。
人工智能的吸收模式
工作量模式如下：
- 四个独立的AI模型，每个生成75 MiB的结果文件。
- 每六小时，这些模型总共生成：
- 来自模型1的260个文件
- 第二种型号的520份文件
- 来自Model 3的8,060个文件（实际上是31个"目录"，每个目录包含260个文件）。
- 4号机型共包含328个文件。
每批次有9,168个文件，总计约0.68太字节（TiB）的数据，全部存储在一个兼容S3的存储桶中。
在本地环境中，这给存储控制器和内部网络都带来了巨大压力。 每种模型都有其自身的重试逻辑和吞吐量假设，因此容量规划只能靠猜测来进行。
测试设置
我为测试设置使用了以下内容：
洛杉矶（us-lax-4）地区提供了一个8 GB专用CPU实例，可作为可预测的客户端。
将芝加哥（us-ord-1）区域的对象存储桶用作与 S3 兼容的目标存储。
平台记录的速率限制和吞吐量指南可作为参考依据。
演示：一个盒子中装有4个模型。
然后，我开发了一个轻量级工具，它能够同时模拟所有四种模型的操作，团队中的任何人都可以直接通过浏览器使用它。 该系统采用 Node.js 作为后端，部署在 us-lax-4 实例上，并搭配单页 HTML/JS 前端。 后端使用了 AWS JavaScript v3 S3 客户端 SDK，并指向 Akamai 的 S3 兼容端点。
目标是位于 us-ord-1 区域的存储桶，可通过 us-ord-1.linodeobjects.com 端点访问。
我们的目标不是设计一个花哨的仪表盘，而是一个透明的工具，让团队中的任何人都能了解系统的运行情况。
结果告诉我们关于AI对象存储的哪些信息？
对于该客户的模式（每六小时批处理约 0.68 TiB）来说，瓶颈在于客户端实例和网络，而非对象存储。 经过几次试验，我们还发现了另外两个显著的结论：
- 存储层拥有充足的可用空间。即使在接近 2 Gbps 的持续数据吞吐量下，该任务也仅消耗了每个存储桶记录的交易容量的一小部分。
- 读后写功能如宣传所述正常运行。新创建的对象会立即显示在列表中，这正是近实时数据处理管道所必需的。
换句话说，问题已经不再是"平台能否跟上进度？" 到"我们希望达到多快的速度？"
结论
对于拥有多个模型且生成大量数据的 AI 团队来说，这种模式既可重复又可观察：只需将输出指向对象存储，运行演示（或其变体），即可快速判断当前存储平台是否成为瓶颈。 你的测试结果可能证明，是时候转向更具扩展性的数据摄取层了。
如果您自己的模型已开始超出当前存储平台的容量，那么现在是验证 Akamai 对象存储如何处理您特定工作负载的最佳时机。 复制这个简单的测试，输入你的文件大小、批量模式和区域信息，然后利用测试结果来指导你的架构决策。
后续步骤
通过我们的文档创建一个存储桶，开启对象存储之旅。 从那时起，你就可以决定自己想要达到的速度，以及想要保留多少未来的发展空间。
如您所在的企业也在考虑采购云服务或进行云迁移，
点击链接了解 AkamaiLinode 解决方案，现在申请试用可得高达 5000 美元专属额度。