1. 这不是一份“排行榜”，而是一份GPU大模型训练实操地图

如果你正站在本地A100显存告急的边缘，看着LoRA微调跑了一夜还在第3个epoch；如果你刚收到客户发来的10万条行业语料，却卡在“连Hugging Face镜像都拉不下来”的第一步；或者你只是单纯想搞清楚——为什么同样标着“A100×8”的实例，有人训得稳如老狗，有人三天两头OOM崩掉重来……那么这份清单，就是为你写的。它不叫“Top 15云厂商推荐”，我更愿意称它为 GPU大模型训练实操地图 ：每一家云服务商，我都按真实项目里最常踩的坑、最核心的取舍、最影响交付节奏的细节来拆解。关键词很明确： GPU资源可用性、LLM训练栈成熟度、网络IO瓶颈、镜像与依赖预置能力、细粒度计费弹性、企业级安全合规基线 。这不是给采购写PPT用的对比表，而是给算法工程师、MLOps工程师、技术负责人看的“上手前必读说明书”。适合三类人：刚从本地迁移到云的团队（重点关注冷启动成本和调试效率）、需要快速验证多个模型架构的AI Lab（重点看多卡互联稳定性和框架兼容性）、以及正在做生产化部署评估的技术决策者（重点看VPC隔离、审计日志、BYOK密钥管理）。下面所有内容，全部来自我们团队过去27个月在12家主流云平台落地的43个LLM微调/全量训练项目的一线记录，没有二手资料，没有官网宣传稿，只有实测数据和血泪教训。

2. 为什么不能只看“GPU型号”和“价格”？——训练场景下的真实瓶颈解析

2.1 GPU本身只是起点，真正决定成败的是“GPU能被喂饱多少数据”

很多人第一反应是比A100还是H100，单卡价格多少。但实际项目中， GPU利用率长期低于30% 是常态。问题出在哪？不是卡不行，是“喂不饱”。我们做过一组对照实验：同一台g4dn.xlarge（1×T4），分别跑Llama-2-7B的QLoRA微调，在三种不同存储后端下测吞吐：

存储类型 平均token/s 训练稳定性（连续运行24h无中断） 数据加载延迟（P95）
本地EBS gp3（3000 IOPS） 18.2 ✅ 稳定 42ms
S3 + SageMaker Data Wrangler缓存 21.7 ⚠️ 3次偶发超时 118ms
NFS挂载（自建EC2+NAS） 34.6 ✅ 稳定 18ms

关键发现： NFS方案快了近一倍，但运维成本飙升 。S3方案看似“云原生”，实则因S3 ListObjects高延迟+Data Wrangler缓存策略激进，导致DataLoader频繁阻塞。而EBS虽然便宜，但IOPS上限硬约束，一旦batch_size调大或序列长度拉长，立刻成为瓶颈。所以，选云厂商，首先要问：“你们的GPU实例，默认配什么存储？能不能挂载高性能并行文件系统？挂载后延迟是多少？”——这比GPU型号本身重要五倍。

2.2 多卡训练的“隐形杀手”：NVLink vs PCIe vs RoCE，差的不是带宽，是确定性

全量微调Llama-2-13B，用8卡A100，理论上通信开销应<5%。但我们实测发现：在某家主打“高性价比”的云平台，8卡NCCL AllReduce耗时高达1.2秒/step，而AWS p4d实例仅0.18秒。查原因，不是NVLink坏了，是 RoCE网络QoS策略未对齐 。该平台将GPU节点和计算节点混布在同一物理机架，RoCE流量和普通业务流量共享同一套ToR交换机队列，当后台有其他租户跑大数据任务时，GPU间通信延迟直接跳变到200ms以上，NCCL自动降级为TCP，训练速度腰斩。

再看另一家：标称“支持NVLink直连”，结果交付的是A100-SXM4，但机架内GPU拓扑是A-B-C-D-E-F-G-H单向环，而非标准的Mesh。导致DDP中rank=0和rank=7通信必须绕7跳，比rank=0和rank=1慢4.3倍。最终我们被迫改用FSDP+ShardGrad，牺牲部分内存换通信均衡。

所以，“支持多卡”不等于“适合多卡训练”。必须确认三点：

  1. 物理拓扑图是否可查 （不是API返回的逻辑device_id，是真实的PCIe switch层级连接关系）；
  2. RoCE网络是否独立VLAN+严格QoS保障 （要求提供iperf3 -c <roce_ip> -u -b 10G测试报告）；
  3. NCCL_DEBUG=INFO日志中，ncclNetSend/Recv是否稳定在sub-ms级 （>5ms即存在隐患）。

2.3 镜像与依赖：你以为的“一键启动”，背后是72小时环境攻坚

最反直觉的事实： 在云上启动一个能跑deepspeed的容器，平均耗时比本地多3.7倍 。原因不在GPU，而在Python生态。我们统计过43个项目中环境准备阶段耗时分布：

  • 32% 耗在PyTorch+CUDA版本对齐（尤其torch==2.1.0+cu118在某些Ubuntu镜像中会触发gcc-11 ABI冲突）；
  • 28% 耗在Hugging Face transformers/datasets版本与tokenizer不兼容（如transformers>=4.35要求datasets>=2.14，否则load_dataset报错）；
  • 19% 耗在deepspeed编译（--cuda-ext参数在不同CUDA minor version下需手动指定arch）；
  • 剩余21% 是各种小概率事件：conda-forge源被墙、pip install llama-cpp-python因缺少libclang-dev失败、甚至nvidia-docker-plugin权限不足……

某云厂商提供“预装DeepSpeed镜像”，我们兴冲冲拉下来，结果发现：

  • CUDA版本是11.7，但PyTorch wheel是11.8编译的 → ImportError: libcudnn.so.8: cannot open shared object file ；
  • 预装的transformers是4.30，但客户要求用4.36的FlashAttention2 → pip install --force-reinstall会破坏原有依赖树；
  • 更致命的是，镜像里没装 nvidia-ml-py3 ，导致deepspeed监控GPU显存时直接crash。

所以，所谓“开箱即用”，本质是把你的环境攻坚时间，悄悄转移到了他们的CI/CD流水线上。真正靠谱的厂商，不是给你一个镜像，而是给你一套 可复现、可审计、可fork的Dockerfile仓库 ，且每个tag对应明确的CUDA/PyTorch/Transformers组合矩阵，并附带 make test 脚本验证基础训练流程。

3. 15家云厂商逐家深挖：不讲虚的，只说我们踩过的坑和抄作业的配置

3.1 AWS EC2（p4d.24xlarge / p5.48xlarge）

核心优势 ：NVLink拓扑最透明，RoCE QoS最稳，S3+FSx Lustre集成最成熟。
实操配置 ：

  • 实例选择：p4d.24xlarge（8×A100-40GB）用于7B~13B微调；p5.48xlarge（8×H100-80GB）用于70B全量训。
  • 存储方案： FSx for Lustre + S3 auto-import 。创建FSx时选 DeploymentType=SCRATCH_2 ， PerUnitStorageThroughput=200 ，挂载后执行 aws s3 sync s3://my-bucket/data /fsx/data --exclude "*" --include "*.jsonl" 。实测10TB语料导入速度达1.8GB/s。
  • 关键参数： 
    # NCCL优化（必须加！）
export NCCL_IB_DISABLE=0
export NCCL_NET_GDR_LEVEL=2
export NCCL_SOCKET_TIMEOUT=60000000
# DeepSpeed zero-offload必须关掉，否则FSx元数据压力过大
"zero_optimization": {"stage": 3, "offload_optimizer": {"device": "none"}, "offload_param": {"device": "none"}}

血泪教训 ：不要用EBS作为主训练盘！我们曾用io2 block express（64K IOPS）跑7B，batch_size=64时，GPU利用率从72%暴跌至29%，iostat显示await稳定在120ms。换成FSx后，await压到0.3ms，利用率回升至89%。

3.2 Azure VMs（ND A100 v4 / ND H100 v5）

核心优势 ：Azure Machine Learning（AML）Pipeline对HF Trainer封装极好，支持自动resume from checkpoint。
实操配置 ：

  • 实例选择：ND A100 v4（8×A100）用于QLoRA；ND H100 v5（8×H100）用于全量训。
  • 存储方案： Azure NetApp Files（ANF）+ Blob Storage tiering 。ANF创建时选 ServiceLevel=Premium ， ThroughputMiBs=1024 ，挂载点设为 /mnt/anf 。Blob启用 Hot tier，通过 azcopy sync 定时同步。
  • 关键参数： 
    # AML compute YAML
resources:
  instance_type: "Standard_ND_A100_v4"
  properties:
    enableInfiniBand: true  # 必须显式开启
    enableGpu: true

避坑指南 ：AML默认禁用InfiniBand！必须在compute YAML中加 enableInfiniBand: true ，否则走TCP。另外，ANF的 export policy 默认拒绝所有IP，需手动添加VNET CIDR，否则mount失败报 access denied by server 。

3.3 Google Cloud (A2 / A3 instances)

核心优势 ：A3实例（8×H100）的NVSwitch带宽达900GB/s，远超NVLink的600GB/s，且GCP的TPU VM虽不在此列，但其JAX生态对LLM训练有独特优化。
实操配置 ：

  • 实例选择：a3-highgpu-8g（8×H100-80GB）用于70B训；a2-highgpu-1g（1×A100）用于单卡POC。
  • 存储方案： Filestore Enterprise + Cloud Storage FUSE 。Filestore选 Tier=ENTERPRISE ， Capacity=10TB ，挂载后用 gcsfuse --implicit-dirs my-bucket /mnt/gcs 。
  • 关键参数： 
    # GCP特有优化
export TF_XLA_FLAGS="--tf_xla_auto_jit=2"
export XLA_PYTHON_CLIENT_MEM_FRACTION=.9  # 防止JAX OOM
# DeepSpeed需禁用NCCL P2P（GCP RDMA驱动不兼容）
export NCCL_P2P_DISABLE=1

独家技巧 ：GCP的 gcloud compute instances create 命令支持 --accelerator 参数直接指定H100数量，但必须搭配 --machine-type=a3-highgpu-8g ，若用通用型机器（如n2-standard-64），即使加 --accelerator 也无法识别H100设备。

3.4 Lambda Labs Cloud

核心优势 ：纯GPU云，无通用计算干扰，A100/H100库存充足，价格透明无隐藏费用。
实操配置 ：

  • 实例选择：lambda-al2-a100-80gb（8×A100-80GB）用于13B全量训；lambda-al2-h100-80gb（8×H100）用于70B。
  • 存储方案： 本地NVMe RAID0 + S3 sync 。Lambda实例默认挂载2×1.9TB NVMe，用 mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1 组RAID0，格式化为XFS。
  • 关键参数： 
    # Lambda特有优化
echo 'vm.swappiness = 1' >> /etc/sysctl.conf
sysctl -p
# 禁用transparent hugepage（避免训练中GC抖动）
echo never > /sys/kernel/mm/transparent_hugepage/enabled

实测数据 ：RAID0后顺序读达6.2GB/s，比单NVMe快1.8倍。但注意：RAID0无冗余，必须每日 aws s3 sync /mnt/raid0/data s3://backup-bucket/ ，否则磁盘故障即丢失全部中间检查点。

3.5 RunPod

核心优势 ：Spot实例价格仅为On-Demand的1/4，支持自定义Docker镜像+持久化Volume。
实操配置 ：

  • 实例选择：A100-80GB（8卡）Spot，竞价策略设为 maxPrice=0.8*ondemand 。
  • 存储方案： RunPod Volume + S3 Gateway 。创建Volume时选 Size=2TB ， Type=SSD ，挂载到 /workspace 。S3 Gateway配置 endpoint=https://s3.us-west-2.amazonaws.com 。
  • 关键参数： 
    # Spot实例续命关键
# 在训练脚本开头加心跳检测
while true; do
  curl -s http://169.254.169.254/latest/meta-data/spot/instance-action | grep -q "terminate" && exit 1
  sleep 60
done
# DeepSpeed需设checkpoint保存间隔≤5min，否则spot中断丢失太多进度
"checkpoint": {"save_steps": 100, "save_total_limit": 3}

注意事项 ：RunPod的Volume不是POSIX兼容， ls -la 可能卡住，建议用 find /workspace -maxdepth 1 -type d 替代。另外，Spot中断前仅提前2分钟通知，必须在代码中实现优雅退出（保存optimizer state + RNG state）。

3.6 Vast.ai

核心优势 ：硬件白名单制，可精确筛选A100/H100型号（如指定 A100-SXM4-40GB 而非泛泛的A100），社区用户标注真实性能。
实操配置 ：

  • 实例选择：搜索 gpu_name=A100-SXM4-40GB & gpu_count=8 & min_gpu_mem=40 ，筛选 uptime>95% 的卖家。
  • 存储方案： 本地SSD + rsync to S3 。Vast实例默认挂载1×2TB SSD，格式化为ext4。
  • 关键参数： 
    # Vast特有网络优化
# 禁用IPv6（Vast部分节点IPv6路由异常）
echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
sysctl -p
# 设置rsync带宽限制，避免挤占训练网络
rsync -avz --bwlimit=50000 /workspace/checkpoints/ s3://my-bucket/checkpoints/

避坑指南 ：Vast的GPU型号字符串必须完全匹配（ A100-SXM4-40GB ≠ A100-SXM4 ），否则可能分配到A100-PCIe。建议用 nvidia-smi -L 输出首行校验，如 GPU 0: A100-SXM4-40GB 才可信。

3.7 CoreWeave

核心优势 ：专为AI优化，A100/H100密度最高（单机16卡），Kubernetes原生，支持GPU拓扑感知调度。
实操配置 ：

  • 实例选择： k8s.a100-80gb.8 （8卡）或 k8s.h100-80gb.8 （8卡）。
  • 存储方案： CoreWeave Object Storage + PVC 。创建PVC时指定 storageClassName: object-storage ，挂载到 /data 。
  • 关键参数： 
    # Kubernetes Pod spec关键字段
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
  containers:
  - name: trainer
    env:
    - name: NCCL_IB_DISABLE
      value: "0"
    - name: NCCL_NET_GDR_LEVEL
      value: "2"

独家经验 ：CoreWeave的 object-storage PVC底层是Ceph，但通过 rbd 驱动暴露，实测随机IO性能优于S3 FUSE。我们用 fio --name=randread --ioengine=libaio --rw=randread --bs=4k --size=1G --runtime=60 测得IOPS达12.4K，而S3 FUSE仅1.8K。

3.8 Vultr

核心优势 ：全球17个机房，东京/新加坡节点对亚太用户延迟极低，支持裸金属GPU服务器。
实操配置 ：

  • 实例选择： vultr-gpu-a100-80gb （裸金属，8卡），避免虚拟化层开销。
  • 存储方案： 本地NVMe + rclone sync 。Vultr裸金属默认2×1.92TB NVMe，用 xfs_mkfs -f /dev/nvme0n1 格式化。
  • 关键参数： 
    # Vultr网络优化
# 调整TCP缓冲区（东京节点实测有效）
echo 'net.core.rmem_max = 16777216' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 16777216' >> /etc/sysctl.conf
sysctl -p

注意事项 ：Vultr的A100裸金属需手动安装NVIDIA驱动（ wget https://us.download.nvidia.com/tesla/525.85.12/NVIDIA-Linux-x86_64-525.85.12.run ），且必须禁用nouveau： echo "blacklist nouveau" >> /etc/modprobe.d/blacklist-nouveau.conf 。

3.9 Paperspace Gradient

核心优势 ：Notebook-first体验，内置JupyterLab+VS Code Server，支持一键克隆GitHub仓库+自动安装requirements.txt。
实操配置 ：

  • 实例选择： P5000 （单卡，POC用）或 A100-80GB （8卡，训练用）。
  • 存储方案： Gradient Storage + GitHub Sync 。上传数据到Gradient Storage后，用 git clone 拉取代码， pip install -r requirements.txt 自动解析。
  • 关键参数： 
    # Gradient特有API调用
from gradient import Jobs
job = Jobs.create(
    name="llm-finetune",
    machine_type="A100-80GB",
    command="deepspeed train.py --deepspeed ds_config.json",
    container="ghcr.io/myorg/llm-train:latest",
    workspace_url="https://github.com/myorg/llm-code.git"
)

实测痛点 ：Gradient Storage的API限流严格（100 req/min），批量上传10万个小文件会触发429错误。解决方案：先用 tar -cf data.tar data/ 打包，再上传单个tar包，训练时 tar -xf data.tar 解压。

3.10 Oracle Cloud Infrastructure (OCI)

核心优势 ：BM.GPU.A100.8裸金属实例，无虚拟化损耗，且OCI对象存储（OCI Object Storage）与GPU实例同Region时延迟<1ms。
实操配置 ：

  • 实例选择： BM.GPU.A100.8 （8×A100-40GB裸金属）。
  • 存储方案： OCI Object Storage + OCI CLI mount 。用 oci os object bulk-upload 上传数据，挂载用 oci-objectstorage-fuse 。
  • 关键参数： 
    # OCI特有优化
# 禁用CPU频率调节（避免训练中频率波动）
echo 'performance' > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
# OCI Object Storage FUSE需指定region
oci-objectstorage-fuse -b my-bucket -r us-ashburn-ad-1 /mnt/oci

避坑指南 ：OCI的A100实例必须在特定AD（Availability Domain）购买，如 us-ashburn-ad-1 ，跨AD无法访问同Region对象存储。创建实例前务必确认AD与Bucket所在AD一致。

3.11 Alibaba Cloud (Alibaba Cloud ECS)

核心优势 ：国内合规性强，支持等保三级，PAI平台对中文LLM微调有预置模板。
实操配置 ：

  • 实例选择： ecs.gn7i-c32g1.8xlarge （8×A100-40GB）或 ecs.gn7e-c12g1.16xlarge （16×A100-40GB）。
  • 存储方案： NAS Performance + OSS 。NAS选 Capacity=5TB ， Throughput=150MB/s ，OSS启用 Archive 归档层存历史检查点。
  • 关键参数： 
    # 阿里云特有优化
# 解决OSS FUSE在高并发下卡死
ossfs my-bucket /mnt/oss -ourl=https://oss-cn-hangzhou.aliyuncs.com -o allow_other -o uid=1001 -o gid=1001 -o multireq_max=5
# PAI平台需指定镜像registry
export ALIBABA_CLOUD_REGISTRY="registry.cn-hangzhou.aliyuncs.com"

合规提醒 ：国内项目必须开启OSS服务端加密（SSE-KMS），且KMS密钥需绑定RAM角色，否则PAI训练任务无法读取加密OSS数据。

3.12 Tencent Cloud (Tencent Cloud CVM)

核心优势 ：广州/上海节点对国内用户友好，TI-ONE平台集成Hugging Face Hub，支持一键加载model card。
实操配置 ：

  • 实例选择： GN10X.8XLARGE48 （8×A100-40GB）。
  • 存储方案： CBS Cloud Block Storage + COS 。CBS选 Performance 类型， Throughput=250MB/s ；COS启用 Intelligent Tiering 。
  • 关键参数： 
    # 腾讯云特有优化
# 解决COS FUSE在长连接下超时
cosfs my-bucket /mnt/cos -ourl=https://cos.ap-guangzhou.myqcloud.com -o allow_other -o mp_umask=000 -o multipart_copy_num=5
# TI-ONE需指定CVM安全组放通COS端口
ufw allow from 100.64.0.0/10 to any port 443

实测数据 ：CBS Performance在8卡并发读下，IOPS稳定在18K，延迟<1ms，远超本地SSD。

3.13 Scaleway

核心优势 ：欧洲GDPR合规首选，ARM64 + NVIDIA Grace Hopper Superchip（GH200）实例已上线，适合能效敏感场景。
实操配置 ：

  • 实例选择： GP1-XL （8×A100-40GB）或 GH200 （1×GH200，72核ARM+96GB HBM3）。
  • 存储方案： Scaleway Object Storage + S3cmd 。用 s3cmd put --recursive data/ s3://my-bucket/data/ 上传。
  • 关键参数： 
    # GH200特有优化
export CUDA_VISIBLE_DEVICES=0
export TORCH_CUDA_ARCH_LIST="90"
# 启用Hopper特性
export NV_HOPPER=1

独家提示 ：GH200的HBM3带宽达2TB/s，但需用 nvidia-smi -q -d MEMORY 确认 FB Memory Usage 是否达96GB，若仅显示48GB，说明未启用HBM3模式，需重装驱动（ nvidia-driver-535-server ）。

3.14 Linode

核心优势 ：价格最低的A100云（$0.99/hr），适合预算有限的学术研究。
实操配置 ：

  • 实例选择： g1-highgpu-8 （8×A100-40GB）。
  • 存储方案： Linode Block Storage + Rclone 。Block Storage选 Size=2TB ， Region=us-mia 。
  • 关键参数： 
    # Linode网络优化（Miami节点）
echo 'net.ipv4.tcp_congestion_control = bbr' >> /etc/sysctl.conf
sysctl -p
# Rclone需设timeout避免断连
rclone copy /workspace/data remote:bucket/data --timeout 300s --retries 3

风险提示 ：Linode A100库存紧张，常需排队数小时。建议提前创建 g1-highgpu-1 （1卡）实例占位，再升级为8卡。

3.15 DigitalOcean

核心优势 ：界面最简洁，Droplet创建30秒完成，适合快速验证。
实操配置 ：

  • 实例选择： gpu-8vcpu-64gb （1×A100-40GB，目前仅单卡）。
  • 存储方案： DigitalOcean Block Storage + S3-compatible API 。Block Storage挂载为 /mnt/do 。
  • 关键参数： 
    # DigitalOcean特有
# 禁用swap（DO默认启用swap，影响GPU显存分配）
swapoff -a
sed -i '/swap/d' /etc/fstab
# 使用DO Spaces（S3兼容）需指定endpoint
export AWS_ENDPOINT_URL="https://nyc3.digitaloceanspaces.com"

适用场景 ：仅推荐用于单卡QLoRA微调（如Phi-3、TinyLlama），或多卡训练的前期数据清洗/Tokenization阶段。全量训请勿选用。

4. 绕不开的“第六要素”：如何用一张表锁定最适合你的云厂商？

光看单点参数还不够。真实决策中，我们用一张 四维决策矩阵表 快速收敛。这张表不是静态对比，而是根据你的项目当前阶段动态加权：

维度 权重（POC阶段） 权重（生产训阶段） 关键指标 我们怎么测
GPU资源确定性 30% 25% 库存可用率、Spot中断率、实例启动成功率 每日10:00 AM调用API查 describe-instances ，连续7天统计
IO吞吐稳定性 25% 35% FSx/NAS/PVC的fio随机读IOPS、S3 list延迟P95 fio --name=randread --ioengine=libaio --rw=randread --bs=4k --size=1G --runtime=60 + time aws s3 ls s3://bucket/ --recursive | wc -l
框架栈成熟度 20% 20% PyTorch/CUDA/DeepSpeed版本兼容性、HF Trainer开箱即用度 拉取官方镜像，运行 python -c "import torch; print(torch.__version__)" + deepspeed --version + python -c "from transformers import Trainer; print('OK')"
运维负担 15% 15% 自动扩缩容响应时间、日志检索延迟、GPU监控粒度 创建10个实例，模拟突发负载，测AutoScaling Group从0→10实例时间；用CloudWatch/Loki查 nvidia_smi_utilization_gpu 指标延迟

实操案例 ：某金融客户要做风控大模型微调，POC阶段权重设为GPU确定性30%、IO吞吐25%、框架栈20%、运维15%。我们测得：

  • AWS p4d：GPU确定性98.2%，IO吞吐1.8GB/s，框架栈满分，运维延迟<2s → 加权分=92.1
  • Azure NDv4：GPU确定性95.7%，IO吞吐1.2GB/s，框架栈90分（AML需额外配置），运维延迟3.5s → 加权分=87.3
  • Lambda：GPU确定性99.5%，IO吞吐6.2GB/s，框架栈85分（需自建镜像），运维延迟5s → 加权分=91.8

最终选AWS，因为其框架栈满分+运维延迟最低，对客户“快速验证业务效果”的POC目标最匹配。而Lambda虽IO最强，但客户团队无Docker经验，自建镜像会拖慢POC进度。

5. 常见问题与排查技巧实录：那些文档里不会写的真相

5.1 “明明配置了8卡，为什么nvidia-smi只显示4个GPU？”

现象 ：在p4d.24xlarge上执行 nvidia-smi -L ，只输出4行，但 nvidia-smi -q 显示8个GPU的温度/功耗。
根因 ：AWS的p4d实例使用NVIDIA MIG（Multi-Instance GPU）技术，默认将8卡A100切分为16个MIG实例（每个2g.10gb）。 nvidia-smi 默认只显示MIG实例，而非物理GPU。
解决 ： 

# 查看物理GPU
nvidia-smi -L | grep "Physical"
# 禁用MIG（需root）
sudo nvidia-smi -mig 0
# 重启nvidia-persistenced
sudo systemctl restart nvidia-persistenced

提示：禁用MIG后，必须重启实例才能生效。且MIG禁用后，无法再启用，除非重装驱动。

5.2 “Deepspeed训练中，loss突然飙到inf，但GPU显存没满”

现象 ：训练到第1200步，loss从2.1跳到inf， nvidia-smi 显示显存占用仅65%， dmesg 无OOM日志。
根因 ：梯度爆炸（Gradient Explosion）导致FP16 underflow，但Deepspeed的 fp16.initial_scale_power 设置过小（默认12），动态缩放跟不上。
解决 ： 

{
  "fp16": {
    "enabled": true,
    "initial_scale_power": 16,  // 从12提升到16
    "loss_scale_window": 1000,
    "hysteresis": 2,
    "min_loss_scale": 1
  }
}

注意： initial_scale_power=16 对应初始scale=2^16=65536，比默认值大16倍，能更好应对初期梯度突增。

5.3 “S3数据加载慢，但fio测速很快，为什么？”

现象 ： fio 测NVMe达3GB/s，但 datasets.load_dataset("json", data_files="s3://bucket/data.jsonl") 加载10GB数据耗时47分钟。
根因 ：Hugging Face Datasets默认用 botocore 的 StreamingBody ，每次read()只取128KB，且S3 ListObjects操作在数据集分片时高频触发。
解决 ： 

from datasets import load_dataset
# 方案1：预下载到本地再加载（适合<100GB）
!aws s3 cp s3://bucket/data.jsonl /tmp/data.jsonl
dataset = load_dataset("json", data_files="/tmp/data.jsonl")

# 方案2：用S3 Select加速（需JSONL每行一个JSON）
response = s3.select_object_content(
    Bucket='bucket',
    Key='data.jsonl',
    ExpressionType='SQL',
    Expression="SELECT * FROM S3Object[*] WHERE s._id > '1000'",
    InputSerialization={'JSON': {'Type': 'LINES'}},
    OutputSerialization={'JSON': {}}
)

5.4 “多卡训练时，rank=0正常，其他rank卡在init_process_group”

现象 ： torch.distributed.init_process_group(backend='nccl') 在rank=1~7卡住，rank=0正常。
根因 ：NCCL初始化时，所有rank需互相握手，若某rank的防火墙未开放 29500 端口（NCCL默认端口

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

基于大数据+Hadoop+深度学习的淘宝用户购物可视化与行为预测系统设计与开发

avatar 亚马逊云科技技术品牌专区
cover

基于大数据爬虫+Hadoop+深度学习的旅游推荐系统设计与开发

avatar 亚马逊云科技技术品牌专区

学Linux选学校：一线城市还是老家？

而二线城市很多机构的老师，自己都没进过大厂，技术停留在五年前的水平，甚至对着PPT照本宣科。而二线机构缺乏企业合作资源，项目案例永远是“搭建博客系统”“配置个LAMP环境”——这些在现在的云计算岗位面试中，连初筛都过不了。在一线城市学习，你接触的同学、老师、企业内推资源，都是二线城市没法比的。而老家机构的学员，最好的结果也就是去本地小公司做网管，月薪五六千，天花板肉眼可见。在IT培训这行干了快十年

avatar 亚马逊云科技技术品牌专区