谈国平在趋动云这种GPU算力平台，或者一些超算中心对外提供的计算资源上跑模型，我落地后的第一件事从来不是急着跑训练脚本，而是先找高速硬盘、再测一遍速。为什么？因为被坑过太多次了——显卡是A100/H100，显存带宽几百GB每秒，结果一个7B模型从磁盘加载到显存花了七八分钟，整个环节里显卡一直在旁边干等，问题根本不在算力，而在存储。
这篇文章我会把整套思路捋一遍：怎么判断模型文件当前放在什么盘上、怎么找到平台里真正的高速盘、用什么命令测速才靠谱、以及迁完模型之后哪些配置必须跟着改。无论是自己租GPU云服务器，还是在算力平台上跑开源模型，这套方法都通用。
1. 模型加载慢，先别怪显卡：存储在背后拖后腿
1.1 云服务器里的存储层级比你想象的多
大多数人刚拿到云服务器时，只会用df -h扫一眼，看到有几个目录就完事了。但云服务器和物理机不一样，同一台机器上可能存在好几类存储，性能差距可以达到几十倍：
- 系统盘：装操作系统、系统依赖用的，容量通常不大，性能中等。
- 数据盘：平台给你挂载的一块独立云盘，一般是SSD或NVMe级别，这是大多数人应该放模型的首选。
- 共享存储/网络文件系统：很多算力平台和超算中心会挂载一个大型并行文件系统（Lustre、BeeGFS这类），路径看起来像本地目录，实际数据散落在集群后端。这类存储容量大、总体带宽高，但单节点访问时的延迟和吞吐受网络和元数据服务器影响。
- 内存盘（tmpfs）：部分平台的
/tmp其实是内存文件系统，速度飞快，但重启即失，容量也受内存限制。
模型加载慢，通常不是某一项指标不行，而是你根本不知道当前路径对应哪一类存储。比如你在容器里看到/workspace，以为它是本地高速盘，实际上底层可能是网络存储，读一个12GB的模型文件时，每一块数据都要跨网络拉回来，速度自然上不去。
1.2 容器镜像层的"写时复制"陷阱
这里必须多说一句。很多GPU云服务器是通过容器交付的，你的模型文件如果放在工作目录里，可能并没有真正写到底层磁盘，而是落在容器镜像的可写层上。容器镜像采用写时复制机制：读取时要逐层查找文件块，写入时还要做一层复制映射，对于动辄几十GB的模型文件，这种间接寻址的开销会被放大。即使底层是NVMe，经过这层包装之后，实际性能也可能打折。
所以，判断模型慢不慢，不能只看文件系统里显示的速度，还要弄清楚模型文件是不是在"裸奔的高速盘"上。这个判断方法，下一节直接给你命令。
1.3 先记住一个判断原则
你只需要记住一条指导原则：模型文件要尽量放在块存储（云盘/NVMe数据盘）或高性能并行文件系统上，避免放在系统盘、镜像可写层、以及任何压缩过或加密过的挂载路径里。至于怎么识别这些路径，看下去就有答案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 在算力平台上"按图索骥"：定位高速盘的三种实用手段
2.1 第一步：先看挂载点和容量分布
登录机器后，先跑一条命令看看全貌：
bash复制df -h | grep -vE "tmpfs|udev|overlay"
输出里会列出所有挂载点、容量和使用率。正常情况下，你会看到这样几类路径：根目录/、数据盘挂载目录（比如/data、/workspace、/mnt之类）、以及可能的共享存储目录（比如/public、/group_homes）。
容量本身不能直接说明速度，但能给你线索：如果某个目录容量有几百GB到几TB，大概率是专门给你放数据的盘；如果只有30GB到50GB，那多半是系统盘。模型文件动辄几十GB，系统盘能放下，但速度和重启持久性都不适合。
接着用lsblk看底层块设备：
bash复制lsblk -o NAME,ROTA,SIZE,TYPE,MOUNTPOINT
ROTA列很关键：值为1表示机械盘，0表示SSD或NVMe。只要看到0，说明这块盘的底层介质是闪存。但注意，云盘可能是网络块存储（如分布式块存储），即使显示ROTA=0，单盘性能也受平台限制，所以lsblk只是第一步，不能替代测速。
2.2 第二步：识别那种"伪装成本地盘"的网络存储
在趋动云、超算中心这类环境里，经常会有NFS、Lustre等网络文件系统挂载在某个目录。用mount命令看挂着什么类型：
bash复制mount | grep -E "nfs|lustre|beegfs|gpfs|glusterfs|ceph"
如果看到这些关键字，说明这个目录是网络存储。网络存储不一定慢——高性能并行文件系统的聚合带宽可能比单块NVMe还猛——但它的性能特征和本地盘完全不同：大文件流式读取可能很快，而大量小文件、目录遍历、stat这些元数据操作会慢得离谱。模型目录里通常是大文件（几个GB的权重），所以单纯看大文件读取，网络存储也能接受，但如果你的模型由几千个碎片文件组成，性能就会很难看。
再看一个指标，确认底层是不是NVMe：
bash复制cat /sys/block/nvme0n1/queue/rota
nvme0n1换成实际设备名（lsblk能看到）。输出0就是SSD/NVMe，1就是机械盘。这个方法对直通的NVMe盘很准，但对云盘虚拟化场景，结果仅供参考。
2.3 第三步：用延迟感知"哪块盘是高速盘"
命令看半天，不如亲手摸一下。在几个候选目录里各建一个小文件，测试创建和删除的耗时：
bash复制time touch /data/test_latency && rm -f /data/test_latency
time touch /workspace/test_latency && rm -f /workspace/test_latency
time touch /public/test_latency && rm -f /public/test_latency
time输出的real时间如果动辄几百毫秒甚至几秒，说明这个目录的元数据操作很重，通常是网络存储或者共享目录。本地NVMe盘上，一次touch+rm一般在一毫秒左右。这个测试不需要安装任何额外工具，是快速排除慢目录的好办法。
做完这三步，你基本能画出一张"候选路径地图"：哪些目录可能快，哪些目录一定慢。接下来就用实测数据来拍板。
3. 测速不是随便dd一下：命令、参数与结果解读
3.1 dd测速：最暴力也最容易踩坑的方式
很多人测速就是一条dd if=/dev/zero of=/data/test bs=1G count=1，然后看到速度很高就高兴了。但实际上这个测试结果非常不可信——写出来的数据先进了page cache，操作系统还没来得及真正落盘，命令就结束了，测到的是内存写入速度，不是磁盘写入速度。
正确的写测速要绕过缓存，用oflag=direct和conv=fdatasync：
bash复制dd if=/dev/zero of=/data/speed_test bs=1M count=2048 oflag=direct conv=fdatasync
iflag/oflag=direct：直接I/O，跳过page cache。conv=fdatasync：确保写入完成后才统计时间。
这条命令会写入2GB数据（bs=1M * count=2048）。执行完后会输出写入速度，比如2147483648 bytes (2.1 GB, 2.0 GiB) copied, 0.813317 s, 2.6 GB/s。
读测速同理，要加iflag=direct：
bash复制dd if=/data/speed_test of=/dev/null bs=1M count=2048 iflag=direct
测完记得删掉测试文件：
bash复制rm -f /data/speed_test
读测速还有个额外情况：如果文件在page cache里，即使加了iflag=direct，部分内核版本仍可能命中缓存。最稳妥的做法是测速前清一次缓存，但在共享服务器上通常没有root权限，echo 3 > /proc/sys/vm/drop_caches大概率被拒绝。退而求其次，测试文件用比内存还大的体积（比如4GB），或者干脆多测几次看稳定性。
3.2 用fio做一次正经的基准测试
dd只能给出顺序大块读写的粗略数据，模型加载时实际发生的IO模式更复杂：既有权重的顺序读取，也有配置文件的随机小读取，还有临时文件写入。专业一点的测速我会用fio，它是存储基准测试的行业标准。
先确认fio装了没有：
bash复制which fio || sudo apt install -y fio || sudo yum install -y fio
然后按顺序跑四组测试，分别覆盖顺序写、顺序读、随机写、随机读：
bash复制# 顺序写
fio --name=seqwrite --filename=/data/fio_test --size=4G --rw=write --bs=1M --direct=1 --ioengine=libaio --iodepth=32 --group_reporting --runtime=30 --time_based
# 顺序读
fio --name=seqread --filename=/data/fio_test --size=4G --rw=read --bs=1M --direct=1 --ioengine=libaio --iodepth=32 --group_reporting --runtime=30 --time_based
# 随机写 4K
fio --name=randwrite --filename=/data/fio_test --size=1G --rw=randwrite --bs=4k --direct=1 --ioengine=libaio --iodepth=32 --group_reporting --runtime=30 --time_based
# 随机读 4K
fio --name=randread --filename=/data/fio_test --size=1G --rw=randread --bs=4k --direct=1 --ioengine=libaio --iodepth=32 --group_reporting --runtime=30 --time_based
参数说明：--direct=1绕过缓存，--ioengine=libaio使用Linux原生异步IO，--iodepth=32模拟并发请求，--group_reporting汇总所有线程结果。每组测试执行30秒后自动停止，不会一直占着磁盘。
fio输出里的关键指标：
BW=：吞吐带宽，大文件顺序读写看这个。IOPS=：每秒IO次数，随机小文件读写看这个。clat、lat：请求延迟，模型训练checkpoint频繁写入时会很敏感。
3.3 多大的数字才算"高速硬盘"
拿到结果后，怎么判断合格？我整理了常见存储的参考区间，供你在云服务器上横向对比：
| 存储类型 | 顺序读 | 随机读4K | 适用性 |
|---|---|---|---|
| 机械盘 HDD | 150-200 MB/s | 1-2 MB/s | 不推荐放模型 |
| SATA SSD | 500-550 MB/s | 20-40 MB/s | 小模型勉强可用 |
| NVMe SSD | 1500-3500 MB/s | 150-300 MB/s | 推荐 |
| 共享并行文件系统 | 500-3000 MB/s（波动大） | 波动极大 | 大文件可接受 |
| 内存盘 tmpfs | 5000 MB/s+ | 5000 MB/s+ | 非常推荐但易失 |
对于加载7B或13B的模型，我个人的建议是顺序读至少要有1GB/s以上，这样一个7GB的权重文件大约7秒左右能读完。如果低于300MB/s，即使显存再大，加载阶段也会成为明显的瓶颈。
3.4 别忽略另一个关键指标：延迟
带宽高不代表不卡。如果你经常做小模型的多次快速load/unload测试，或者在意几百毫秒级别的响应，延迟比带宽更关键。可以用ioping测一下IO延迟：
bash复制ioping -c 10 -i 0.1 /data/
每条请求的延迟数值如果小于1ms，那是非常健康的本地存储；如果去到了几十毫秒，基本能确定是网络盘或者是负载很重的共享存储。模型小文件散落时，这种延迟会被放大，导致加载慢的问题更明显。
4. 把模型迁到高速盘：拷贝、软链与缓存目录配置
4.1 迁移模型文件：优先rsync，不要用cp
确定了高速盘路径后，接下来就是把模型文件从慢目录搬到快目录。很多人第一反应是cp -r，但大文件拷贝时cp没有断点续传、没有校验，拷完也不知道有没有缺文件。我更推荐rsync，它在大量文件场景下也更快：
bash复制# 把模型从慢路径迁到高速盘
rsync -av --progress --partial /slow_path/your_model/ /data/your_model/
# 迁移完成后校验主目录大小是否一致
du -sh /slow_path/your_model/ /data/your_model/
--partial允许中断后继续，--progress能看到实时进度。如果模型文件里有大量碎图片、tokenizer的词典、JSON配置，rsync可以多线程加速，用--itemize-changes查看哪些文件占用了头部时间。
拷贝期间建议开个screen或tmux会话，几百GB的模型搬运耗时可能很长，断开会话不值得。
4.2 用软链接让原路径无缝指向高速盘
模型文件搬走后，很多旧脚本里写死的路径都指向原目录，一个一个去改太麻烦。更优雅的做法是软链接：
bash复制# 迁移完成后，把原目录删掉，再创建软链接指向新位置
rm -rf /slow_path/your_model
ln -s /data/your_model /slow_path/your_model
这样任何原来读取/slow_path/your_model的代码，都会自动落到/data/your_model上。但注意一个前提：软链接本身会占用一份路径映射，如果容器重启后/data的挂载没恢复，软链接会变成断链。所以创建后要立刻验证：
bash复制ls -l /slow_path/your_model
# 如果结尾显示指向 /data/your_model 而不是 "No such file or directory"，说明链接有效
4.3 框架级缓存目录必须跟着改
模型加载慢，很多时候不是因为权重文件在慢盘，而是因为框架默认把缓存下到了慢盘。以HuggingFace生态为例，默认缓存目录是~/.cache/huggingface，如果~所在分区是系统盘或共享盘，模型第一次下载和后续加载都会卡在那里。
建议把这几个环境变量统一设置到高速盘：
bash复制export HF_HOME=/data/highspeed_hf
export HF_HUB_CACHE=/data/highspeed_hf/hub
export TRANSFORMERS_CACHE=/data/highspeed_hf
export HUGGINGFACE_HUB_CACHE=/data/highspeed_hf/hub
可以写进~/.bashrc或启动脚本里，避免每次重启后失效。
其他几个常见框架对应关系：
| 框架 | 环境变量/配置 | 说明 |
|---|---|---|
| Ollama | OLLAMA_MODELS=/data/ollama/models |
管理本地模型存储位置 |
| vLLM | 启动时传入模型绝对路径 | 用高速盘上的权重路径即可 |
| ComfyUI | 修改extra_model_paths.yaml或软链models/checkpoints |
Stable Diffusion类模型适用 |
| DeepSpeed | --checkpoint_dir或配置里的save_dir |
训练中断/恢复会频繁访问 |
改完环境变量后，记得echo $HF_HOME验证，再跑一个加载测试。
4.4 一个更容易被忽略的目录：临时文件
模型加载过程中会产生不少临时文件：tokenizer缓存、编译缓存、反量化临时文件。很多框架默认把临时目录放在/tmp，如果/tmp也是慢盘或容量很小，会在加载中段突然卡住。
可以用export TMPDIR=/data/tmp把临时目录导向高速盘，并提前创建目录：
bash复制mkdir -p /data/tmp
export TMPDIR=/data/tmp
不过要评估一下：如果/tmp是tmpfs内存盘，速度比NVMe还快，那就不用改；如果/tmp是网络存储或者已经快满了，改到数据盘很必要。
5. 实测中必须绕开的几个坑，外加一点提速心得
5.1 坑一：dd测速时没绕过缓存，数字"虚胖"
我见过最典型的案例：有人在某平台的共享目录上，用普通dd测出1.2GB/s的"高速"，于是把所有模型都放了过去，结果实际加载模型时依然慢到爆。原因就是共享存储的元数据写入由后端缓存加速，但模型加载这种大量小请求的读操作，会被网络和元数据服务器的处理能力拖住。
所以测速一定要用direct=1或oflag=direct，且不能只在空闲时段测一次，建议挑一个平台繁忙时段再测一次，看波动幅度。如果两次测速结果差了三倍以上，那这块盘的稳定性不适合做模型仓库。
5.2 坑二：容器重启后软链失效，脚本全部报错
在算力平台上，容器重启后数据盘的挂载点位可能会变。比如上次启动时/data挂载正常，这次启动后平台只自动挂了/workspace，你辛辛苦苦建的软链接就全部指向了不存在的路径。
我的应对措施是写一个启动脚本，在每次会话开始时自动检测并重建链接：
bash复制#!/usr/bin/env bash
# fix_model_links.sh
RSYNC_SOURCE=${RSYNC_SOURCE:-/workspace/models}
HIGH_SPEED_DIR=${HIGH_SPEED_DIR:-/data}
if [ -d "$HIGH_SPEED_DIR" ]; then
rm -f /workspace/models
ln -s "$HIGH_SPEED_DIR/models" /workspace/models
echo "link re-created: /workspace/models -> $HIGH_SPEED_DIR/models"
else
echo "high speed dir not mounted, skip link fix"
fi
这个脚本放在启动用户.bashrc最后一行执行，保证每次打开终端都自动恢复。首次迁移时也可以用类似逻辑做增量同步，避免重复拷贝整个模型。
5.3 坑三：小文件碎片风暴，把高速盘也打成慢速盘
有些模型仓库里有大量小文件，比如数据集切片、每个样本的json标注、多个分片权重。即使底层是NVMe，如果一次性读取几千个几KB的文件，性能也会被文件系统的元数据操作拖垮。特别是os.listdir遍历目录、torch.load读取分散权重时，IOPS消耗非常惊人。
解决方案有两个方向。一是打包成大文件：把权重目录用safetensors格式合并为单个或几个大文件，safetensors本身就是为此设计的，读取时只需要连续IO。二是如果模型权重没有safetensors版，可以用tar归档，加载前先解压到高速盘。
需要提醒的是，tar包读取也有代价。如果平台支持直接传递文件夹路径，就不必强行打包，否则每次启动都要解压一遍，反而多花时间。这个策略需要实测对比。
5.4 一次完整对比：同样的模型，慢盘和高盘加载差多少
我实测过一个6.7B模型文件（约13GB），环境是趋动云的GPU实例，显存40GB。模型权重初始在系统盘（SATA SSD级别），后来迁到NVMe数据盘。加载耗时对比：
| 存储位置 | 冷加载耗时 | 备注 |
|---|---|---|
| 系统盘（SATA SSD） | 48秒 | 期间CPU占用不高，磁盘接近饱和 |
| NVMe数据盘 | 6.2秒 | 大幅提升 |
| 内存盘 /dev/shm（实验） | 2.8秒 | 受内存容量限制，不常用 |
从48秒降到6秒，这个差距对交互式调试非常致命。如果反复在改prompt、反复重启推理服务，每次省下40秒，一天就能省很多时间。这也是我坚持"模型一定要放高速盘"的根本原因。
5.5 验证是否真的从高速盘加载
迁移完成后，别急着信time命令。确认加载路径真的指向了高速盘，用lsof看进程打开了哪些文件，或者用strace -f -e trace=openat,stat,read追踪模型加载时的文件访问调用：
bash复制strace -f -e trace=openat python your_load_script.py 2>&1 | grep "your_model" | head -50
如果输出里的路径全部指向/data/your_model，说明加载确实发生在高速盘。如果还有不少访问落在慢目录，说明代码里有路径写死或者缓存配置没改全，需要回头排查。
5.6 一点关于"将模型放高速盘"的全局建议
现在每拿到一台新机器，我都会按固定顺序处理：先看df -h和lsblk，再在候选目录里测速，然后把模型迁到最快的持久盘，最后用find检查一次有没有遗漏的大文件还在慢盘上。这套流程看起来麻烦，但一次性投入半小时，之后每次加载都能省下几分钟，非常划算。
如果平台同时提供对象存储和块存储，还有一个选择：把模型放在对象存储中，启动时按需拉取到本地盘。这种方式适合模型文件大、但使用的频次不高的情况。这里就不展开讲了，核心原则没变：最终喂给框架的路径，必须落在高速盘上。
最后的最后，提醒一句：测速文件记得清理干净，别让几个GB的测试文件占着高速盘的容量。你可以把所有测试用的临时文件名都统一成*_speed_test，退出前一次性删除，干净利落。