Supermicro 的 JumpStart 项目已成为 AI 基础设施采购前评估工具包中最有用的工具之一。JumpStart 并非在共享环境中进行脚本化的演示，而是为符合条件的用户提供免费、限时、裸机访问权限，用户可以通过 SSH、IPMI 和 VNC 访问真实的生产服务器，从而在实际硬件上运行工作负载。我们去年 11 月曾对该项目进行过深入报道。 配备 NVIDIA HGX B200 的 X14 系统并由此清晰地了解了一周的集中访问能够以及不能告诉你什么。这一次，Supermicro 提供了一套 H14 8U 系统的访问机会，该系统的加速器情况则截然不同。
我们测试了 AS-8126GS-TNMR 系统这是一款采用8U风冷设计的平台，搭载两颗AMD EPYC 9575F处理器和八颗AMD Instinct MI350X GPU。MI350X是AMD目前旗舰级的数据中心加速器，基于台积电3nm工艺的第四代CDNA架构，每颗GPU配备288GB HBM3e显存。八颗GPU通过AMD Infinity Fabric互连，单节点即可提供2.3TB的GPU总显存，总带宽高达1,024GB/s。整个系统采用六个5,250W钛金级电源，并配置3+3冗余，Supermicro还为每颗GPU配备了专用的400Gbps网络，以满足横向扩展部署的需求。
过去两年，AMD 在数据中心 GPU 市场的地位发生了显著变化，MI350X 系列显卡对 NVIDIA 的竞争威胁比以往任何 Instinct 产品都更为严峻。ROCm 7 于 2025 年 9 月发布，目前已更新至 7.2 版本，它不仅原生支持 MI350X，还大幅提升了推理性能，更新了 HIP API 以弥补 CUDA 兼容性方面的不足，并扩展了框架支持，包括 PyTorch、JAX、TensorFlow、ONNX Runtime、vLLM 和 SGLang。
vLLM 项目于 2025 年 12 月底新增了专用的 AMD ROCm CI 流水线，使 AMD 硬件成为该推理堆栈中的一流平台，而非下游移植平台。该生态系统的普及程度也不容忽视： AMD和Meta宣布 Meta与合作伙伴签署了一份为期多年、涵盖多代产品的6吉瓦GPU部署协议，该协议将于2026年2月生效，并将在Meta现有MI300和MI350系列硬件的生产部署基础上进一步扩展。作为全球最大的AI基础设施运营商之一，Meta的这种承诺绝非营销噱头。
对于目前正在评估 AI 加速器基础设施的组织而言，NVIDIA 硬件的交付周期仍然是一个令人担忧的问题。关键在于 AMD 是否是一个可靠的替代方案，而不仅仅是备选方案。基于使用 ROCm 7.2.0 和当前 vLLM 进行的一周测试，答案与 18 个月前相比已截然不同。
我们的测试涵盖了一系列流行的模型；单个节点上的 2.3TB HBM3e 实现了对大参数模型的单服务器推理，包括 Moonshot 的 Kimi K2.5 和 MiniMax M2.5。
AMD Instinct MI350X：架构和代际改进
MI350X 代表了 AMD 迄今为止在 Instinct 产品线中架构上最具雄心的一次代际飞跃。了解其背后的工程设计决策，对于解读后续的性能测试结果至关重要。
CDNA 4 架构和流程节点过渡
MI350系列从MI300系列到MI350系列的根本性转变在于加速计算芯片（XCD）采用了台积电的N3P工艺节点，取代了上一代使用的5nm工艺。晶体管总数达到约1850亿，比MI300系列增加了约21%，而功耗并未相应增加。
MI350X 沿用了 AMD 成熟的多芯片封装策略。其核心 GPU 封装包含八个加速计算芯片 (XCD) 作为主要计算引擎。每个 XCD 包含四个着色器引擎，每个着色器引擎配备八个活跃的 CDNA 4 计算单元，每个 XCD 提供 32 个计算单元，整个加速器共包含 256 个计算单元。
在CDNA 4封装设计中，I/O芯片层也从四个芯片简化为两个。这种重组使AMD能够将Infinity Fabric总线宽度增加一倍，从而提高双向带宽，同时降低总线频率和工作电压，进而降低功耗。
重新设计的计算单元和扩展的精度支持
借助 CDNA 4 计算单元的矩阵运算能力，性能得到了显著提升：与 MI300 计算单元相比，MI350 计算单元在 16 位 (BF16, FP16) 和 8 位 (FP8, INT8) 运算方面，每个计算单元的吞吐量提高了 2 倍。
除了原始吞吐量的提升之外，CDNA 4 还引入了对 MI300 系列中不存在的低精度数据类型（特别是 FP6 和 FP4）的硬件支持，以及从上一代产品延续下来的 FP8 支持。
除了这些标准格式之外，MI350X 还增加了对 OCP 微缩放变体（MXFP4、MXFP6 和 MXFP8）的原生硬件支持。微缩放格式旨在提供低精度计算的吞吐量优势，同时保持输出质量更接近高精度基准，而这通常是标准量化所无法实现的。这并非 AMD 独有的开发成果。NVIDIA 的 NVFP4 格式也基于相同的微缩放原理，并在前沿模型部署中得到广泛应用，OpenAI 的 GPT-OSS 系列就是基于这些格式构建的最杰出示例之一。MI350X 的原生 MXFP4 支持使其能够服务于这些以及类似的量化模型系列，而无需回退到软件模拟或精度提升。
MI350X 在 MXFP4 和 MXFP6 下可提供 9.2 PFLOPs 的计算能力，而 OCP-FP8 下为 4.6 PFLOPs，FP16 下为 2.3 PFLOPs，峰值引擎时钟频率为 2,200 MHz。对于可进行微缩量化的推理优化部署，其计算余量相对于 FP8 工作负载有效翻倍。此外，CDNA 4 计算单元中还新增了一个向量 ALU，支持 2 位运算，并能够将 BF16 的结果累加到 FP32 中，从而为主矩阵计算路径之外的低精度向量工作负载提供了更大的灵活性。
内存子系统：HBM3e、无限缓存和带宽效率
MI350 系列显卡配备了大幅升级的内存子系统，包含八个 HBM3e 内存堆栈，每个 GPU 的总容量高达 288GB。每个 36GB 的堆栈由 12 个 24Gbit 的 HBM3e 芯片组成，每个引脚的传输速度均为 8Gbps。该架构保留了 AMD 的 Infinity Cache，这是一种位于 HBM 和 Infinity Fabric/L2 缓存之间的内存端缓存。它包含 128 个通道，每个通道配备 2MB 缓存，每个 GPU 的总缓存容量为 256MB。AMD 还拓宽了 IOD 内部的网络总线，并降低了其工作电压，与 MI300 系列相比，每瓦内存带宽提高了约 1.3 倍。
MI350X 的显存容量从 192GB 提升至 288GB，进一步巩固了 AMD 在单 GPU 显存容量方面的领先优势，这对大型模型推理具有直接意义。每个 MI300X GPU 均可独立运行参数超过 500 亿的模型。在配备八个 GPU 的服务器上，总计 2.3TB 的 HBM3e 显存消除了多节点分布式部署的需求，而多节点分布式部署通常会使万亿参数规模的模型部署变得复杂，正如本次评测中 Kimi K2.5 和 MiniMax M2.5 的结果所示。
灵活的分区和部署架构
MI350 系列支持每个插槽灵活的 GPU 分区，内存被划分为两个独立的集群。这种灵活性也适用于 XCD，四路 XCD 集群可以拆分为双路或单路模块，使芯片能够支持诸如 CPX+NPS2 中 8 个 70 亿模型实例之类的配置。对于在共享基础架构上运行异构推理工作负载的组织而言，这种分区功能减少了每个模型层级对专用硬件的需求，并提高了混合部署环境中的资源利用率。
MI350 系列还保持了与 MI300 系列系统中使用的 UBB（通用基板）基础架构的即插即用兼容性。现有的服务器机箱、电源和散热基础架构无需任何修改即可继续使用，从而降低了已部署 MI300 的企业升级的难度。
MI355X：液冷版兄弟
MI350系列芯片有两种型号，均采用相同的底层硅芯片，并针对不同的散热工作环境进行了优化。本文测试的MI350X为风冷版本，而MI355X则是其液冷版本，专为高密度部署环境而设计，在这些环境中可以直接使用液冷散热。
虽然两款产品基于相同的基本硬件，但MI355X更高的运行功耗使其能够维持更高的时钟频率，从而在实际端到端工作负载下比MI350X性能提升约20%。MI355X的总功耗上限为1,400W，而MI350X为1,000W；MI355X的最高时钟频率为2.4GHz，而风冷版MI350X的最高时钟频率为2.2GHz。
从代际角度来看，MI355X 平台的理论峰值性能比 MI300X 提升高达 4 倍，在智能体和聊天机器人工作负载中，实际推理性能提升约为 4.2 倍，在内容生成场景中提升约为 3 倍。对于正在评估 MI350X 部署的组织而言，两款产品之间 20% 的性能差异已达到性能上限。拥有 DLC 基础设施的机构应评估 MI355X，以确定散热方面的投入是否能为其特定的工作负载带来足够的吞吐量提升，然后再大规模部署风冷配置。
通过 Supermicro JumpStart 计划访问 AMD Instinct MI350X
要开始使用 JumpStart 服务，需要在 Supermicro 的门户网站上注册。符合条件的用户可以在该网站上浏览可用的系统并预约使用时段。审核通过后，门户网站会提供 SSH 凭据、IPMI 访问权限以及基于 Web 的远程控制台，供您在预约期间使用。系统预装了 Ubuntu 系统，到货即可使用。无需任何配置延迟，也无需任何技术支持即可开始使用。我们的预约时间为 2026 年 3 月 23 日至 27 日，让我们在该平台上使用了一整周，这与我们之前使用 HGX B200 的 JumpStart 服务时长一致。
下面的屏幕截图显示了 H14 系统 jumpstart 的终端输出，其中 AMD-SMI 工具显示了八个 AMD Instinct MI350X GPU 及其运行的软件版本。
AMD Instinct MI350X 性能测试结果
系统配置
- 底盘： 超微 H14
- CPU： 双路 AMD EPYC 9575F
- 记忆： 3TB DDR5
- GPU： 八款 AMD Instinct MI350X
- 存储： 2块3.8TB PCIe 4.0 M.2 NVMe SSD和1块1.92TB NVMe M.2
结果汇总
| 型号 | 平台精度 | 等于 (256/256) | 预填充-重（8k/1k） | 解码密集型（1k/8k） |
|---|---|---|---|---|
| GPT-OSS 20B | NVFP4 | 62,247 | 123,714 | 32,468 |
| GPT-OSS 120B | NVFP4 | 33,538 | 84,018 | 20,602 |
| 骆驼 3.1 8B 指导 | BF16 | 51,467 | 77,658 * | 19,326 |
| 米斯特拉尔小号 3.1 24B | FP8 | 40,742 | 56,093 | 14,557 |
| 米斯特拉尔小号 3.1 24B | BF16 | 30,530 | 53,740 | 13,559 |
| Qwen3 Coder 30B A3B | BF16 | 34,980 | 51,550 | 11,782 |
| Qwen3 Coder 30B A3B | FP8 | 25,928 | 47,179 | 11,014 |
| MiniMax M2.5 | 块级缩放 FP8 | 14,391 | 23,689 | 6,068 |
| 基米 K2.5 | INT4 QAT + BF16 | 6,527 | 11,256 | 2,513 |
| 所有数值均以 tok/s 为单位，峰值吞吐量为 BS=256。*Llama 3.1 8B 预填充重度在 BS=128 时达到峰值（77,658 tok/s）；BS=256 时为 76,893 tok/s。 | ||||
Claude Code Serving – MiniMax M2.5
除了传统的原始LLM推理基准测试之外，我们还想评估该硬件在智能体编码工作流程中的性能，特别是支持多个并发的Claude Code会话以及本地托管的模型。此用例直接关系到开发团队的生产力：在体验下降之前，有多少工程师可以同时使用由单个节点提供的AI编码助手？
为了验证这一点，我们构建了一个基准测试框架，该框架生成一个中等难度的编码问题数据集（例如实现 LRU 缓存、构建 CLI 待办事项应用程序、编写 Markdown 转换器以及构建 REST API 等任务），并在各自的 Docker 容器中针对本地 vLLM 服务器运行每个 Claude Code 会话。会话和推理端点之间有一个透明代理，用于捕获每个 Claude Code 实例的请求指标。我们使用的模型是 MiniMax M2.5，通过 vLLM 在八块 MI350X GPU 上运行。虽然 M2.5 在公开排行榜上并非排名最高的编码模型，但它是一个功能强大的模型，许多用户（包括我们的许多开发者朋友）都在本地运行该模型。
作为基准参考点，我们使用 Anthropic 的 Claude Opus 4.6 通过 OpenRouter.ai（最流行的生产 API 访问路由服务之一）测得的平均输出吞吐量。该基准值约为每个 API 请求每秒 37 个令牌。
我们测量了两个关键指标：每个 Claude Code 会话每秒平均输出令牌数（每个开发人员的体验）和所有会话每秒总输出令牌数（服务器产生的总工作量）。
从结果来看，单并发会话的单用户吞吐量为 38.8 tok/s，总吞吐量为 38 tok/s，略高于 OpenRouter 云基准。在双并发会话时，随着 vLLM 的批处理开始分摊开销，系统单用户吞吐量略微提升至 39.5 tok/s，总吞吐量攀升至 63 tok/s。四并发会话的单用户吞吐量为 37.3 tok/s，与云基准持平，同时可同时服务四位开发者，总吞吐量达到 128 tok/s。从八并发会话开始，单实例吞吐量开始下降：八并发会话时为单用户 34.6 tok/s，十六并发会话时为 31.4 tok/s，总吞吐量为 190 tok/s，在三十二并发会话和六十四并发会话时分别稳定在单用户 23 tok/s 左右，而总吞吐量则分别攀升至 578 tok/s 和 986 tok/s。这就是典型的批处理吞吐量与交互性之间的权衡：系统可以通过批处理更多请求来显著提高总吞吐量，但每个用户的响应时间都会变慢。即使有 64 个并发用户，每个开发者仍然可以获得可用的交互体验，尽管速度明显慢于云端基准水平。
对于正在权衡数十个同时进行的商业 API 订阅成本与自托管基础设施成本的组织而言，权衡显而易见：单个 MI350X 节点可以为 16 至 32 名工程师的开发团队提供服务，将每个用户的响应速度保持在云基线的 60-85% 以内，同时提供 600 至 1,000 tok/s 的聚合输出，并具有数据本地性、无按令牌计费的 API 费用以及对模型选择的完全控制等额外优势。
vLLM 在线服务 – LLM 推理性能
vLLM 是 LLM 领域最流行的高吞吐量推理和服务引擎之一。vLLM 在线服务基准测试评估了该推理引擎在并发请求下的实际服务性能。它通过向运行中的 vLLM 服务器发送请求来模拟生产环境的工作负载，并可配置请求速率、输入/输出长度和并发客户端数量等参数。该基准测试测量关键指标，包括吞吐量（每秒令牌数）、首令牌时间 (TTF) 和单次输出令牌时间 (TPOT)，帮助用户了解 vLLM 在不同负载条件下的性能。
我们测试了涵盖各种架构、参数规模和量化策略的一系列模型的推理性能，以评估不同并发配置下的吞吐量。
GPT-OSS 120位和20位
GPT-OSS 模型系列在 Supermicro H14 上分别以 120B 和 20B 配置进行了测试。
GPT-OSS 120B
在相同工作负载 (256/256) 下，120B 模型在 BS=1 时输出速度为 313.42 tok/s，在 BS=64 时达到 11,261.72 tok/s，在 BS=256 时达到峰值 33,538.23 tok/s。预填充较多 (8k/1k) 的初始速度为 1,724.84 tok/s，在 BS=32 时攀升至 36,156.80 tok/s，在 BS=128 时达到 79,247.76 tok/s，在 BS=256 时达到峰值 84,018.79 tok/s。解码密集型（1k/8k）从 BS=1 时的 288.90 tok/s 增长到 BS=256 时的 20,602.52 tok/s，在较低的并发水平下延迟仍然得到很好的控制。
GPT-OSS 20B
在相同工作负载下，20B 模型在 BS=1 时吞吐量为 485.17 tok/s，在 BS=64 时达到 17,986.36 tok/s，在 BS=256 时达到峰值 62,247.52 tok/s。预填充密集型任务的吞吐量从 3,120.72 tok/s 开始，在 BS=32 时攀升至 48,132.52 tok/s，在 BS=64 时攀升至 83,968.71 tok/s，在 BS=256 时达到峰值 123,714.50 tok/s——这是两种模型尺寸中记录到的最高绝对预填充吞吐量。解码密集型运算速度从 BS=1 时的 378.20 tok/s 增长到 BS=256 时的 32,468.67 tok/s，在峰值并发时实现了 120B 解码吞吐量的约 1.6 倍，同时保持了更紧凑的延迟特性。
Qwen3 Coder 30B A3B 指导和 FP8 指导
在 Supermicro H14 上对 Qwen3-Coder-30B-A3B-Instruct 进行了标准 (BF16) 和 FP8 精度测试。
Qwen3-Coder-30B-A3B-Instruct (BF16)
在 BF16 上，相同工作负载 (256/256) 在 BS=1 时达到 240.53 tok/s，在 BS=64 时达到 13,312.70 tok/s，在 BS=128 时达到 21,333.79 tok/s，峰值吞吐量在 BS=256 时达到 34,980.97 tok/s。预填充密集型 (8k/1k) 的吞吐量从 1,276.76 tok/s 开始，在 BS=32 时攀升至 25,069.32 tok/s，在 BS=128 时攀升至 50,198.94 tok/s，峰值吞吐量在 BS=256 时达到 51,550.66 tok/s。解码密集型（1k/8k）从 BS=1 时的约 188 tok/s 稳步增长到 BS=256 时的 11,782 tok/s，在三种场景中保持了最紧凑的延迟特性。
Qwen3-Coder-30B-A3B-Instruct (FP8)
在相同工作负载下，FP8 变体在 BS=1 时速度为 188.92 tok/s，在 BS=64 时达到 10,866.27 tok/s，在 BS=128 时达到 17,617.60 tok/s，在 BS=256 时达到峰值 25,928.77 tok/s——在所有范围内均略低于 BF16 的结果。预填充密集型变体的初始速度为 860.07 tok/s，在 BS=32 时攀升至 20,513.77 tok/s，在 BS=128 时达到 44,205.46 tok/s，在 BS=256 时达到峰值 47,179.15 tok/s。解码密集型任务从 BS=1 时的 133.79 tok/s 增长到 BS=256 时的 11,014.95 tok/s，持续扩展并始终接近 BF16。
Mistral Small 3.1 24B 指令 2503
在 H14 上测试了 Mistral-Small-3.1-24B-Instruct-2503 的标准精度和 FP8 动态精度，结果表明在所有三种工作负载配置文件中均具有一致的扩展性。
Mistral-Small-3.1-24B-Instruct-2503 (BF16)
在 BF16 精度下，相同工作负载 (256/256) 在 BS=1 时达到 236.15 tok/s，在 BS=64 时达到 15,494.56 tok/s，在 BS=128 时达到 24,216.52 tok/s，在 BS=256 时达到峰值 30,530.54 tok/s。预填充较多 (8k/1k) 的初始速度为 1,429.41 tok/s，在 BS=32 时攀升至 29,631.68 tok/s，在 BS=128 时达到 54,871.74 tok/s，在 BS=256 时达到峰值 53,740.04 tok/s。解码密集型（1k/8k）从 BS=1 时的 242.66 tok/s 增长到 BS=256 时的 13,559.19 tok/s，并在整个范围内稳步增长。
Mistral-Small-3.1-24B-Instruct-2503 (FP8-动态)
在相同工作负载下，FP8动态变体在BS=1时速度为184.25 tok/s，在BS=64时达到16,113.95 tok/s，在BS=128时达到26,409.01 tok/s，在BS=256时达到峰值40,742.04 tok/s。预填充重采样变体的初始速度为1,210.06 tok/s，在BS=32时攀升至28,773.52 tok/s，在BS=128时达到57,765.02 tok/s，在BS=256时达到峰值56,093.09 tok/s，从BS=64开始领先于标准精度结果。解码密集型数据从 BS=1 时的 183.94 tok/s 增长到 BS=256 时的 14,557.94 tok/s，在中段范围内紧密跟踪，然后在 BS=128 和 BS=256 时略微领先。
骆驼 3.1 8B 指导
对于 Llama-3.1-8B-Instruct，我们看到，在 BS=1 时，等负荷 (256/256) 的吞吐量为 373.26 tok/s，在 BS=64 时达到 19,363.33 tok/s，在 BS=128 时达到 34,155.70 tok/s，并在 BS=256 时达到峰值 51,467.30 tok/s。预填充较多 (8k/1k) 的吞吐量起始值为 1,959.04 tok/s，在 BS=32 时攀升至 37,227.63 tok/s，在 BS=64 时达到 60,062.40 tok/s，在 BS=128 时达到峰值 77,658.50 tok/s，之后略有下降，在 BS=256 时降至 76,893.77 tok/s。解码密集型（1k/8k）的初始速度为 326.48 tok/s，在 BS=128 时达到 17,877.52 tok/s，在 BS=256 时达到 19,326.35 tok/s，在并发范围内保持比任何测试过的较大模型更低的单令牌延迟。
MiniMax M2.5
H14 上的 MiniMax-M2.5 完善了该系列产品线，其吞吐量介于 Kimi K2.5 和中型处理器之间，其特性体现了混合专家架构。在相同工作负载 (256/256) 下，BS=1 时吞吐量为 79.31 tok/s，BS=64 时达到 5,029.76 tok/s，BS=128 时达到 7,801.10 tok/s，BS=256 时达到 14,391.98 tok/s。预填充密集型（8k/1k）在三种场景中展现出最强的扩展性，初始速度为 424.41 tok/s，在 BS=32 时攀升至 10,376.75 tok/s，在 BS=128 时攀升至 20,658.57 tok/s，并在 BS=256 时达到峰值 23,689.18 tok/s。解码密集型（1k/8k）的扩展性稳定，在 BS=128 时达到 4,257.68 tok/s，在 BS=256 时达到 6,068.70 tok/s，在整个并发范围内提供了最稳定的延迟增长。
基米 K2.5
H14 上的 Kimi K2.5 1 万亿参数模型是本次评测中测试的最大、最智能的模型，其吞吐量也反映了这一重量。
相同工作负载 (256/256) 在批处理深度 (BS) 为 1 时吞吐量为 72.06 tok/s，在 BS=64 时达到 2,693.07 tok/s，在 BS=128 时达到 4,244.27 tok/s，并在 BS=256 时达到峰值 6,527.62 tok/s。预填充密集型 (8k/1k) 的吞吐量扩展性更强，从 185.29 tok/s 开始，在 BS=32 时达到 3,798.85 tok/s，在 BS=128 时达到 9,153.12 tok/s，并在 BS=256 时达到峰值吞吐量 11,256.69 tok/s。从 BS=128 到 BS=256 的阶跃式增加带来了显著的延迟开销，表明对于此模型大小，系统在满批处理深度下已接近其内存和计算能力的极限。解码密集型（1k/8k）从 BS=1 时的 29.88 tok/s 增长到 BS=256 时的 2,513.85 tok/s，在三种场景中实现了最紧凑的扩展曲线，同时在整个范围内都表现出一致的吞吐量提升。
结语
AMD Instinct MI350X 在本文测试的工作负载配置文件中均展现出极具竞争力的推理性能，而 Supermicro AS-8126GS-TNMR 则提供了一个精心设计的平台来充分发挥其优势。每个加速器配备 288GB HBM3e 显存，八个 GPU 通过 Infinity Fabric 互连，单个节点即可提供 2.3TB 的总 GPU 显存，足以支持 Kimi K2.5 和 MiniMax M2.5 等万亿参数模型，无需多节点分布或模型分区等变通方案。这一能力显著简化了大规模推理的部署架构。
较小的模型也取得了优异的成绩。Llama 3.1 8B 在预填充密集型工作负载下吞吐量超过 77,000 tok/s，而 Mistral Small 3.1 24B 和 Qwen3 Coder 30B 等中端架构在整个并发范围内均保持了高吞吐量和良好的延迟控制。总体而言，结果表明该硬件平台在负载下能够实现可预测的扩展，而不是在高批处理深度下性能急剧下降。
ROCm 7.2 对 AMD 推理软件栈进行了显著改进，尤其是在与 vLLM 0.18 配合使用时。这种组合带来了比以往 ROCm 版本更稳定、性能更高的服务体验，并扩展了框架支持范围，同时减少了早期 Instinct 部署中存在的缺陷。AMD 硬件生态系统的发展势头也值得关注：上游 vLLM 现在维护着专用的 AMD ROCm CI 流水线，而 Meta 在 6 吉瓦规模下的多代部署承诺也表明，生产验证远不止于受控的基准测试环境。
Claude Code 的服务评估为原始吞吐量数据增添了实际应用价值。单个 MI350X 节点在支持多达 16 个并发编码会话的情况下，仍能保持接近云端基准的响应速度，并能与多达 64 个并发用户保持交互，同时还能产生近 1,000 tok/s 的总输出。对于正在权衡商业 API 订阅成本与自托管基础设施成本的组织而言，在这种密度下，经济效益显而易见，此外，自托管基础设施还具有数据本地化、免除按令牌计费以及不受限制的模型选择等额外优势。
Supermicro 的 JumpStart 项目在基础设施评估流程中持续发挥着重要作用。该项目允许我们直接访问生产硬件，无需任何配置开销，从而在整个测试期间，在真实环境下运行实际工作负载。对于进行加速器采购评估的团队而言，这种级别的实际操作体验远比规格表对比或厂商精心策划的演示更具参考价值。
Amazon