做推理部署这件事最容易被低估的从来不是模型本身而是从一张GPU到一条稳定线上服务的完整链路。我见过太多人卡在“模型在本地能跑”和“服务能上生产”之间的巨大鸿沟里——明明同一套权重换张显卡就OOM明明镜像在测试机好好的一到新的机器CUDA版本就不对压测一上来延迟直接翻倍还搞不清是显存带宽不够还是并发排队设计有问题。这篇文章就把我从GPU选型、CUDA环境镜像、再到推理服务上线的完整思路拆开讲一遍。所有内容都来自实际部署项目中的总结属于可以直接抄作业的那一类。涉及PyTorch、Ollama、vLLM的部署配置、NVIDIA显卡的选型逻辑、CUDA容器镜像的构建方法、服务压测与高并发优化。适合正在做模型部署、算法工程化、后端接入的同学参考也适合准备租GPU跑服务的团队避坑。1. 显卡选型不能只盯着显存先搞清推理的阻力在哪很多人选GPU就一句话“显存越大越好”这个观念在推理场景下其实非常危险。显存决定的是能不能装下模型而真正决定推理快不快的是显存带宽、算力利用率、并发调度能力这三项。模型参数量只是推理服务成本的起点不是全部。1.1 推理和训练的负载特征截然不同选型逻辑要分开训练是典型的“高算力密集”负载GPU绝大部分时间都在做矩阵乘法和梯度更新所以训练卡追求的是FLOPS每秒浮点运算次数和显存容量。推理不一样推理是“存储带宽密集”负载特征更重尤其是自回归生成类的大模型GPT类每一步都要把所有参数从显存里读一遍去做计算。我来列一个粗算模型。以7B参数模型为例半精度FP16状态下参数占用大约14GB显存如果按token逐个生成每生成一个token都需要把14GB过一遍假设GPU显存带宽是1TB/s比如A100 80G的带宽在2TB/s左右那理论上的token生成速度上限就是2000/14大约每秒142个token但这还是理想的数学上限真实环境加上KV Cache、注意力计算、调度开销能到上限的三分之一至二分之一就很不错了。这个分析告诉我们两件事。第一同样参数规模的模型在A100上比在普通显卡上快不完全是算力差距很大程度是显存带宽带来的第二推理场景比训练更容易受制于带宽所以选卡一定要把带宽放在显存之后第二位去权衡。1.2 用“模型参数 推理并发数”推导真实显存需求具体选卡时显存需求可以用一个经验公式来做前期估算 所需显存 ≈ 模型权重体积 × 1.2推理框架运行开销系数 KV Cache占用KV Cache这一项很多人会忽略。8个并发请求、4K上下文长度、7B模型下KV Cache的额外显存开销大约在1GB到3GB之间如果把上下文做到32K、并发加到32路这个数字会快速冲到十几GB。所以显存规划一定要把并发度和上下文长度算进去拿着一张24GB的卡跑7B模型长上下文多并发分分钟OOM。型号层面从我实际使用来看显卡型号显存显存带宽典型适配场景RTX 409024GB~1TB/s7B~13B模型私有化部署、中小并发、开发测试L2048GB~864GB/s13B~32B模型推理性价比不错的推理卡A100 80G80GB~2TB/s70B级别模型部署、高并发生产环境L40S48GB~864GB/s通用AI推理渲染类混合负载昇腾910B64GB高带宽纯国产化环境约束下的部署替代方案以7B模型8路并发8K上下文为基准需求一张RTX 4090或者L20基本能平稳扛住没必要动辄就上A100。反过来说如果你想在单卡跑满70B的量化版本例如Q4量化后体积约40GB那48GB的卡就会非常勉强A100 80G或H系列会更稳妥。1.3 推理服务选卡的综合考量并发度、生态兼容、成本模型另外一个非常容易踩坑的地方是只看推理性能不看生态兼容。NVIDIA的TensorRT-LLM、vLLM、Triton Inference Server等一系列工具链都基于CUDA开发对N卡的支持永远是最完善最及时的。如果用非NVIDIA的产品例如AMD的ROCm或者国产加速卡很多时候不是不能跑而是要面对算子兼容、框架版本滞后、资料稀缺这一连串问题。对大多数团队如果没有强制的国产化需求第一块推理卡老老实实买NVIDIA不会错。成本模型也不只是显卡硬件价格还要算GPU的利用率。GPU租用按小时计费时选一块过大显存的卡但跑不满每小时都在浪费钱。我一般建议团队先按“最大目标模型预期并发”圈出显存下限再在这个基础上叠加一档余量然后去租对应规格的实例测试而不是一步到位买最高配。拿实际业务请求压测几天用数据决定最终采购什么显卡。GPU选型本质上不是参数游戏是需求匹配游戏。2. CUDA环境与镜像准备把“版本地狱”消灭在构建阶段环境配置在大模型部署项目里占用时间比例很高。如果直接在物理机上逐一安装显卡驱动、CUDA Toolkit、cuDNN和PyTorch每换一台机器就要重来一遍中间任何一个版本对不上就有一堆诡异问题。把环境固化成镜像才是服务能平滑迁移和上线的关键。2.1 驱动、CUDA、PyTorch三者的兼容关系先理清概念虽然很多时候混着说但它们是完全不同的东西NVIDIA驱动运行在操作系统内核层负责和GPU硬件通信是一切的上层基础。CUDA Toolkit包含编译器、运行时库和开发工具是给开发者写CUDA程序用的完整工具链。cuDNN针对深度学习的卷积、循环神经网络等算子做了深度优化的加速库跑深度学习框架几乎必装。PyTorch/TensorFlow等框架在CUDA运行时上封装了一层用户友好的API。这里有一个特别常见的误区很多人在服务器上执行nvidia-smi看到右上角显示的CUDA Version是12.4就以为CUDA Toolkit已经装好了这个理解不对。nvidia-smi里显示的是驱动所支持的最高CUDA版本它不代表系统里实际安装了对应版本的CUDA Toolkit。判断PyTorch能不能用GPU不能只看驱动要看PyTorch自带的CUDA运行时和驱动版本是否能匹配。NVIDIA驱动的兼容策略是向后兼容的也就是说只要驱动版本足够新驱动内置的CUDA运行时能够兼容旧版Toolkit编译出来的程序。所以最稳的做法是先把NVIDIA驱动升到较新版本然后上面放不同CUDA版本的容器镜像完全没必要在主机上纠结CUDA版本切换。2.2 Ubuntu系统上安装NVIDIA驱动如果是全新的Ubuntu服务器安装驱动的步骤建议走以下流程# 1. 检查推荐驱动版本 ubuntu-drivers devices # 2. 自动安装推荐版本也可以手动指定例如nvidia-driver-535 sudo apt install -y nvidia-driver-535 # 3. 重启后检查 nvidia-smi重启之后执行nvidia-smi能看到类似下面的输出就说明驱动OK了----------------------------------------------------------------------------- | NVIDIA-SMI 535.xx.xx Driver Version: 535.xx.xx CUDA Version: 12.2 | -----------------------------------------------------------------------------这里要提醒一下CUDA Version显示12.2只能说明当前驱动最高支持到CUDA 12.2并不意味着系统已装好了CUDA Toolkit。真正的CUDA环境应该放在容器里解决。安装驱动的过程中我也踩过不少坑。比如在部分云服务器上禁用nouveau开源驱动是必要的前置步骤否则会和NVIDIA驱动冲突装完重启后驱动加载失败。常规做法是sudo bash -c echo blacklist nouveau /etc/modprobe.d/blacklist-nvidia-nouveau.conf sudo update-initramfs -u另外如果不需要图形界面建议直接安装server版驱动而不是desktop版少装一堆用不到的依赖也减少后续系统升级时驱动被破坏的概率。2.3 基于nvidia/cuda基础镜像构建CUDA镜像容器化部署大模型推理服务时镜像的构建思路通常基于NVIDIA官方提供的nvidia/cuda镜像来分层扩展。只要服务器安装了NVIDIA Container Toolkit容器内就能直接访问GPU。我推荐直接用官方的CUDA基础镜像来作为起点从Docker Hub拉取选择带runtime的关键词而不是devel因为部署阶段不需要编译器工具链镜像体积会更小。例如# 用带cudnn的runtime镜像作为基础 FROM nvidia/cuda:12.4.0-runtime-ubuntu22.04 # 安装Python和基础工具 RUN apt-get update apt-get install -y \ python3.10 python3-pip curl \ ln -s /usr/bin/python3 /usr/bin/python # 安装PyTorch的CUDA版本这里用到清华源加速 RUN pip install torch --index-url https://download.pytorch.org/whl/cu124 # 拷贝推理服务代码 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . . CMD [python, serve.py]镜像构建时有一个细节经常被忽视pip install torch这一步体积非常大一个PyTorch的CUDA版本的轮子包就接近2GB如果直接把它和业务代码放在同一层每次改代码重新构建镜像都会重新走一遍安装流程耗时很恐怖。应该把依赖安装放在业务代码拷贝之前利用Docker的层缓存机制只要requirements.txt没变后面再构建都直接命中缓存秒级完成。另外一个很实际的建议是不要盲目追新版CUDA。对大部分团队来说CUDA 12.x系统版本下配PyTorch 2.x系列完全够用。选镜像时找到一个“已有一堆人在用、坑都被踩平了”的组合比换一个“看起来更新更强但资料很少”的组合省心得多。我常用的稳定组合是CUDA 12.4 cuDNN 9 PyTorch 2.3这个组合在vLLM、Ollama、FastAPI服务的部署中表现都很稳。2.4 NVIDIA Container Toolkit配置让容器用上GPU的关键镜像构建好了如果没有NVIDIA Container Toolkit容器起来也无法访问GPU。在Ubuntu上安装它也比较简单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-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker装好之后验证容器能否访问GPU的方式是docker run --rm --gpus all nvidia/cuda:12.4.0-runtime-ubuntu22.04 nvidia-smi如果能正常输出GPU信息就说明容器到GPU的链路已经通了。这一步做完后面的模型服务镜像可以在任何一台同样装好NVIDIA驱动的机器上跑起来不再需要关心CUDA环境问题这也正是镜像化部署的最大价值。还有一个小建议如果在Kubernetes集群里管理GPU资源可以调研一下NVIDIA GPU Operator它能把驱动、runtime这些组件全部作为集群内的Operator自动化装上节点扩缩容时不用再手动维护驱动版本了在企业级环境里属于省心很多的做法。3. 推理服务的核心工具选型、模型加载、API暴露与调优环境问题解决之后真正的推理服务工程问题才开始。调用一个模型做推理和把一个模型变成稳定服务之间隔着并发管理、显存控制、请求排队、错误处理这一整层。这一节我分别拆解推理引擎的选型和端到端上线过程。3.1 推理引擎选型Ollama还是vLLM还是手写PyTorch服务目前主流的推理部署方案无外乎三种路线各有偏向方案优点不足适配场景Ollama安装极简单一条命令拉起模型服务自动做显存管理并发控制能力有限高级参数暴露少开发调试、内部小规模使用vLLM吞吐量高PagedAttention优化显存支持高并发和连续批处理对显卡型号和算子库有一定要求首次启动需要编译/下载生产环境对外API服务原生PyTorch FastAPI定制自由度高适合特殊逻辑介入需要自己处理显存释放、并发控制、排队策略特殊结构模型、深度定制服务个人经验是能直接用vLLM就优先vLLM毕竟生产服务最终主要指标还是吞吐和延迟。但如果是面向个人开发者或者团队内部快速验证Ollama也完全够用而且在显存比较小的机器上Ollama的模型加载调度做得相当顺手。如果是基于国产加速卡比如昇腾要注意工具链适配昇腾社区目前主要支持MindIE或MindSpore推理路线直接照搬vLLM的NVIDIA方案会跑不起来部署前先查一下算子适配范围别盲目用网上教程。3.2 vLLM部署实操参数详解与启动配置生产环境里我用得最多的还是vLLM。这里给一个能直接跑的部署示例。# 安装vLLM注意要和CUDA版本对应 pip install vllm # 启动OpenAI兼容的推理服务 python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000参数含义--tensor-parallel-size使用多少张GPU并行切分模型。单卡能放下就填1多卡分布式推理时填对应的卡数vLLM会自动完成张量并行。--max-model-len模型最大上下文长度。显存有限时适当调小能有效增加并发吞吐。--gpu-memory-utilization允许vLLM使用显存的比例。默认是0.9意思是保留10%显存给CUDA context等额外开销这个值也可以根据实际情况调到0.95。--served-model-name对外暴露的模型名称。模型加载时可以本地读取模型路径也可以让它从HuggingFace自动拉取。国内网络环境不理想建议先在国内镜像站下载好权重到本地再挂载路径。服务启动后可以用一行命令验证是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen, messages: [{role: user, content: 你好}]}如果能返回正常的ChatCompletion响应说明推理服务已经就绪。这一步是整个上线流程的“关键里程碑”——从模型文件到能对外提供API的推理服务。3.3 Ollama部署与指定GPU的使用细节Ollama在轻量部署场景中的热度很高因为它确实足够省心。一条命令就能把主流开源模型下载下来并启动服务ollama serve ollama run qwen2.5:7b但Ollama在GPU使用上有一个容易让人困惑的点它默认会自动选择可用GPU但如果你有多张显卡希望指定某一张跑模型就需要手动设置显存可见性。做法如下# 只让Ollama看到第一张显卡 CUDA_VISIBLE_DEVICES0 ollama serve # 只让Ollama看到第二张显卡 CUDA_VISIBLE_DEVICES1 ollama serveWindows环境下的处理方式不太一样由于Windows下没有直接暴露CUDA_VISIBLE_DEVICES给整个系统一般是到Ollama的配置里去指定GPU。实际做法是打开Ollama的配置文件夹找到对应的环境变量配置文件把需要使用的GPU序号写进去然后重启Ollama服务。如果发现模型运行时Ollama没有用GPU优先检查是否缺少NVIDIA驱动或nvidia-smi是否正常输出。另一个常见原因是没有安装NVIDIA Container Toolkit——Ollama在Linux下实际是以容器方式加载GPU的工具链缺失就会退回CPU模式性能骤降。想确认模型是否真的跑在GPU上可以用ollama ps查看ollama ps NAME ID SIZE PROCESSOR UNTIL qwen2.5:7b xxx 5.2GB 100% GPU 4 minutes如果PROCESSOR一栏显示100% GPU就说明GPU推理正常工作如果看到100% CPU那就要回到上面两点排查。3.4 服务上线前的最终封装FastAPI对外暴露与自动重启vLLM和Ollama自带了API Server但很多时候业务侧还需要额外做一些逻辑比如鉴权、内容过滤、用量统计或者把多个模型统一路由到同一个网关。此时自己基于FastAPI封装一层会非常灵活。简单示例from fastapi import FastAPI from fastapi.responses import StreamingResponse import httpx app FastAPI() MODEL_SERVER http://127.0.0.1:8000/v1/chat/completions app.post(/chat) async def chat(request: dict): async with httpx.AsyncClient(timeout120) as client: resp await client.post(MODEL_SERVER, jsonrequest) return resp.json() app.post(/chat_stream) async def chat_stream(request: dict): request[stream] True async def gen(): async with httpx.AsyncClient(timeout120) as client: async with client.stream(POST, MODEL_SERVER, jsonrequest) as resp: async for line in resp.aiter_lines(): if line: yield line \n return StreamingResponse(gen(), media_typetext/event-stream)上线进程管理上建议直接交给systemd或者supervisor托管保证挂掉能自动拉起。如果是容器部署加上--restartalways策略。Python服务进程本身做守护不是强项不要裸跑。4. 推理服务上线后的稳定性排查与性能调优记录服务开通之后才进入真正的战场——压测、调优、处理各种奇怪的环境问题。这里挑几个出现频率最高的问题附上排查方法。4.1 GPU显存溢出OOM类问题的系统化排查CUDA out of memory大概是出现频率最高的错误但很多人看到这个错误就以为单纯是显存不够其实背后有几种完全不同的情况。情况一单次请求的显存峰值超过剩余空间。这种情况通常不是模型权重本身超了而是并发线程同时申请显存导致峰值叠加。常规解决策略是限制vLLM的max-num-seqs参数或Ollama的并发数给显存占用加一个天花板。情况二显存碎片化严重。长时间运行后PyTorch的缓存分配器会持有大量碎片化的缓存块即使显存总量还有剩余新的连续大块申请仍然会失败。我实际排查中遇到过一次显存剩余3GB但申请2GB显存仍然OOM的问题最终通过周期性重启服务或者调用torch.cuda.empty_cache()缓解。情况三代码里有显存泄漏。每请求都创建新的CUDA context或者不断加载模型副本服务跑着跑着显存占用一路走高压测一段时间后必然OOM。排查的时候可以每处理100个请求打一次显存占用观察趋势曲线是线性增长还是震荡平稳线性增长基本就是泄漏。实际遇到的最典型的过程是一张A100跑7B模型并发开到8路上下文长度拉满到32KKV Cache一下子把显存撑爆。用--max-model-len限制上下文长度同时把并发限制到4稳定运行率显著提升。显存不够时不一定是卡不行很多时候是参数没调对。4.2 GPU利用率上不去或程序崩溃类问题排查模型加载后GPU利用率很低通常出在以下几个地方请求并发太低GPU算力饥饿一个请求生成结束后另一个才进来中间空窗期太多。CPU侧数据预处理或tokenizer成为瓶颈GPU一直在等CPU喂数据。模型分割方式不对多卡并行时通信开销远大于计算收益。解决办法也直接提高并发请求数做benchmark看利用率曲线用nsys或NVIDIA Nsight Systems做一次profiling看时间花在哪个阶段检查数据加载路径是否做了异步处理。还有一种偶发性的问题日志里会出现类似GPU crash dump triggered的现象其实是GPU在执行某个kernel时发生了异常跳变。这种问题通常和驱动版本、CUDA版本稳定性有关或者是因为显卡在长时间高负载下温度过高触发了保护机制。排查顺序是先看nvidia-smi里温度是否异常再看驱动日志是否有ECC错误或Xid报错最后考虑回退驱动版本。4.3 多张显卡同时测试与统一调度如果机器上有多张GPU并且要验证每张卡是否都能正常工作可以用一个简单的命令并发的跑测试# 同时对所有GPU做压力测试 nvidia-smi dmon -s pucvmet -d 1 # 也可以通过CUDA_VISIBLE_DEVICES分别指定GPU运行PyTorch测试脚本 CUDA_VISIBLE_DEVICES0 python test_gpu.py CUDA_VISIBLE_DEVICES1 python test_gpu.py CUDA_VISIBLE_DEVICES2 python test_gpu.py test_gpu.py里可以放一个简单的矩阵乘法再加一次真实的CUDA内存申请与释放观察是否有报错。多GPU同时测试经常能发现单卡测试发现不了的问题比如供电不足导致的多卡同时高负载时降频、PCIe带宽抢占用导致的性能骤降。调度层面如果使用Docker多容器共享GPU建议通过--gpus device0,1来让容器指定可见的物理GPU不要直接用--gpus all一股脑全给否则容易出现资源争抢互相干扰。4.4 常见问题速查表现象大概率原因解决方案容器里nvidia-smi不可用未装NVIDIA Container Toolkit按文中的方法装nvidia-container-toolkit并重启DockerPyTorch提示CUDA不可用PyTorch装成了CPU版本使用--index-url https://download.pytorch.org/whl/cu124重装模型加载到一半OOMKV Cache 权重超过显存降max-model-len、减小gpu-memory-utilization的期望值或换更大显存卡Ollama在Windows下不调用GPU驱动/容器运行时缺失或配置未生效检查NVIDIA驱动、确认配置已设置并重启OllamaGPU利用率长期低于30%并发不足或数据预处理瓶颈加大压测并发、检查tokenizer与数据装载路径推理首token延迟高未做预热或模型权重没驻留显存挂载模型前先发几条请求做warmup确保权重页常驻显存vLLM启动报算子不支持显卡架构过老或版本不匹配升级显卡或改用TGI/Ollama方案还有个细节值得单独提一下很多框架在首次推理时会做kernel autotune会有一个明显的“预热”过程第一个请求可能要等几十秒才能返回这是正常的。生产上线前最好先发一次假请求让模型热起来否则监控系统会在服务刚启动时疯狂报警容易误判事故。4.5 服务灰度与回滚上线不只取决于推理本身最后聊聊大模型服务上线中经常被忽略的部分——发布策略。模型推理服务不像普通Web服务模型更新带来的行为变化难以通过单测完全覆盖所以建议至少要有两套推理服务实例一套旧模型一套新模型通过网关做灰度路由。先用5%到10%的流量打到新模型上观察延迟、错误率、用户反馈再逐步放量。一旦出现异常网关一键切回旧实例即可止血。如果团队规模不大没有自研网关也可以通过Nginx或Kong这类七层代理配置上游权重来实现简单的灰度分发。核心思路只有一个模型可以迭代但服务不能随便挂推理代码和模型文件每一次变更都要按照可回滚的标准走流程。我在实际部署中还有一个比较深的体会——GPU资源成本不要光看硬件租赁单价要看“单位token成本”。同样是跑7B模型vLLM用PagedAttention优化后单位显存能承担的并发请求量可能比naive部署高出三到四倍折算下来单token的GPU成本才是真实的成本。这也是为什么我一直强调显存参数看着够用远远不够“会调”比“买贵”重要得多。从选型那一刻开始到环境打包镜像再到服务上线和调优每一个环节都在为最终的单位成本与稳定性做累积。把这套链路理顺了后续不管换什么模型、加多少并发都是在已有框架上的替换升级不用每次从零开始踩坑。最后分享一个小技巧上线前的压测很有必要但别只测平均延迟要重点看P95和P99延迟。7B级别模型的推理在并发上来以后长尾延迟通常比平均值高出一个数量级而用户的体感往往由最慢的那次请求决定。我自己上线前都会留一两个小时专门跑并发压测把max-num-seqs、max-model-len这些参数用数据调到位再安全放量。 大模型推理部署进阶：从GPU选型到线上服务稳定调优
做推理部署这件事最容易被低估的从来不是模型本身而是从一张GPU到一条稳定线上服务的完整链路。我见过太多人卡在“模型在本地能跑”和“服务能上生产”之间的巨大鸿沟里——明明同一套权重换张显卡就OOM明明镜像在测试机好好的一到新的机器CUDA版本就不对压测一上来延迟直接翻倍还搞不清是显存带宽不够还是并发排队设计有问题。这篇文章就把我从GPU选型、CUDA环境镜像、再到推理服务上线的完整思路拆开讲一遍。所有内容都来自实际部署项目中的总结属于可以直接抄作业的那一类。涉及PyTorch、Ollama、vLLM的部署配置、NVIDIA显卡的选型逻辑、CUDA容器镜像的构建方法、服务压测与高并发优化。适合正在做模型部署、算法工程化、后端接入的同学参考也适合准备租GPU跑服务的团队避坑。1. 显卡选型不能只盯着显存先搞清推理的阻力在哪很多人选GPU就一句话“显存越大越好”这个观念在推理场景下其实非常危险。显存决定的是能不能装下模型而真正决定推理快不快的是显存带宽、算力利用率、并发调度能力这三项。模型参数量只是推理服务成本的起点不是全部。1.1 推理和训练的负载特征截然不同选型逻辑要分开训练是典型的“高算力密集”负载GPU绝大部分时间都在做矩阵乘法和梯度更新所以训练卡追求的是FLOPS每秒浮点运算次数和显存容量。推理不一样推理是“存储带宽密集”负载特征更重尤其是自回归生成类的大模型GPT类每一步都要把所有参数从显存里读一遍去做计算。我来列一个粗算模型。以7B参数模型为例半精度FP16状态下参数占用大约14GB显存如果按token逐个生成每生成一个token都需要把14GB过一遍假设GPU显存带宽是1TB/s比如A100 80G的带宽在2TB/s左右那理论上的token生成速度上限就是2000/14大约每秒142个token但这还是理想的数学上限真实环境加上KV Cache、注意力计算、调度开销能到上限的三分之一至二分之一就很不错了。这个分析告诉我们两件事。第一同样参数规模的模型在A100上比在普通显卡上快不完全是算力差距很大程度是显存带宽带来的第二推理场景比训练更容易受制于带宽所以选卡一定要把带宽放在显存之后第二位去权衡。1.2 用“模型参数 推理并发数”推导真实显存需求具体选卡时显存需求可以用一个经验公式来做前期估算 所需显存 ≈ 模型权重体积 × 1.2推理框架运行开销系数 KV Cache占用KV Cache这一项很多人会忽略。8个并发请求、4K上下文长度、7B模型下KV Cache的额外显存开销大约在1GB到3GB之间如果把上下文做到32K、并发加到32路这个数字会快速冲到十几GB。所以显存规划一定要把并发度和上下文长度算进去拿着一张24GB的卡跑7B模型长上下文多并发分分钟OOM。型号层面从我实际使用来看显卡型号显存显存带宽典型适配场景RTX 409024GB~1TB/s7B~13B模型私有化部署、中小并发、开发测试L2048GB~864GB/s13B~32B模型推理性价比不错的推理卡A100 80G80GB~2TB/s70B级别模型部署、高并发生产环境L40S48GB~864GB/s通用AI推理渲染类混合负载昇腾910B64GB高带宽纯国产化环境约束下的部署替代方案以7B模型8路并发8K上下文为基准需求一张RTX 4090或者L20基本能平稳扛住没必要动辄就上A100。反过来说如果你想在单卡跑满70B的量化版本例如Q4量化后体积约40GB那48GB的卡就会非常勉强A100 80G或H系列会更稳妥。1.3 推理服务选卡的综合考量并发度、生态兼容、成本模型另外一个非常容易踩坑的地方是只看推理性能不看生态兼容。NVIDIA的TensorRT-LLM、vLLM、Triton Inference Server等一系列工具链都基于CUDA开发对N卡的支持永远是最完善最及时的。如果用非NVIDIA的产品例如AMD的ROCm或者国产加速卡很多时候不是不能跑而是要面对算子兼容、框架版本滞后、资料稀缺这一连串问题。对大多数团队如果没有强制的国产化需求第一块推理卡老老实实买NVIDIA不会错。成本模型也不只是显卡硬件价格还要算GPU的利用率。GPU租用按小时计费时选一块过大显存的卡但跑不满每小时都在浪费钱。我一般建议团队先按“最大目标模型预期并发”圈出显存下限再在这个基础上叠加一档余量然后去租对应规格的实例测试而不是一步到位买最高配。拿实际业务请求压测几天用数据决定最终采购什么显卡。GPU选型本质上不是参数游戏是需求匹配游戏。2. CUDA环境与镜像准备把“版本地狱”消灭在构建阶段环境配置在大模型部署项目里占用时间比例很高。如果直接在物理机上逐一安装显卡驱动、CUDA Toolkit、cuDNN和PyTorch每换一台机器就要重来一遍中间任何一个版本对不上就有一堆诡异问题。把环境固化成镜像才是服务能平滑迁移和上线的关键。2.1 驱动、CUDA、PyTorch三者的兼容关系先理清概念虽然很多时候混着说但它们是完全不同的东西NVIDIA驱动运行在操作系统内核层负责和GPU硬件通信是一切的上层基础。CUDA Toolkit包含编译器、运行时库和开发工具是给开发者写CUDA程序用的完整工具链。cuDNN针对深度学习的卷积、循环神经网络等算子做了深度优化的加速库跑深度学习框架几乎必装。PyTorch/TensorFlow等框架在CUDA运行时上封装了一层用户友好的API。这里有一个特别常见的误区很多人在服务器上执行nvidia-smi看到右上角显示的CUDA Version是12.4就以为CUDA Toolkit已经装好了这个理解不对。nvidia-smi里显示的是驱动所支持的最高CUDA版本它不代表系统里实际安装了对应版本的CUDA Toolkit。判断PyTorch能不能用GPU不能只看驱动要看PyTorch自带的CUDA运行时和驱动版本是否能匹配。NVIDIA驱动的兼容策略是向后兼容的也就是说只要驱动版本足够新驱动内置的CUDA运行时能够兼容旧版Toolkit编译出来的程序。所以最稳的做法是先把NVIDIA驱动升到较新版本然后上面放不同CUDA版本的容器镜像完全没必要在主机上纠结CUDA版本切换。2.2 Ubuntu系统上安装NVIDIA驱动如果是全新的Ubuntu服务器安装驱动的步骤建议走以下流程# 1. 检查推荐驱动版本 ubuntu-drivers devices # 2. 自动安装推荐版本也可以手动指定例如nvidia-driver-535 sudo apt install -y nvidia-driver-535 # 3. 重启后检查 nvidia-smi重启之后执行nvidia-smi能看到类似下面的输出就说明驱动OK了----------------------------------------------------------------------------- | NVIDIA-SMI 535.xx.xx Driver Version: 535.xx.xx CUDA Version: 12.2 | -----------------------------------------------------------------------------这里要提醒一下CUDA Version显示12.2只能说明当前驱动最高支持到CUDA 12.2并不意味着系统已装好了CUDA Toolkit。真正的CUDA环境应该放在容器里解决。安装驱动的过程中我也踩过不少坑。比如在部分云服务器上禁用nouveau开源驱动是必要的前置步骤否则会和NVIDIA驱动冲突装完重启后驱动加载失败。常规做法是sudo bash -c echo blacklist nouveau /etc/modprobe.d/blacklist-nvidia-nouveau.conf sudo update-initramfs -u另外如果不需要图形界面建议直接安装server版驱动而不是desktop版少装一堆用不到的依赖也减少后续系统升级时驱动被破坏的概率。2.3 基于nvidia/cuda基础镜像构建CUDA镜像容器化部署大模型推理服务时镜像的构建思路通常基于NVIDIA官方提供的nvidia/cuda镜像来分层扩展。只要服务器安装了NVIDIA Container Toolkit容器内就能直接访问GPU。我推荐直接用官方的CUDA基础镜像来作为起点从Docker Hub拉取选择带runtime的关键词而不是devel因为部署阶段不需要编译器工具链镜像体积会更小。例如# 用带cudnn的runtime镜像作为基础 FROM nvidia/cuda:12.4.0-runtime-ubuntu22.04 # 安装Python和基础工具 RUN apt-get update apt-get install -y \ python3.10 python3-pip curl \ ln -s /usr/bin/python3 /usr/bin/python # 安装PyTorch的CUDA版本这里用到清华源加速 RUN pip install torch --index-url https://download.pytorch.org/whl/cu124 # 拷贝推理服务代码 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . . CMD [python, serve.py]镜像构建时有一个细节经常被忽视pip install torch这一步体积非常大一个PyTorch的CUDA版本的轮子包就接近2GB如果直接把它和业务代码放在同一层每次改代码重新构建镜像都会重新走一遍安装流程耗时很恐怖。应该把依赖安装放在业务代码拷贝之前利用Docker的层缓存机制只要requirements.txt没变后面再构建都直接命中缓存秒级完成。另外一个很实际的建议是不要盲目追新版CUDA。对大部分团队来说CUDA 12.x系统版本下配PyTorch 2.x系列完全够用。选镜像时找到一个“已有一堆人在用、坑都被踩平了”的组合比换一个“看起来更新更强但资料很少”的组合省心得多。我常用的稳定组合是CUDA 12.4 cuDNN 9 PyTorch 2.3这个组合在vLLM、Ollama、FastAPI服务的部署中表现都很稳。2.4 NVIDIA Container Toolkit配置让容器用上GPU的关键镜像构建好了如果没有NVIDIA Container Toolkit容器起来也无法访问GPU。在Ubuntu上安装它也比较简单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-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker装好之后验证容器能否访问GPU的方式是docker run --rm --gpus all nvidia/cuda:12.4.0-runtime-ubuntu22.04 nvidia-smi如果能正常输出GPU信息就说明容器到GPU的链路已经通了。这一步做完后面的模型服务镜像可以在任何一台同样装好NVIDIA驱动的机器上跑起来不再需要关心CUDA环境问题这也正是镜像化部署的最大价值。还有一个小建议如果在Kubernetes集群里管理GPU资源可以调研一下NVIDIA GPU Operator它能把驱动、runtime这些组件全部作为集群内的Operator自动化装上节点扩缩容时不用再手动维护驱动版本了在企业级环境里属于省心很多的做法。3. 推理服务的核心工具选型、模型加载、API暴露与调优环境问题解决之后真正的推理服务工程问题才开始。调用一个模型做推理和把一个模型变成稳定服务之间隔着并发管理、显存控制、请求排队、错误处理这一整层。这一节我分别拆解推理引擎的选型和端到端上线过程。3.1 推理引擎选型Ollama还是vLLM还是手写PyTorch服务目前主流的推理部署方案无外乎三种路线各有偏向方案优点不足适配场景Ollama安装极简单一条命令拉起模型服务自动做显存管理并发控制能力有限高级参数暴露少开发调试、内部小规模使用vLLM吞吐量高PagedAttention优化显存支持高并发和连续批处理对显卡型号和算子库有一定要求首次启动需要编译/下载生产环境对外API服务原生PyTorch FastAPI定制自由度高适合特殊逻辑介入需要自己处理显存释放、并发控制、排队策略特殊结构模型、深度定制服务个人经验是能直接用vLLM就优先vLLM毕竟生产服务最终主要指标还是吞吐和延迟。但如果是面向个人开发者或者团队内部快速验证Ollama也完全够用而且在显存比较小的机器上Ollama的模型加载调度做得相当顺手。如果是基于国产加速卡比如昇腾要注意工具链适配昇腾社区目前主要支持MindIE或MindSpore推理路线直接照搬vLLM的NVIDIA方案会跑不起来部署前先查一下算子适配范围别盲目用网上教程。3.2 vLLM部署实操参数详解与启动配置生产环境里我用得最多的还是vLLM。这里给一个能直接跑的部署示例。# 安装vLLM注意要和CUDA版本对应 pip install vllm # 启动OpenAI兼容的推理服务 python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000参数含义--tensor-parallel-size使用多少张GPU并行切分模型。单卡能放下就填1多卡分布式推理时填对应的卡数vLLM会自动完成张量并行。--max-model-len模型最大上下文长度。显存有限时适当调小能有效增加并发吞吐。--gpu-memory-utilization允许vLLM使用显存的比例。默认是0.9意思是保留10%显存给CUDA context等额外开销这个值也可以根据实际情况调到0.95。--served-model-name对外暴露的模型名称。模型加载时可以本地读取模型路径也可以让它从HuggingFace自动拉取。国内网络环境不理想建议先在国内镜像站下载好权重到本地再挂载路径。服务启动后可以用一行命令验证是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen, messages: [{role: user, content: 你好}]}如果能返回正常的ChatCompletion响应说明推理服务已经就绪。这一步是整个上线流程的“关键里程碑”——从模型文件到能对外提供API的推理服务。3.3 Ollama部署与指定GPU的使用细节Ollama在轻量部署场景中的热度很高因为它确实足够省心。一条命令就能把主流开源模型下载下来并启动服务ollama serve ollama run qwen2.5:7b但Ollama在GPU使用上有一个容易让人困惑的点它默认会自动选择可用GPU但如果你有多张显卡希望指定某一张跑模型就需要手动设置显存可见性。做法如下# 只让Ollama看到第一张显卡 CUDA_VISIBLE_DEVICES0 ollama serve # 只让Ollama看到第二张显卡 CUDA_VISIBLE_DEVICES1 ollama serveWindows环境下的处理方式不太一样由于Windows下没有直接暴露CUDA_VISIBLE_DEVICES给整个系统一般是到Ollama的配置里去指定GPU。实际做法是打开Ollama的配置文件夹找到对应的环境变量配置文件把需要使用的GPU序号写进去然后重启Ollama服务。如果发现模型运行时Ollama没有用GPU优先检查是否缺少NVIDIA驱动或nvidia-smi是否正常输出。另一个常见原因是没有安装NVIDIA Container Toolkit——Ollama在Linux下实际是以容器方式加载GPU的工具链缺失就会退回CPU模式性能骤降。想确认模型是否真的跑在GPU上可以用ollama ps查看ollama ps NAME ID SIZE PROCESSOR UNTIL qwen2.5:7b xxx 5.2GB 100% GPU 4 minutes如果PROCESSOR一栏显示100% GPU就说明GPU推理正常工作如果看到100% CPU那就要回到上面两点排查。3.4 服务上线前的最终封装FastAPI对外暴露与自动重启vLLM和Ollama自带了API Server但很多时候业务侧还需要额外做一些逻辑比如鉴权、内容过滤、用量统计或者把多个模型统一路由到同一个网关。此时自己基于FastAPI封装一层会非常灵活。简单示例from fastapi import FastAPI from fastapi.responses import StreamingResponse import httpx app FastAPI() MODEL_SERVER http://127.0.0.1:8000/v1/chat/completions app.post(/chat) async def chat(request: dict): async with httpx.AsyncClient(timeout120) as client: resp await client.post(MODEL_SERVER, jsonrequest) return resp.json() app.post(/chat_stream) async def chat_stream(request: dict): request[stream] True async def gen(): async with httpx.AsyncClient(timeout120) as client: async with client.stream(POST, MODEL_SERVER, jsonrequest) as resp: async for line in resp.aiter_lines(): if line: yield line \n return StreamingResponse(gen(), media_typetext/event-stream)上线进程管理上建议直接交给systemd或者supervisor托管保证挂掉能自动拉起。如果是容器部署加上--restartalways策略。Python服务进程本身做守护不是强项不要裸跑。4. 推理服务上线后的稳定性排查与性能调优记录服务开通之后才进入真正的战场——压测、调优、处理各种奇怪的环境问题。这里挑几个出现频率最高的问题附上排查方法。4.1 GPU显存溢出OOM类问题的系统化排查CUDA out of memory大概是出现频率最高的错误但很多人看到这个错误就以为单纯是显存不够其实背后有几种完全不同的情况。情况一单次请求的显存峰值超过剩余空间。这种情况通常不是模型权重本身超了而是并发线程同时申请显存导致峰值叠加。常规解决策略是限制vLLM的max-num-seqs参数或Ollama的并发数给显存占用加一个天花板。情况二显存碎片化严重。长时间运行后PyTorch的缓存分配器会持有大量碎片化的缓存块即使显存总量还有剩余新的连续大块申请仍然会失败。我实际排查中遇到过一次显存剩余3GB但申请2GB显存仍然OOM的问题最终通过周期性重启服务或者调用torch.cuda.empty_cache()缓解。情况三代码里有显存泄漏。每请求都创建新的CUDA context或者不断加载模型副本服务跑着跑着显存占用一路走高压测一段时间后必然OOM。排查的时候可以每处理100个请求打一次显存占用观察趋势曲线是线性增长还是震荡平稳线性增长基本就是泄漏。实际遇到的最典型的过程是一张A100跑7B模型并发开到8路上下文长度拉满到32KKV Cache一下子把显存撑爆。用--max-model-len限制上下文长度同时把并发限制到4稳定运行率显著提升。显存不够时不一定是卡不行很多时候是参数没调对。4.2 GPU利用率上不去或程序崩溃类问题排查模型加载后GPU利用率很低通常出在以下几个地方请求并发太低GPU算力饥饿一个请求生成结束后另一个才进来中间空窗期太多。CPU侧数据预处理或tokenizer成为瓶颈GPU一直在等CPU喂数据。模型分割方式不对多卡并行时通信开销远大于计算收益。解决办法也直接提高并发请求数做benchmark看利用率曲线用nsys或NVIDIA Nsight Systems做一次profiling看时间花在哪个阶段检查数据加载路径是否做了异步处理。还有一种偶发性的问题日志里会出现类似GPU crash dump triggered的现象其实是GPU在执行某个kernel时发生了异常跳变。这种问题通常和驱动版本、CUDA版本稳定性有关或者是因为显卡在长时间高负载下温度过高触发了保护机制。排查顺序是先看nvidia-smi里温度是否异常再看驱动日志是否有ECC错误或Xid报错最后考虑回退驱动版本。4.3 多张显卡同时测试与统一调度如果机器上有多张GPU并且要验证每张卡是否都能正常工作可以用一个简单的命令并发的跑测试# 同时对所有GPU做压力测试 nvidia-smi dmon -s pucvmet -d 1 # 也可以通过CUDA_VISIBLE_DEVICES分别指定GPU运行PyTorch测试脚本 CUDA_VISIBLE_DEVICES0 python test_gpu.py CUDA_VISIBLE_DEVICES1 python test_gpu.py CUDA_VISIBLE_DEVICES2 python test_gpu.py test_gpu.py里可以放一个简单的矩阵乘法再加一次真实的CUDA内存申请与释放观察是否有报错。多GPU同时测试经常能发现单卡测试发现不了的问题比如供电不足导致的多卡同时高负载时降频、PCIe带宽抢占用导致的性能骤降。调度层面如果使用Docker多容器共享GPU建议通过--gpus device0,1来让容器指定可见的物理GPU不要直接用--gpus all一股脑全给否则容易出现资源争抢互相干扰。4.4 常见问题速查表现象大概率原因解决方案容器里nvidia-smi不可用未装NVIDIA Container Toolkit按文中的方法装nvidia-container-toolkit并重启DockerPyTorch提示CUDA不可用PyTorch装成了CPU版本使用--index-url https://download.pytorch.org/whl/cu124重装模型加载到一半OOMKV Cache 权重超过显存降max-model-len、减小gpu-memory-utilization的期望值或换更大显存卡Ollama在Windows下不调用GPU驱动/容器运行时缺失或配置未生效检查NVIDIA驱动、确认配置已设置并重启OllamaGPU利用率长期低于30%并发不足或数据预处理瓶颈加大压测并发、检查tokenizer与数据装载路径推理首token延迟高未做预热或模型权重没驻留显存挂载模型前先发几条请求做warmup确保权重页常驻显存vLLM启动报算子不支持显卡架构过老或版本不匹配升级显卡或改用TGI/Ollama方案还有个细节值得单独提一下很多框架在首次推理时会做kernel autotune会有一个明显的“预热”过程第一个请求可能要等几十秒才能返回这是正常的。生产上线前最好先发一次假请求让模型热起来否则监控系统会在服务刚启动时疯狂报警容易误判事故。4.5 服务灰度与回滚上线不只取决于推理本身最后聊聊大模型服务上线中经常被忽略的部分——发布策略。模型推理服务不像普通Web服务模型更新带来的行为变化难以通过单测完全覆盖所以建议至少要有两套推理服务实例一套旧模型一套新模型通过网关做灰度路由。先用5%到10%的流量打到新模型上观察延迟、错误率、用户反馈再逐步放量。一旦出现异常网关一键切回旧实例即可止血。如果团队规模不大没有自研网关也可以通过Nginx或Kong这类七层代理配置上游权重来实现简单的灰度分发。核心思路只有一个模型可以迭代但服务不能随便挂推理代码和模型文件每一次变更都要按照可回滚的标准走流程。我在实际部署中还有一个比较深的体会——GPU资源成本不要光看硬件租赁单价要看“单位token成本”。同样是跑7B模型vLLM用PagedAttention优化后单位显存能承担的并发请求量可能比naive部署高出三到四倍折算下来单token的GPU成本才是真实的成本。这也是为什么我一直强调显存参数看着够用远远不够“会调”比“买贵”重要得多。从选型那一刻开始到环境打包镜像再到服务上线和调优每一个环节都在为最终的单位成本与稳定性做累积。把这套链路理顺了后续不管换什么模型、加多少并发都是在已有框架上的替换升级不用每次从零开始踩坑。最后分享一个小技巧上线前的压测很有必要但别只测平均延迟要重点看P95和P99延迟。7B级别模型的推理在并发上来以后长尾延迟通常比平均值高出一个数量级而用户的体感往往由最慢的那次请求决定。我自己上线前都会留一两个小时专门跑并发压测把max-num-seqs、max-model-len这些参数用数据调到位再安全放量。