面向 LLM 的 Linux 服务器检查清单
- 形成摸清 Linux 服务器的基本思路。
- 判断服务器是否支持 LLM 部署或训练,以及可能的瓶颈。
拿到一台新的 Linux 服务器后,第一件事通常不是立刻部署模型,而是先摸清这台机器的基本情况。
检查思路:
- 先看这台机器有什么资源
- 再看这些资源能不能支撑 LLM 部署或训练
- 最后判断哪里可能成为瓶颈
1. 为什么要先摸清服务器
同样一台“8 卡机器”,实际可用性可能差很多。
差异通常不只在 GPU 型号,还在这些地方:
- CPU 核数够不够
- 内存和 swap 是否正常
- GPU 驱动、CUDA 是否可用
- 磁盘空间是否足够放模型和数据
- 网络能不能支撑模型下载、分布式训练或服务访问
如果不了解服务器的这些基础信息,后面很容易遇到几类问题:
- 模型还没启动就 OOM
- 训练速度很慢,但一时看不出瓶颈在哪
- 多卡看起来都在工作,实际通信效率很差
- 服务能跑,但吞吐、延迟和稳定性都不达标
所以更实际的做法是:先用几条命令把机器轮廓摸清,再决定下一步。
2. 基本检查清单
基本检查围绕 系统基础信息 / GPU / 内存 / GPU / 存储 / 网络 这6方面来展开:
2.1 系统基础信息
这部分容易被忽略,但很实用。
常用的命令有:
uname -a # 查看内核、架构和系统基本信息
cat /etc/os-release # 查看操作系统发行版信息
hostnamectl # 查看主机名及系统版本等主机信息
date # 查看当前系统时间和时区
这几条命令能让我们看到当前 操作系统的内核、发行版本、架构、系统时间和时区 等,方便我们把握后续安装驱动、CUDA、Docker 等时是否有兼容性风险。
2.2 CPU
常用命令有:
lscpu # 查看 CPU 架构、核心数和处理器详细信息
nproc # 查看系统可用 CPU 逻辑核心数量
cat /proc/cpuinfo | grep "model name" | head -1 # 查看 CPU 型号名称
uptime # 查看系统运行时长及平均负载
top # 实时查看 CPU、内存和进程资源占用情况
numactl -H # NUMA 拓扑
通过这几条命令能了解关于 CPU 的下面几方面信息:
- CPU 架构、型号
- CPU 核心数、线性数
- NUMA 拓扑
- 当前运行的负载和资源占用情况
实践中需要关注两件事:
- 核数够不够支撑数据处理、tokenization、日志和推理服务调度
- 是否有 NUMA,避免后面多卡训练时踩到跨 NUMA 的性能坑
2.3 内存
常用命令:
free -h # 查看系统内存与 Swap 使用情况(人类可读单位)
cat /proc/meminfo | head # 查看内核提供的前几项内存详细信息
vmstat 1 5 # 每秒采样一次,共输出 5 次系统内存、IO、CPU 等运行状态
这几条命令看的是:
- 总内存、可用内存、Swap
- 内存压力是否异常
实践上最先关注:
- 内存是不是明显偏小
- swap 是否已经被大量使用
2.4 GPU
常用命令:
# Nvidia
lspci | grep -i nvidia # 查看系统是否识别到 nvidia PCIe 设备
nvidia-smi # 查看 NVIDIA GPU 使用率、显存、温度和进程信息
nvidia-smi -L # 列出所有 NVIDIA GPU 设备及型号编号
nvidia-smi topo -m # 查看 GPU 间 NVLink / PCIe / NUMA 拓扑关系
watch -n 1 nvidia-smi # 每秒刷新一次 GPU 实时状态
# Ascend
lspci | grep -i ascend # 查看系统是否识别到 Ascend PCIe 设备
ls /dev/davinci* # 查看 Ascend 设备节点是否正常创建
npu-smi info # 查看 Ascend NPU 使用率、HBM、温度和设备状态
npu-smi info -l # 列出所有 Ascend NPU 设备及编号信息
hccn_tool -i 0 -hilink_info -t 0 # 查看 Ascend NPU 之间的拓扑连接关系(如支持)
watch -n 1 npu-smi info # 每秒刷新一次 NPU 实时状态
这些命令告诉我们的是:
- GPU 型号、数量
- 显存
- 驱动版本
- CUDA 版本
- GPU 利用率、显存占用、温度
- 多卡互联/通信信息
对 LLM 来说,GPU 是最关键的一层,我们最关注的是这几个问题:
- 这是消费级卡还是数据中心卡
- 单卡显存有多大
- 多卡之间有没有 NVLink 或更好的互联
- 驱动和 CUDA 能不能支撑后续框架
2.5 磁盘和存储
常用命令:
lsblk # 查看磁盘及分区设备结构信息
df -h # 查看各挂载点磁盘空间使用情况(人类可读单位)
mount | head -20 # 查看前 20 条已挂载文件系统信息
du -sh /var/log # 查看 /var/log 目录总占用空间
du -sh /path/to/model # 查看模型目录总占用空间
这里看的有:
- 总容量
- 剩余空间
- 挂载点
- 盘类型
- 数据盘和系统盘是否分开
实践上常见问题不是“没盘”,而是:
- 模型权重放得下,但数据集和缓存放不下
- checkpoint 写盘太慢
- 系统盘被日志或缓存打满
如果要做训练,存储性能通常比“总容量”更重要。
2.6 网络
常用命令:
ip addr # 查看本机网卡接口、IP 地址和链路状态
ip route # 查看系统路由表与默认网关配置
ping -c 4 8.8.8.8 # 连续发送 4 次 ICMP 请求测试外网连通性
ss -tulpen # 查看当前监听中的 TCP/UDP 端口及对应进程信息
ethtool <网卡名> # 查看指定网卡速率、双工模式和驱动链路信息
这里要看的是:
- 网卡信息
- IP 地址
- 默认路由
- 连通性
- 监听端口
实践上主要关注:
- 能不能访问外网下载模型和依赖
- 服务监听端口是否正确
- 多机时网络是否稳定
如果是单机部署,网络问题更多影响模型下载和 API 服务访问。
如果是多机训练,网络质量会直接影响训练效率。
3. LLM 部署和训练时的重点关注
同样是检查服务器,做 LLM 部署和做训练,关注的重点不完全一样。
3.1 LLM 部署
如果是做 LLM 部署,要优先关注:
- GPU 显存是否放得下模型权重,上下文长度和并发下,KV Cache 会不会成为瓶颈
- 推理框架和驱动、CUDA 是否兼容
- 磁盘是否够放模型、量化版本和缓存
- CPU 和内存是否够支撑 tokenizer、前后处理和服务调度
一个很实用的判断方法是:
- 先看模型权重能不能放下
- 再看长上下文和并发时 KV Cache 会不会把显存吃满
- 最后再看吞吐和延迟
很多时候,部署失败不是因为“模型太大”,而是因为低估了 KV Cache 和运行时开销。
3.2 LLM 训练
如果是做 LLM 训练,要优先关注:
- GPU 型号、显存、卡数
- 多卡互联方式
- CPU 核数和内存是否够数据加载
- 磁盘吞吐是否够数据集和 checkpoint
- 多机网络是否足够稳定
训练场景下,下面这些问题尤其常见:
- GPU 很强,但 CPU 太弱,数据加载跟不上
- 显存够,但卡间通信差,扩展效率低
- checkpoint 频繁写盘,结果被磁盘拖慢
- 多机网络抖动,导致训练不稳定
所以训练时不要只盯着 GPU,还要一起看 CPU、内存、存储和网络。
4. 推荐实践
如果你刚拿到一台机器,可以先按下面顺序过一遍:
uname -a、cat /etc/os-release看系统版本lscpu、free -h看 CPU 和内存nvidia-smi、nvidia-smi topo -m看 GPU 和拓扑lsblk、df -h看磁盘和挂载ip addr、ip route、ss -tulpen看网络top或htop看当前负载
通常这几条命令获得的信息,通常就能判断:
- 这台机器更适合推理还是训练
- 主要瓶颈可能在哪
- 下一步应该先装环境、先压测,还是先换机器