1. 这份清单不是“排行榜”而是我踩过坑后画出的实操地图如果你正站在GPU资源门口犹豫该选哪家云平台来跑自己的LLM微调任务是直接冲AWS EC2 p4d实例还是试试Lambda Labs新推的A100裸金属又或者被Google Vertex AI的自动扩缩搞得晕头转向那你大概率已经经历过——模型训到一半OOM、显存爆得莫名其妙、数据上传卡在97%、账单突然翻倍却查不出原因……这些不是玄学是每个真实训练者都撞过的墙。我过去三年带过12个不同规模的LLM微调项目从7B参数的Qwen-7B LoRA微调到70B模型的全参微调用过8家主流云厂商的GPU服务亲手配过23种不同规格的实例类型也替客户复盘过5次因选错平台导致的训练中断事故。这份《15家主流云厂商GPU训练支持能力实录》不按官网宣传口径写不照搬白皮书参数只记录每一家在真实LLM训练场景下的可交付能力边界它能不能稳定跑满A100的显存带宽它的NVLink拓扑是否真能打通8卡它的容器镜像里预装的PyTorch版本是否兼容FlashAttention-2它的对象存储和训练节点之间的IO延迟实测多少它的竞价实例在训练中途被回收的概率有多高这些细节决定了你明天早上是看到loss曲线平稳下降还是收到一封“实例已终止”的邮件。适合谁看刚完成模型选型、准备进入工程落地阶段的算法工程师需要向技术决策层汇报云资源方案的技术负责人以及正在对比成本、纠结要不要自建集群的AI Infra团队。它不教你怎么写LoRA代码但能帮你避开90%的环境级失败。2. 为什么不能只看“支持A100/H100”这句宣传语很多团队拿到云厂商的销售材料第一眼就盯住“支持NVIDIA A100 80GB”或“H100 SXM5”这几个字然后拍板——错了。GPU型号只是冰山露出水面的1/10真正决定你能否把模型训下去的是整条计算栈的协同能力。我拿一个最典型的7B模型全参微调任务来拆解假设你用Llama-3-7B-basebatch size设为128sequence length 2048混合精度训练bf16目标是跑通一个epoch。这个任务对底层设施提出5个硬性要求显存容量与带宽匹配7B全参微调在bf16下仅模型权重就占约14GB加上梯度、优化器状态AdamW、激活值缓存单卡显存需求轻松突破40GB。A100 40GB卡会频繁OOM必须上80GB版本。但光有80GB不够——A100的显存带宽是2TB/s如果PCIe通道被其他设备抢占实际可用带宽可能掉到1.2TB/s以下导致数据加载成为瓶颈GPU利用率长期卡在30%。多卡通信效率8卡并行时All-Reduce操作必须走NVLink而非PCIe。实测发现某云厂商标称“8×A100”但物理上8张卡分属两个NUMA节点NVLink只在每组4卡内连通跨组通信强制走PCIe x16All-Reduce耗时比预期高3.7倍最终吞吐量只有理论值的42%。存储IO吞吐能力训练时每秒要从对象存储读取数百MB的tokenized数据。如果云盘IOPS只有3000而你的DataLoader开8个worker实际读取速度会被卡死在120MB/sGPU等数据时间占比超65%。我们曾在一个项目中把S3桶迁移到同区域的高性能文件存储如AWS FSx for Lustre数据加载延迟从85ms降到3ms单epoch耗时缩短41%。网络稳定性与延迟当使用DeepSpeed Zero-3做模型并行时节点间需高频同步小块参数。实测显示某些云厂商的VPC内网延迟波动极大2ms~47ms导致Zero-3的all-gather操作超时重试训练step time方差高达±220%。而另一家采用RDMA over Converged EthernetRoCE的厂商延迟稳定在0.8±0.1ms同样配置下step time标准差仅±3%。软件栈成熟度不是所有云都默认提供torch2.3.0cu121flash-attn2.5.8vllm0.4.2的黄金组合。我们遇到过某平台镜像里PyTorch CUDA扩展编译时缺少cudnn.h头文件导致FlashAttention无法启用训练速度直接打七折也遇到过某厂商容器运行时禁用了--privileged权限导致nvidia-smi dmon监控失效故障排查时间延长3倍。所以“支持GPU”和“能跑好LLM训练”中间隔着一整条技术栈。这份清单的筛选逻辑就是围绕这5个硬指标逐家验证、交叉比对、实测留痕。下面每一项评估都对应着我在真实项目中填过的坑。3. 15家云厂商GPU训练能力深度实测对照表我们选取了当前市场活跃度最高、API开放程度最好、且明确提供A100/H100实例的15家云服务商。评估维度全部来自真实训练场景非官网参数摘抄。所有测试均在2024年Q2完成使用统一基准任务Llama-3-7B全参微调bf168卡A100 80GBbatch size128sequence length2048DeepSpeed ZeRO-2数据集为The Pile子集128GB。测试环境均为按需实例On-Demand排除竞价实例Spot/Preemptible的干扰。厂商实例型号NVLink拓扑存储IO实测MB/s网络延迟msPyTorchFlashAttention预装DeepSpeed兼容性典型问题现场记录AWSp4d.24xlarge (8×A100)全互联8卡NVLink1,840S3FSx Lustre0.9±0.2✅ torch 2.3.0cu121, flash-attn 2.5.8✅ 零配置数据上传S3时偶发503错误需加指数退避AzureND96amsr_A100_v4 (8×A100)全互联1,620BlobPremium NFS1.1±0.3⚠️ torch 2.2.2需手动升级flash-attn✅NCCL超时需调大NCCL_ASYNC_ERROR_HANDLING1GCPa2-highgpu-8g (8×A100)全互联1,410Cloud StorageFilestore0.7±0.1✅ torch 2.3.0cu121, flash-attn 2.5.8✅启动时偶发GPU device not found重启实例解决Lambda LabsA100 80GB 8x全互联2,150本地NVMe直连0.4±0.05✅ torch 2.3.0cu121, flash-attn 2.5.8✅无管理控制台全靠CLI新手学习曲线陡RunPodA100 80GB Cloud全互联1,380S3兼容存储1.8±0.5✅ torch 2.3.0cu121, flash-attn 2.5.8✅WebUI偶尔卡顿建议用SSH直连Vast.aiA100 80GB拓扑不透明实测为44分组920对象存储2.3±1.1⚠️ torch 2.1.0需手动编译flash-attn⚠️ Zero-3需降级到v0.8.3多卡通信延迟抖动大All-Reduce耗时不稳定CoreWeaveA100 80GB全互联1,980S3Lustre0.6±0.1✅ torch 2.3.0cu121, flash-attn 2.5.8✅GPU监控需额外部署Prometheus exporterPaperspaceA100 80GB全互联1,250S31.5±0.4✅ torch 2.3.0cu121, flash-attn 2.5.8✅控制台日志截断严重debug需进容器查journalctlCUDO ComputeA100 80GB全互联1,760对象存储0.8±0.2✅ torch 2.3.0cu121, flash-attn 2.5.8✅文档更新滞后H100实例配额需邮件申请ExafunctionH100 80GB全互联2,450本地NVMe0.3±0.05✅ torch 2.3.0cu121, flash-attn 2.5.8✅H100仅限企业客户起订5卡Stability AI API——托管API不适用————不开放❌ 仅支持推理不支持训练无训练接口纯推理服务Together AI——托管API不适用————不开放❌ 仅支持推理同上定位非训练平台Fireworks.ai——托管API不适用————不开放❌ 仅支持推理同上AnyscaleA100 80GB全互联1,120S31.2±0.3✅ torch 2.3.0cu121, flash-attn 2.5.8✅Ray Train集成Ray集群启动慢平均47s影响快速迭代ModalA100 80GB全互联1,080S31.4±0.4✅ torch 2.3.0cu121, flash-attn 2.5.8✅Modal Functions封装函数冷启动时间长首次调用20s不适合交互式调试提示表格中标记⚠️的条目代表需额外投入人力进行适配会直接拉长POC周期。例如Vast.ai的NVLink分组问题我们在一个客户项目中花了17小时才定位到是NUMA绑定策略导致最终改用numactl --cpunodebind0 --membind0强制绑定才将吞吐量从38 samples/sec提升到61 samples/sec。注意“托管API”类厂商Stability AI、Together AI、Fireworks.ai虽在市场声量大但严格来说不属于“GPU云提供商”它们不售卖算力资源只提供封装好的模型服务。本清单将其列入是为了明确划清边界——如果你需要的是训练能力它们不在候选范围内。4. 关键能力逐项拆解从选型到上线的实操链路4.1 实例选型别被“H100”三个字晃花眼H100确实强但强在哪很多人没想清楚。H100 SXM5的FP16算力是4000 TFLOPSA100是624 TFLOPS看起来是6.4倍。但LLM训练的瓶颈从来不在峰值算力而在有效算力利用率。我们做过一组对照实验同样训Llama-3-7BA100 8卡 vs H100 2卡总卡数减半但单卡算力翻倍。A100 8卡实测平均GPU利用率78%step time 1.24s单epoch耗时3h12m。H100 2卡实测平均GPU利用率89%step time 0.87s单epoch耗时2h05m。表面看H100快了1.5倍但成本呢H100实例小时单价是A100的2.8倍。算下来A100方案的$ / epoch是$187H100是$293——贵了57%只换来了35%的时间节省。更关键的是H100的Hopper架构引入了新的内存管理机制HBM3 Transformer Engine但并非所有框架都适配完善。我们遇到过H100上torch.compile()生成的kernel在某些attention pattern下触发CUDA assertion failed回退到A100立刻正常。所以我的建议是中小团队优先选A100把钱花在数据工程和超参搜索上只有当你卡在A100的显存墙比如训70B全参或通信墙跨机All-Reduce太慢时再切H100。另外H100分SXM5板载和PCIe插槽两种SXM5带宽更高但云厂商通常只提供SXM5PCIe版极少——这点务必在询价时确认。4.2 存储方案90%的IO瓶颈源于选错存储类型LLM训练的数据流是对象存储原始数据→ 训练节点本地缓存预处理后→ GPU显存实时喂入。这三个环节任何一处卡住GPU就空转。我们统计了12个项目的IO瓶颈分布38% 卡在对象存储下载S3/Blob/Cloud Storage41% 卡在训练节点本地磁盘HDD/低IOPS SSD21% 卡在GPU显存加载DataLoader worker不足或prefetch设置不当解决方案不是堆SSD而是分层设计对象存储层选与计算节点同区域、同AZ的存储。AWS S3 us-east-1的us-east-1a AZ内延迟10ms跨AZ升至35ms。GCP Cloud Storage的us-central1-a与a2实例同AZ实测首字节延迟12ms若选us-west1则飙升至89ms。中间缓存层绝不用系统盘EBS gp3 / Azure Premium SSD。必须挂载高性能共享存储AWSFSx for Lustre推荐scratch2部署类型IOPS可配到100万AzureAzure NetApp FilesUltra tier吞吐配到10GB/sGCPFilestore MAXIMUM tier吞吐12GB/sLambda/CoreWeave直接提供NVMe直连盘无需额外挂载本地加载层DataLoader必须开启pin_memoryTruenum_workers8等于GPU卡数prefetch_factor2。我们曾在一个项目中把num_workers从4调到8数据加载耗时从210ms降到85msGPU利用率从52%升至79%。实操心得Lambda Labs的NVMe直连盘是目前实测IO最高的方案2.15GB/s但它没有共享存储概念——8卡节点的数据必须提前rsync到每张卡对应的本地路径否则会出现“卡1读完数据卡2还在等”的情况。我们写了个轻量脚本在训练前自动同步耗时8s。4.3 网络与通信DeepSpeed和FSDP的隐形杀手DeepSpeed ZeRO-2/3和FSDP的核心是节点内和节点间的参数同步。同步效率取决于两个指标延迟Latency和带宽Bandwidth。前者影响单次同步耗时后者影响大数据块传输速度。我们用nccl-tests做了全网扫描最佳实践选择支持RoCERDMA over Converged Ethernet或InfiniBand的厂商。CoreWeave和Exafunction的RoCE网络all_reduce_perf测试结果8卡间1GB数据同步耗时仅18ms带宽56GB/s。而某家标榜“高性能网络”的厂商实测all_reduce_perf耗时142ms带宽7.1GB/s原因是其VPC网络基于普通TCP/IP未启用RDMA卸载。避坑指南警惕“虚拟网络”陷阱。有些厂商用SR-IOV虚拟化网卡看似独占但底层仍走软件转发。实测其ping延迟稳定但ib_write_bwRDMA带宽测试结果只有物理网卡的35%。验证方法很简单在实例上执行ibstat若输出CA mlx5_0 state: PORT_ACTIVE说明RDMA可用若报错No HCAs found则无RDMA。参数调优即使有RoCE也要调NCCL参数。我们固定使用的环境变量组合export NCCL_IB_DISABLE0 export NCCL_IB_GID_INDEX3 export NCCL_IB_SL3 export NCCL_SOCKET_TIMEOUT60000000 export NCCL_ASYNC_ERROR_HANDLING1其中NCCL_IB_GID_INDEX3指向RoCE v2的GID能避免IPv4/IPv6双栈冲突NCCL_SOCKET_TIMEOUT设为60秒防止短暂网络抖动触发进程退出。4.4 软件栈那些文档里不会写的兼容性雷区云厂商的镜像看似“开箱即用”但LLM训练栈极其敏感。我们整理了高频兼容性问题TOP5PyTorch CUDA版本错配某厂商镜像预装torch2.2.0cu118但flash-attn2.5.8要求cu121。强行pip install会触发undefined symbol: cusparseLtMatDescriptorInit错误。解法先conda install pytorch2.3.0 pytorch-cuda12.1 -c pytorch -c nvidia再pip install flash-attn。CUDA Driver与Runtime不兼容H100需要CUDA Driver 525但某些旧镜像Driver为515。nvidia-smi显示正常但torch.cuda.is_available()返回False。解法sudo apt update sudo apt install --upgrade cuda-drivers重启实例。Docker容器权限限制为安全默认禁用--privileged。但nvidia-smi dmonGPU监控和nvidia-persistenced持久化模式需要此权限。解法启动容器时加--security-opt seccompunconfined或改用nvidia-container-toolkit的--no-opengl模式。文件系统inode耗尽LLM训练产生海量小文件checkpoints、logs、tensorboard events。某项目用ext4文件系统128GB盘分配了200万个inode训到第3天inode用尽touch test报No space left on device。解法格式化时加-i 4096每4KB一个inode或直接换XFS默认inode无限。时区与日志时间错乱多个节点日志时间不同步导致故障排查困难。某次All-Reduce超时主节点日志显示10:23:45worker节点显示10:22:18。解法所有实例启动时执行sudo timedatectl set-ntp on sudo timedatectl set-timezone UTC。注意事项永远不要相信“最新版”就是最好的。我们线上稳定运行的是torch2.3.0cu121transformers4.41.2accelerate0.29.3组合。transformers4.42.0引入了一个cache_dir路径解析bug导致HuggingFace Datasets加载失败回滚即解决。5. 成本、稳定性与运维那些决定项目生死的隐藏变量5.1 真实成本结构别只看实例单价云厂商官网标价只是冰山一角。真实成本包含5块计算成本实例小时费最大头但可预测存储成本对象存储$0.023/GB/月 高性能缓存FSx $0.15/GB/月网络成本跨AZ流量AWS $0.01/GB、公网出口$0.09/GB隐性成本因配置错误导致的重复训练一次7B微调失败≈$120、人工排障时间按$150/h计平均每次故障2.3h机会成本因平台限制无法尝试的优化如H100的Transformer Engine加速某厂商不开放CUDA Graph我们核算过一个典型7B微调项目3天训练2天调试的总成本厂商计算成本存储成本网络成本隐性成本总成本ROI备注AWS$218$42$18$290$568隐性成本高因S3 503错误频发Lambda Labs$192$0$0$85$362无网络/存储费用隐性成本最低CoreWeave$205$38$5$112$360RoCE网络减少排障隐性成本可控Vast.ai$167$22$15$410$614NVLink问题导致多次重训隐性成本爆炸实操心得Lambda Labs的成本优势源于其“裸金属无中间层”架构。没有虚拟化开销没有VPC网络转发所有资源100%透出。但代价是——你需要自己搞定一切从内核模块加载nvidia-uvm、到CUDA驱动更新、再到监控告警。它适合有Infra能力的团队不适合算法团队单兵作战。5.2 稳定性真相竞价实例Spot的甜蜜陷阱Spot实例价格是按需实例的25%~40%极具诱惑。但我们统计了15家厂商的Spot中断率过去30天A100实例最低CoreWeave0.8%、Lambda Labs1.2%中等AWS3.5%、GCP4.1%、Azure5.3%较高Vast.ai12.7%、RunPod9.8%中断不是随机的。AWS Spot中断有明显规律每天UTC时间00:00、06:00、12:00、18:00四个高峰因为此时大量批处理作业提交竞价池被挤占。我们的应对策略是Checkpoint策略每100 steps强制保存一次checkpoint而非默认的1000 steps确保中断后最多损失10分钟训练。中断监听AWS Spot实例会在中断前2分钟发送EC2_INSTANCE_RETIREMENT事件到实例元数据。我们写了个守护进程监听http://169.254.169.254/latest/meta-data/spot/instance-action一旦检测到立即触发deepspeed --save。跨区域冗余核心训练任务同时在us-east-1和us-west-2各起一个Spot集群用rsync实时同步checkpoint主集群中断时备集群10秒内接管。提示GCP的Preemptible VM中断前30秒通知比AWS更友好。但它的中断率略高因为GCP的竞价池更小供需波动更大。5.3 运维监控没有监控的训练就像蒙眼开车LLM训练周期长数小时至数天必须建立三层监控基础设施层GPU温度85℃预警、显存占用95%预警、PCIe带宽80%理论值预警。工具dcgm -e 1NVIDIA Data Center GPU Manager。框架层DeepSpeed的ds_report、PyTorch Profiler的torch.profiler.record_function。重点监控cudaMemcpyAsync耗时数据拷贝、cublas_gemm耗时矩阵乘。业务层Loss曲线平滑度连续10步std 0.05预警、梯度范数突增预示梯度爆炸、learning rate warmup是否按计划执行。我们自研了一个轻量监控面板基于Grafana Prometheus采集所有指标设置如下关键告警gpu_temp{instance~train.*} 85→ 立即停止训练检查散热nvml_gpu_utilization{instance~train.*} 40→ 触发IO瓶颈诊断流程deepseed_step_time_seconds{jobtrain} 2.0→ 检查All-Reduce耗时loss_std_10steps{jobtrain} 0.05→ 检查数据混洗和label噪声这套监控让我们在3个客户项目中提前23分钟发现显存泄漏loss缓慢上升但grad_norm正常避免了整轮训练报废。6. 我的实操经验总结什么情况下该选哪家最后说说我个人在真实项目中如何决策。这不是理论推演是血泪教训换来的条件反射如果你是初创公司算法团队5人首期预算5万美元闭眼选Lambda Labs。理由价格最低、IO最强、无隐藏费用。缺点是你得自己搭监控、写重试脚本、处理驱动更新。但省下的钱够你雇半个DevOps兼职干这事。我们帮一个AI原生应用团队用Lambda Labs训Qwen-14B LoRA3天跑通总成本$412比AWS便宜58%。如果你是中大型企业已有Kubernetes集群需要与现有CI/CD打通选CoreWeave。它的K8s Operator成熟kubectl apply -f train.yaml就能起训练任务且RoCE网络让跨节点训练像单机一样稳。我们给一家金融科技客户迁移从自建集群切到CoreWeave运维人力减少70%训练成功率从82%升至99.4%。如果你的模型30B必须用H100且对延迟极度敏感如实时微调只考虑Exafunction或CoreWeave。Exafunction的H100集群延迟最低0.3ms但起订门槛高CoreWeave性价比更好且支持H100A100混合部署方便渐进式迁移。我们训Mixtral-8x7B时CoreWeave的H100 8卡方案比AWS的p5.48xlarge便宜22%性能持平。如果你只是想快速验证一个想法不想碰infra用RunPod或Paperspace。WebUI点几下就起环境自带Jupyter和VS Code适合算法同学自己折腾。但记住它们不是生产环境。我们有个客户用RunPod训7BPOC成功后想切生产结果发现其对象存储不支持IAM Role无法对接企业AD被迫重做权限体系。绝对要避开的场景需要长时间不间断训练7天→ 避开Vast.ai和RunPod中断率太高需要极致成本控制且无Infra人力→ 避开Lambda Labs你会被驱动问题逼疯需要企业级SLA和审计日志→ 避开所有新兴厂商只选AWS/Azure/GCP哪怕贵30%。我最后一次做这种选型是在上个月。客户要训一个13B医疗大模型要求3天内出首个可用版本预算卡在$2000。我打开这张表扫了一眼“隐性成本”列直接否掉了Vast.ai和AWS前者中断率高后者S3错误多。在Lambda Labs和CoreWeave之间我选了后者——因为客户CTO明确说“不能接受任何训练中断宁可多付钱”。最终CoreWeave集群72小时零中断跑完loss从2.17降到1.32客户当场签了年度合同。你看选型不是比参数是比谁更懂你的约束条件。