随着 AI 基础设施的发展，数据管道速度越来越快，范围越来越广，也越来越复杂。从训练大型模型到大规模实时推理，存储子系统对于确保 GPU 持续接收必要数据至关重要。随着存储在 AI 集群中的重要性日益凸显，各组织正在重新思考如何提供高吞吐量、可预测的性能和弹性，尤其是在数据丢失或停机不可接受的环境中。
随着人工智能模型的规模持续呈指数级增长，这一挑战变得更加严峻。现代大型语言模型和基础模型需要频繁设置检查点以保持训练进度。随着模型规模从数十亿个参数扩展到数万亿个参数，这些检查点的存储需求也随之增长。这迫切需要能够处理海量检查点文件，同时保持极快读写性能的大型统一存储命名空间。传统的存储架构难以同时满足这些高要求工作负载所需的容量和速度。
当前的检查点管理方法，例如将模型权重转储到 CPU 内存中以允许 GPU 继续训练的异步检查点，随着模型的增长面临着巨大的局限性。将这些检查点临时存储在系统内存中变得越来越浪费且成本高昂，需要大量的 RAM，从而增加了系统成本和功耗。更重要的是，随着模型规模的不断扩大，这种方法可能会变得完全不切实际，因为需要临时存储在内存中的数据量非常大。
Graid Technology 推出了一种专门针对这些挑战的新方法。基于早期解决方案中建立的软件定义模型，例如 SupremeRAID SR1010，Graid 的新 SupremeRAID AE（AI版） 只需极少的基础架构改动，即可将企业级 RAID 功能引入 AI 工作负载。AE 并非采用专用硬件 RAID 卡或定制设备，而是以软件许可证的形式提供，并且仅占用现有 NVIDIA GPU 的一小部分资源。这意味着企业无需 1) 占用额外的 PCIe 插槽，2) 进行基础架构改造，3) 即可获得企业级存储性能和可靠性，而无需承受训练和推理工作负载的 GPU 性能显著影响。
关键精华
- 大规模高性能： SupremeRAID AE 实现高达 183.60GB/s 的读取吞吐量和高达 54.23GB/s 的写入吞吐量，满足苛刻的 AI 要求。
- 最小 GPU 开销： 在 GPU 密集型推理期间引入最小开销（~4%），保持强大的整体系统性能。
- 海量统一存储命名空间： 每个阵列支持最多 32 个 NVMe SSD，在单个统一命名空间中提供近 1PB 的存储。
- 高级集成功能： 与 NVIDIA GPUDirect Storage 和领先的 AI 文件系统（BeeGFS、Lustre、Ceph）完全集成。
- 简化的基础设施： 消除专用 RAID 硬件，显著降低复杂性、成本和运营开销。
针对高级 AI 工作负载优化的存储和弹性
SupremeRAID AE 单个阵列最多支持 32 个 NVMe SSD，并将它们聚合到统一的命名空间中。这种结构使 AI 工作负载能够高效访问大型数据集，同时保持弹性，这对于运行长期训练作业的环境尤为重要。即使发生驱动器故障，阵列仍然可用，并保留检查点进度。这种保护措施可最大限度地降低数据丢失或耗时重启的风险，这对于管理大型模型或海量推理流程的团队而言，是一项显著的优势。
SupremeRAID AE 的智能资源管理功能为 AI 工作负载提供了额外的优化机会。虽然我们的测试表明并发操作期间的开销极小，但通过智能调度可以进一步降低影响。检查点操作通常不会与同一节点上的主动训练同时运行；在检查点阶段，训练通常会出现短暂的暂停。在这些间隔期间，SupremeRAID AE 可以利用其他未使用的 GPU 资源来加速检查点的完成。
SupremeRAID AE 还支持 NVIDIA GPUDirect Storage。这实现了存储和 GPU 内存之间的直接路径，从而降低了延迟并提高了 I/O 效率。它与 BeeGFS、Lustre 和 Ceph 等以 AI 为中心的文件系统集成，并包含智能数据卸载功能以及用于自动化编排的 API。总而言之，SupremeRAID AE 提供了一种简化但强大的方法，将 RAID 的优势融入现代 AI 工作流程。
除了训练工作负载之外，SupremeRAID AE 还能满足现代 AI 推理场景的关键需求。随着企业规模化推理操作，他们越来越依赖诸如持久性键值缓存管理、预填充-解码优化和分层内存架构等高级策略。这些技术通常需要在键值缓存超过 VRAM 容量时将其卸载到存储中。NVIDIA Dynamo、Red Hat 的 LLM-D 和 vLLM 生产堆栈等解决方案都集成了依赖于快速、高容量存储的分层键值缓存集成。在这些场景中，拥有大型高性能存储池对于维持低延迟推理至关重要，而 SupremeRAID AE 能够提供海量容量和卓越速度，使其成为这些高级推理架构的理想基础。
在本分析中，我们评估了在戴尔 PowerEdge R770 平台上运行的 SupremeRAID AE，该平台配备双 NVIDIA H100 GPU 和 16 块美光 6550 61.44TB Gen5 NVMe SSD。我们使用 GDSIO 和 FIO 工具探索 RAID 5 下的性能，并分析了 Graid AE 在实时 LLM 推理工作负载下如何影响 GPU 行为。目标是了解该解决方案如何集成到企业级 AI 环境中，在这种环境中，性能、容量、弹性和简易性必须同时扩展。
数字内幕：SupremeRAID AE 性能深度解析
为了测试 Graid SupremeRAID AE 的性能，我们配置了一台戴尔 PowerEdge R770 计算机，该计算机配备双 NVIDIA H100 GPU 和 16 个 E3.S 插槽（位于前端）。该系统基于英特尔最新的至强 6 平台构建，配备两颗英特尔至强 6787P 处理器，每颗处理器拥有 86 个核心，可处理 AI、HPC 和数据密集型环境中的高度并行工作负载。
R770 配置 16 个 E3.S 托架，存储部分则全系搭载美光 6550 ION 61.44TB Gen5 NVMe TLC SSD，旨在为各种工作负载提供始终如一的性能。美光 SSD 在卓越性能和海量容量之间实现了完美平衡，使 AI 工作负载能够保持高吞吐量，同时大幅简化 AI 基础设施。仅需 16 个硬盘即可提供 PB 级存储空间，帮助企业在单台服务器内高效管理海量数据集和大规模模型检查点，从而显著降低复杂性和基础设施开销。
测试系统规格
- 平台： 戴尔 PowerEdge R770
- CPU： 2 个 Intel Xeon 6787P（各 86 个核心）
- 记忆： 32x Micron 64 GB 双列 DDR5 6400 MT/s 总内存：2TB
- 网络： 戴尔 BRCM 4P 25G SFP 57504S OCP 网卡
- GPU 1： NVIDIA H100（显存 80GB）
- GPU 2： NVIDIA H100NVL（显存 96GB）
- 存储： 16点¯x 61TB 美光 ION 6550 SSD（915TB RAID 5 池）
作为本次性能测试的一部分，美光固态硬盘 (SSD) 使用 SupremeRAID AE 配置在单个 RAID 5 池中。选择此布局是为了评估 SupremeRAID AE 在需要高容量存储的 AI 驱动环境中如何平衡性能和容错能力。RAID 5 将奇偶校验分布在所有驱动器上，从而防止单个驱动器发生故障，同时保持可用的存储容量。
在深入性能测试之前，务必注意在使用 Graid 测量存储性能时 GDSIO 和 FIO 之间的差异。在我们之前对 Graid 性能的评估中，一个关键的观察结果是，它没有限制峰值带宽的瓶颈（例如硬件 RAID 卡）。硬件 RAID 卡管理与其连接的存储设备，而 PCIe 插槽可能会成为此过程中的瓶颈。Graid 使用 GPU 进行 RAID 操作，但并非所有数据都需要通过 GPU。因此，GPU 不会限制带宽。
FIO 存储基准测试通过利用 CPU 访问存储来衡量存储性能，并且仅受存储解决方案的限制。另一方面，GDSIO 衡量的是 GPU 直接存储的性能，其中 GPU 可能是限制因素。例如，NVIDIA H100 具有 PCIe Gen5 x16 接口，能够提供约 63GB/s 的输入或输出带宽。在这种情况下讨论 GPU 性能瓶颈时，问题在于 GPU 通过 GPU 直接存储所能支持的带宽，而不是 Graid 瓶颈。
NVIDIA GPU 直接存储
我们在这个测试平台上进行的测试之一是 Magnum IO GPU 直接存储 (GDS) 测试。GDS 是 NVIDIA 开发的一项功能，允许 GPU 在访问存储在 NVMe 驱动器或其他高速存储设备上的数据时绕过 CPU。GDS 无需通过 CPU 和系统内存路由数据，而是实现 GPU 和存储设备之间的直接通信，从而显著降低延迟并提高数据吞吐量。
GPU 直接存储的工作原理
传统上，当 GPU 处理存储在 NVMe 驱动器上的数据时，数据必须先经过 CPU 和系统内存，然后才能到达 GPU。这个过程会造成瓶颈，因为 CPU 会成为中间人，增加延迟并消耗宝贵的系统资源。GPU 直接存储通过使 GPU 能够通过 PCIe 总线直接从存储设备访问数据，消除了这种低效率。这种直接路径减少了与数据移动相关的开销，从而实现了更快、更高效的数据传输。
AI 工作负载（尤其是涉及深度学习的工作负载）是高度数据密集型的。训练大型神经网络需要处理数 TB 的数据，数据传输的任何延迟都可能导致 GPU 利用率不足和训练时间延长。GPU Direct Storage 通过确保尽快将数据传送到 GPU、最大限度地减少空闲时间并最大限度地提高计算效率来解决这一挑战。
此外，GDS 对于涉及流式传输大型数据集的工作负载（例如视频处理、自然语言处理或实时推理）尤其有益。通过减少对 CPU 的依赖，GDS 可加速数据移动并释放 CPU 资源以用于其他任务，从而进一步提高整体系统性能。
GDSIO 16 驱动器随机读取吞吐量
在深入研究性能数据之前，必须注意的是，GDSIO 数据读写性能的限制因素是 GPU。该测试旨在衡量 GPU 所能提供的最大存储性能。最终，您会在 PCIe 插槽中遇到瓶颈，对于 PCIe Gen5 x16 来说，其速度约为 63GB/s。
在 GDSIO 随机读取吞吐量方面，该阵列在块大小和线程数较大的情况下表现出色，但在低端性能扩展方面却举步维艰。在 16K/128 线程下，吞吐量开始明显提升，达到 7.3GiB/s，但真正的吞吐量加速直到 32K 及以上才真正显现，阵列在 15.5 线程下达到 64GiB/s。在 64K 下，吞吐量显著提升，攀升至 25.9GiB/s；128K 下，性能进一步提升，在 41.3 线程下达到 64GiB/s，并在 40 线程下保持 128GiB/s 以上。在块大小为 1M、线程数为 32 线程下，吞吐量达到峰值，阵列达到 88.5GiB/s，并在最高线程数下保持这一水平。
GDSIO 16 驱动器随机读取延迟
继吞吐量结果之后，阵列的随机读取延迟曲线反映了之前观察到的扩展行为。在所有块大小和线程数（最多 16 个线程）下，延迟都保持在极低的水平，对于 0.1K 以下的所有块，延迟值都保持在 128 毫秒以下。即使是更大的块，例如 128K，也保持在 0.13 毫秒到 0.20 毫秒左右。然而，超过 16 个线程后，延迟明显增加。在 16k/32 线程下，延迟继续上升，最终在 980 线程时达到 128 毫秒。同样，吞吐量最高的 1M 读取从单线程的 0.242 毫秒上升到 2.892 线程时的 128 毫秒。所有大小的延迟趋势一致，在中等并发性下延迟保持平稳，但随着线程数超过 32，延迟急剧上升，尤其是在块大小较大的情况下。
GDSIO 16 驱动器随机写入吞吐量
谈到 GDSIO 写入吞吐量，该阵列在较大块大小下再次展现出强劲性能，但与读取相比，整体扩展速度较为缓慢。从 32K 开始，性能提升更为显著，吞吐量超过 5.9GiB/s，尤其是在 64 线程及以上，512K 和 1M 块在高线程数下仍能持续提升。在 64 线程及以上，512K 写入速度达到 25.4GiB/s，1M 写入速度达到峰值 38.4GiB/s；而在 128 线程下，1M 写入速度持续扩展至 45.9GiB/s 的最高峰值。512K 和 128K 块大小在高并发性下也保持稳定，分别稳定在 26.2GiB/s 和 8.0GiB/s 左右。
GDSIO 16 驱动器随机写入延迟
随着写入吞吐量的强劲提升，随着块大小和线程数的增加，阵列随机写入的延迟曲线也呈现稳步上升趋势。即使在线程数较低的情况下，写入延迟也明显高于读取延迟，从 0.367 毫秒开始，随着块大小的增加而攀升，在 1.222M 时达到 1 毫秒。随着并发性的增加，延迟逐渐上升至 16 个线程，然后加速更为显著。在 64 个线程时，写入延迟达到 0.663 毫秒，而 1M 写入延迟则上升至 3.255 毫秒。到了 128 个和 256 个线程时，延迟显著增加，尤其是在块大小较大的情况下。例如，在 512 个线程时，4.770K 写入延迟达到 128 毫秒，而 512K 和 1M 写入延迟均超过 5 毫秒，在 5.436M 时达到最高 1 毫秒。
FIO 性能基准
接下来，我们来测量单个 RAID5 池中的 FIO 性能。虽然 GDSIO 最终取决于系统中安装的 GPU 的性能及其 PCIe 带宽，但 FIO 可以根据 SSD 的性能以及 RAID 解决方案本身的性能而提高。
整个阵列经过一致的测试流程，首先是预处理阶段，包含两次使用顺序写入工作负载的全卷填充，然后是顺序和随机工作负载。这确保驱动器在性能测量开始前达到稳定状态。
对于每种新的工作负载类型，我们使用相应的传输大小重新启动预处理，以保持结果的准确性和一致性。
本节重点介绍应用于 Graid 16 SSD RAID 5 阵列的以下随机写入/读取 FIO 基准：
- 1M 随机写入/读取
- 64K 随机写入/读取
- 16K 随机写入/读取
- 4K 随机写入/读取
1M随机读写带宽
转向随机 1M 操作，读取带宽在性能曲线上领先，在 183.60 的 IO 深度和 16 个作业的情况下达到峰值 172GB/s，这是测试中最激进的配置。在 8/172 和 4/172 的配置下也记录了类似的高吞吐量结果，均超过了 182GB/s，这凸显了该阵列随着作业数量和深度的增加而扩展的能力。即使是 4/86 和 16/43 这样的中端配置也保持强劲，维持在 147GB/s 以上，在不同并发级别下均表现出一致的读取性能。转换到写入，随机 1M 带宽在 54.233/8 时达到峰值 172GB/s，在 53.77/2 时达到几乎相同的 86GB/s，验证了并行工作负载下高效的写入扩展能力。在 1/43 和 2/43 等较低线程组合中，性能平稳下降，分别产生 24.88GB/s 和 42.48GB/s，即使在中等并发水平下仍然反映出强烈的饱和曲线。
1M 随机读/写延迟
在整个测试范围内，读取延迟始终保持可控。在 0.714/2 和 86/4 的配置下，观察到的最低延迟均为 86 毫秒，而更高深度的负载（例如 8/172 和 4/172）则保持在 2 毫秒以下。产生最高读取吞吐量的配置（16/172）也伴随着最高延迟，达到 7.516 毫秒——这显然是一种权衡，因为更深的队列会增加响应时间。在写入方面，延迟也遵循类似的模式。1.727/1 的配置测得的最低写入延迟为 43 毫秒。2/86 的配置实现了吞吐量和延迟之间的良好平衡，延迟为 3.197 毫秒。更高并发选项（例如 8/43）的延迟为 6.389 毫秒，而 16/172 的配置虽然提供了峰值写入性能，但最高延迟为 50.741 毫秒，这突显了极端深度下吞吐量和响应速度之间常见的反比关系。
64K 随机读/写带宽
切换到随机 64K 操作后，读取带宽显著提升，队列深度和作业数量也随之增加，在 91.65 IO 深度下，作业数量为 32 个，峰值达到 172GB/s。其他几种配置紧随其后，包括 16/172 的 83.59GB/s 和 32/86 的 82.85GB/s，突显了随着工作负载的扩展，性能持续提升。8/172 和 16/86 等中端配置在 78GB/s 到 79GB/s 之间保持了强劲的性能。相比之下，1/43 和 1/172 等并发性较低的组合产生的吞吐量水平有所降低，范围从 21.89GB/s 到 42.63GB/s，这表明阵列对并行性的依赖才能实现峰值性能。在写入方面，64K 随机带宽在 6.44/32 的配置下达到 86GB/s 的峰值。其他性能最佳的配置，包括 32/172 和 16/86，表现非常接近，分别为 6.41GB/s 和 6.36GB/s。大多数测试点集中在 6.3GB/s 和 6.4GB/s 之间，在不同队列深度下表现出稳定的一致性。轻量级配置（例如 1/43）的写入性能最低，仅为 3.83GB/s，这仍然体现了在较高工作负载下性能逐渐提升的趋势。
64K 随机读/写延迟
在大多数测试用例中，随机 64K 读取延迟始终保持较低水平。最低延迟为 0.123/1 的 43 毫秒，其次是 0.175/1 的 86 毫秒。随着吞吐量的提升，延迟保持在可控范围内：4/172 的延迟为 0.666 毫秒，而 16/172 的延迟达到了 2.057 毫秒。即使在更重的负载条件下，响应速度依然高效，32/86 的延迟为 2.076 毫秒，尽管其带宽测试结果名列前茅。在写入方面，延迟随深度和作业数量的增加而急剧变化。最低延迟来自 2/43，为 0.887 毫秒，4/43 和 2/86 的延迟紧随其后，分别为 1.694 毫秒和 1.697 毫秒。较重的配置显示出响应时间权衡的明显迹象：8/172 记录为 13.445 毫秒，16/172 攀升至 26.862 毫秒，32/172 达到峰值 63.201 毫秒，强调了随着工作负载的增加，排队开销也随之增加。
16K 随机读/写 IOPS
即使在峰值 IOPS 下，随机 16K 读取延迟也保持较低水平。响应速度最快的配置是轻量级配置，1/43 的延迟仅为 0.087 毫秒，1/86 的延迟为 0.114 毫秒。更高并发度的组合，例如 4/86 和 8/86，延迟分别为 0.236 毫秒和 0.420 毫秒。即使是性能最高的配置也保持了合理的延迟，16/172 的延迟为 1.143 毫秒，32/172 的延迟达到 2.372 毫秒，这证明了其高效的扩展能力，并且对响应时间的影响可控。对于随机 16K 写入，最低延迟记录在 2/43 的延迟为 0.848 毫秒，其次是 1.253/4 的延迟为 43 毫秒，以及 1.415/1 的延迟为 43 毫秒。随着深度和作业数量的增加，延迟逐渐上升：8/172 达到 5.574ms，而 16/172 和 32/172 分别攀升至 10.455ms 和 22.958ms，突显了随着队列饱和度增加而出现的预期权衡。
16K 随机读/写延迟
随机 16K 读取延迟始终保持低位。响应最快的配置是 1/43，延迟为 0.123 毫秒，紧随其后的是 1/86，延迟为 0.175 毫秒。即使在最大压力下，32/172 和 16/172 等配置也能将延迟保持在 2.1 毫秒以下，这表明阵列在处理高 IOPS 的同时仍能保持快速的响应时间。相比之下，随机 16K 写入延迟的差异较大。最低延迟为 0.496/1 的 43 毫秒，其他高效运行（例如 2/86 和 4/43）也保持在 1 毫秒以下。随着并发性和深度的增加，延迟也相应增加：16/172 的延迟为 7.017 毫秒，32/172 的延迟达到 17.246 毫秒，这进一步证实了在最大饱和度下峰值吞吐量和响应速度之间的预期权衡。
4K 随机读/写 IOPS
在更高的并发负载下，随机 4K 读取 IOPS 在 IO 深度 10.77 和 32 个作业下达到了令人印象深刻的 344 万 IOPS 峰值。其他配置紧随其后，包括 16/344 (10.52M)、4/344 (10.51M) 和 8/344 (10.42M)，均展现出卓越的扩展性以及积极的队列和作业深度组合。即使是 8/172 和 16/172 等较低深度的选项也能在 5.23M 到 5.35M IOPS 之间保持强劲的吞吐量，进一步凸显了该阵列处理高要求并行工作负载的能力。在写入方面，4K IOPS 在 987.9/32 的配置下达到了 172K 的峰值。类似的高效配置包括 32K 的 86/985.1 阵列、16K 的 172/985.6 阵列以及 8K 的 172/976.9 阵列。从 8/86 到 16/86 的其他组合在 875K 到 977K 的范围内保持了性能，从而增强了阵列在并发写入操作完全饱和时的一致性和可靠性。
4K 随机读/写延迟
随机 4K 读取延迟全面保持极低。最快的响应时间为 0.084 毫秒（1/86），其他几种配置（包括 1/43、2/43 和 4/43）均低于 0.12 毫秒。即使在 IOPS 峰值下，延迟也保持良好控制，性能最高的 32/344 配置仅为 1.142 毫秒。这反映出即使在阵列达到最大吞吐量潜力时，其响应速度也非常出色。在写入方面，随机 4K 延迟也得到了良好的控制。记录的最低值为 0.352 毫秒（1/43），而其他高效配置（例如 1/86、2/43 和 4/43）均保持在 0.6 毫秒以下。 32/172 和 32/86 等高吞吐量配置的延迟适度上升至 2.79ms 至 5.87ms 之间，考虑到持续的写入饱和度，这仍处于可接受的范围内。
测量 Grid SupremeRAID AE GPU 开销
在检查 Graid 的 SupremeRAID AE 存储性能指标时，必须考虑共享 GPU 资源的 SupremeRAID 会如何影响同样使用这些 GPU 的工作负载。在过去的 SupremeRAID 部署中，系统中的 GPU 专用于 Graid。使用此解决方案，您可以将其部署在一个已经包含 GPU 的平台上，Graid 可以利用这些 GPU 并共享资源。为了衡量开销影响，我们使用 vLLM 构建了一个 LLM 推理场景。我们在 Graid 空闲时测量了工作负载的基准性能，然后再次测量了 Graid 在 RAID 172 池中读取 5GB 数据的情况。这模拟了推理工作负载，在一个工作负载运行时预分配下一个工作负载。由于 vLLM 将 GPU 的利用率推至 100%，任何 Graid 操作都会影响令牌速率和延迟。
对于 AI 工作负载，我们使用 Llama 3.3 70B 模型，以全精度 (BF16) 和 16K KV 缓存大小，通过 vLLM 进行推理。这几乎完全利用了两张卡上的 VRAM（78G 卡上为 80G，86G 卡上为 94G）。然后，我们运行 vLLM 的基准测试脚本，最大输出长度为 256 个令牌。每次测试运行 256 个查询，最大并发量为 32 个请求，利用连续批处理来模拟真实的请求模式。我们收集的指标包括 Tok/s、第一个令牌时间 (TTFT)、每个输出令牌时间 (TPOT) 和令牌间延迟 (ITL)。我们在推理测试期间启动的 FIO 工作负载包括 172 个 16K 随机读取作业，每个作业读取 1GB 数据。
吞吐量整体略有下降。请求吞吐量从每秒 1.86 个请求下降到 1.78 个请求，下降了 4.3%。输出令牌吞吐量从每秒 225.44 个令牌下降到 215.94 个令牌，下降了 4.2%。总令牌吞吐量从每秒 2029.77 个令牌下降到 1944.30 个令牌，同样下降了 4.2%。这表明转移操作引入了一些开销，对性能产生了轻微影响。
延迟指标结果喜忧参半。平均TTFT增加了3.6%，从6,704毫秒增加到6,945毫秒，而中值TTFT增加了1.5%。值得注意的是，P99 TTFT有所改善，从2.8毫秒下降到14,199毫秒，下降了13,803%，这表明该指标的尾端性能有所提升。对于TPOT，平均值增加了5.3%，而中值则相对持平，仅增加了0.65%。然而，P99 TPOT却急剧上升了24.6%，从127.69毫秒增加到159.15毫秒，这表明最坏情况下的令牌生成时间受到了显著影响。令牌间延迟 (ITL) 也呈现出类似的趋势，平均值增加了5.1%，中值基本保持不变，而P99则增加了2.2%。
Graid 的 SupremeRAID AE 与我们的 vLLM 工作负载同时运行，导致吞吐量略有下降（约 4%），但持续下降，平均延迟略有增加，令牌生成的 P99 性能也明显下降。尽管存在这些影响，系统仍然保持完全稳定和响应能力，这表明使用大型模型（例如 Llama 3.3 70B）进行高并发推理，在 Graid SupremeRAID AE 的帮助下，仍然可以稳定运行。
| 指标（持续时间越短/tok/s 越高越好） | 底线 | 具有 172GB FIO 读取操作 |
| 成功的请求 | 256 | 256 |
| 基准持续时间（秒） | 137.68 | 143.73 |
| 总输入令牌 | 248,414 | 248,414 |
| 生成的代币总数 | 31,037 | 31,037 |
| 请求吞吐量（req/s） | 1.86 | 1.78 |
| 输出令牌吞吐量（tok/s） | 225.44 | 215.94 |
| 总令牌吞吐量（tok/s） | 2029.77 | 1944.30 |
| 第一个令牌的时间（TTFT）（延迟越低越好） | ||
| 平均TTFT（毫秒） | 6,704.43 | 6,945.72 |
| 中位TTFT（毫秒） | 6,469.88 | 6,569.80 |
| P99 TTFT（毫秒） | 14,199.21 | 13,803.62 |
| 每个输出令牌的时间（TPOT，不包括第一个令牌）（延迟越低越好） | ||
| 平均 TPOT（毫秒） | 81.44 | 85.72 |
| 中位 TPOT（毫秒） | 80.38 | 80.90 |
| P99 TPOT（毫秒） | 127.69 | 159.15 |
| 令牌间延迟（ITL）（延迟越低越好） | ||
| 平均 ITL（毫秒） | 79.94 | 83.99 |
| 中位 ITL（毫秒） | 49.75 | 49.78 |
| P99 ITL（毫秒） | 539.07 | 550.73 |
关闭的思考
Graid SupremeRAID AE 为构建或扩展 AI 基础架构的组织提供实用且高效的解决方案。SupremeRAID AE 通过使用 GPU 驱动的软件定义方法取代传统的硬件 RAID，简化了部署，同时消除了阻碍现代 AI 工作流程的常见瓶颈。
我们的测试展示了它能够将多达 32 个 NVMe SSD 统一到一个弹性命名空间的能力，并在一台服务器中提供近 1PB 的容量，并具有卓越的性能。峰值读取吞吐量高达 183GB/s，写入吞吐量高达 54GB/s，再加上实时推理期间极低的 GPU 开销，证明了它能够满足大规模模型检查点和低延迟大规模推理的双重需求。
SupremeRAID AE 消除了专用 RAID 硬件的成本和复杂性，同时与 NVIDIA GPUDirect Storage 和 AI 专用文件系统等技术无缝集成，打造了面向未来的存储基础。对于专注于简化推理和降低运营风险的组织，SupremeRAID AE 可提供生产 AI 环境所需的性能、简便性和弹性。
Amazon