Supermicro JumpStart 评测：NVIDIA HGX B200 一周体验

Supermicro 的 JumpStart 项目采用了一种截然不同的硬件评估方法。它并非在共享实验室环境中进行简短的脚本演示，而是为符合条件的客户提供免费、限时的裸机访问权限，让他们能够使用一系列真实的生产服务器。从搭载 Intel Xeon 6 处理器的全新 X14 平台，到配​​备第五代 AMD EPYC 处理器和大型 HGX GPU 配置的 H14 系统，客户可以预订系统，远程登录，并像使用自己的机架上的硬件一样运行自己的工作负载。

快速、明智地做出平台决策，其商业价值便显而易见。搭建一个切实可行的 AI 或高性能计算概念验证通常意味着等待评估硬件、与多家供应商协调，并寄希望于测试配置与计划部署的配置足够接近。JumpStart 消除了这些障碍。团队无需占用内部实验室资源或将大量服务器运送到全国各地，即可验证性能、检查软件兼容性、探索功耗和散热特性并比较架构。对于大多数组织而言，只需集中一周时间进行正确的配置，就足以确认平台是否符合自身需求，或在做出最终承诺之前将其排除在外。

JumpStart 的吸引力不仅在于其在线系统的数量，更在于 Supermicro 愿意公开的技术深度。热门选择包括搭载 Intel Xeon 6 和 NVIDIA 加速器的 X14 GPU 服务器、针对密集型 CPU 计算优化的搭载第五代 AMD EPYC 处理器的 H14 平台，以及结合了现代 CPU 和全 NVMe 后端的存储专用系统。在高端产品方面，Supermicro 已提供用于 AI 训练和推理的 HGX B200 和 B300 级系统，并利用 JumpStart 平台，在签署保密协议 (NDA) 的前提下，提前展示尚未广泛上市的下一代平台。我们尚未看到其他任何 OEM 厂商如此积极地将产品正式发布前的基础设施转化为结构化、可重复的远程实验室体验。

大多数厂商的演示环境仅限于引导式解决方案实验室或功能有限的产品沙箱。这些环境虽然有助于学习管理工具和编排工作流程，但很少提供顶级服务器的根访问权限，也不允许用户自由安装和运行自己的技术栈。JumpStart 更像是远程数据中心的备用机架。预订特定系统后，您可以在预订期间通过 SSH、VNC 和 IPMI 获得完全控制权，Supermicro 会在下一位客户使用前擦除并重建环境。实际上，这与其说是营销演示，不如说是在一个运行良好的远程实验室中进行的一次简短而专注的互动。

为了进行本次分析，Supermicro 向 StorageReview 提供了与客户实际体验完全相同的 JumpStart 访问权限。我们安排了一段时间使用一台X14 10U GPU 服务器，该服务器配备了 NVIDIA HGX B200 八 GPU 主板和两颗第六代英特尔至强铂金 6960P 处理器。服务器配置了 3TB DDR5-6400 ECC 内存、M.2 和 U.2 NVMe SSD 混合用于本地存储，以及八块 B200 GPU，每块 GPU 配备 180GB HBM3e 显存。在一周的时间里，我们利用该平台对 AI 工作负载和系统运行情况进行了抽查，重点关注实际买家在部署新一代基础设施之前最想了解的问题。

我们在Supermicro JumpStart项目的一周

预约窗口开放后，JumpStart 门户网站就成了我们测试的中心枢纽。如下所示的初始仪表盘清晰地展示了预约时间表，并提供了所有必要的启动信息，包括远程 Ubuntu 环境的 SSH 凭据和完整的 IPMI 访问权限。由于这两个接口都能立即使用，我们可以在几分钟内开始验证系统，而无需等待配置或技术支持介入。

我们工作流程的第一步是确认硬件已准备就绪。通过门户网站的“系统概览”页面（见下方截图），我们验证了机箱已通电、两个 CPU 均已被检测到、内存已完全配置，并且 BMC 显示系统运行状况良好。这种快速检查已成为我们实验室评估的标准流程，而通过门户网站进行远程查看则简化了这一过程。

系统验证完毕后，我们开始进行实际操作。测试资产的文件上传直接通过 JumpStart 界面完成，省去了以往在远程平台上搭建数据集的繁琐步骤。之后，我们通过 SSH 连接进行工作负载部署，并在需要底层访问权限或观察启动行为时使用 IPMI 远程控制台。

整个测试周的工作流程与我们在实验室操作设备非常相似。我们可以快速启动、停止和迭代工作负载，在需要时重启平台，并在无需Supermicro技术支持的情况下监控硬件运行状况。操作系统级别的访问权限和完全带外控制相结合，使得测试环境可预测且高效，尤其适合短周期测试。

预订结束后，系统会自动回收并重置，顺利完成整个项目。这种可预测的流程让我们能够专注于测试而非后勤保障，并确保我们充分利用了有限的访问窗口。

GPUDirect存储性能

我们在Supermicro X14平台上进行的一项测试是Magnum IO GPUDirect Storage (GDS)测试。GDS是NVIDIA开发的一项功能，它允许GPU在访问存储在NVMe驱动器或其他高速存储设备上的数据时绕过CPU。GDS无需通过CPU和系统内存路由数据，而是实现GPU与存储设备之间的直接通信，从而显著降低延迟并提高数据吞吐量。

GPUDirect 存储的工作原理

传统上，当GPU处理存储在NVMe驱动器上的数据时，数据必须先经过CPU和系统内存才能到达GPU。这个过程会造成瓶颈，因为CPU充当了中间人，增加了延迟并消耗了宝贵的系统资源。GPUDirect Storage通过允许GPU直接通过PCIe总线访问存储设备中的数据，消除了这种低效。这种直接路径减少了数据传输开销，从而实现了更快、更高效的数据传输。

AI 工作负载，尤其是涉及深度学习的工作负载，是高度数据密集型的。训练大型神经网络需要处理数 TB 的数据，任何数据传输延迟都可能导致 GPU 无法充分利用并延长训练时间。GPUDirect Storage 通过确保数据尽快传输到 GPU，最大限度地减少空闲时间并最大限度地提高计算效率，解决了这一挑战。

此外，GDS 对于涉及流式传输大型数据集的工作负载（例如视频处理、自然语言处理或实时推理）尤其有益。通过减少对 CPU 的依赖，GDS 可加速数据移动并释放 CPU 资源以用于其他任务，从而进一步提高整体系统性能。

除了原始带宽之外，搭载 NVMe-oF (TCP/RDMA) 的 GPUDirect 还能提供超低延迟 I/O。这确保 GPU 永远不会缺数据，使该系统成为实时 AI 推理、分析管道和视频回放的理想选择。

GDSIO读取顺序吞吐量

在B200平台上进行GDSIO顺序读取测试时，初始负载较低，单线程吞吐量约为14至15GiB/s，具体数值取决于数据块大小。随着线程数和数据块大小的增加，性能迅速提升。当线程数增加到2个和4个时，吞吐量更是达到了20至36GiB/s，充分展现了系统在引入并行处理后优异的扩展性。

真正的加速发生在线程数达到八个或更多时，此时大多数工作负载的性能都稳定在 30 GiB/s 以上。较大的数据块受益最大，5MB 和 10MB 的数据块在所有线程数下都能持续提供强劲的性能。

在 256 个线程、10M 块大小下，吞吐量最终达到约 43GiB/s 的最大值，代表了我们在本次测试中观察到的最高持续顺序读取速率。

GDSIO 读取顺序延迟

在延迟方面，工作负载初期响应非常迅速，单线程读取较小数据块的延迟在 0.06–0.1 毫秒范围内。随着线程数的增加，延迟逐渐增大，在大多数工作负载下，即使达到 8 个线程，延迟也保持在 1 毫秒以下。

当线程数超过 16 个时，随着存储路径逐渐饱和，更大的数据块大小开始将延迟推至毫秒级。最高延迟出现在测试末尾，此时 10M 的数据块大小和 256 个线程的延迟峰值略高于 1.2 秒（约 1200 毫秒），这反映了旨在使系统不堪重负的最坏情况负载。

GDSIO 写入顺序吞吐量

与读取相比，顺序写入的性能波动要小得多。工作负载很快稳定下来，大多数线程和块大小组合的性能都稳定在 6.3–6.5 GiB/s 左右。这表明写入路径很早就达到了一个稳定的上限，这可能与存储介质和缓冲有关，而不是 GPU 或 PCIe 的限制。

增加线程数并没有产生显著影响，吞吐量在 2 到 128 个线程之间基本保持不变。唯一突出的结果出现在最后阶段，在 256 个线程下，10M 的数据块大小峰值达到了 18.2GiB/s，这表明当系统能够充分利用深度队列和写入聚合时，性能会有短暂的优势。

GDSIO 写入顺序延迟

写入延迟起初相对较低，单线程工作负载在较小数据块大小下约为 0.15–0.5 毫秒。随着线程数的增加，写入延迟的增长速度远超读取延迟，四线程时达到 1–4 毫秒，八线程时达到 4–9 毫秒。

当线程数达到 32 个且数据块大小增大时，延迟急剧增加，5M 和 10M 的数据块延迟跃升至 170-350 毫秒。最极端的情况是 256 个线程使用 10M 的数据块，延迟峰值接近 3 秒（约 2900 毫秒），这清楚地表明在高并行负载下，写入路径很快就会饱和。

GDSIO随机读取吞吐量

对于随机读取任务，工作负载迅速提升。单线程性能约为 11–31GiB/s，具体数值取决于数据块大小，较大的数据块能立即受益于更高的带宽。当线程数增加到两线程和四线程时，吞吐量攀升至 20–36GiB/s，展现出早期就非常强的扩展性。

从 8 个线程开始，系统性能稳定在 30GiB/s 以上的高位，与我们在顺序读取测试中观察到的结果非常相似。最高结果是在 10M 块大小和 256 个线程的情况下获得的，峰值约为 42.7GiB/s。

GDSIO随机读取延迟

随机读取延迟一开始非常低，单线程工作负载在较小数据块大小下约为 0.15–0.4 毫秒。随着线程数的增加，延迟逐渐上升，在 4 个线程时保持在 1 毫秒以下，到 8 个线程时达到约 1–3 毫秒。

一旦我们将线程数增加到 32 个，数据块大小也增大，延迟就急剧上升，5M 和 10M 的数据传输延迟就达到了 30-55 毫秒。最极端的情况出现在 256 个线程、数据块大小为 10M 时，此时延迟峰值略高于 1.1 秒（约 1180 毫秒）。

 

GDSIO 随机写入吞吐量

随机写入性能总体上非常稳定，大多数块大小和线程数下的性能都稳定在 5.8–6.1GiB/s 左右。工作负载几乎立即达到这个水平，并且随着线程数的增加，性能扩展性很差，表明写入路径很早就达到了极限。

唯一值得注意的异常值出现在测试的最后，在 256 个线程下，10M 块大小短暂地飙升至 12.5GiB/s，这可能是由于在高并行负载下，深度队列和写入聚合所致。

GDSIO随机写入延迟

随机写入延迟初始值相对较低，单线程性能在较小数据块大小下约为 0.6–1.2 毫秒，最大数据块传输时约为 5–12 毫秒。随着并发数的增加，延迟迅速增加，8 个线程时达到 4–9 毫秒，32 个线程时达到 18–38 毫秒。

超过这个点后，写入路径就饱和了。在 64 个线程的情况下，更大的数据块大小会导致延迟飙升至 150–380 毫秒，而继续扩展则会使延迟急剧增加。最糟糕的情况是 256 个线程下使用 10M 的数据块大小，延迟最高约为 4.4 秒。

vLLM 在线服务 – LLM 推理性能

vLLM 是目前最流行的 LLM 高吞吐量推理和服务引擎。vLLM 在线服务基准测试是一个性能评估工具，用于衡量该推理引擎在并发请求下的实际服务能力。它通过向运行中的 vLLM 服务器发送请求来模拟生产环境的工作负载，并可配置请求速率、输入/输出长度和并发客户端数量等参数。该基准测试会测量关键指标，包括吞吐量（每秒令牌数）、首令牌时间 (TTF) 和单次输出令牌时间 (TPOT)，帮助用户了解 vLLM 在不同负载条件下的性能。

我们测试了涵盖各种架构、参数规模和量化策略的一系列模型的推理性能，以评估不同并发配置下的吞吐量。

密集模型性能

密集模型遵循传统的LLM架构，在推理过程中所有参数和激活函数都会被调用，因此其计算量比稀疏模型更大。为了全面评估不同模型规模和量化策略下的性能特征，我们对Llama 3.1 8B系列中的多种密集模型配置进行了基准测试。

我们的测试套件包含 Meta Llama 3.1 8B 模型在三种精度格式下的评估：默认配置，以及使用 NVIDIA NVFP4 格式的 FP8 和 FP4 量化版本。需要注意的是，vLLM 目前使用 Marlin 内核来处理 NVFP4 量化模型，因此在这些基准测试中尚未完全发挥该量化格式的性能优势。未来针对原生 NVFP4 张量核心操作的 vLLM 优化可能会带来进一步的性能提升。这种模型选择策略能够实现直接的性能比较，同时隔离渐进式量化对推理吞吐量的影响。

Llama 3.1 8B 性能

Llama 3.1 8B 在标准精度下展现出以下并发级别的扩展特性。在单用户并发（BS=1）时，该模型每个用户吞吐量为 279.27 tok/s，总吞吐量为 1,727.62 tok/s，TPOT 为 3.37 ms。随着批处理大小的增加，每个用户的吞吐量下降，而总吞吐量上升。当 BS=8 时，该模型每个用户吞吐量达到 82.85 tok/s，总吞吐量为 3,386.48 tok/s，TPOT 为 3.28 ms。性能继续提升，直至 BS=32（每个用户 56.46 tok/s，总吞吐量 8,274.66 tok/s）和 BS=64（每个用户 52.70 tok/s，总吞吐量 13,707.66 tok/s）。

该模型在 BS=256 时达到最大总吞吐量，为 32,797.67 tok/s，平均每个用户吞吐量为 30.64 tok/s，TPOT 为 16.13 ms。与单用户性能相比，总吞吐量提高了 19 倍。在 BS=64 时，TPOT 值保持在 3-4 ms 范围内，而在 BS=256 时增加到 16.13 ms。

Llama 3.1 8B FP8 性能

FP8量化变体展现出不同的特性。当BS=1时，每个用户的吞吐量为149.46 tok/s，总吞吐量为9,565.20 tok/s，TPOT为3.44 ms。帕累托前沿分析揭示了三个最优解（BS=1、BS=128、BS=256）。

在 BS=128 时，该模型每位用户可提供 44.12 tok/s 的吞吐量，总吞吐量为 19,198.40 tok/s，耗时 11.04 毫秒。 

TPOT。最大总吞吐量出现在 BS=256 时，总吞吐量为 29,219.67 tok/s，每用户 30.13 tok/s，TPOT 为 13.26 ms。FP8 变体的最大总吞吐量低于标准精度（29.2K tok/s 对比 32.8K tok/s）。

Llama 3.1 8B FP4 性能

FP4 量化配置显示以下结果。在单用户并发 (BS=1) 时，每个用户可达到 279.73 tok/s，总吞吐量为 830.46 tok/s，TPOT 为 3.43 ms。

FP4 模型显示了七个帕累托前沿点。当 BS=2 时，每个用户吞吐量为 159.95 tok/s，总吞吐量为 928.60 tok/s，TPOT 为 3.43 ms。性能持续提升，BS=4 时每个用户吞吐量为 76.36 tok/s，总吞吐量为 1,631.69 tok/s，BS=32 时每个用户吞吐量为 76.09 tok/s，总吞吐量为 9,014.29 tok/s。该模型在 BS=256 时达到最大总吞吐量，为 29,340.89 tok/s，每个用户吞吐量为 30.13 tok/s，TPOT 为 16.18 ms。

稀疏模型性能

稀疏模型，特别是专家混合模型（MoE）架构，是一种新兴的高效扩展语言模型的方法。这些架构在保持较高总参数数量的同时，每个词元仅激活一部分参数，从而有可能提高每个激活参数的性能。

我们评估了两种 MoE 架构：DeepSeek-R1（一种侧重推理的模型）和 Qwen3 Coder 30B-A3B（一种专用于代码生成的稀疏架构）。DeepSeek-R1 是最流行的侧重推理的模型，与传统语言模型相比，它展现出显著的性能特征。Qwen3 Coder 模型保留了 3 亿个参数，但每个生成的标记仅激活 30 亿个参数。我们对 Qwen3 Coder 进行了基准测试，分别测试了其在标准语言和 FP8 量化语言环境下的性能，以了解不同量化策略下的性能特征。

DeepSeek-R1 性能

DeepSeek-R1 模型在不同批处理大小下展现出有趣的扩展性。在单用户并发（BS=1）时，该模型每个用户可达到 30.24 tok/s 的处理速度，总吞吐量为 88.13 tok/s，TPOT 为 29.85 ms。当批处理大小扩展至 BS=4 时，每个用户的性能提升至 29.77 tok/s，总吞吐量达到 266.40 tok/s，TPOT 为 32.04 ms，这是所有配置下所能达到的最大总吞吐量。

DeepSeek-R1 的性能在批处理大小 (BS) 超过 4 后趋于稳定。当 BS=8 时，每个用户的吞吐量急剧下降至 14.98 tok/s，并且随着批处理大小的增加，吞吐量持续下降，在 BS=256 时仅为每个用户 0.46 tok/s。在 BS=4 到 BS=256 的范围内，总吞吐量保持在 200 到 260 tok/s 之间相对稳定，这是因为该模型无法在单个节点上扩展以应对更多的并发请求，导致延迟增加而吞吐量没有显著提升。值得注意的是，B200 DGX 是少数能够运行这种大规模模型的单服务器解决方案之一。

Qwen3 Coder 30B-A3B 性能

标准精度的 Qwen3 编码器在不同并发级别下的性能表现如下。在单用户并发（BS=1）时，该模型每个用户的吞吐量为 178.30 tok/s，总吞吐量为 527.25 tok/s，TPOT 为 5.46 ms。当 BS=2 时，每个用户的性能提升至 174.56 tok/s，总吞吐量达到 718.70 tok/s，TPOT 为 5.60 ms。随着批处理大小的增加，每个用户的吞吐量下降，而总吞吐量则持续增长：当 BS=16 时，每个用户的吞吐量为 127.76 tok/s，总吞吐量为 4,204.40 tok/s，TPOT 为 6.93 ms。

该模型在 BS=256 时达到最大总吞吐量，总吞吐量为 22,305.88 tok/s，平均每个用户吞吐量为 46.16 tok/s，TPOT 为 17.64 ms。帕累托前沿包含八个不同的点，其中 BS=32 处有一个重复的点（总吞吐量为 72.97 tok/s，平均每个用户吞吐量为 93.50 tok/s，可能代表不同的配置）。在 BS=64 之前，TPOT 值保持在 5-9 ms 的范围内。

Qwen3 Coder 30B-A3B FP8 性能

FP8 量化变体展现出以下性能特征。在单用户并发（BS=1）下，其每用户吞吐量为 107.46 tok/s，总吞吐量为 317.75 tok/s，TPOT 为 9.16 ms。在 BS=2 时，该模型每用户吞吐量为 99.55 tok/s，总吞吐量为 409.87 tok/s，TPOT 为 9.86 ms。

扩展到更高的批处理大小：批处理大小为 8 时，每个用户吞吐量为 54.60 tok/s，总吞吐量为 1,383.13 tok/s，TPOT 为 10.24 ms；批处理大小为 32 时，每个用户吞吐量为 48.78 tok/s，总吞吐量为 3,874.21 tok/s，TPOT 为 10.67 ms。最大总吞吐量出现在批处理大小为 256 时，总吞吐量为 19,114.86 tok/s，每个用户吞吐量为 36.38 tok/s，TPOT 为 20.00 ms。这大约相当于标准精度最大吞吐量的 86%。

微扩展数据类型性能

微尺度化是一种先进的量化方法，它将细粒度的缩放因子应用于小块权重，而不是对大型参数组进行统一量化。NVIDIA 的 NVFP4 格式通过分块浮点表示实现了这项技术，其中每个包含 8-32 个值的微尺度块共享一个公共指数作为缩放因子。这种精细方法在实现 4 位表示的同时保留了数值精度，从而保持了 Transformer 架构所需的动态范围。该格式与 NVIDIA 的 Tensor Core 架构集成，可在矩阵运算过程中实现高效的混合精度计算和动态解压缩。

我们使用 NVFP4 量化方法，在两种参数尺度下评估了 OpenAI 的 GPT OSS 模型：20B 版本和更大的 120B 版本。这些基准测试展示了微尺度量化方法在不同模型规模下的性能表现。

GPT-OSS-20B 性能

20B 参数模型在不同批处理大小下实现了以下性能。在单用户并发 (BS=1) 时，每个用户吞吐量为 299.28 tok/s，总吞吐量为 943.43 tok/s，TPOT 为 3.23 ms。在 BS=2 时，该模型保持每个用户 299.19 tok/s 的吞吐量，总吞吐量为 1,356.87 tok/s，TPOT 为 3.19 ms。

扩展到更高的批处理大小：批处理大小为 8 时，每个用户的处理速度为 259.02 tok/s，总处理速度为 5,149.59 tok/s，TPOT 为 3.42 ms；批处理大小为 16 时，每个用户的处理速度为 200.69 tok/s，总处理速度为 7,765.73 tok/s，TPOT 为 3.77 ms。该模型继续扩展，批处理大小达到 32（每个用户 168.34 tok/s，总处理速度为 12,411.72 tok/s）和 64（每个用户 123.96 tok/s，总处理速度为 16,931.47 tok/s）。

当 BS=256 时，总吞吐量达到 38,258.50 tok/s，平均每个用户吞吐量为 65.08 tok/s，TPOT 为 9.39 ms。与单用户性能相比，总吞吐量提高了 40.5 倍。在 BS=32 时，TPOT 值保持在 3-5 ms 范围内。帕累托前沿包含八个不同的点。

GPT-OSS-120B 性能

尽管参数数量增加，更大的 120B 参数模型仍保持了以下性能。在单用户并发 (BS=1) 时，每个用户的吞吐量为 248.62 tok/s，总吞吐量为 783.73 tok/s，TPOT 为 3.89 ms。在 BS=2 时，该模型每个用户的吞吐量为 240.99 tok/s，总吞吐量为 1,092.91 tok/s，TPOT 为 3.99 ms。

随着批处理大小的增加，性能持续提升：批处理大小为 4 时，每个用户的处理速度为 190.63 tok/s，总处理速度为 2,096.73 tok/s，TPOT 为 4.22 ms；批处理大小为 8 时，每个用户的处理速度为 172.66 tok/s，总处理速度为 3,692.10 tok/s，TPOT 为 4.54 ms。批处理大小依次增加至 16（每个用户 138.28 tok/s，总处理速度为 5,751.41 tok/s）、32（每个用户 111.63 tok/s，总处理速度为 8,646.05 tok/s）和 64（每个用户 88.64 tok/s，总处理速度为 13,027.97 tok/s）均显示出吞吐量的持续增长。

该模型在 BS=256 时达到最大总吞吐量，为 29,976.99 tok/s，平均每个用户吞吐量为 48.64 tok/s，TPOT 为 12.53 ms。与单用户性能相比，总吞吐量提高了 38.2 倍。最大总吞吐量约为 20B 模型峰值的 78%。帕累托前沿包含九个不同的点，是所有测试模型中最多的。

意料之外的量化模型性能

量化模型的结果出乎意料，值得进一步研究。在某些情况下，NVFP4 和 FP8 量化版本的模型并未达到预期的性能提升，与对应的原生精度版本相比并无显著差异。例如，Llama 3.1 8B FP4 模型在 BS=1 时的总吞吐量仅为 830.46 tok/s，而标准精度版本则为 1,727.62 tok/s，尽管二者的用户吞吐量相近。在更高的批处理大小下，虽然量化模型的吞吐量接近标准精度版本（BS=256 时为 29.2K-29.3K tok/s，而标准精度版本为 32.8K tok/s），但总体结果表明，vLLM 的当前实现可能并未针对 Blackwell 进行充分优化。

我们计划对 vLLM 进行更多测试，并将其与 TensorRT-LLM 进行比较，以了解最终用户目前可以期待的性能。

Supermicro JumpStart 改变了 AI PoC 的游戏规则

Supermicro 的 JumpStart 项目兑现了其承诺：真正、不受限制地使用生产级硬件，无需承担传统概念验证 (PoC) 的物流、运输延误或实验室开销。我们在 X14 HGX B200 平台上的 JumpStart 体验周启动迅速，运行流畅，让我们能够以与在自家机架上使用相同方式评估其性能。

对于那些需要快速制定 AI 基础设施决策的组织而言，这种平台访问方式可以将数周的规划时间缩短至数天。无论目标是验证 GPU 吞吐量、存储行为、模型性能，还是仅仅确认堆栈兼容性，JumpStart 都能以最小的阻力助您获得答案。这是一种以信心为导向的硬件评估方法，我们希望看到更多供应商采用这种方法。