一、第一步：先估场景属于哪一类

1. 推理为主：看并发与上下文长度

只做推理的场景，估算的落点是「同时在线的请求数×单个请求占多少显存」。上下文越长，单个请求占的显存越多，同样的卡能带的并发越少。

这类场景的卡数与参数量关系不大，与并发和长度关系很大。一个常见误判是按模型大小估卡数，结果上线后发现并发上不去。

2. 微调为主：看显存能不能装下

做领域适配、指令微调这类任务，估算的落点是「这个规模在所选微调方式下要多少显存」。全参数微调与只训练少量参数的方法，显存需求能差好几倍。

这类场景的规模不必大，但要把显存算足。装不下就是装不下，靠调参数解决不了。

3. 预训练为主：看互联与节点数

从零训练大模型的场景，估算的落点变成「多少张卡协同、互联撑不撑得住」。此时单卡能力的重要性低于节点内与节点间的通信能力。

这类场景的规模通常不小，且对现场条件要求高：供电、散热、网络都要专门规划。

4. 混合场景：按上限需求定卡型，按日常用量定规模

多数团队其实是混合的：日常做微调与推理，一年做一两次较大规模的训练。这时不要按峰值配规模，而是按上限需求定卡型，保证任务能跑起来；按日常用量定数量，保证日常不浪费，峰值部分再靠外部补充。

这条思路与一体机的固定配置有冲突，所以更要提前想清楚：是否接受峰值时再另想办法。

二、第二步：从参数量推到卡数

1. 显存的粗算公式

显存需求大致由三块构成：权重、梯度与优化器状态、激活值与缓存。把参数量乘以每参数字节数，再按用途乘上不同倍数，得到大致需求。

经验倍数：纯推理约两到四倍，含上下文缓存；只训练少量参数时约三到六倍；全参数训练可到十倍以上。倍数上下浮动很大，取决于批大小、序列长度与是否使用重计算。

2. 卡数的粗算办法

用总显存需求除以单卡可用显存，向上取整，得到理论卡数。再考虑并行带来的额外开销与余量，通常要在此基础上加一档。

这个算法给出的数字只能用来估量级，不能用来定采购。真实卡数要靠实测：先用少量卡跑一个小批次，测出单卡吞吐与显存水位，再推算。

3. 三个必须留的余量

一是显存余量：跑起来后显存贴顶，一次流量波动就会溢出，留出一部分。二是性能余量：实际产出通常低于理论值，排期时要按实测效率算。三是扩容余量：一体机扩容不如租用灵活，现场要留出机柜位置与供电能力。

4. 用一个实例说明推法

假设目标是一个百亿参数级的模型做全参数训练。按每参数十余倍字节估，总需求在千余吉字节量级；单卡可用显存按几十吉字节算，理论需要十几张卡。加上并行开销与余量，实际配置要到十六张卡上下，且需要跨节点互联。

同样的模型换成只训练少量参数的微调，显存需求降到两到三成，四到八张卡就能起步。同一份模型，两种用途的卡数差出一倍以上——这也是为什么必须先定用途再定规模。

三、第三步：在三个档位里找匹配

1. 入门档：单节点、八卡以内

适用的是数十亿参数以内的模型做微调、领域适配或批量推理。形态上单台机器即可，必要时两台互联做小规模并行。

这一档要追求的不是峰值，而是够用加省心：功耗与散热要求低，普通机房就能放；软件栈开箱可用，团队不必配专门的运维角色。

配置上要留一处余量：存储。数据集与检查点往往比预期占地方，入门档常见的问题是盘不够。

2. 进阶段：四到十六节点、每节点八卡

适用的是数百亿参数级的预训练或大规模多任务学习。这一档的形态从单机变成集群，选型的重心转到互联上。

这一档常见的痛点是互联成为隐形瓶颈：单卡数字好看，集群跑起来加速比上不去。选型时要专门确认节点内互联方式与节点间网络方案，并要求提供同类任务的实测加速比。

网络方案在这一档不能含糊。跨节点的梯度同步走哪条链路、带宽多少、是否支持无损传输，这几项决定了集群能不能跑出接近线性的效率。

3. 旗舰档：数十至数百节点

适用的是千亿参数以上预训练、跨模态联合训练这类前沿任务。这一档的选型重点是系统级能力：互联拓扑怎么规划、故障怎么隔离、长周期任务怎么续、供电与散热怎么解决。

4. 档位之间怎么过渡

档位不是必须一步到位。常见路径是从入门档起步，跑通一两个真实任务后再扩。若预计一年内会跨档，选型时就要提前确认扩容方式：能否按节点追加、追加后软件配置要不要重做。

四、现场条件：六项约束先过一遍

1. 供电容量

按整机功率乘节点数，再留出余量。高功耗配置集中布置时，单柜功率密度会远超普通机房，需要专门配电。这一项要提前与场地方确认，不能假定够用。

2. 机柜空间与承重

节点数量、机柜位数、单柜承重三项都要核。高密度配置对承重要求高，普通机房的地板承重不一定满足。

3. 散热与风道

风冷与液冷对应的现场条件完全不同。选型时要确认场地方能不能提供对应的散热条件，改造周期多长。这一项常常是整个项目里颇花时间的一段。

4. 网络与对外链路

内部要有足够的节点间带宽，对外要有稳定的上行链路用于数据同步与远程管理。涉及数据不出场地的场景，外链只走管理与更新通道即可。

5. 场地与物理安全

一体机放在自有场地，物理访问控制、消防、监控这些要一并安排。放在托管场地则要确认对方的管理规范与访问流程。

6. 运维承接

一体机省掉的是软件栈搭建，不省硬件维护。要有明确的人负责日常巡检、故障报修、固件与驱动更新。没有这个角色，出问题时只能等厂家上门，恢复时间会拉长。

五、交付与验收怎么验

1. 到货先验三样

一是配置与合同一致：卡数、显存、内存、存储、网络接口逐项核对。二是软件栈可启动：调度、存储、监控、权限这几项能正常起来。三是基础性能达标：跑一个标准测试，与合同承诺的数字对比。

2. 用真实任务验一次

标准测试跑分不能代表自己的任务。要拿一个真实的小任务完整跑一遍：读数据、跑训练、存检查点、中断恢复、导出产出。这一遍跑通，才算真能用。

中断恢复这一步特别值得验。长周期任务靠它兜底，没验过的恢复流程，真用时总会出意外。

3. 把交付文档收齐

至少四份：配置清单、软件栈说明与版本、运维手册、故障处理流程。四份齐了，后面换人接手才不至于全靠问厂家。

4. 约定响应时限

上门时限、远程支持时段、备件更换周期，这三项要写进合同。不写清楚，故障时的等待时间无法预期。

六、什么情况下这类方案并不合适

1. 用量波动很大的场景

一年只用两三个月、其余时间闲置，一体机的固定成本摊不下来。这类场景按需取用更合适，用多少算多少，用完释放。

2. 需要频繁换型的场景

任务形态在变、卡型需求也在变，固定配置会跟不上。这类场景更适合能随时换规格的方式。

3. 团队没有运维承接能力

一体机把软件栈的问题解决了，硬件与现场的问题还在。没有承接的人，一套设备可能因为一次小故障停摆好几天。

4. 场地条件不具备

供电、散热、承重任何一项不达标，改造周期可能长于项目周期。这种情况下不如先用外部资源起步，把业务跑起来，场地条件成熟后再考虑。

结语

一体机适不适合，取决于三个数字：场景属于哪一类、卡数需要多少、现场条件能承受到哪一档。场景决定看重哪个参数，卡数决定落在哪个档位，现场条件决定档位能不能落地。三样都估清楚，选型就从「哪档便宜」变成「哪档匹配」。

落地建议：先用一页纸写下用途、模型规模、并发或时长目标、可用卡数上限、现场六项条件；再按显存粗算得出卡数量级；末了在档位里找匹配，并用真实验收清单过一遍。判断选得对不对，有个很实在的标准：设备到位一周内，团队能独立跑通一个真实任务并完成一次中断恢复，全程不需要厂家到场。