橡树岭国家实验室（ORNL）将发布一份关于下一代高性能计算（HPC）系统，即计划于2027年交付的OLCF-6的需求建议书（RFP）。于2023年9月25日，ORNL发布了OLCF-6合同的技术要求草案文件《OLCF-6 技术要求文件草案 v1.0》。本文仅摘选该的存储系统相关章节：
- 1 引言（Introduction）
- 2 总体系统要求（High Level System Requirements）
- 4 I/O 子系统（I/O Subsystem）
- 5 高性能互连（High Performance Interconnect）
关于ORNL
美国橡树岭国家实验室（Oak Ridge National Laboratory，ORNL）是位于美国田纳西州橡树岭的一家由美国政府资助的研究与开发中心。成立于1943年，该实验室目前由美国能源部（Department of Energy）赞助并由UT–Battelle, LLC管理。
ORNL是美国能源部体系中（按照规模计算）最大的科学与能源国家实验室，按年度预算计算则居第三位。它位于田纳西州橡树岭（Oak Ridge）的罗恩县（Roane County）。其科研项目侧重于材料科学、核科学、中子科学、能源、高性能计算、系统生物学和国家安全领域，有时与田纳西州政府、大学和其他行业合作开展研究。
ORNL拥有世界顶尖的超级计算机，包括被TOP500评为全球最强大的Frontier。该实验室是领先的中子与核能研究设施，包括散裂中子源、高通量同位素反应堆和纳米材料科学中心。
Source: DRAFT OLCF-6 TECHNICAL REQUIREMENTS，September 25, 2023
https://www.olcf.ornl.gov/draft-olcf-6-technical-requirements/
1 引言
本文概述了针对 2027 年交付给橡树岭国家实验室（ORNL）和橡树岭领先计算设施（OLCF，Oak Ridge Leadership Computing Facility）的 OLCF-6 后E级（Post-Exascale）高性能计算（HPC）系统所需的技术规范。这一计算能力的目标是满足美国能源部（DOE）科学办公室（SC，Office of Science）高级科学计算研究（ASCR）计划的任务需求。ORNL由UT-Battelle，LLC进行管理，以下简称为“公司”。
对于此文档中提出的每个解决方案建议，都必须明确说明主要的技术子承包商（如CPU、加速器、互连）以及第三方软件合作伙伴（例如工作负载管理器、性能工具）的角色，以及这些子承包商提供的增值服务。
此能力的全部生命周期将在有限的资金限制下进行，包括设计、开发、现场准备、维护、支持和运营等各个方面。整体成本（例如，系统成本、非重复性工程（NRE）成本、租赁成本以及电力和冷却成本）将在系统选择的评估中进行考虑。没有提供具体配置或完整价格的投标者可能会受到负面评估。
本草稿需求文件详细描述了所需系统的硬件和软件能力，以及满足应用基准要求的具体技术要求。有关准备提案的更多信息将在《提案评估和提案准备说明书》（PEPPI）中提供。
上述的交付时间表代表当前的展望，将会根据程序要求和可用资金的对齐进行调整。公司保留根据自身需求和/或DOE的要求修改上述时间表的权利。
1.1 项目概述与使命需求
1.1.1 科学办公室
美国能源部（DOE）科学办公室（SC）是支持能源领域基础科学研究的主要联邦机构，也是国家最大的物理科学基础研究支持者。SC的使命分为两个核心方向：一是直接支持科学研究，二是积极推动开放式科学用户设施的开发、建设和运营。这些活动所产生的影响是广泛而深远的。SC在全美50个州、哥伦比亚特区、DOE实验室以及全国300多所大学和高等教育机构支持着各种前沿研究。SC的用户设施为全国的研究人员提供了世界上无可比拟的尖端科研能力。
在SC内，高级科学计算研究（ASCR）计划的使命是发现、开发和部署计算和网络能力，以分析、建模、模拟和预测对DOE至关重要的复杂现象。该计划面临的特殊挑战之一是充分释放新兴计算系统和其它新型计算架构在科学领域的潜力，这需要对现有工具和技术进行大规模改进，以实现在可计算时代的科学承诺。
1.1.2 使命需求
当前，高性能计算（HPC）在推动美国能源部（DOE）在科学和工程领域的任务中得到广泛应用。然而，到2028年，OLCF的Frontier超级计算机将接近寿命终点。为了继续满足DOE的任务需求和国家优先事项，我们必须对系统进行全面的更新和重新构想，以适应未来的需求、推动技术创新，并扩展计算能力，以确保我们在先进计算生态系统中保持领先地位。
根据2004年的高端计算振兴法案，美国能源部成立了领先计算设施（LCF）。根据该法案，能源部的使命包括通过科学办公室行动来建立和运营领先系统设施，并以竞争性、审查优先的方式为美国工业、高等教育机构、国家实验室和其它联邦机构的研究人员提供领先系统设施的访问。对领先规模计算的需求不断增长，并扩展到需要先进计算能力的新领域。LCF的旗舰分配计划，INCITE，在计算和数据请求方面一直供不应求，突显了对领先级资源的持续需求。美国科学界也已经确定了这种能力缺口，并在最近的科学人工智能和多机构HPC研讨会中进行了描述。LCF的资源必须满足各个科学领域的用户需求，包括传统建模和模拟、数据分析和人工智能等不同领域的计算和数据科学能力。
在未来几年内，实验和观测设施的数据生成速率将呈数量级增长，这是由于探测器技术的进步、边缘传感器的部署以及其它因素所推动的。与此同时，更高分辨率的模拟科学也将继续以相似的速度生成大规模数据集。LCF的下一代资源必须与综合研究基础设施（IRI）实现互操作性，以支持研究人员将大规模实验/观测数据与高分辨率模拟和/或人工智能技术相融合。
随着全球对各种规模的人工智能、数据分析和计算需求呈指数级增长，能源利用既是LCF和IRI的制约因素，也是使命的驱动因素。美国能源部一直是全球领先者，与研究人员和供应商合作，推动能效的重大提升。在过去几十年中，美国能源部在超级计算领域的领先地位已经为计算机行业建立了强大的合作关系，包括人工智能加速器、内存技术、高速互连、系统软件和其它创新。继续在整个生态系统中大幅提高能效是一项任务需求。
为满足使命需求，期望的资源必须具备以下关键特点：
- 在Frontier基线上提供显著增强的领先计算和数据科学能力；
- 支持应用程序在整个系统规模上的强和弱的扩展性；
- 具备可扩展的新型架构，以提供增强的功能；
- 与领先规模的综合研究基础设施（IRI）实现互操作性，即具备与和支持连接DOE实验用户设施和其它LCF基础设施的综合研究基础设施的接口能力；
- 继续在整个生态系统中大幅提高能效；
- 在Frontier服役寿命结束之前开始运营；
- 在OLCF的实用性和运营预算内运行；
- 为用户提供高效的编程环境，即一套多样化、受支持且处于最新状态的编译器、调试器、库和工具。
1.1.3 领先型工作负载
建模和仿真（ModSim）
在OLCF系统中，建模和仿真（ModSim）一直是重要的工作负载。这些工作负载通常涉及大规模同步运算，使用分布式内存应用程序，从强到弱规模应用程序不一而足。最小规模的领先型作业通常利用系统的20%节点，并且这些应用程序往往会扩展到整个系统，或者至少适用于系统的2的幂次方进程数。因此，互连系统需要提供足够的带宽，以支持整个系统的协同工作。OLCF还对并行文件系统进行了优化，以处理大规模的流式写入。尽管大多数应用程序（高达90%）每小时写入的加速器内存总量不超过15%，但平均而言，系统每天都会添加大约1.5倍的总加速器内存。此外，文件大小分布呈双峰分布，其中大多数文件非常小（≤32KiB），但大文件（≥1GiB）占用了绝大部分容量。
虽然传统上使用双精度数据类型，但科学家们正在探索使用较低精度数据类型的可能性，无论是在本地使用还是通过迭代改进来恢复完整精度，以加速其ModSim工作负载。需要指出，这一工作不仅适用于人工智能工作负载，还包括其它领域。
人工智能（AI）
人工智能（AI）是OLCF系统上不断增长的工作负载。OLCF-6预计将处于AI技术的前沿，支持领域科学家和应用程序开发人员，他们正在探索和整合革命性的AI技术，以加速在科学、能源和国家安全领域的发现。AI应用的用例多种多样，从反向设计和控制复杂系统（如电力网络和核反应堆）到生成式AI和融合文本和图像的基础模型，这些模型通常是非结构化的、高分辨率的，来自多模态数据源。执行AI增强的计算任务和工作流将对系统架构提出新的需求，可能需要更多的互连带宽以及优化存储层，以处理大量随机读取的I/O操作（IOPs）。
综合研究基础设施（IRI）
除了运营领先的计算设施外，DOE还管理着多个其它实验设施，而其它联邦机构也运营着许多观测设施。DOE正在领先开发将这些研究设施互连以缩短科学洞察时间的能力。OLCF-6需要具备与这种新计算生态系统互操作的能力，这包括系统外带宽、存储容量和用户环境等方面的支持。
在本文档的“工作流上下文”附录中，提供了额外的背景信息，以便投标方更好地理解这些需求并作出相应回应。
1.2 投标方指南
公司的目标是为投标方提供多种解决方案选择，包括带有或不带存储的本地系统、位于外部的系统，以及对现有的Frontier系统进行升级。此外，我们也欢迎针对并行文件系统（PFS，Parallel File System）和AI优化存储（AOS，AI-Optimized Storage）方案的独立提案。
以下是针对每种情况的具体指导，投标方可以为每种情况提供一个或多个提案。请注意，所有投标方（除了仅存储提案）必须至少回应第2节（2.1.1.1 系统描述和2.1.2.1 高级软件模型）中的强制要求，以被视为响应。所有其它要求都分为TR-1/2/3以表示对公司的重要性。投标方应根据适用于提案并且可行的要求和方案作出回应，但不应感到有义务回应全部。
在第13节，我们要求在接受后的前五年进行维护，并提供第六和第七年的维护方案。如果您的提案包括在服务价格中包含维护，请按照要求描述维护，并在独立的价格提案中注明已包括在成本中。对于第六和第七年的延期维护，请在本文件中描述维护，并在价格提案中注明这两年的服务价格。
1.2.1 本地提案指南
橡树岭国家实验室（ORNL）有两个数据中心位置方案，大小和电力供应能力相似（30MW）。第10节的设施要求提供了有关两者的信息。您的回应应指出您的解决方案是否适用于两者，或者是否专为其中一个而设计。
对于本地基础设施即服务（IAAS）提案，请在高级软件模型回应的一部分中指示您正在提议的服务级别，以及您将如何向公司提供软件（例如，基本操作系统、编程环境、工作负载管理器、存储）以便在系统上部署。
1.2.2 远程提案指南
公司在技术需求中明确包括了远程系统提案作为备选方案。如果您选择提出远程解决方案，则第10节的设施要求不适用，无需回应。
我们期望在系统描述中提供有关处理器、节点、互连和存储的详细信息，就像在本地提案中提供的一样。作为高级软件模型回应的一部分，请指示您正在提议的服务级别以及您将如何向公司提供软件（例如，基本操作系统、编程环境、工作负载管理器、存储）以便在系统上部署。
请注意，任何位于田纳西州以外的数据中心提案将需要公司支付额外的9.75%销售税，这将在提案评估期间包括在总拥有成本估算中。
1.2.3 升级Frontier提案指南
公司预计任何升级将在原地进行，并尽可能充分重用Frontier基础设施。此外，存储系统可能也需要升级。
1.2.4 仅存储提案指南
如果投标方选择仅提出存储解决方案，则需要完成第4节：I/O子系统和第10至13节的相关内容。提案应包括两种解决方案的方案：并行文件系统（PFS）和人工智能优化存储（AOS）。此外，提案还应包括延期维护的方案，即第6和第7年，以及增加和减少所有媒体容量、扩展带宽以及投标方认为有意义的任何其它方案。
一些存储要求是按照计算系统内存容量的倍数编写的。仅存储提案应假定此值为8PiB。提案的方案应允许公司在最终确定系统内存容量后调整存储系统的容量。
在提案中，投标方应明确列出目前支持的互连技术，并说明计划在此时间段内支持的互连技术。对于第4.1.1和4.2.1节，提案的硬件和软件描述应包括需要安装在客户端（即计算节点）上的软件。提案还应指明支持哪些企业级Linux发行版。
存储投标方的提案应考虑第10节中描述的两种数据中心方案，以定义解决方案。
1.3 需求定义
在本文件中，需求被分为不同的优先级，它们的定义如下：
- 强制性要求（MR，Mandatory Requirements）：这些是公司认为至关重要的性能特征，投标方必须满足所有强制性要求才能被视为响应此提案。
- 目标要求（TR-1、TR-2或TR-3，Target Requirements）：这些性能特征、组件、性能特性或其它属性对公司非常重要，但如果在提案中遗漏，不会导致非响应决定。目标要求按照横杠编号进行优先排序，TR-1对公司最为重要，TR-2比TR-3更为重要。
- 目标可选要求（TO，Target Option Requirements）：这些性能特征、组件、性能特性或升级同样对公司重要，但如果在提案中遗漏，也不会导致非响应决定。目标方案增加了提案的价值。提供目标方案的回应将作为提案评估过程的一部分考虑，但公司可能会根据未来的预算考虑选择是否在最终的分包中包括这些目标方案。每个提出的目标方案应以单独可识别的项目出现在投标方的提案回应中。
MR和TR-1的总和形成了一个基线系统。TR-2是提升基线系统的目标，作为MR、TR-1和TR-2的总和，形成一个中度有用的系统。TR-3是提升中度有用系统的伸缩目标，作为MR、TR-1、TR-2和TR-3的总和，形成一个高度有用的系统。因此，理想的OLCF-6系统将满足或超过所有MR、TR-1、TR-2和TR-3。目标要求的回应将作为提案评估过程的一部分考虑。
TO提供了可能因技术和/或预算原因而考虑的备选性能特征、组件、性能特性或系统规模。目标方案还可能根据未来的预算考虑影响公司对理想的OLCF-6系统的看法。
2 总体系统要求
2.1 系统架构需求
2.1.1 硬件
2.1.1.1 系统描述
投标方应提供详细的架构描述，涵盖所提议的计算系统的各个方面，包括但不限于文本、图表和表格。以下是需要包括的信息：
- 组件架构：提供所有处理器、内存技术、存储技术、网络互连和其它相关组件的详细信息。
- 计算节点架构：解释组件如何组装成计算节点架构，包括组件之间的带宽和延迟规格或预测。对每种计算节点类型提供详细信息。
- 板卡和/或刀片架构：描述如何在板卡和/或刀片级别集成节点架构的详细信息，包括节点间和板卡/刀片间的通信路径以及任何额外的板卡/刀片级组件。
- 机架和/或机柜架构：说明板卡和/或刀片如何组织并集成到机架和/或机柜中的详细信息。包括所有机架/机柜间的通信路径以及任何附加的机架/机柜级组件。
- 互连：提供系统高速网络拓扑和所有系统组件之间的连接详细信息，包括计算节点、登录节点和管理系统。
- 系统架构：解释如何组合机架或机柜以生成系统架构的详细信息，包括高速互连和网络拓扑（如果有多个），以及存储系统。
- 管理节点：提供用于支持管理和操作OLCF-6系统的硬件的详细信息。描述管理节点类型，如管理员、领导者、Slurm/资源管理器、布局管理器等。可能需要多种节点类型以优化不同的用途。确保即使计算系统不可用，管理节点仍然可访问。
- 前端环境节点（FEN）：提供硬件的详细信息，用于支持用户访问和潜在用户驱动的工作流活动。需要一组FEN来满足第7节中描述的要求，包括支持50个交互式用户、5个数据分析前端应用程序、500个批处理作业以及与最新GNU编译器套件的等效复杂性相当的20个同时编译的软件。确保即使计算系统不可用，FEN也仍然可访问。附录中的“工作流背景”提供了额外的上下文信息，以指导投标方的回应。
关于I/O子系统的描述将在第4节中提供。
优先级：强制性要求（MR）
2.1.1.2 系统性能
投标方将提供系统级性能FOMs，正如在基准测试部分所定义。FOMs的数量将对总体最佳价值评估产生重要影响。
2.1.1.3 高带宽内存带宽
投标方需要详细描述系统内的总HBM带宽，包括峰值性能和估计的流式性能。拥有比Frontier更多的HBM带宽（即实测值大于105TiB/s，而非仅峰值）将被高度重视。
优先级：目标要求（TR-1）
2.1.1.4 高带宽内存容量
投标方应提供系统内的总HBM容量描述。拥有比Frontier更多的HBM容量（即大于4.6PiB的HBM2e）将被高度重视。
优先级：目标要求（TR-1）
2.1.1.5 计算处理器性能
对于每种计算节点中的处理器类型（例如，CPU、GPU），需要提供每种数据类型（例如，FP64、FP32、FP16、BF16、INT8、INT4）在每个支持的数据路径（例如，标量、向量、矩阵/张量）中的估算GEMM性能。如果浮点数据类型不符合IEEE 754标准，请描述所使用的格式和不规范处理方法。
优先级：目标要求（TR-1）
2.1.1.6 计算处理器能效
在计算密集型阶段（例如GEMM）期间以性能/功耗曲线上的最佳点操作系统是非常可取的。因此，描述用户可编程处理器（例如，计算节点、网卡、交换机）的特性，允许用户控制功耗和/或频率。
优先级：目标要求（TR-1）
2.1.1.7 预计系统功率
投标方应提供系统的峰值功耗要求以及在运行诸如HPL之类的压力工作负载时的持续系统功耗的估算。
优先级：目标可选要求（TO-3）
2.1.1.8 最大进程数
投标方需要提供关于每个节点的预期进程数量的详细描述，以及针对完整系统作业（即节点数量乘以每个节点的进程数量）的要求。支持2的幂个数的进程每个节点是非常可取的。
优先级：目标要求（TR-1）
2.1.1.9 可靠性
投标方应描述预计的MTBF（平均故障间隔时间）、MTBAI/MTTAI（平均时间到下次不可用/平均时间到下次维护）以及MTTR（平均维修时间）。OLCF允许领先作业运行24小时，希望在这期间能够无中断地运行。系统的可靠性对于满足这一需求至关重要。需要确保应用程序在计算阶段中间无需添加防御性检查点I/O阶段。
2.1.1.10 服务性能
投标方应提供系统的可维护性描述，并描述硬件自我报告问题的能力。系统应安装并上线足够的额外节点，以确保系统性能要求所需的节点数量可用。这将有助于确保系统能够持续高效地运行，即使在故障情况下也能够提供可靠的服务。
优先级：目标要求（TR-2）
2.1.1.11 处理受保护信息工作负载的能力
投标方需要描述系统处理受保护信息（例如，HIPAA、ITAR）的能力。这些信息通常需要额外的数据安全、加密传输、卸载默认文件系统、挂载受保护文件系统以及擦除任何本地存储。确保系统可以满足这些安全性需求对于处理受保护信息的工作负载至关重要。
优先级：目标要求（TR-2）
2.1.2.1 总体软件模型
投标方需要提供一个总体软件体系结构图，显示与其系统一起提供的所有主要软件组件以及它们之间的依赖关系。此图应包括每个组件的高级描述，以便公司了解系统的整体软件架构。
优先级：强制性要求（MR）
2.1.2.2 软件共享策略
投标方需要描述哪些主要软件组件是开源的、共享源代码的（即，专有但与公司共享的），以及闭源的（即，专有且不与公司共享的）。投标方应承诺及时共享由其及其分包商开发的开源和共享源代码软件，并描述在其通用可用性之前与公司共享该软件的策略。
优先级：目标要求（TR-1）
2.1.2.3 多软件堆栈
在相关情况下，投标方需要描述其提供的软件是否包括多个具有相似用途的“堆栈”或工具链，以及如何处理这些堆栈之间的互操作性、集成、协调、测试和发布计划，以确保生成的软件套件提供所需的质量、可用性和对OLCF用户的积极用户体验。
优先级：目标要求（TR-1）
2.1.2.4 协调开源软件开发
在投标方所提供的软件基于包括投标方或其承包商进行的更改或添加的开源软件的情况下，投标方需要描述其与上游开发的协调计划。这涵盖了计划上游开发中的更改是否是公开的或私有的，以及投标方对上游开发活动的依赖程度，以提供投标方认为对其OLCF-6方案至关重要的功能。
2.1.2.5 软件许可证
投标方需要描述其软件许可证的方法，包括许可证范围以及为特定软件包从该范围的许可证中选择的标准。
优先级：目标要求（TR-1）
2.1.2.5.1 可重建的设备驱动程序和内核模块
投标方应确保所有提供的设备驱动程序或内核模块可以由公司使用所提出的操作系统进行重建和管理。这有助于确保系统的可维护性和稳定性。
优先级：目标要求（TR-1）
2.1.2.5.2 访问源代码和构建环境
投标方应提供所有软件的源代码和必要的构建环境，除了固件、编译器和第三方产品。此外，投标方应在分包期间为所有软件提供源代码的更新，以及任何必要的构建环境，以确保公司能够管理和维护系统的软件组件。
优先级：目标要求（TR-1）
2.2 需求方案
投标方将提供技术方案，允许公司根据需要对系统各个组件进行调整。以下是这些需求的描述，但不包括具体价格，价格将在价格提案中提供。公司将在决策点确定要执行哪些方案，例如增加机架、更改内存容量或改变互连方式。投标方应明确说明哪些方案在系统部署后仍然有效，以及它们的有效期。
2.2.1 硬件需求
2.2.1.1 扩展系统规模
投标方将提供一个方案，允许增加或减少计算分区的规模。在此处应描述可扩展的单位，例如机架、带CDU的N个机架或其它标准单位。同时，应标识任何需要增加基础设施组件的阈值，例如额外的核心（Spine）交换机或电缆，以及与扩展相关的预期技术挑战和生产问题。
优先级：目标可选要求（TO）
2.2.1.2 扩展处理器内存
对于每种处理器类型，投标方将提供一个方案，允许增加或减少内存容量，如果可能的话。应提供有关扩展单元的详细描述，并将价格按照扩展单元进行计费，例如按机架或N个机架等。
优先级：目标可选要求（TO）
2.2.1.3 扩展互连
投标方将提供一个方案，允许增加或减少互连带宽。此方案可能包括每个节点的额外NIC、额外的交换机、额外的电缆等。应描述互连的可扩展性，并标识任何需要增加基础设施组件的阈值，例如额外的核心（Spine）交换机或电缆，以及与扩展相关的预期技术挑战和生产问题。
优先级：目标可选要求（TO）
2.2.1.4 额外维护期
系统价格应包括五年的全天候维护。投标方将提供第六年和第七年系统维护和支持的单独方案。如果投标方是云服务提供商，则应提供每年继续提供服务的价格。
优先级：目标可选要求（TO）
2.2.1.5 中期升级
投标方应详细描述并单独定价在拟议的OLCF-6系统的五年寿命内的中期升级方案。这包括可能的硬件或性能升级，以确保系统在其寿命内保持最佳状态。
优先级：目标可选要求（TO）
2.2.1.6 拆卸
投标方将提供一个方案，用于在系统寿命结束时卸载、移除和/或回收系统及其支持基础设施。此过程应包括存储介质的擦除或销毁，并根据公司的要求将硬件退还给公司。
优先级：目标可选要求（TO）
2.2.1.7 仅CPU节点
为了提供额外的功能，如分析和/或推理，投标方可以提供一个方案，允许购买仅包含CPU节点的可扩展单位（例如，机架，带CDU的N个机架）。该方案应详细描述节点的架构，包括处理器类型、数量、内存、节点内部连接、与高速互连的连接以及节点本地存储（如适用）。投标方可以选择提供多个方案和价格，以满足不同的需求。
优先级：目标可选要求（TO）
2.2.1.8 双向连接的仅CPU节点
为了提供额外的功能，例如分析、推理、数据传输和/或工作流支持，投标方可以提供一个方案，允许购买双向连接的仅CPU节点的可扩展单位（例如，机架，带CDU的N个机架）。该方案应详细描述节点的架构，包括处理器类型、数量、内存、节点内部连接、与高速互连的连接、与公司以太网基础设施的连接以及节点本地存储（如适用）。投标方可以选择提供多个方案和价格，以满足不同的需求。
优先级：目标可选要求（TO）
2.2.1.9 可视化节点
为了提供额外的可视化和渲染功能，投标方可以提供一个方案，允许购买可视化/渲染节点的可扩展单位（例如，机架，带CDU的N个机架）。该方案应详细描述节点的架构，包括处理器类型、数量、内存、节点内部连接、与高速互连的连接以及节点本地存储（如适用）。投标方可以选择提供多个方案和价格，以满足不同的需求。
优先级：目标可选要求（TO）
2.2.1.10 节点本地存储
对于每种节点类型，投标方将提供一个方案，允许添加至少是节点内存容量三倍的NVMe驱动器。该方案应描述NVMe驱动器的性能特性以及系统软件的要求。
优先级：目标可选要求（TO）
2.2.1.11 人工智能和分析加速节点
公司对新颖的人工智能和分析加速技术表现出浓厚兴趣，这些技术旨在加速人工智能工作负载，可能还包括建模和仿真，可集成到高性能计算生态系统中。这一方案可以与OLCF-6系统同时提供，也可以后续提供，由投标方确定的可扩展单位组成。该方案的规模应足够满足第3.0节中描述的1.0x人工智能基准。描述内容应包括：
- 总体架构图，显示了所有硬件、互连、编译基础设施和输入/输出（I/O）子系统（如适用）。投标方应与公司合作，确保该分区安装了适合实现所需性能水平的文件系统。
- 软件架构概述，包括库、软件开发工具包（如SDK）、框架支持（如TensorFlow、PyTorch等）、可用性和可编程性。描述还应包括软件许可条款、包含的许可数量以及支持方案。
- MLPerf基准测试的可用结果或预测，特别是”Training”、”Training: HPC”和”Inference Datacenter”基准测试套件。所提供的结果和预测应指定使用的基准测试版本，是否已正式提交以及为获得报告的结果或预测所需的基准测试规则修改。
- 建议系统的性能结果（实际、预测或外推），至少要适用于第3节中列出的一个或多个基准测试。
投标方可以选择为不同的技术提供多个方案，并对每个方案进行分别描述和定价。
优先级：目标可选要求（TO）
2.2.1.12 其它相关架构
投标方可以提出其它相关技术，例如数据流、粗粒度可重构、可编程领域、神经形态等，这些技术可以集成到高性能计算生态系统中。描述内容应包括：
- 总体架构图，显示了所有硬件、互连、编译基础设施和输入/输出（I/O）子系统（如适用）。投标方应与公司合作，确保该分区安装了适合实现所需性能水平的文件系统。
- 软件架构概述，包括库、软件开发工具包（如SDK）、框架支持、可用性和可编程性。描述还应包括软件许可条款、包含的许可数量以及支持方案。
- 建议系统的性能结果（实际、预测或外推），至少要适用于第3节中列出的一个或多个基准测试。
投标方可以选择为不同的技术提供多个方案，并对每个方案进行分别描述和定价。
优先级：目标可选要求（TO）
2.2.2 预览技术（Early Access Technology）
2.2.2.1 预览版硬件
投标方应提供机制，以便公司获得预览版硬件技术，用于硬件和软件测试。特别鼓励提供小型的预览版系统，其中包含N-1或N-2个处理器，尤其是如果这些系统可以部署在公司的站点上。同时，也鼓励提供其它技术（例如互连）的预览版。
投标方可以选择为不同的N-1和N-2技术提供多个预览版系统的方案。每个方案应分别描述和定价。
优先级：目标可选要求（TO）
2.2.2.2 预览版软件
投标方应提供机制，以便公司获得预览版软件技术，并在将其安装到OLCF-6系统之前进行软件发布和补丁的测试。
优先级：目标可选要求（TO）
2.2.3 测试和开发系统
2.2.3.1 独立的测试和开发系统
投标方将提供一个系统配置，其中包含与拟议的OLCF-6系统相对应的最小可部署系统。该方案将包括最小可用的计算分区，例如机架和CDU，以及最小的前端环境，例如管理和登录节点。此外，还将提供用于扩展TDS的方案和成本。具体而言，投标方将描述并分别定价最小可用计算分区的方案，以及添加到较大系统所需的任何基础设施方案。如果系统包括不同类型的计算节点，投标方应描述并分别定价每种计算节点类型的独立增加方案，而不影响其它计算节点类型。
优先级：目标可选要求（TO）
4 I/O 子系统
OLCF-6计算系统需要一个能够处理两种不同存储工作负载的I/O子系统。主要的建模/仿真工作负载需要一个具有写入优化功能的并行文件系统（PFS）来处理应用程序的输出和检查点/重新启动。这个工作负载可能包括小文件（例如32 KiB）的读写以及大块的流式写入。
公司预计将会有一个不断增长的AI工作负载，需要高IOPs来进行小的随机读取。如果传统的并行文件系统无法满足这两种需求，公司将考虑针对AI工作负载定制的第二个I/O子系统。这个工作负载需要一个共享资源，可以从作业中的所有节点进行读取。由于随机访问模式，这个工作负载无法使用传统的文件系统缓存（例如客户端缓存）。
这两种用例都需要支持使用单个计算节点，一定比例的计算节点（例如20%），以及整个系统（即至少90%的计算节点）。
4.1 并行文件系统
并行文件系统（PFS）提供一个设计用于为OLCF-6计算系统和中心内的其它计算和数据资源提供大规模容量和高性能带宽的单一POSIX文件系统命名空间。该文件系统支持与位于其它网络技术上的不同网络系统、数据传输集群、分析系统、工作流节点等的离线连接。本文附录中的“工作流上下文”提供了更多信息，以帮助投标方提供响应。
如果投标方只提出了一个I/O子系统，请假设SAHM（System Aggregate HBM Memory）为8PiB。提供在实际系统SAHM确定后扩展系统的方案。
4.1.1 PFS 架构
投标方将提供所提议的PFS设计的高级架构定义，包括所有硬件和软件主要组件的明确定义，连接到哪个网络，以及适用的客户端和服务器端子系统。
投标方将在价格提案中为PFS提供一个单独的价格方案。
如果投标方只提出了一个I/O子系统，请描述支持的互连技术。
优先级：目标可选要求（TO）
4.1.2 PFS 容量
4.1.2.1 PFS 空间
PFS将具有可用且已格式化的POSIX命名空间容量，以支持存储60天的输出，其中每天将SAHM的1.5倍添加到PFS。可以使用以下公式计算总容量：
容量（PFS）= SAHM * 1.5 * 60
优先级：目标要求（TR-1）
4.1.2.2 PFS 文件数量
PFS POSIX命名空间将具有存储1000亿个文件系统命名空间条目（文件或目录）的能力。
优先级：目标要求（TR-1）
4.1.2.3 PFS 组织
PFS应构建具有可扩展存储单元（SSU）和可扩展存储集群（SSC）的存储单元。投标方应描述每个SSU和SSC的数据容量、元数据容量和性能属性。
优先级：目标要求（TR-2）
4.1.2.4 PFS 连接
PFS需要支持OLCF-6系统以及位于OLCF数据中心内的其它资源。理想的解决方案是即使OLCF-6计算系统和互连进行维护，PFS也仍然可用。首选的方法是在OLCF-6计算高速网络（HSN）和公司的InfiniBand SAN上为PFS提供双重入口。
如果PFS不连接到OLCF-6 HSN，但连接到独立的高速网络，请描述这个高速网络，包括计算系统和PFS之间的预期可实现的带宽，以及与公司InfiniBand SAN的连接。
优先级：目标要求（TR-1）
4.1.3 PFS 性能
4.1.3.1 PFS 15% SAHM 写入性能
PFS将具备在5分钟内以每进程顺序写入SAHM的15%的能力。性能将针对PFS的所有情况启用压缩进行报告。投标方将描述所使用的压缩算法。
投标方将描述单客户端、应用程序检查点、应用程序重新启动、应用程序冷重启、应用程序冷重启重启、Hero顺序和Hero随机用例的预期性能。
如果投标方的解决方案需要分层满足性能要求，投标方将描述每个层的读/写性能。此外，投标方将描述文件对象的放置、文件大小、I/O请求大小、用于测量性能的工具和工具方案、每个性能值的导出所需的CN数量，以及每个节点使用的进程或线程数。
优先级：目标要求（TR-1）
4.1.3.2 PFS 小型 I/O 事务性能
PFS将从多个计算节点中总计每秒至少执行50,000个32KiB文件创建事务，持续至少20秒。文件创建事务包括以下元数据操作：打开（创建）、状态、写入、读取、关闭。每个计算节点将在自己的目录中创建文件。投标方将指定需要实现此性能所需的CN数量。将分别报告打开、状态、写入、读取和关闭操作的性能。
优先级：目标要求（TR-1）
4.1.3.3 PFS 树遍历性能
PFS将执行一次完整的树遍历，假设完整的PFS命名空间的inode利用率为85%，并清除1亿个文件。树遍历和清除操作将在最多24小时内完成。投标方将描述用于实现此性能所需的所有工具和假设。
优先级：目标要求（TR-1）
4.1.3.4 PFS 成熟文件系统性能
在85%利用率下，PFS的应用程序重新启动和Hero顺序用例性能应与空（即新格式化）文件系统相同。投标方应描述PFS如何在85%利用率下实现此性能。
优先级：目标要求（TR-2）
4.1.4 PFS 功能/RRAS
4.1.4.1 PFS 预览版和 TDS
投标方将提出预览版（EAS）（例如，N-1 代）的 PFS 硬件和软件技术，用于测试和开发。鼓励提供小型的额外预览版系统，特别是如果它们位于现场。投标方将为每种类型的 PFS 服务器提供单独定价的方案。
投标方还将提出与最终 PFS 配置相同（例如，每台服务器和/或机箱的设备数量和容量）的测试和开发系统（TDS）。TDS 的大小将足够大，以复制较大系统的所有架构特性。TDS 将支持各种各样的活动，包括验证和回归测试。投标方将为每种类型的 PFS 服务器提供单独定价的方案。
优先级：目标要求（TR-1）
4.1.4.2 PFS 故障防护
PFS 架构应优化现场可维护性，并且不应具有单点故障。投标方将描述在 FRU 故障时的性能和可用性影响。PFS 将能够实现不低于 99.5% 的计划可用性。
投标方将描述所有 FRU 的 FIT 率。基于这些 FIT 率，投标方将描述 MTBF、MTBI 和 MTTR。
优先级：目标要求（TR-1）
4.1.4.3 PFS 高可用性
投标方将描述 FS 利用高可用性和/或自动故障转移来最小化非计划停机时间的能力。
优先级：目标要求（TR-1）
4.1.4.4 PFS 隔离运行
投标方将提出操作 PFS 以与 OLCF-6 计算系统和基础设施资源隔离的方法。描述重新配置后需要资源重新平衡的任何情况，以及整个 PFS 需要停机的任何情况。
优先级：目标要求（TR-1）
4.1.4.5 PFS 自动重建
PFS 将自动启动存储介质故障的重建过程。故障的存储介质将以正确的数据进行重建，数据完整性和存储冗余性将在检测到故障后的最多 6 小时内恢复。PFS 将在重建期间保持所需带宽的 70%。
投标方将描述相关的数据保护方案、恢复机制以及存储重建的预期性能影响。
优先级：目标要求（TR-1）
4.1.4.6 PFS 一致性时间
投标方将描述与 POSIX 兼容性、一致性时间以及可靠数据消耗可能出现的任何异常情况。
优先级：目标要求（TR-1）
4.1.4.7 PFS 对象存储接口
PFS 设计应支持对象存储接口。投标方应描述并量化与 POSIX I/O 接口相对于 PFS 的读取和写入访问性能。
优先级：目标要求（TR-2）
4.1.5 PFS 系统管理
4.1.5.1 PFS 电源循环性能
PFS 将在合理的时间内完成上电和下电。投标方将描述完整的 PFS 初始化和完整的 PFS 关闭的步骤和时间序列。包括任何依赖关系以及时间如何随系统大小而扩展。
4.1.5.2 PFS 系统软件升级
投标方的 PFS 解决方案应支持及时进行固件升级和系统软件升级。所有固件升级应从 Linux 命令行发布。投标方应描述固件刷新和系统软件升级的持续时间。包括任何依赖关系以及时间如何随系统大小而扩展。
优先级：目标要求（TR-2）
4.1.5.3 PFS 软件更新
投标方应提供每季度的 PFS 软件交付，跟踪上游功能发布和安全漏洞修补。
优先级：目标要求（TR-2）
4.1.5.4 PFS 开源
投标方应描述 PFS 的开源软件组件。支持 PFS 的此类软件的补丁应在 3 个月内提交上游。
优先级：目标要求（TR-2）
4.1.5.5 PFS 配额支持
投标方将提供功能，以根据 uid、gid 和项目/文件集来强制执行和报告软性（计算）和硬性（强制执行）的配额。
优先级：目标要求（TR-1）
4.1.5.6 PFS 站点远程监测集成
投标方的 FS 解决方案将支持与站点监视/远程监测框架的集成。
优先级：目标要求（TR-1）
4.1.5.7 PFS 配置管理
投标方将描述 PFS 的配置管理和诊断能力，以解决以下系统管理细节：
- 软件管理工具组件对 PFS 服务器节点上可用的 CPU 或内存的任何影响或开销。
- 支持多个同时或备用的系统软件配置。
- 用户活动跟踪，例如审计日志记录和进程会计。
- 对交付的系统硬件组件的不受限制的特权访问。
优先级：目标要求（TR-1）
4.1.5.8 PFS 站点供应集成
投标方应描述：
- 与公司核心基础设施（RSA、LDAP、DNS、配置管理 – puppet、电子邮件服务器等）的集成。
- 支持使用站点开发和维护的系统供应软件 – Anchor。
- 支持基于本地软件包存储库的站点生成的映像。
- 遵守公司的网络安全要求/政策。
优先级：目标要求（TR-2）
4.2 AI 优化存储
4.2.1 AI 优化存储描述和方案
投标方将提供关于所提议的 AI 优化存储（AOS）设计的高级架构定义，包括所有硬件和软件的主要组成部分以及客户端和服务器端（如适用）的子系统的明确定义。投标方将包括一个方案，但公司鼓励投标方提供多个方案。投标方和公司将评估所提议的方案以及 FS，以在 Go/No-Go 决策时决定是否要行使方案。
优先级：目标可选要求（TO）
4.2.2 AOS 容量
AOS 总体上将具有至少两倍的 SAHM 可用容量。定价提案将提供增加/减少容量的方案。在此处描述增加/减少的单位（例如，节点、机箱、机架）。
优先级：目标要求（TR-1）
4.2.3 AOS 性能
投标方将描述针对带宽和 IOPS 的分布式机器学习培训、分布式作业暂存、大规模应用程序检查点/应用程序重启、时间敏感的外部数据分析和数据密集型分析以及对象存储用例的预期性能。投标方将描述每个用例相对于计算系统节点数量的五分位数的预期性能。此外，投标方将描述文件对象的放置、文件对象的移动、文件大小、I/O 请求大小、用于测量性能的工具和工具方案，以及用于推导每个性能值的每个节点的 CN 数量和进程或线程数量。对于与 AOS 的对象存储接口，投标方将描述并量化相对于 AOS 的 POSIX I/O 接口的读取和写入访问性能。
优先级：目标要求（TR-1）
4.2.4 AOS功能/RRAS
4.2.4.1 AOS EAS和TDS
投标方将提出机制，以便在将技术插入 OLCF-6 系统之前，为 AOS 硬件和软件技术提供测试的预览版（EAS）。鼓励提供额外的小型预览版系统，特别是如果它们在现场。投标方将提供一个独立于 AOS 的测试和开发系统（TDS）。TDS 的规模足够大，以复制更大系统的所有架构特性。TDS 将支持各种各样的活动，包括验证和回归测试。
优先级：目标要求（TR-1）
4.2.4.2 AOS 重新平衡
投标方将描述任何在重新配置后需要重新平衡资源的情况，以及任何需要整个 AOS 停机的情况。
优先级：目标要求（TR-1）
4.2.4.3 AOS 容错性
AOS 架构将优化现场可维护性，投标方将描述 AOS 设计中的任何单点故障。投标方将描述 FRU 故障对性能和可用性的影响。投标方将描述 AOS 中所有 FRU 的 FIT 速率。基于这些 FIT 速率，投标方将描述 MTBF、MTBI 和 MTTR。
优先级：目标要求（TR-1）
4.2.4.4 AOS I/O 接口
投标方将描述供 O 使用的所有可用 I/O 接口，包括但不限于 POSIX I/O、对象和其它 API。描述对 POSIX 合规性的任何异常情况，时间一致性以及可靠的本地和远程数据消耗的任何潜在延迟。
优先级：目标要求（TR-1）
4.2.4.5 AOS 开源工具支持
投标方应描述 AOS 支持的开源软件解决方案。可以使用开源工具，如 HVAC、UnifyFS、Spectral 或其它类似的解决方案，以提供作业共享存储。
优先级：目标要求（TR-2）
4.2.4.6 AOS 站点远程监测集成
投标方将支持与站点监测/远程监测框架的集成。
优先级：目标要求（TR-1）
4.2.4.6.1 AOS 并行数据传输工具
投标方将描述并提供 FS 和 AOS 之间的高效并行数据传输工具。
优先级：目标要求（TR-1）
4.2.4.7 AOS 数据保护
投标方将描述 AOS 支持的任何数据保护方案、恢复机制以及相关性能影响。投标方将描述 AOS 需要使用擦除编码以满足容量、性能或数据完整性要求的任何情况。
优先级：目标要求（TR-1）
4.2.4.8 AOS 数据清理
公司预计需要在支持 HIPAA 和受出口管制的工作负载的计算作业之间清理持久性存储设备。投标方应描述 AOS 的任何数据清理能力。
优先级：目标要求（TR-2）
4.2.5 AOS 系统管理
4.2.5.1 AOS 系统软件升级
投标方的 AOS 解决方案应支持及时的固件升级和软件升级。所有固件升级应从 Linux 命令行发出。投标方应描述固件刷新和软件升级的持续时间，包括任何依赖关系，以及随着系统规模的增加，时间如何扩展。
优先级：目标要求（TR-2）
4.2.5.2 AOS 上游软件交付
投标方应提供每季度的 AOS 软件交付，跟踪上游功能发布和安全漏洞修补。
优先级：目标要求（TR-2）
4.2.5.3 AOS 开源上游提交
投标方的 AOS 解决方案中包含的开源软件的补丁应在 3 个月内提交到上游。
优先级：目标要求（TR-2）
5 高性能互连
5.1 网络需求
5.1.1 网络描述
投标方将描述高速网络，包括：
- 拓扑和路由协议的高级描述。
- 与其它网络的总带宽和传输速率，包括网络层次结构上的任何带宽变化。
- 全系统规模下的全对全预期带宽。
- 每个接口的传输规模和连接数量，以及总体数量。
- 用于通信卸载的硬件支持（例如，GPUDirect、GPUDirectRDMA、智能网卡）。
优先级：目标要求（TR-1）
5.1.2 较低级别通信 API
投标方将提供较低级别通信（LLCA）API，例如 UCX 或 Libfabric。描述在支持标准和 LLCA 的最新版本时可以预期的任何增强或限制。描述一侧和双侧消息支持。
优先级：目标要求（TR-1）
5.1.3 拓扑提取
投标方应提供一个库或 API，供应用程序提取其运行中应用程序的拓扑信息。
优先级：目标要求（TR-2）
5.1.4 弹性
投标方将描述网络的弹性特性，包括链路和交换机故障方案。描述在保持连接的同时可以发生的链路、网络接口和交换机故障数量，并描述随着组件故障而性能下降。
优先级：目标要求（TR-1）
5.1.5 管理
投标方将描述带外管理网络以及通过中介网络（例如数据中心网络）安全地扩展管理段的机制。
优先级：目标要求（TR-1）
5.1.6 服务质量
投标方应描述提供互连的服务质量的能力和机制（拥塞控制、流量类别、虚拟通道）。投标方应描述标准 HPC 用例（消息急切、消息约会、集体操作）和存储系统的 QoS 配置（映射），并描述支持复杂工作流程的增强功能。
优先级：目标要求（TR-2）
5.1.7 外部连接
投标方将提供一个高带宽且弹性的解决方案，允许系统与 OLCF 数据中心网络之间进行外部连接。这将支持同时传输，并具有 1 TB/s 的总吞吐量。
优先级：目标要求（TR-1）
5.1.8 外部连接 IETF
投标方应描述外部连接解决方案将如何利用符合 IETF 标准的技术，包括以下功能：
- 跨网络边界的拥塞控制机制。
- 用于可靠连接的 QoS，带有可配置的缓冲区。
- 在链路或邻接级别进行流量排空的能力，使用抽样流量或类似技术进行流量跟踪。
- 加密和身份验证。
- 集成的 SDN 与作业管理和调度系统。
优先级：目标要求（TR-2）
5.1.9 离场外部连接
如果任何资源部署在场外，投标方应描述 ORNL 与场外资源之间的外部连接。任何由投标方提供的光纤连接应在公司位于 5600 号建筑物的 RDF 终止。
优先级：目标要求（TR-3）
5.1.10 计算网络集成
描述将其它供应商的其它技术（例如存储、专用机架）整合到高性能网络基础架构中的能力。
优先级：目标要求（TR-2）
5.1.11 协议支持
对于管理和 HSN，投标方将描述对以下内容的支持：
- Jumbo 帧、IPv6、IPv4、TCP/IP、UDP 以及虚拟网络支持。
- 使用访问控制列表控制 IP 流量的能力。
- 负载平衡和跨多个路径路由流量的能力。
- 动态配置路由并在数据中心、存储和其它外部网络之间交换路由信息的能力。
优先级：目标要求（TR-1）
5.1.12 CXL
如果提供 CXL，投标方应描述其 CPU、GPU-NIC 和存储产品对 CXL 2.0（或更高版本）标准的支持。包括对 CXL.io、CXL.mem 和 CXL.cache 的预期使用模型的支持级别。
优先级：目标要求（TR-3）
5.2 通信软件要求
5.2.1 MPI
系统将提供支持 MPI 4.0 或更高版本的 MPI 库，并在加速器供应商支持的情况下提供支持加速器感知的 MPI，这将能够在全系统规模上运行作业。投标方将描述可用 MPI 库中 MPI 标准的扩展或限制。
优先级：目标要求（TR-1）
5.2.2 立即启动
投标方将描述其解决方案的即时启动功能，即从应用程序启动（例如，srun）到进行全系统运行的 MPI_Init 所需的时间。
优先级：目标要求（TR-1）
5.2.3 PMI
系统将支持进程管理界面（PMI）。投标方将描述版本和支持的集成。
优先级：目标要求（TR-1）
5.2.4 其它 PMI
系统应描述对其它进程管理接口（PMI2、PMIX）的支持。
优先级：目标要求（TR-3）
5.2.5 其它通信库
投标方应描述提供的任何其它通信库（例如，Gasnet、SHMEM、 Charm++ 等）。
优先级：目标要求（TR-3）
5.2.6 优化的集体库
投标方应描述任何优化的集体库（例如，NCCL、RCCL 等）。
优先级：目标要求（TR-3）
