1 AI 集群架构要回答什么
把几台装有加速器的服务器连接起来，只能说明设备可以互通，还不能说明训练任务能稳定完成。AI 集群架构要回答的是：数据从哪里来，计算在哪里发生，任务怎样拿到资源，结果存到哪里，以及某个环节出错后由谁发现和恢复。架构图上的每条线都应对应实际的数据、请求或依赖，否则图画得再整齐，也无法帮助团队判断建设规模。
先给集群安排真实工作。贯穿本课的任务是用公开的 CIFAR-10 数据集训练图像分类模型：输入是 32×32 的彩色图像，输出是 10 个类别中的类别概率。原始训练集有 50000 张图像，另有 10000 张测试图像。我们从原始训练集中按类别分层留出 5000 张作为验证集，用其余 45000 张训练。验证集用于选择模型和配置，测试集保留到最终评估；不能每次改完配置都看测试成绩。
这套集群还会承接公开 UCI Bank Marketing 数据集上的定期存款订阅预测，以及 AG News 短文本分类。前者可以使用职业、联系方式、历史联系次数等字段，目标是预测客户是否订阅；后者输入新闻标题和描述，预测新闻类别。它们对资源的需求不同：表格基线可能用 CPU 就够，图像训练可能需要加速器，文本清洗又可能主要消耗 CPU 和内存。不能把所有任务都当成同样的“大模型训练”。
因此，建设目标不应只是“提供 8 张加速卡”，还应说明服务对象和完成条件。例如允许 2 个图像实验并发，给表格分析保留可用 CPU，训练结果必须记录数据版本、代码版本和评估指标。指标包括任务排队时间、完成时间和失败恢复时间，也包括模型准确率、各类别召回率与宏平均 F1。前者回答平台是否好用，后者回答模型是否有效，两类指标不能互相替代。
还要区分共享资源和共享责任。数据负责人决定数据能否使用，平台负责人保证资源和服务可用，实验负责人确认划分与指标合理。即使硬件完全正常，重复样本进入训练集和测试集，也会产生误导性的高分；反过来，某个模型召回率低，也不能直接证明网络设备有问题。架构应让这些问题能够被分别观测和追溯。
阅读总图时先找 3 条路径：任务申请资源的控制路径，样本进入训练进程的数据路径，检查点和模型写回存储的产物路径。控制路径传输量往往较小，却可能决定所有任务能否启动；数据路径流量较大，决定计算设备会不会等待。后面所有分区、调度和排障，都围绕这些路径展开。
2 计算、存储与网络分区
计算区不只包含加速器。CPU 负责解码图像、清洗字段和组织批次，内存暂存正在处理的数据，加速器执行适合并行的张量计算。若 CPU 解码跟不上，加速器即使很贵也会空等。对于 CIFAR-10 这样的入门数据集，单机甚至 CPU 就能完成部分实验；在这里画集群，是为了理解任务扩大和多人共享后的边界，不代表这个数据集本身需要大规模设备。
存储区可以按职责分成数据源、工作缓存和持久产物。数据源保存经过版本标记的原始数据与划分清单；节点本地盘可以放能够重新生成的缓存；持久存储保存检查点、模型文件和实验记录。检查点是为了继续训练而保存的状态，除模型参数外还可能包含优化器状态和训练进度。本地盘很快，却会随节点故障丢失，不能因为路径看起来像普通目录，就把它当成可靠的最终归档。
网络也可以按用途划分。管理通信包括任务提交、节点状态和权限校验；存储通信搬运样本、检查点与模型；分布式训练通信交换参与计算的进程之间的数据。这里的“分区”首先是逻辑职责，可以通过不同地址范围、访问规则和带宽策略实现，并不要求每类流量都配置独立交换机。只有业务规模和测量结果证明共享链路无法满足要求时，才有理由增加物理隔离。
沿图像实验走 1 遍：用户提交数据版本、训练配置与资源请求；调度服务选择节点；节点检查数据划分清单并准备缓存；训练进程读取训练样本，用验证集评估候选配置；最终测试由独立评估步骤执行，产物写入持久存储。验证和测试不参与梯度更新。训练数据的预处理规则需要被记录，例如归一化所用的统计量只能从训练部分计算。
在表格任务里，这个边界更容易被忽视。Bank Marketing 的通话时长字段 duration 只有通话结束后才能确定；若目标是联系前预测，它就属于上线时不可获得的信息，应从特征中删除。数值填补和类别编码也只能在训练部分拟合，再应用到验证与测试。集群可以高速复制错误数据，却不能自动纠正数据泄漏，因此清单中应同时写入特征可用时点和预处理版本。
容量估算要顺着路径进行。先估计每个任务的样本读取量、缓存占用和检查点大小，再结合并发数量与保存周期估计总需求。还要分别看字节吞吐量和文件操作次数：读取少量大文件与打开海量小文件，即使总字节数相同，对存储服务的压力也可能完全不同。网络带宽、存储吞吐和文件查找能力中的任何短板，都可能让计算等待。
3 调度、亲和与故障域
调度服务负责把资源请求放到能够满足条件的节点上。请求至少需要说明 CPU、内存、加速器数量以及临时空间需求；还可能要求特定的软件环境。请求过小会造成内存不足或数据加载拥塞，请求过大则会让任务长期排队并占住用不完的资源。合理的起点是先运行有代表性的小实验，观察峰值与波动，再给出留有余量的请求，而不是凭经验统一申请最大规格。
“亲和”表示任务倾向于靠近某类资源或其他任务。例如训练数据已经缓存在某个节点，将后续实验放到那里可以减少重复读取。但缓存亲和通常应是可退让的偏好：如果那个节点已经很忙，等待可能比重新下载还慢。必须满足的条件与优先满足的偏好要分开，否则 1 条无意写死的节点要求就可能让整个队列卡住。
“反亲和”常用于降低共同失效的风险。例如 2 个提供相同能力的服务副本，不应都落在同一台宿主机上。故障域是可能一起失效的范围，可以是进程、节点、机架或供电区域。把副本放在不同节点只能抵御部分节点故障；如果它们共享电源、交换机和后端数据库，仍可能同时不可用。架构图需要画出共享依赖，不能只数副本图标。
训练任务与长期服务的恢复方式也不同。训练进程退出后，调度服务可以重新安排节点，再从已成功保存的检查点继续；但必须确认检查点完整且与数据版本、模型结构兼容。服务副本失效时，客户端则可能切换到健康副本。调度服务只负责放置任务，不会凭空生成缺失的训练状态，也不能保证业务请求重试后没有重复副作用。
交互中的放置过程先检查硬性资源，再考虑缓存位置，最后检查故障域。假设节点甲已有图像缓存但没有空闲加速器，节点乙资源充足却需要读取数据，系统应比较可接受的排队时间和启动成本，而不能只按缓存命中决定。若实验只需 1 个节点，就没有必要强行启动跨节点训练；增加节点会引入额外的协调与通信成本。
共享集群还要处理公平性。短表格实验与长时间图像训练混排时，单纯先到先运行可能让后续用户等很久。入门方案可以先采用团队配额、并发上限和不同任务队列，配合清晰的取消规则。是否允许抢占长任务，应结合检查点成本决定。调度算法的细节可以后续再学，本课只要求你能说明谁可以占用多少资源，以及被中断后如何恢复。
4 动手：画一张集群逻辑架构
现在把概念放进可讨论的图。练习条件设为 1 个小团队共享 4 台计算节点，其中 2 台带加速器，另外 2 台用于数据准备、表格基线和文本处理。团队同时需要运行 2 个图像实验，保存训练检查点，并允许其他成员查看历史结果。这只是教学设定，设备数量不构成采购建议；能否满足时限仍需用代表性任务测量。
先画边界，再画节点。在纸上分出使用者、平台控制服务、计算节点池和持久存储，补上外部公开数据的导入入口。给每条连接标注动作，例如提交任务、读取划分清单、读取样本、写入检查点、查询实验记录。这样能够发现某个箭头到底代表控制请求还是大批量数据，而不是把所有连线都写成含义模糊的“访问”。
第 2 步给数据加身份。为 CIFAR-10 记录来源、校验值、训练与验证划分清单及预处理配置；为 AG News 记录文本清洗规则与类别映射。AG News 的官方训练部分有 120000 条样本，可分为 108000 条训练和 12000 条验证，官方 7600 条测试样本保留用于最终评价。若发现近重复文本跨集合出现，应先处理重复关系再重新形成划分，不能只删除测试中难以预测的样本。
第 3 步标注资源和失败边界。在节点池旁写明任务请求的 CPU、内存、加速器与缓存空间，在持久存储旁写明容量、访问权限与保留周期。把可能共用的机架、交换机或电源框出来。对控制服务画出其状态保存位置：任务记录和实验记录一旦丢失，即使模型文件仍在，也可能无法解释这个模型由什么数据和配置产生。
第 4 步做 3 次走查。正常走查从提交任务到产生可下载的模型；容量走查假设 2 个实验同时读取数据并写检查点；故障走查假设其中 1 台计算节点退出。每次都沿箭头说出下一步由谁执行、依赖什么状态、等待多久才算异常。若回答只是“平台会处理”，就继续补齐负责的服务、所需证据和恢复动作。
最后交付的不是漂亮的服务器摆放图，而是带注释的逻辑图和假设表。表中写清并发量、数据规模、缓存可丢失性、检查点间隔及测量方法。可以先假设每 10 分钟保存检查点，但要注明最终间隔取决于写入耗时和可接受的重算时间。再给图附上 1 条实验记录，包含数据版本、代码版本、资源配置、运行时长和验证指标，便于别人复现你的判断。
5 专用优化与通用平台取舍
专用优化是在明确工作负载后，让资源和软件更贴近它。例如固定图像尺寸、复用解码缓存、提前准备相同的数据分片，都可能减少重复工作。通用平台则强调让图像、表格与文本任务共享入口、权限和运行环境。两者没有固定的优劣关系：如果任务经常变化，过度固定配置会增加迁移成本；如果长期运行高度相似的训练，重复执行通用步骤也可能浪费大量资源。
先区分必须统一的内容与可以变化的内容。数据身份、权限、实验记录、模型产物格式和失败状态，通常值得统一；具体使用哪种计算设备、是否缓存、是否跨节点，可以按任务选择。比如表格分类先跑逻辑回归或树模型基线，可能比直接占用加速器更快得到有意义的结果。选择硬件前先建立可比较的模型基线，能避免把建模问题误当成算力问题。
评价优化时需要固定比较条件。图像任务保持数据划分、模型和训练轮数一致，比较端到端完成时间与指标；如果改变批次大小影响了收敛，就不能只用每秒处理图片数宣布方案更好。对类别不平衡的订阅预测，准确率尤其容易误导。假设正类占 10%，始终预测负类也有 90% 准确率，却无法找到任何正类客户，应同时查看精确率、召回率、F1 和合适的 AUC 指标。
精确率关注预测为正的样本中有多少正确，召回率关注真实正类中找到了多少，F1 综合这两者。ROC-AUC 描述不同阈值下的排序表现；正类稀少时还可以查看 PR-AUC，但需要明确具体计算方式。不同阈值会改变精确率和召回率，因此阈值只能依据训练与验证阶段的约定选择。平台优化不应偷偷改变评估口径，让资源节省和模型质量混在一起。
滑块用简化的时间模型展示取舍：每个任务都要做准备，但缓存准备只能在数据和处理规则相同时复用。复用次数增加，准备成本可以被更多任务分担；同时缓存占用不会因此消失。图中数字是教学假设，不能当成真实设备的性能承诺。实际选型必须测量冷缓存、热缓存和任务混跑，并记录哪些阶段被加速、哪些阶段没有变化。
取舍还应考虑维护成本。某种特殊布局可能让图像训练快一些，却要求每次数据更新都手动重建缓存，或者让文本任务无法运行。在入门建设方案里，可以优先使用统一提交与记录机制，再为证据充分的瓶颈增加局部优化。是否值得专用，取决于节省的总时间、资源占用和维护负担，而不只取决于某次演示里的最高吞吐量。
6 常见坑：存储与训练争抢网络
集群刚上线时，单个训练任务运行顺畅；团队开始并发实验后，加速器利用率却周期性下降。这时常见的误判是“加速器不够强”或“训练代码有问题”。实际上，读取样本、保存检查点和跨节点训练通信可能经过同一条链路。当 2 个任务同时写入较大的检查点，其他任务的数据加载就可能变慢，计算进程等待输入，最终表现为利用率下降。
不要仅凭利用率曲线定位原因。应把任务时间线、数据加载等待、检查点写入耗时、网络吞吐与存储延迟对齐到同一时间轴。如果下降时段恰好对应检查点写入，只能说明存在关联，还需要通过错开写入时间、限制某类流量或减少并发的对照来确认。正常训练中的评估阶段也可能降低加速器利用率，因此必须知道任务当时执行了什么。
检查时先画共享路径。节点网口是否同时承担读取与训练通信？不同机架是否经过同一条上联？存储服务是否已经达到吞吐上限？即便节点显示发送带宽未满，接收端队列或上联仍可能拥塞。反过来，如果网络很空闲而 CPU 持续繁忙，也可能是图像解码或文本分词跟不上；不能看到“读数据慢”就直接购买更快的网络。
应对方式按证据选择。错开检查点时间可以减少瞬时冲击，本地缓存可以减少重复远程读取，合理打包小文件可以减少操作次数，流量策略可以为关键通信保留空间。物理拆分网络也可能有效，但会增加设备、布线和运维成本。若瓶颈在元数据请求而非传输字节数，提高链路带宽就未必改善启动速度，这正是下一节要讨论的情况。
缓存也有失效风险。若原始样本或预处理规则改变，旧缓存继续被命中，训练可能读到不一致的数据。缓存键至少需要能区分数据版本和转换规则，任务记录还要注明是否命中缓存。缓存是可重新生成的副本，不能成为唯一数据源。对敏感字段，缓存目录同样需要权限和清理策略，不能因为它位于计算节点上就默认所有用户可读。
最终的验证应回到工作负载。比较调整前后同样并发、同样数据和相同保存策略下的完成时间，检查等待是否减少，同时观察模型指标与失败率。为了降低网络峰值而无限推迟检查点，会扩大节点故障后的重算损失。合理方案是在训练速度、共享公平性和恢复能力之间找到可解释的平衡，并明确还未覆盖的并发范围。
7 案例：单一元数据服务成瓶颈
考虑一个教学案例：团队把大量图像文件放进共享文件系统，8 个训练任务启动时都要遍历目录、查询文件属性并打开样本。文件系统的元数据包括文件名、目录关系、大小和访问权限等信息。元数据服务不一定搬运图像主体，却要回答“文件在哪里、是否允许打开”。因此，数据盘吞吐看起来充足，也可能因为查找请求排队而让训练启动缓慢。
症状是任务长时间停在准备阶段，网络总字节量并不大，加速器也几乎没有工作。正常启动后速度有所恢复，新增任务又会出现同样的等待。进一步观察发现文件打开延迟上升，元数据请求队列变长，而连续读取已打开文件的速度基本正常。这里的判断来自这些相互支持的证据，不能仅凭“只有 1 个服务实例”就认定它必然是瓶颈。
排查可以先做低风险对照：保持图像内容与训练配置不变，减少同时启动的任务；使用固定清单替代每次完整目录遍历；比较读取少量打包文件和打开大量独立小文件的准备耗时。需要分别记录准备阶段和稳定训练阶段。打包可能增加随机访问和更新成本，所以实验结果应表述为“此访问模式下减少了文件操作”，不能扩展为所有数据都必须打包。
这类瓶颈与服务故障也要分开讨论。瓶颈表现为请求排队和延迟上升；服务失效则可能让新任务无法解析文件路径，即使已有进程还能读取部分已打开的数据。重试可以应对短暂异常，但无上限地同时重试会增加压力。应设置有间隔且有次数限制的重试，在持续失败时明确标记任务状态，并保留请求失败的时间与原因。
改进分成访问方式与服务能力两方面。前者包括复用清单、减少重复属性查询、按实际读取方式组织文件；后者需要根据存储系统支持的机制评估缓存、扩容或高可用配置。增加副本之前必须确认状态一致性和故障切换能力；复制 2 个进程却共用一个脆弱的状态库，并不能消除单点。具体元数据分片与一致性机制留到后续存储课程深入讨论。
案例的验收应同时覆盖性能和故障。逐步增加并发，观察启动时间、元数据延迟和错误率；在隔离测试环境中模拟服务不可用，检查任务能否停止无效重试、给出可定位状态，并在服务恢复后按约定继续。教学案例不预设优化百分比，因为真实收益取决于文件数量、访问方式和实现。结论必须和测量条件一起保留，才能迁移到其他集群。
8 把集群架构写进建设方案
建设方案要把逻辑图转换成可以交付和验收的承诺。起点是工作负载表：记录数据规模、文件组织方式、任务类型、并发量、完成时限和可接受的中断损失。CIFAR-10 练习可以验证流程是否完整，但不能代表未来高分辨率图像的读取压力。若建设目标包含后者，就需要加入相应的代表性样本与访问模式，而不是直接按样本数量等比例外推。
然后给关键路径写预算。任务的总耗时至少包括排队、准备、训练、评估和产物保存；其中任何阶段超时，用户都会感到任务慢。容量预算也要包含原始数据、缓存、多个检查点和实验产物，并注明增长与清理规则。不能只写最终模型有多大，因为优化器状态、历史检查点和重复缓存可能占据更多空间。预算是待验证的假设，应注明测量来源。
再把责任落到接口。数据导入需要来源与校验记录，任务提交需要资源和版本信息，模型发布前需要评估结果与负责人确认。对于表格预测，要明确标签何时形成、哪些字段在预测时可用。若数据没有可靠时间戳，就不能声称完成了时间外验证；可以先做分层划分并记录局限，后续收集较新样本检验分布漂移。上线环境中人群和特征分布变化，需要独立跟踪。
验收模型质量时，报告各类别样本量、精确率、召回率和 F1，二分类还可报告 ROC-AUC 或明确口径的 PR-AUC。若使用重采样或类别权重，应只在训练阶段应用，测试集保持预定的评估分布。架构验收则记录排队分位数、完成时间、存储延迟和恢复表现。两组验收可以放在同一份报告，但通过条件必须分别写明，避免高准确率掩盖平台不稳定。
故障验收应具体到可观察动作。计算节点退出后，任务是否能被识别并重新放置；持久检查点是否完整；恢复进程是否继续使用相同划分与代码；元数据服务异常时，是否出现无休止的重试。测试前约定检查点间隔和允许重算量，测试后保留事件时间线。不要只写“支持高可用”，却不给故障范围、状态保护方法和恢复目标。
最后说明建设边界与扩容触发条件。例如先支持单节点训练与有限并发，连续观测到数据加载等待超过约定比例后，再评估缓存或存储调整；排队长期超标且现有资源已被有效使用时，再评估计算扩容。具体阈值由代表性测量和团队时限确定。分阶段交付能让每笔投入对应可验证的问题，也为以后更复杂的训练通信与存储方案留下依据。
9 从AI 集群架构走向AI 存储（A51）
走到这里，集群已经不再是硬件清单，而是围绕任务、数据和状态组织的系统。计算节点决定能够执行什么工作，调度决定任务在哪里运行，网络连接数据与计算，持久存储保留能够复现和恢复的证据。下一步学习 AI 存储，是把其中的数据路径继续展开：同样的样本为何有时读取顺畅，有时却让整个集群等待。
进入 A51 前，先区分容量、吞吐、延迟和操作次数。容量回答能放多少内容，吞吐回答单位时间能搬多少字节，延迟回答某次请求等待多久，操作次数则影响大量小文件的服务压力。它们彼此有关，却不能用其中任意 1 项代替其他项。只给出总容量的存储方案，无法判断并发启动是否顺畅；只给出顺序读取速度，也无法推断随机打开文件的表现。
还要区分训练输入和训练产物。输入数据通常被多次读取，适合讨论版本、复用和缓存；检查点需要在有限时间内成功写入，并在故障后读回；最终模型与评估报告需要长期可追溯。不同用途对访问方式、保留周期和可靠性的要求不同。如果把所有内容都放进同一种目录规则，团队很容易在清理缓存时误删检查点，或者长期保留无法对应实验的文件。
带到下一课的材料应包括数据清单、样本大小范围、文件数量、典型读取模式和产物保存策略。对图像任务，记录是否逐文件读取及是否随机打乱；对文本任务，记录清洗后文本长度的差异；对表格任务，记录整表扫描和重复特征处理的需求。这些描述比笼统写“支持 AI 数据”更有用，因为存储设计最终要服务具体的访问路径。
模型效果同样依赖这种数据管理。测试划分被覆盖、旧标签与新特征混用、缓存版本没有更新，都可能让复现实验失效。分布漂移则需要把后续数据与既有评估基准进行比较，而不能看到新一批样本分数降低就立刻调整硬件。平台应保存足够的版本与运行证据，让团队能判断变化来自数据、模型还是资源环境。
可以用自己的逻辑图做最后一次口述：从 1 个样本进入系统开始，说明它属于哪个划分、经过哪些转换、如何送入计算、指标如何产生，以及节点退出后还能依靠哪些状态继续。如果某条路径解释不清，就先补齐图与责任边界。A51 会继续讨论数据如何组织、放置和读取；本课先把“为什么需要这些存储能力”说清楚，为下一步选择留下可检查的依据。
放进方案里
本期集群面向图像分类、表格分类与短文本分类实验，采用统一任务提交、版本记录和产物归档流程。图像流程以 CIFAR-10 验证，固定 45000 张训练、5000 张验证与 10000 张测试图像；表格流程使用 UCI Bank Marketing，删除预测时不可获得的通话时长等字段，记录特征可用时点。验证集用于配置选择，测试集用于最终评价，预处理参数仅在训练部分拟合。
架构划分为控制服务、计算节点池、数据存储与可重建缓存，分别标注任务提交、样本读取、训练通信和检查点写入路径。带加速器节点承担图像训练，CPU 节点承担适合的准备与基线任务，按实测资源需求配置配额和并发上限。缓存使用数据与预处理版本标识，检查点写入持久存储。服务副本的放置需说明共享依赖及覆盖的故障域。
验收使用固定代码、数据划分与并发条件，记录排队时间、准备耗时、完成时间、数据等待和检查点写入延迟；分类报告包含精确率、召回率、F1，二分类补充约定口径的 AUC。对类别不平衡保留各类样本量，对缺少可靠时间信息的数据注明验证局限，并规划后续新数据评估。
故障演练覆盖计算节点退出、元数据服务不可用和存储链路竞争，保留事件时间线，检查有限重试、任务状态及检查点恢复。恢复验收须在替换节点上读回检查点，核对模型参数、优化器状态与训练步数，确认任务能继续更新参数；写入中断留下的不完整文件不得作为恢复入口。报告附检查点校验值、恢复日志和实际重算步数，作为中断损失是否达标的证据。恢复时限、检查点间隔和容量余量由代表性试运行确定并经双方确认。扩容依据持续排队、数据等待与存储延迟等证据分别提出；小数据集流程验证结果不直接外推为大规模性能承诺。
10 小结：下一步AI 存储（A51）
AI 集群架构把计算、存储、网络、调度和故障恢复连成可解释的任务路径。判断方案时，既要看任务是否按时完成，也要看数据划分与模型指标是否可信。
自测：加速器利用率降低时，你会补充哪些证据？2 个副本共用状态库时，还存在什么故障域？若目录查找排队而数据带宽空闲，提高网络速率是否足够？尝试在自己的逻辑图上指出对应位置。
下一课 A51「AI 存储」将沿样本读取与检查点保存路径，继续讨论数据组织、访问性能和可靠保存。