算力正在成为 AI 项目建设中最贵的资源从芯片、整机、机房到网络每一笔预算几乎都和 GPU 相关。公开报道中数千亿美元级别资金涌入算力市场的说法已经出现过多次很多企业也在重新评估自建算力中心的成本与收益。但对开发者和运维工程师来说真正要面对的问题往往更具体把一张英伟达 GPU 装进服务器后驱动怎么装、CUDA 版本怎么选、模型推理怎么部署、多个团队怎么共用同一批显卡以及出现问题后从哪里开始排查。这篇文章从工程落地角度切入算力话题围绕英伟达 GPU 搭建一套最小可用的 AI 计算平台。你会看到算力指标如何理解、驱动和容器环境如何安装、一个实际 LLM 推理服务如何跑起来以及算力资源在多团队场景下的共享和排错方式。这套流程适合算法工程师、后端开发、运维工程师也适合正在规划 GPU 基础设施的团队参考。1. 算力不是空泛概念先理解算力如何被度量和消耗算力这个词在项目汇报里经常出现但落到技术层面它必须有明确的度量方式和消耗对象。否则就会出现“采购了很多 GPU但实际能跑什么模型、能支撑多少并发”都说不清楚的情况。1.1 算力的本质从抽象名词到可量化资源算力的通俗含义是计算机执行数值计算的能力。AI 场景里的算力更具体地指向 GPU、TPU 或专用 AI 芯片在单位时间内可以完成多少矩阵运算。训练模型时参数梯度更新需要大量矩阵乘法推理时每一轮 token 生成都要重新计算注意力矩阵。这些运算大量集中在 GPU 的 Tensor Core 或类似专用单元上所以算力不能只看 CPU 主频和核数更要看 GPU 的浮点运算能力、显存容量和显存带宽。实际项目中算力消耗主要分布在三条链路上模型训练CPU 负责数据处理和调度GPU 负责前向传播和反向传播显存承载权重、梯度和优化器状态。模型微调相比完整预训练算力需求低一些但显存优化和并行策略依然是核心问题。模型推理在线服务对延迟和吞吐高度敏感相比训练推理更看重显存容量、算子优化和批处理策略。如果把算力看成“钱”那么 CPU、内存、网络和存储就是帮这笔钱周转的系统。GPU 峰值算力再高数据喂不进去计算单元也只能空转。1.2 算力指标速查TFLOPS、TOPS、显存带宽和 token/s一个常见的误区是只比较 GPU 的“算力数字”忽略精度、稀疏性和实际负载。下面是经常出现的指标指标常见单位说明使用场景FP32TFLOPS单精度浮点计算能力科学计算、部分传统 HPC 负载TF32TFLOPSTensor Core 支持的截断精度训练加速兼顾精度与速度FP16 / BF16TFLOPS半精度浮点计算能力深度学习训练和推理的主流精度INT8TOPS整数运算能力量化推理、边缘设备性能评估显存容量GB模型权重和中间激活能否放得下决定可以运行多大的模型显存带宽GB/s显存读写速度大模型推理时经常成为性能瓶颈token/s个/秒每秒生成 token 数量直接反映用户感知的推理速度需要注意的是厂商宣传的峰值算力通常是最有利状态下的结果例如开启稀疏化、使用 BF16 或 INT8。真实业务中一个 7B 模型在英伟达消费级显卡上推理能跑到多少 token/s取决于量化精度、上下文长度、并发数和引擎优化程度。1.3 为什么 GPU 比 CPU 更适合 AI 负载CPU 的核心数量少单核逻辑复杂擅长分支判断和复杂指令流GPU 则由大量相对简单的计算核心组成适合把一个大矩阵切成多个块并行计算。AI 模型的主要运算是矩阵乘法和卷积运算天然适合 GPU 的并行结构。英伟达在 AI 场景中还叠加了软件栈优势。CUDA 生态经过多年积累PyTorch、TensorFlow、vLLM、TensorRT 等框架都对 CUDA 做了深度优化。这也是很多算力项目先选择英伟达 GPU 的原因之一硬件之外软件生态能让模型更快跑起来也能减少开发团队踩坑成本。2. 从显卡到业务算力平台的软硬件分层在项目推进中最怕把“算力”理解成单纯购买显卡。真正的算力平台是一套分层系统从底层 GPU 到顶层业务服务中间隔着驱动、CUDA、容器运行时、调度系统和推理引擎。任何一层配置不对上层应用都会出现千奇百怪的问题。2.1 一张英伟达 GPU 背后有哪几层软件以一张典型的英伟达数据中心 GPU 为例把它接入业务系统至少需要经过以下层级层级典型组件职责硬件层GPU 板卡、显存、NVLink提供计算单元和显存资源驱动层NVIDIA Linux Driver让操作系统能够识别和控制 GPU用户态运行时CUDA Toolkit、cuDNN、NCCL提供算子库、通信库和开发接口容器运行时NVIDIA Container Toolkit让 Docker 等容器内访问 GPU资源调度层Kubernetes、Slurm、MIG、MPS分配、隔离、排队和管理 GPU推理/训练框架vLLM、PyTorch、TensorRT-LLM执行模型计算和 API 服务业务层应用服务、Agent、RAG 链路调用模型能力完成业务目标实际排错时问题可能出现在任何一层。比如容器内报了 CUDA driver version is insufficient但宿主机的 nvidia-smi 显示驱动正常这个矛盾通常发生在容器运行时或驱动版本匹配层而不是模型代码本身。2.2 容器化是 GPU 算力复用的关键在裸机上直接部署训练环境会遇到一个典型问题一个项目需要 CUDA 11.8另一个项目需要 CUDA 12.1换版本很容易把系统级依赖搞乱掉。容器化之后每个项目自带独立的 CUDA、Python 和依赖库版本互不干扰。容器访问 GPU 的方式并不是默认支持的。Docker 本身无法直接操作 GPU需要通过 NVIDIA Container Toolkit 将宿主机的驱动和 CUDA 运行时挂载进容器。容器内运行的还是宿主机的 GPU 驱动CUDA 用户态库则由镜像自己提供。2.3 从金融杠杆到工程杠杆为什么软件层决定了真实算力报道里常说的“给 AI 装上金融杠杆”更多是资本层面的表达。工程层面同样存在杠杆同样一张 GPU配置得当可以同时服务多个模型实例配置不当可能只有 30% 利用率。软件层就是这种工程杠杆的支点。驱动版本统一能让多容器共存推理引擎开启 continuous batching 能大幅提高吞吐Kubernetes 调度能减少资源碎片。这些优化不需要多花硬件预算却能决定已有 GPU 能承载多少业务这也是为什么本文后面会花大篇幅讲容器、推理服务和资源调度。3. Ubuntu 24.04 下安装英伟达官方驱动的完整流程环境准备是整个算力平台最容易出乱子的阶段。这里以 Ubuntu 24.04 为例讲一条相对稳妥的驱动安装路径。步骤适用于一台刚装好系统、准备作为 GPU 计算节点的服务器也可以是带 NVIDIA GPU 的台式机。3.1 安装前先确认硬件、系统和安全启动状态在下载任何驱动之前先确认三件事GPU 型号是否被识别、系统内核版本、Secure Boot 是否开启。# 查看 PCI 设备中是否有 NVIDIA 显卡 lspci | grep -i nvidia # 查看系统内核版本 uname -r # 查看是否已经安装过 NVIDIA 驱动 nvidia-smi # 查看 Secure Boot 状态 mokutil --sb-state如果nvidia-smi返回command not found说明驱动还没有安装。如果mokutil --sb-state显示SecureBoot enabled那么驱动模块加载时会多一步签名校验后面安装需要配置 MOK 或进入 BIOS 关闭 Secure Boot。生产环境建议保留 Secure Boot 并通过 MOK 导入驱动签名但这个过程在不同主板上差异较大这里先提醒有这一层存在。这个阶段最简单的检查方法是同时执行三行命令lspci | grep -i nvidia cat /proc/driver/nvidia/version 2/dev/null lsmod | grep nvidia如果内核模块已经加载但 nvidia-smi 不在 PATH 中可能是驱动安装不完整。3.2 方法一通过 apt 安装发行版驱动在 Ubuntu 24.04 下最推荐先尝试的方法是通过 apt 安装发行版内的 NVIDIA 驱动。这种方式的优势是依赖关系由系统管理内核更新后 dkms 会自动重新编译驱动模块。sudo apt update sudo apt install ubuntu-drivers-common ubuntu-drivers devicesubuntu-drivers devices会列出当前机器支持哪些驱动版本比如nvidia-driver-550。如果没有特殊要求直接执行自动安装sudo ubuntu-drivers autoinstall sudo reboot重启后检查nvidia-smi如果输出类似下面的内容说明驱动已经工作----------------------------------------------------------------------------- | NVIDIA-SMI 550.54.14 Driver Version: 550.54.14 CUDA Version: 12.4 | |--------------------------------------------------------------------------- | GPU Name Persistence-Mode | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |需要注意nvidia-smi顶部显示的CUDA Version是这个驱动支持的最高 CUDA 版本并不代表当前系统已经安装了对应版本的 CUDA Toolkit。两者要分开理解。如果安装过程中遇到 nouveau 开源驱动冲突需要把 nouveau 加入黑名单。传统做法是在/etc/modprobe.d/blacklist-nouveau.conf中写入blacklist nouveau options nouveau modeset0然后重新生成内核 initramfs 并重启sudo update-initramfs -u sudo rebootUbuntu 的官方驱动包在部分版本中会自动处理 nouveau 冲突。如果没有自动处理再手工执行这一步。3.3 方法二通过 NVIDIA 官网 .run 文件安装如果 Ubuntu 仓库里没有你需要的驱动版本或者你需要英伟达某个特定分支的驱动可以从 NVIDIA 官网下载.run文件安装。先安装编译驱动需要的工具链sudo apt install build-essential dkms从官网下载与 GPU 型号匹配的.run文件后执行安装chmod x NVIDIA-Linux-x86_64-550.54.14.run sudo ./NVIDIA-Linux-x86_64-550.54.14.run.run安装过程中会询问是否启用 dkms、是否更新 X 配置。生产服务器建议启用 dkms这样内核升级后驱动模块能自动重新编译。如果之前已经安装过其他 NVIDIA 驱动升级版本前最好先清理一次sudo apt remove --purge nvidia-* sudo apt autoremove注意.run文件安装适合有一定 Linux 经验的用户。它不会像 apt 那样自动管理所有依赖安装失败时更容易留下半配置状态。新手如果条件允许优先使用发行版仓库安装。3.4 安装 CUDA Toolkit 并验证编译环境Ubuntu 24.04 上驱动装好后通常还需要安装 CUDA Toolkit 才能编译或运行部分深度学习代码。判断标准是如果只是使用预编译镜像和推理引擎可能不需要安装完整 CUDA Toolkit但如果你要编译自定义算子、使用 PyTorch 源码安装就需要nvcc。查看当前驱动支持的最高 CUDA 版本nvidia-smi安装 CUDA Toolkit 最推荐的方式是使用 NVIDIA 提供的 apt 源并按驱动支持的 CUDA 版本选择对应大版本。安装完成后确认nvcc --version如果nvcc找不到但 CUDA 目录已经存在可以手动加入 PATH。例如 CUDA 12.4 安装到/usr/local/cuda-12.4export PATH/usr/local/cuda-12.4/bin${PATH::${PATH}} export LD_LIBRARY_PATH/usr/local/cuda-12.4/lib64${LD_LIBRARY_PATH::${LD_LIBRARY_PATH}}这条 PATH 配置建议写入/etc/profile.d/cuda.sh或用户的.bashrc避免每次登录都手动设置。3.5 驱动安装检查单重新开机后建议按下面顺序确认系统状态检查项命令期望结果GPU 是否识别lspci | grep -i nvidia输出 NVIDIA 设备驱动是否加载lsmod | grep nvidia输出 nvidia 相关模块工具是否可用nvidia-smi显示 GPU 型号、显存、驱动版本内核模块是否自动编译dkms statusnvidia 模块状态为 installedCUDA 编译器是否可用nvcc --version输出 CUDA release 号GPU 是否持续占用nvidia-smi dmon -s pucm看到 GPU 利用率和显存变化4. 使用 Docker 和 NVIDIA 容器工具包让 GPU 进入容器驱动安装完成只是第一步。真正开发时团队成员通常不会直接在宿主机上跑模型而是把推理服务、训练脚本打包进镜像通过容器运行。这样环境一致、交付简单、资源隔离也更好。4.1 为什么要用容器承载推理服务容器隔离的是进程和文件系统内核还是共享的。对 GPU 来说这意味着容器并不天然具备访问 GPU 的能力需要把宿主机的 NVIDIA 设备节点、驱动库和运行时挂载进去。容器化带来的收益很直接CUDA 版本可以由镜像自行固化不污染宿主机。同一个 GPU 上可以运行多个容器按需分配显存。推理服务版本回滚方便镜像即环境。和 Kubernetes 等调度系统集成容易便于后续扩展。4.2 安装 NVIDIA Container ToolkitNVIDIA Container Toolkit 的作用是让容器运行时识别 GPU并注入 CUDA 运行所需的库和工具。安装过程可以分成三步添加 apt 源、安装nvidia-container-toolkit、配置 Docker 运行时。添加 apt 源的常见流程curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \ sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list然后安装并配置sudo apt update sudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker注意不同发行版、不同 Docker 版本的安装命令可能存在差异。如果仓库地址或签名方式发生变化要以 NVIDIA 官方文档为准。核心概念是让 Docker 新增一个nvidiaruntime再由这个 runtime 调用 NVIDIA Container Toolkit。4.3 运行第一个 GPU 容器配置完成后运行一个带 CUDA 基础镜像的容器验证docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi如果命令行输出 GPU 信息说明容器已经能够访问 GPU。如果报could not select device driver 或Unknown runtime specified nvidia通常是nvidia-ctk runtime configure没有正确修改 Docker daemon 配置需要重新执行并重启 Docker。4.4 理解 GPU 隔离参数--gpus all表示把宿主机所有 GPU 都暴露给容器。实际项目中更推荐精确指定docker run --rm --gpus device0,1 nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi如果只想赋予容器一张 GPU也可以使用环境变量docker run --rm --gpus device0 -e NVIDIA_VISIBLE_DEVICES0 nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smiNVIDIA_VISIBLE_DEVICES的取值可以是设备编号、UUID也可以是all和void。容器编排时通过这个变量控制 GPU 可见范围比--gpus all更可控。5. 部署最小 LLM 推理服务实测算力是否被真正用起来驱动和容器都跑通之后可以部署一个真实的大模型推理服务。目标不是搭建完整生产系统而是通过一个小而完整的链路验证模型文件放在哪里、显存占用多少、GPU 利用率如何、用户看到的 token/s 是多少。5.1 选择引擎先用 Ollama 跑通再用 vLLM 压测推理引擎选择分两层理解如果目标是快速体验、验证模型效果Ollama 最方便一条命令就能拉模型并启动服务。如果目标是生产环境、高并发、高吞吐vLLM 更合适它内置了 PagedAttention、continuous batching 等优化能显著提升利用率。本文先用 Ollama 跑通再用 vLLM 演示需要更高性能时的部署模式。5.2 基于 Ollama 快速完成模型推理使用官方镜像启动 Ollamamkdir -p /data/ollama docker run -d --gpus all \ -v /data/ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama进入容器拉取模型docker exec -it ollama ollama run qwen2.5:7b也可以先拉取再通过 API 调用docker exec -it ollama ollama pull qwen2.5:7b curl http://localhost:11434/api/generate \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, prompt: 用一句话解释什么是算力, stream: false }如果模型已经拉取成功响应会包含模型名、生成文本、token 耗时和eval_count。可以用eval_count / eval_duration换算每秒生成 token 数。5.3 基于 vLLM 启动 OpenAI 兼容推理服务生产环境通常要求 OpenAI 兼容 API这样上层应用可以无缝切换模型服务。vLLM 提供的镜像可以直接启动。docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1启动日志出现Application startup complete后用 curl 调用curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 用一句话解释什么是算力}], max_tokens: 256, temperature: 0.7 }如果返回结构包含choices和usage字段说明服务已经正常。usage里的completion_tokens和耗时数据可以用于吞吐计算。注意vLLM 镜像和模型版本更新很快不同组合对 GPU 显存、驱动和 CUDA 版本的要求可能不同。示例中的镜像和模型仅说明流程实际部署前要结合官方模型卡和镜像 tag 确认兼容性。5.4 从 nvidia-smi 和生成日志验证算力推理服务运行过程中可以在宿主机另开一个终端观察 GPU 状态watch -n 1 nvidia-smi正常工作时可以看到 GPU-Util 实时变化显存被模型权重和 KV cache 占用。如果 GPU-Util 长期为 0%而请求已经开始产生说明数据搬运和算子调用链路可能存在问题。更细粒度的监控可以使用nvidia-smi dmon -s pucm关键指标包括pwr当前功耗判断是否进入高负载状态。mclk显存频率推理过程中高频率代表资源正在被访问。SM流式多处理器利用率直接反映计算单元活跃程度。fbframebuffer 显存占用判断 KV cache 和权重复用是否正常。如果需要压力测试可以在服务启动后并行发送多个请求观察吞吐# 一个非常朴素的并发压测方式 for i in $(seq 1 10); do curl -s http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:Qwen/Qwen2.5-7B-Instruct,messages:[{role:user,content:计算 11}],max_tokens:32} \ /dev/null done wait并发场景下GPU 利用率通常会逐步上升单请求延迟可能变高但总吞吐有提升空间。这个现象是理解算力规划和性能调优的基础。6. 多团队共用 GPUMIG、MPS 和 Kubernetes 调度当一台服务器只有一张或少数几张 GPU 时资源冲突很快会出现。算法团队要跑微调业务团队要跑推理测试团队要压测。如果不做资源隔离和配额显存溢出、进程互相抢占甚至整卡宕机都有可能发生。6.1 GPU 共享为什么比“一人一块卡”更现实在资源有限的情况下一人独占一块卡非常浪费。一个小模型推理可能只需要 8GB 显存但 GPU 有 80GB其余部分空闲。合理的做法是把一张 GPU 同时分配给多个任务但又要保证它们之间尽量不影响。英伟达提供了多种共享策略从硬件级隔离到软件级调度对应不同的使用场景。6.2 MIG把一张物理 GPU 切成多个实例MIG 是 Multi-Instance GPU 的缩写适用于 A100、H100 等数据中心级 GPU。它可以把一张 GPU 切分成多个相互隔离的 GPU 实例每个实例拥有独立的显存、计算核心和带宽近似于多张虚拟 GPU。查看当前 MIG 支持情况nvidia-smi mig -h启用 MIG 前需要先关闭 GPU 上运行的服务然后为指定 GPU 配置可用 profile。常见的 profile 命名类似1g.5gb、2g.10gb但不同型号 GPU 支持的组合不同需要以nvidia-smi mig -lpgpu输出的实际列表为准。MIG 适合将大显存 GPU 拆给多个稳定负载。缺点是配置和调度相对繁琐且不是所有软件都支持。6.3 MPS 和容器的软共享MPS 即 Multi-Process Service它把多个进程的计算任务合并调度到一个 GPU 上提高计算单元利用率。相比 MIGMPS 更适合多个进程同时跑但每个进程显存需求较低的场景。在容器场景里可以通过环境变量和容器配置限制 GPU 显存与计算能力。例如docker run --gpus device0 \ -e NVIDIA_VISIBLE_DEVICES0 \ -e CUDA_MPS_PIPE_DIRECTORY/tmp/mps \ -e CUDA_MPS_LOG_DIRECTORY/tmp/mps \ your-train-image需要说明的是MPS 不是严格隔离方案一个进程出现非法显存访问时可能影响同一 GPU 上的其他进程。生产环境要根据业务重要程度决定是否使用。6.4 Kubernetes 调度 GPU 的最小配置如果是多台服务器组成的集群推荐用 Kubernetes 管理 GPU。NVIDIA 官方提供了 device plugin负责让 Kubernetes 感知每台节点上的 GPU 数量和健康状态。安装完 device plugin 后Pod 可以通过资源限制声明 GPUapiVersion: v1 kind: Pod metadata: name: gpu-inference spec: containers: - name: inference image: nvidia/cuda:12.4.1-base-ubuntu22.04 command: [nvidia-smi] resources: limits: nvidia.com/gpu: 1当 Pod 里声明了nvidia.com/gpu调度器会把 Pod 放到有足够 GPU 的节点上并由 device plugin 把对应 GPU 设备挂载进容器。实际上 Kubernetes GPU 调度涉及 GPU 类型划分、显存限制、MIG 分区、共享模式等多层配置。如果团队还处于单机阶段不必一步迁移到 Kubernetes。先把 Docker 下的资源配额、镜像管理和日志理清楚再引入集群调度更稳妥。6.5 小团队演进路径阶段规模推荐方案单人开发1 张 GPUDocker --gpus 参数即可小团队共用1 台服务器多张 GPUDocker NVIDIA_VISIBLE_DEVICES 限定设备人工排期多项目在线服务多台 GPU 服务器Kubernetes device plugin Prometheus 监控大型训练集群数十台以上 GPUKubernetes Slurm 高速网络 多租户配额不要一开始就在 GPU 集群上堆 K8s。算力的第一优先级是让模型能稳定跑起来之后再考虑调度和利用率。7. 常见问题排查从驱动装不上到推理速度上不去GPU 问题排查有一个基本原则从底层硬件向顶层应用逐层确认。先看 GPU 是否被系统识别再看驱动是否加载再确认容器运行时是否能注入 GPU最后才怀疑模型和代码。7.1 驱动层问题花屏、黑屏、重启后驱动消失现象一安装驱动后显示器花屏或黑屏。可能原因包括桌面环境与驱动版本不兼容、nouveau 驱动没有完全禁用、X Server 配置被修改。排查顺序lsmod | grep nouveau cat /var/log/Xorg.0.log | grep -i nvidia journalctl -b | grep -i nvidia如果 nouveau 还在加载说明黑名单配置没有生效需要重新确认/etc/modprobe.d/blacklist-nouveau.conf和update-initramfs -u。如果日志里出现 nvidia 模块加载失败优先查看dmesg | grep -i nvidia。现象二重启后 nvidia-smi 显示 command not found 或 driver not loaded。常见原因是内核升级后 dkms 没有重新编译模块。确认方式dkms status如果状态不是 installed需要手动重新编译sudo dkms install -m nvidia -v version现象三Windows 下无法安装英伟达驱动。这是很多混合环境开发会遇到的问题。先确认系统是否残留旧驱动建议在设备管理器中卸载显卡设备驱动然后断开网络使用干净环境重新安装。Windows Update 偶尔会强制安装旧驱动导致新版驱动装不上要留意系统更新记录。7.2 容器层问题找不到 GPU、版本不匹配常见报错之一docker: Error response from daemon: could not select device driver with capabilities: [[gpu]].原因通常是 Docker daemon 没有配置 nvidia runtime。重新执行sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker常见报错之二CUDA error: no kernel image is available for execution on the device原因可能是容器内 CUDA 版本过高超过驱动支持范围也可能是容器镜像使用了错误的架构。先检查宿主驱动和镜像 CUDA 版本是否匹配。常见报错之三libcuda.so.1: cannot open shared object file原因通常是容器内没有正确挂载驱动库或缺少 nvidia-container-toolkit。运行docker run --rm --gpus all ubuntu:24.04 ls /usr/lib/x86_64-linux-gnu/libcuda.so.1检查是否存在。7.3 推理层问题GPU 利用率低、显存不足现象一请求已经发出但 GPU-Util 为 0 或很低。可能原因是 batch size 过小GPU 计算单元还没来得及满载就进入等待也可能是 CPU 数据预处理成为瓶颈GPU 一直在等数据。观察方法top -H -p $(pgrep -f vllm | head -1)如果 CPU 占满、GPU 利用率低优先检查数据加载和 tokenizer 是否有性能问题然后尝试增大 batch size 或并发数。现象二启动模型时报 CUDA out of memory。先明确模型权重、KV cache、激活层三部分显存占用。降低max-model-len可以减少 KV cache 预留启用量化可以减少权重显存。若还是不够只能换更小模型或用多卡张量并行。现象三模型多副本后显存耗尽快但 GPU 利用率依然不高。可以考虑把多个小模型合并到同一张卡上或者使用支持 continuous batching 的引擎以动态 batch 提升吞吐。7.4 标准排查顺序和日志关键字层级排查命令常见关键字结果判断硬件lspci | grep -i nvidiaNVIDIA设备必须出现驱动nvidia-smiDriver Version正常显示型号和版本内核模块dmesg | grep -i nvidiaNVRM, failed无致命错误容器运行时docker info | grep -i runtimenvidia存在 nvidia runtime容器内部docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smiGPU 信息输出正常推理服务curl /v1/chat/completionschoices, usageAPI 返回正常性能监控nvidia-smi dmon -s pucmSM, fb, pwr高负载时数值上升8. 从千亿算力投入到单机落地容量规划与最佳实践如果团队正在规划 GPU 基础设施不要一开始就模仿大型云厂商的集群规模。先按业务实际跑一个最小链路统计显存、并发、吞吐和成本再横向扩容。算力投资越大越需要把基础环境标准化。8.1 先算清楚业务需要什么规模的算力容量规划可以从模型参数、量化精度和预期并发三个维度粗略估算。单个 7B 模型用 FP16 推理时仅模型权重就需要大约 14GB 显存加上 KV cache 和中间激活一张 24GB 显存的显卡能够运行但可支持并发有限。如果用 INT4 量化权重显存降到约 4GB单卡可承载更多并发或更大上下文。模型规模FP16 权重显存估算INT4 权重显存估算适合的 GPU 显存1.5B约 3GB约 1GB8GB - 16GB7B约 14GB约 4GB16GB - 24GB14B约 28GB约 8GB40GB 及以上70B约 140GB约 35GB80GB 多卡估算过程中不要漏掉 KV cache。上下文越长KV cache 占用越大这会直接影响最大并发数。8.2 监控是算力平台的“仪表盘”GPU 一旦上生产必须有持续监控否则显存泄漏和驱动异常只能等业务报障才发现。推荐的最小监控方案宿主机定时采集nvidia-smi指标包括显存使用率、功耗、温度和 SM 利用率。容器层面记录日志并监控容器退出码和重启次数。使用 Prometheus Grafana 展示历史趋势设置显存使用率超过 90% 或温度超过 85 摄氏度时的告警。对推理服务单独记录延迟、token/s、请求吞吐和错误率而非只看 GPU 指标。只有 GPU 利用率并不能判断业务是否正常。一个请求都没进来时GPU 利用率自然是 0真正要关心的是有流量进来时GPU 是否处于合理负载。8.3 生产环境落地清单发布到生产环境之前建议逐项核对这份清单驱动版本固定更新驱动必须走变更流程并在灰度节点验证。CUDA 版本按镜像固化容器内外保持一致性。nvidia-smi的 ECC 错误和 Xid 错误有日志采集和告警。宿主机 Docker 的日志轮转已配置避免日志撑满磁盘。GPU 节点有显存、功耗、温度监控。容器没有使用 host network 时确认端口映射和健康检查路径。推理服务有超时、重试和熔断策略。多卡场景明确tensor-parallel-size和数据并行策略避免盲目加卡。备份并固定镜像版本出现模型效果异常时可快速回滚。8.4 后续扩展方向算力平台跑通之后可以从三个方向继续深入。方向一是推理引擎优化。学习 vLLM 的 continuous batching、PagedAttention、前缀缓存和量化策略能显著提高单卡吞吐减少 GPU 采购压力。方向二是多机调度。在 Kubernetes 中接入 GPU device plugin、给不同团队划分 namespace 和 quota让资源分配不再是人工沟通排期。方向三是网络和存储规划。当模型规模超过单机显存时节点间通信会变得非常关键NCCL 通信路径、NVLink、IB 或 RoCE 网络的配置将直接影响训练效率。算力话题之所以被反复讨论是因为 AI 应用的最终瓶颈往往不在算法而在资源和基础设施。英伟达 GPU 只是计算的起点真正决定项目能不能上线的是驱动、容器、调度和推理服务这一整条链路是否稳定可靠。对于现阶段的技术团队最值得做的事情不是追逐更大规模的集群而是把眼前的几块 GPU 用好先把最小可运行的推理链路跑通再逐步向多机集群演进。