大模型项目启动后，最先卡住人的往往是GPU云服务器如何选。配置表上的型号、显存和单价都写得很清楚，真正下单后却可能出现两种情况：算力不够，训练跑到一半显存溢出；或者配置过高，预算花了，卡大半时间在闲置。这篇文章梳理选型时需要看的几个维度，并用两个案例说明判断方法。
一、先弄清楚任务类型
选卡之前，先确定你要做的是推理、微调还是训练。三者对硬件的要求差别很大，不能放在一起比较。
- 模型推理：主要看显存容量和单卡吞吐，对多卡互联的要求相对低。
- 轻量微调（如LoRA、QLoRA）：显存要够，但单卡或双卡通常就能跑完。
- 全参数训练或预训练：算力、显存带宽和多机互联都要跟上，很多时候网络质量决定了整体效率。
任务类型定下来，后面看参数会容易得多。
二、显存是第一道门槛
显存决定模型能不能装下。粗略的估算办法是：FP16精度下，参数量乘以2字节就是权重占用。7B模型约需14GB，70B模型约需140GB，单卡装不下，只能多卡切分。
训练时还要加上梯度、优化器状态和激活值，总占用常常是权重的数倍。全参数微调7B模型，往往要40GB以上，甚至80GB。如果改用QLoRA量化微调，24GB显存的卡就有机会完成。
案例一：一家做客服问答的小团队计划部署13B模型提供推理服务。最初选了显存较小的卡，并发稍高时就频繁溢出。后来换成单卡显存更大的机型，同时用量化压缩模型体积，单卡即可稳定运行，总成本反而低于多卡方案。显存要和量化方案一起算，只看裸参数很容易选错。
三、算力和显存带宽要分开看
算力决定计算快慢，显存带宽决定数据搬运快慢。推理阶段，瓶颈常在带宽而不是算力；训练阶段则更看重Tensor Core对混合精度（如FP16、BF16）的支持。
对比机型时可以逐项核对：
- 框架用到的精度格式是否支持，比如BF16，或者FP8。
- 显存带宽数值。大批量推理时，带宽高的卡吞吐通常更好。
- 实际可用算力。纸面峰值参考意义有限，最好看厂商或社区公开的基准测试。
四、多卡和多机场景，互联比单卡更关键
任务需要多卡甚至多机协同时，通信往往比单卡性能更早成为瓶颈。同机多卡之间一般通过NVLink或PCIe互联，NVLink带宽明显更高，适合张量并行这类通信密集的场景。跨机训练则依赖RDMA网络，比如InfiniBand或支持RoCE的高速以太网。
案例二：某团队用四台八卡服务器训练中等规模模型，起初使用普通以太网，GPU利用率长期低于50%，大量时间耗在等待通信上。换成支持RDMA的高速网络后，同一任务的训练时长缩短了接近一半。多机训练时，网络配置的重要性并不比GPU本身低。
五、计费方式直接影响总成本
计费模式选对了能省不少钱，选之前先想清楚自己的使用节奏。
- 按量付费：适合短期实验、调试，或时长不确定的任务。灵活，但单价高，长期跑并不划算。
- 包月或包年：适合长期稳定运行的推理服务，单价低，前提是用量能预估准。
- 抢占式实例：价格最低，但随时可能被回收。适合能断点续训的训练任务，前提是检查点机制要做好。
比较稳妥的做法是先用按量实例把流程跑通，确认资源需求后再转包月或包年，免得一开始就锁定过多资源。
六、软件生态和运维细节别漏掉
硬件之外，有几项很容易被忽略：
- 驱动与CUDA版本：下单前确认镜像预装的驱动和你的深度学习框架对得上，版本不匹配会耗掉大量排查时间。
- 镜像：优先选带常用框架的官方镜像，能省下不少环境配置的时间。
- 存储：数据读取跟不上，GPU就会空等。关注云盘或并行文件系统的吞吐，别只盯着GPU型号。
- 地域与合规：数据是否必须留在境内，离用户的网络距离多远，都会影响选址。
- 服务与SLA：硬件故障时的响应时长和补偿规则，在长期项目里比想象中更重要。
七、选型的大致顺序
把前面的内容串起来，决策顺序大致是：先定任务类型，再估算显存，然后按精度和吞吐要求确定算力档次，接着判断是否需要多卡或多机互联，最后结合预算选计费方式。选定之后，用小规模测试跑一遍。很多时候，实际跑一次基准测试，比反复对比参数表更能说明问题。
GPU云服务器没有一套配置适用于所有场景，只有和任务匹配的方案。把负载特征想清楚，再逐项核对显存、算力、互联和成本，大部分选型问题都能理出头绪。
