1. 先聊明白部署GPU平台到底是在部署什么先说一个容易踩的认知误区。很多人第一次接触“GPU部署”这个词会下意识以为是指把显卡插进机箱、装个驱动、然后拿个AI程序去跑。但在2025年的实际工作流里绝大多数人部署的不是“显卡”而是“一套能让模型快速跑起来的软件栈”。这中间包含系统、驱动、CUDA、容器运行时、模型推理框架、模型文件本身还有一套监控和调用工具。任何一个环节出了错前面全白搭。我最早自己搭GPU环境是在一台二手服务器上当时天真地以为装个NVIDIA驱动就能用PyTorch跑训练。结果光是“驱动版本和CUDA版本对应不上”这一个问题就折腾了我一整个下午。后来换了带GPU的云主机发现事情也没简单太多——因为虽然底层硬件就绪但你要跑通的是一条完整的链路SSH进系统、装驱动、配CUDA、装容器引擎、拉模型、起服务、测试推理。任何一个动作没对齐模型的准确率再高也跟你没关系。所以这篇文章的核心思路很简单从一个第一次接触GPU平台的普通用户视角出发讲清楚服务商怎么选、开机后第一步做什么、驱动和运行时怎么配、模型怎么最快跑起来、遇到典型问题怎么排查。我会尽量把每一步的命令行和判断逻辑都写出来而不是只给一句“装一下就行”。如果你手头已经有一台GPU服务器或者正准备租一台跟着这篇走基本能在一个小时内从零跑到模型输出。有人会问为什么不用厂商自带的镜像或者一键部署包当然可以用而且我强烈建议第一次跑通用镜像。但问题在于镜像解决的是“快”而你要理解的是“每一步在干什么”这样到了换机器、换卡、换模型的时候才不至于抓瞎。本篇文章先讲落地流程再讲为什么这样做。2. GPU服务商怎么选我的推荐排序和选型逻辑2.1 第一次部署最重要的不是算力而是“到货即用”的程度先说结论我推荐的顺序是——云GPU实例按需租用优先于自建服务器而云服务商里优先推荐主流大厂GPU云主机和专注AI算力的中小服务商最后才考虑买整机。原因是第一次部署GPU平台你真正需要的是“能远程操作、随开随停、坏了一键重来”的环境而不是一台放在家里或机房的裸机。为什么这么排序我见过太多人在选型阶段就被卡住买整机要考虑电源功率、散热、主板PCIe通道够不够、机箱能不能装下4090这种大卡。这些事不是不能做但和“跑通模型”这个目标完全是两码事。本地自建一套能跑大模型的机器硬件成本至少两万起步而且大多数人的网络带宽和物理环境并不适合跑远程推理服务。云GPU实例本质上是把“硬件兼容性”这个最大的坑帮你填了。你要做的只是在控制台上选择对应的GPU型号、系统镜像和数据盘大小几分钟后就能拿到一台带公网IP和SSH登录权限的主机。在这个过程中真正影响你体验的不是“哪家的A100便宜五块钱”而是“镜像仓库是否自带CUDA驱动”、“安全组的默认策略会不会拦住你的端口”、“重装系统之后数据盘还在不在”。2.2 具体来说不同预算和服务场景怎么站队如果你只是个人学习、跑通大模型推理常见选择是带单张RTX 4090或L20的实例24GB显存足够跑满血版7B甚至14B模型。这类实例大多按小时计费用完关机只收存储费很适合试错。我之前测试过某国产算力平台的4090实例一小时大概十来块跑一个7B量化模型并完成并发推理压测两个小时之内全部搞定成本不到一杯咖啡钱。如果是小团队做模型微调或批处理建议直接上多卡机型比如4卡A800或8卡4090。这时候要额外关注两件事卡间通信是否走NVLink/NVSwitch以及服务商是否允许你自定义驱动版本。很多平台的多卡机器默认用了统一镜像驱动版本偏新但某些微调框架要求特定CUDA版本这时候就需要你能自己装驱动而不是只能干瞪眼。如果是企业生产环境我反而建议回归保守优先选择服务商提供的全托管推理服务或带GPU的Kubernetes节点但不要自己折腾底层驱动。不过本文既然讲“从第一次开机到跑通”我还是以云GPU实例为基准场景来写。自建服务器的读者可以参考其中驱动和推理部署部分逻辑完全一致。2.3 服务商之外还有一个不言自明的选择本地机器最后补充一句如果你手上已经有了一块NVIDIA显卡的Windows电脑也可以体验GPU部署。把Windows当作一个“隐蔽的Linux环境”来用装WSL2、在WSL里跑Docker和GPU驱动透传就能在不动原生系统的情况下完成绝大部分模型部署实验。这部分我会在驱动章节简要说明因为很多人的第一块“GPU平台”其实就是自己的游戏本。总结选型要点第一次选平台看三个指标——开机速度、镜像可用性、售后响应。算力榜单反而不重要因为只要是近几年的NVIDIA显卡跑主流推理模型基本没有性能瓶颈。3. 第一次开机从零初始化一台GPU主机3.1 登录前的三个关键选择镜像、数据盘和登录方式绝大多数云GPU实例创建后会进入一个“待初始化”状态。这时候你需要在控制台做三个决定它们会直接影响后面的操作路径。第一个是操作系统镜像。我的建议是选Ubuntu 20.04或22.04 LTS不要选带桌面环境的版本更不建议一上来就选厂商预置的“AI镜像”。为什么因为带桌面的系统会占用显存和内存预置AI镜像虽然方便但会“隐藏”掉很多你本该理解的配置过程而且一旦镜像里预装的CUDA和你的需求对不上改起来比从零装还麻烦。选一个纯净的Ubuntu Server版后面所有环境自己装出了问题你知道是怎么回事。第二个是数据盘。GPU实例默认系统盘通常只有40到80GB一旦开始拉模型这空间撑不了多久。一个7B的模型FP16权重就有14GB上下量化后约4GB但Ollama或Hugging Face的缓存目录还会放下游依赖和多版本文件分分钟几十GB。我建议额外挂载一块至少100GB的数据盘甚至直接选200GB这是我在多次部署中得出的最实用经验。第三个是登录方式。尽量用SSH密钥而不是密码。虽然密钥对生成和配置听起来比密码多一步但长期来看安全性和便利性都远超密码。如果你不太熟悉可以在创建实例时让服务商生成一个密钥对然后把私钥下载到本地后面用ssh -i指定登录。万一真的要用密码登录记得修改默认端口并开启Fail2Ban这个后面会提。3.2 拿下一台新机器后我的“习惯性五分钟”拿到实例的公网IP后我习惯先在本地终端跑几条命令摸清机器底细而不是直接开始装东西。第一件事确认硬件是否如预期。SSH登录后看GPU是否被系统识别lspci | grep -i nvidia nvidia-smi如果第二条命令报“command not found”说明驱动还没装这是正常的。如果机器确实挂着GPUlspci里一定能看到类似“NVIDIA Corporation GA102 [GeForce RTX 3080]”的信息。如果这一步都看不到卡立刻去控制台检查实例是否选错了规格或者联系客服确认资源是否分配成功。第二件事确认系统版本和内核cat /etc/os-release uname -a这两条命令的输出将直接决定你去哪个源下载驱动以及后面装Docker时选择哪个版本的CUDA运行时。第三件事更新系统并安装基础工具sudo apt update sudo apt upgrade -y sudo apt install -y build-essential git curl wget vim net-tools不要跳过apt upgrade。很多云镜像的预装软件包版本偏旧直接装驱动会在依赖层面踩到奇怪的坑。3.3 安全组和防火墙别让服务裸奔GPU实例往往要跑推理服务意味着你会开放类似8000、8080的端口。创建实例时阿里云、腾讯云这类平台默认安全组只会开放22和3389端口其他全阻挡。这里我建议你保持默认原则只开必要端口不要图省事放行全端口。同时登录后要检查机器自带的防火墙sudo ufw status sudo ufw allow 22/tcp如果后续要暴露某个推理服务的API再单独开放对应端口。我见过不少人是把整个安全组设置成允许全部流量结果日志里全是扫描器的攻击尝试白白消耗带宽和CPU。安全组是云平台给你的第一道防线用好了能省很多事。4. GPU驱动与CUDA一次配好后面全是坦途4.1 驱动装得好不好决定了你今晚几点睡驱动安装这件事说难也难说简单也简单——只要你能忍住不“凭感觉下载”。很多人第一次装驱动习惯在NVIDIA官网手动选型号然后下载一个几百兆的.run安装包。这条路能走通但对新手来说风险极高你可能选错Linux版本可能和GCC版本冲突还会在nouveau内核模块没禁用时直接装失败。我推荐的方式是先让系统自动推荐再手动校验sudo ubuntu-drivers devices sudo apt install -y nvidia-driver-535ubuntu-drivers devices会列出当前机器匹配的驱动版本通常显示“recommended”字样的就是最稳妥的选择。比如很多RTX 30系卡首选535或550驱动装完重启后nvidia-smi就能正常输出了。等一下这里有个容易被忽略的细节重启。驱动装完必须重启或者重新加载内核模块否则nvidia-smi照样报错。我建议直接sudo reboot等一两分钟重新登录。很多新手在“装完驱动不出东西”这个环节崩溃其实就是没重启。4.2 服务器场景下容器化才是正解驱动装好后下一步是装CUDA。这里我必须给出一条重要建议不要直接在主系统里安装CUDA Toolkit除非你有明确的编译需求。原因很简单CUDA Toolkit的版本和驱动版本互相约束而且深度学习框架对CUDA版本有具体要求。比如最新版PyTorch要求CUDA 11.8或12.1老版本代码可能需要10.2。如果你直接在宿主机装一套CUDA 11.8过段时间要跑一个需要CUDA 12.1的框架升级伴随着驱动变更和系统库冲突极其痛苦。正确的做法是宿主机只装驱动CUDA和所有深度学习依赖全部交给Docker容器管理。NVIDIA官方提供了nvidia-container-toolkit装好之后运行容器时加上--gpus all参数容器内就能直接看到宿主的GPU设备。装Docker和NVIDIA容器工具的步骤curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker这套操作做完验证是否成功docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi如果容器内能看到GPU信息说明整个GPU透传链路已经打通。这一步是我在每次新装机时的“标准试金石”它验证的不只是Docker还验证了驱动版本与CUDA镜像的匹配度。4.3 Windows用户WSL2是GPU部署的隐藏彩蛋Windows用户如果不装Linux双系统又想跑GPU模型建议直接启用WSL2。安装流程很简单管理员权限的PowerShell里跑wsl --install装Ubuntu 22.04然后去NVIDIA官网下载Windows版CUDA驱动注意Windows版驱动同时支持WSL2内的Linux容器再在WSL内部安装 nvidia-container-toolkit。这样做的最大好处是Windows桌面上可以开浏览器和IDEWSL里跑模型训练和推理服务两边共用一块物理GPU文件系统互通性能和纯Linux相差无几。我自己在笔记本上做的很多模型测试都是在WSL2里跑的。如果你手头只有一个Windows环境先别急着租服务器按这个路子体验一下原地起飞的感觉。5. 模型推理框架与部署工具从Ollama到vLLM5.1 第一次跑通模型Ollama是最短路径环境配好之后下一步就是选一个“模型运行时”。这里推荐最省事的方式Ollama。Ollama是一个本地方便跑大模型的工具支持Llama、Qwen、DeepSeek等主流开源模型一条命令拉模型一条命令起服务还自带一套HTTP API。它最大的优点是“隐藏了所有复杂性”不需要手动下载权重、不需要写推理脚本、也不需要配置并行参数。你只要确认GPU可用然后执行curl -fsSL https://ollama.com/install.sh | sh ollama run qwen2.5:7b第一次运行会下载模型权重等待时间取决于你的网络和模型大小。下载完成后终端就会变成一个交互式对话界面你可以直接输入中文问题模型会基于GPU算力流式返回回答。看到最终输出时这个“第一次跑通”的目标就基本达成了。但这里要提醒Ollama虽然方便它默认只使用本机所有可见GPU。如果你有多张显卡Ollama默认会把模型均匀分布到所有卡上。这个行为对于单用户推理没问题但如果你即将进入多人服务甚至生产压测阶段直接用默认行为是不妥的需要手动限制Ollama使用的GPU编号。5.2 从“能跑”到“会服务”切换到vLLM做并发推理如果你跑通了Ollama后觉得“确实能出结果但是速度不够快而且并发一高就开始排队”那恭喜你你已经来到了需要vLLM的阶段。vLLM是一个专门为LLM推理优化的高性能运行时核心特性是PagedAttention能极大提升显存利用率和并发吞吐。相比Ollama那种“逐条处理”的体验vLLM可以同时处理数十路请求而且支持OpenAI兼容的接口协议很多语言模型应用可以直接把API地址改成vLLM的地址就能用。部署vLLM的方式依然是Dockerdocker run --runtime nvidia --gpus all \ -p 8000:8000 \ -v /path/to/models:/models \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1这里有几个参数值得解释。--tensor-parallel-size是指定张量并行的GPU数量。如果你的机器有2张4090可以把模型切到两张卡上跑显存等效翻倍。但如果模型能在单卡跑完我建议这个值设为1因为张量并行会引入卡间通信开销小模型在2卡上反而比单卡慢。--max-model-len决定模型最大上下文长度如果显存不够优先降低这个值而不是换小模型。你可能还会问模型文件从哪里来可以用huggingface-cli下载pip install -U huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /path/to/models也可以直接用modelscope国内用户下载速度更稳。这一步没有复杂逻辑核心就是“把权重文件准备好vLLM只是一个执行器”。5.3 从对话到API让模型变成可用服务跑通模型后真正“能用”的定义是它能通过API被其他程序调用。Ollama和vLLM都内置HTTP服务区别在于接口兼容性。Ollama默认服务端口是11434调用方式curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好介绍一下你自己, stream: false }vLLM用的是OpenAI兼容接口端口8000curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好}] }两者的区别很重要如果你之后想接LangChain、FastGPT或Dify这类开源应用框架它们默认适配OpenAI格式也就是说用vLLM作为后端会更省事。而Ollama只有在它的生态里用起来最舒服。我自己目前的分工是本地快速验证用Ollama生产服务一律vLLM。6. 模型选择与显存规划跑得动才是硬道理6.1 一眼算出你的显存够不够很多人第一次跑模型失败不是因为不会装环境而是模型选大了。这里给一个基本公式模型权重显存 ≈ 参数量 × 权重精度字节数 × 1.2额外开销举例7B模型用FP16精度每权重2字节理论权重需要14GB加上KV Cache和框架开销实际需要约20GB显存。所以24GB显存的4090跑7B FP16刚好跑14B就不太现实。如果换成4bit量化7B权重降到约4GB24GB显存就能舒服地跑更大的模型甚至给上下文留下充足空间。所以选模型之前先问自己三个问题我手头是多少显存我愿意接受多少性能损失来换取更低的显存占用我是要长上下文还是普通问答答案组合起来基本能锁定模型档位——24GB适合跑7B-14B量化模型48GB适合跑32B量化模型80GB以上才有资格考虑70B及以上的大家伙。6.2 模型文件从哪里来权重格式怎么选目前主流开源模型权重有两种格式Hugging Face Transformers格式和GGUF格式。前者适合vLLM和Transformers后者适合Ollama以及llama.cpp系列。如果你的部署路径是Ollama直接在Ollama仓库里拉取官方量化版即可如果是vLLM就用Hugging Face或ModelScope上的模型原始权重。国内网络环境下强烈建议先试ModelScopepip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir /path/to/models这个命令的本质是“把指定模型的权重文件同步到本地目录”下载速度通常比Hugging Face快一个数量级。对于大模型部署来说权重文件是核心资产把它放在单独的数据盘而不是系统盘能让你重装系统后无需重新下载。6.3 一个低成本起手式先用量化小模型跑全流程如果你只是想完整走一遍从环境到服务的链路我建议第一步先跑一个量化版1.5B或3B模型。原因很简单下载快、显存占用低、出结果快。整个流程走通后再替换成大模型那时你已经有经验了大模型的部署只是换一个模型路径的问题。比如Ollama跑qwen2.5:1.5b半分钟就能下完之后你可以在交互界面测试中文回答再用vLLM跑一份GGUF格式的同模型观察它在并发请求下的响应速度。整个过程可能不到二十分钟却能把“部署”两个字的全貌看透。7. 常见问题与排查技巧实录7.1 问题一nvidia-smi 提示驱动未安装或版本不匹配这是GPU部署中出现频率最高的问题。排查逻辑按以下顺序走先确认显卡被系统识别lspci再确认Ubuntu版本然后重新执行驱动安装步骤。很多情况是内核升级导致驱动模块失效重装驱动并重启即可。另外请确认你是否在云主机上占了“GPU虚拟化实例”而选了“不带GPU的普通实例”这两种是不同的计费和硬件规格控制台上很容易选错。7.2 问题二docker run --gpus all 报错提示RuntimeError这种情况多半是nvidia-container-toolkit没有正确安装或在Docker配置中未生效。重新执行sudo nvidia-ctk runtime configure --runtimedocker并重启Docker。如果还不行检查Docker版本是否过旧旧版本不支持--gpus参数。确保你安装的是Docker Engine 19.03以上版本注意Docker Desktop和Docker Engine在Linux上是两套东西。7.3 问题三显存看着还有很多但Ollama说CUDA out of memory这个看起来矛盾实际是因为Ollama默认会预留一部分显存作为KV Cache而模型估算显存又不够准确。解决方法是限制Ollama的模型并发数或设置OLLAMA_MAX_LOADED_MODELS1。更常见的情况是你的shell已经加载了多个模型每个模型都占了一块显存用ollama ps查看当前已加载模型不用的用ollama stop释放。7.4 问题四模型跑通了但速度慢到怀疑人生先确认是不是用了CPU推理。如果在GPU机器上跑出了CPU速度十有八九是你的程序没有正确调用GPU设备。检查代码里是否有devicecuda或框架里是否指定了环境变量CUDA_VISIBLE_DEVICES0。如果GPU确实在工作但速度还是慢去看模型的量化等级4bit比8bit快小模型比大模型快。最后检查是否开启了对硬件不利的节能模式比如笔记本在电池模式下会自动降频。7.5 问题五服务可以被本机curl通但公网访问不了优先检查云平台安全组是否放行了对应端口再检查系统防火墙sudo ufw status sudo iptables -L -n如果是Docker部署的服务别忘了查看端口映射是否正确容器内的8000端口是否真的映射到了宿主机的8000端口。有时候你以为你暴露的是8000但实际映射的宿主端口是32768这种随机端口自然访问不了。8. 部署完成后下一步还能做什么整个流程走完你已经拥有了一个能跑模型、能对外提供推理接口的GPU平台。接下来可以考虑用这套能力做什么——比如我自己习惯在服务器上再装一个Open WebUI作为前端把Ollama或vLLM作为后端这样就有了一个带聊天界面的私有AI助手通勤路上用手机也能访问。还有个我强烈推荐的实践用FastAPI写一个薄封装层把vLLM的并发能力接进自己的业务代码里。很多人卡在“模型已经会对话了但怎么接到项目里”这一步——其实很简单用Python的requests库调一下vLLM的接口把返回的文本抽取出来就是一个完整的AI功能模块。根据我的经验大部分人在第一次成功跑通模型之后会立刻产生两个新需求换更大的模型、接更复杂的应用。这也是好事说明你已经开始把部署能力转化成实际产品了。此时再回头看服务商选择、驱动配置和框架调优这些环节你会觉得它们只是“走向目的地的路上的基础路标”而不再是障碍。每次新机器到手我依然会花五分钟跑一遍nvidia-smi然后重复那些熟得不能再熟的安装命令。本质上这是在给自己买一份安心确认这个环节依旧畅通后面的事才有底气继续。希望这篇从第一次开机到跑通模型的经验总结也能成为你未来每次部署时的参考依据。