1. 为什么要在本地跑 DeepSeek-V4从数据主权到推理成本的真实账本把 DeepSeek-V4 这种量级的模型塞进自己的机箱放在两年前还是件不太现实的事。但到了现在随着模型量化技术的成熟和消费级显卡显存的持续膨胀本地部署已经从极客玩具变成了很多团队认真评估的生产方案。我自己前前后后折腾过七八种部署路径从最早的纯 CPU 推理到现在的多卡张量并行踩过的坑足够写一本小册子。这篇就把我实测过的四套方案完整摊开讲包括每套方案适合谁、硬件门槛在哪、以及那些官方文档里不会写的细节。先说清楚一件事本地部署 DeepSeek-V4 的核心动机绝大多数情况下不是省钱。如果你只是偶尔用用云端 API 的按量计费远比买卡划算。真正驱动本地部署的是三个东西——数据不出内网、推理延迟可控、以及不受调用配额限制。尤其是涉及企业内部文档、代码库、客户资料的场景数据主权这条就足以一票否决云端方案。那成本账到底怎么算我拿 RTX 5090 实测的数据给你一个参考锚点。DeepSeek-V4 的 FP16 原始权重体积相当可观直接全精度加载对显存的要求会劝退大部分人。所以实际部署中量化是绕不开的一步。常见的量化档位和对应的显存占用大致是这样的量化精度权重体积约最低显存需求推理质量损失适用场景FP16基准 100%极高无多卡企业级INT8约 50%高极小单卡高配Q4_K_M约 27%中等轻微消费级主力Q4_0约 25%中等偏低可感知显存紧张Q3_K_M约 20%低明显极限压缩这张表是我自己反复测下来总结的经验值不同量化工具的具体数字会有出入但量级关系是稳的。关键判断点在于你要的是能跑起来还是跑得好。Q4_K_M 是我个人最推荐的平衡点质量损失在日常问答和代码补全场景下几乎感知不到而显存占用直接砍到四分之一左右。再说延迟。本地推理的首 token 延迟TTFT和吞吐量tokens/s跟硬件强相关。RTX 5090 单卡跑 Q4 量化的 DeepSeek-V4在 batch size 为 1 的情况下实测生成速度能稳定在一个相当可用的区间具体数字后面每套方案里我会分别给。这里先给个结论单卡 5090 跑量化版日常交互式使用完全够用但如果你要做批量推理或者多用户并发就得上多卡或者换 vLLM 这类高吞吐框架。还有一个容易被忽略的点模型加载时间。第一次加载几十 GB 的权重到显存冷启动可能要几分钟。如果你把它当成一个随时待命的服务就得考虑常驻内存而不是用完就卸载。这个细节直接影响到你选哪套方案——Ollama 这类工具默认会做模型保活而某些手动加载的方式每次都要重新读盘。2. 四套方案的全景对比先选路线再抠细节在动手之前我强烈建议你先花十分钟把四套方案的定位搞清楚。很多人一上来就照着某个教程装 Ollama结果发现自己的场景根本不适合白白浪费时间。这四套方案我按上手难度和可控程度两个维度排了个序你可以对号入座。方案一Ollama——开箱即用的入门首选。它的定位就是让本地跑模型像装个 App 一样简单。一条命令拉取模型一条命令启动服务自带 OpenAI 兼容的 API 接口。适合个人开发者、快速验证想法、以及对底层细节不感兴趣的用户。缺点是可控性有限量化档位、并行策略这些底层参数你基本插不上手。方案二LM Studio——带图形界面的桌面方案。如果你不习惯命令行LM Studio 提供了完整的 GUI模型下载、参数调节、对话测试都在一个界面里完成。它底层其实也是基于类似的推理引擎但把复杂度藏起来了。适合产品经理、设计师这类需要快速体验但不想碰终端的人群。方案三vLLM——生产级高吞吐引擎。这是真正给企业和服务端准备的方案。它的核心优势是 PagedAttention 和连续批处理continuous batching在高并发场景下的吞吐量能把 Ollama 甩开好几条街。支持张量并行可以跨多张卡部署大模型。代价是配置复杂对环境和显存管理的要求高。适合有运维能力的团队、需要支撑多用户的内部服务。方案四llama.cpp 手动编译——极致可控的硬核路线。如果你想榨干每一滴性能或者有特殊的量化需求直接上手 llama.cpp 是最灵活的。你可以自己决定量化方式、线程数、GPU 层数分配。缺点是全手动编译、转换、调参都得自己来。适合喜欢折腾、对性能有极致要求的工程师。为了让你一眼看清差异我把四套方案的关键指标拉了个对比维度OllamaLM StudiovLLMllama.cpp上手难度低极低高中高图形界面无有无无并发吞吐一般一般极强一般多卡支持有限有限完善部分量化灵活度低低中极高API 兼容OpenAIOpenAIOpenAI需自建适合人群个人/验证非技术团队/生产硬核玩家选路线的核心逻辑就一句话先问自己我要不要支撑多人同时用如果要直接上 vLLM别在 Ollama 上浪费时间如果只是自己用Ollama 或 LM Studio 足够如果对性能有执念llama.cpp 等你。3. Ollama 路线实操从安装到跑通 DeepSeek-V4 的完整链路Ollama 是我推荐给所有人的第一站哪怕你最终要用 vLLM也建议先用 Ollama 把模型跑起来感受一下确认硬件没问题、模型质量符合预期再去折腾复杂的方案。3.1 安装环节那些没人告诉你的坑Ollama 的安装本身很简单官网下载对应系统的安装包双击或者一行脚本搞定。但这里有几个实操细节值得单独拎出来说。第一安装路径问题。Windows 上默认装到 C 盘而模型文件默认也存放在用户目录下。DeepSeek-V4 量化后动辄几十 GBC 盘很容易被撑爆。解决办法是设置环境变量OLLAMA_MODELS指向一个大容量盘符。这个变量必须在启动 Ollama 服务之前设置好否则不生效。Linux 上则是通过 systemd 的 service 文件里配置Environment字段。第二下载慢的问题。这是国内用户最常遇到的。模型仓库的拉取速度受网络影响很大几十 GB 的模型可能下到一半就断了。我的经验是优先找国内的镜像源或者用支持断点续传的下载工具先把模型文件拉下来再手动导入。Ollama 支持从本地文件导入模型具体做法是写一个 Modelfile用FROM指向本地的 GGUF 文件然后ollama create创建。第三版本兼容性。Ollama 更新很频繁新版本对新型号显卡的支持往往更好。如果你用的是 RTX 5090 这类新卡务必确认 Ollama 版本足够新否则可能识别不到 GPU退化成纯 CPU 推理速度会慢到让你怀疑人生。3.2 拉取与运行 DeepSeek-V4安装完成后拉取模型就是一条命令的事。但这里有个关键选择拉哪个量化版本。Ollama 的模型库里通常会提供多个 tag对应不同的量化精度。默认 tag 一般是最通用的量化档但未必最适合你。我的建议是先用默认版本跑通确认能用之后再根据显存余量决定要不要换更高精度的版本。运行命令很简单ollama run deepseek-v4第一次运行会自动下载模型耐心等待。下载完成后会进入交互式对话界面你可以直接测试。如果要作为服务常驻用ollama serve这会在本地起一个服务默认监听 11434 端口提供 OpenAI 兼容的 API。你的其他应用就可以通过这个接口调用本地模型了。3.3 RTX 5090 实测数据与调优在 RTX 5090 单卡上跑 Q4 量化的 DeepSeek-V4我的实测结果是生成速度稳定在每秒几十个 token 的量级首 token 延迟在秒级以内。这个表现对于交互式对话完全够用打字的速度绝对跟不上模型生成的速度。但有几个调优点能进一步压榨性能。一是 GPU 层数。Ollama 会自动判断能卸载多少层到 GPU但有时候判断偏保守。你可以通过参数手动指定num_gpu层数把尽可能多的层塞进显存。二是上下文长度。上下文越长KV Cache 占用越大显存压力越高。如果发现显存吃紧适当调小上下文窗口能明显缓解。三是并行请求数。Ollama 默认的并行度不高如果你要同时服务多个请求需要调整OLLAMA_NUM_PARALLEL环境变量。提示调整任何参数后记得重启 Ollama 服务否则不生效。这是新手最容易犯的错。3.4 Ollama 的边界在哪里用了几个月 Ollama 之后我对它的能力边界有了清晰认识。它适合单用户、低并发、快速验证的场景。一旦你要支撑十几个人的团队同时使用或者要做批量文档处理它的吞吐瓶颈就会暴露出来。这时候不是调参能解决的而是架构层面的限制必须换 vLLM。另外Ollama 对多卡的支持比较有限它不像 vLLM 那样有成熟的张量并行方案。如果你有多张卡想一起用Ollama 更多是每张卡各跑各的而不是合力跑一个模型。这个区别在部署超大模型时很关键。4. vLLM 生产级部署多卡并行与高并发的正确打开方式当你决定上 vLLM说明你已经过了玩一玩的阶段开始认真考虑把它做成一个能扛住真实流量的服务。vLLM 的配置确实复杂但它的性能回报是实打实的。4.1 环境准备Python 生态的依赖管理vLLM 是 Python 生态的项目安装方式主要是 pip。但这里有个大坑PyTorch 版本和 CUDA 版本的匹配。vLLM 对底层依赖很敏感装错版本会导致各种莫名其妙的报错比如找不到 CUDA 设备、算子不支持等等。我的做法是先确认显卡驱动支持的 CUDA 版本然后去 PyTorch 官网找到对应的安装命令先装好 PyTorch再装 vLLM。不要直接pip install vllm就完事那样很可能拉到一个和你的环境不匹配的版本。用虚拟环境隔离是基本操作conda 或者 venv 都行别在系统 Python 里瞎搞。4.2 单机多卡部署的核心参数vLLM 最强大的能力之一就是张量并行Tensor Parallelism可以把一个大模型切分到多张卡上。启动命令里最关键的参数是--tensor-parallel-size它决定了用几张卡来跑。假设你有 4 张卡想全部用上vllm serve deepseek-v4 \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192这里每个参数都有讲究。--tensor-parallel-size 4表示把模型切成 4 份每张卡放一份。--gpu-memory-utilization 0.9表示允许 vLLM 使用 90% 的显存留一点给系统和其他进程。--max-model-len控制最大上下文长度这个值直接影响 KV Cache 的显存占用设太大容易 OOM。张量并行的卡数不是随便设的它通常需要能整除模型的注意力头数。如果设了一个不合适的值vLLM 启动时会直接报错。一般 2、4、8 是比较安全的选择。4.3 连续批处理带来的吞吐飞跃vLLM 真正的杀手锏是 PagedAttention 和连续批处理。简单说传统推理框架处理并发请求时要么排队一个个来要么把请求凑成一批一起算中间会有大量等待。而 vLLM 能把不同请求的 KV Cache 分页管理动态地把新请求插进正在进行的批次里让 GPU 始终处于满载状态。这个机制带来的吞吐提升在高并发下非常明显。我实测过同样的硬件Ollama 在十几个并发请求下就开始明显排队而 vLLM 能轻松扛住几十个并发还保持稳定输出。如果你的场景是团队共享或者对外提供服务这个差距就是决定性的。4.4 踩坑记录那些让服务起不来的报错vLLM 的报错信息有时候不太友好我整理几个最常见的。显存不足OOM最常见。解决办法是降低--gpu-memory-utilization、减小--max-model-len、或者换更激进的量化。有时候也是因为张量并行度设小了模型没切开。模型类找不到类似ValueError: model class ... not found这种通常是 vLLM 版本太旧不认识新的模型架构。升级 vLLM 到最新版一般能解决。CUDA 版本不匹配报错里会出现 CUDA 相关的字样。这时候要检查 PyTorch 的 CUDA 版本和系统驱动是否兼容。端口占用vLLM 默认监听 8000 端口如果被占用会启动失败。用--port换一个。注意vLLM 启动时会预分配显存所以启动瞬间显存占用就会拉满。别看到显存满了就以为出问题了那是正常行为。4.5 纯 CPU 模式的适用边界vLLM 也支持纯 CPU 模式但说实话用 CPU 跑 DeepSeek-V4 这种量级的模型体验只能用能跑但别指望来形容。生成速度会慢到每秒几个 token 甚至更低只适合做离线批处理或者对延迟完全不敏感的场景。如果你手上没有像样的 GPU与其硬上 vLLM CPU 模式不如考虑用 llama.cpp 的 CPU 优化版本效率会好一些。5. 量化、显存与性能的三角平衡把硬件吃干榨净这一节专门讲怎么在有限的硬件上把性能调到最优。这是区分能跑和跑得好的关键。5.1 量化档位怎么选才不后悔前面表格里给了量化档位的大致参考但实际选择时还要考虑你的具体用途。做代码补全和逻辑推理对量化损失更敏感建议用 Q4_K_M 及以上做文本摘要和简单问答Q4_0 甚至 Q3 都能接受。我的经验法则是先用一个中等量化档跑起来然后拿一批你熟悉的测试问题去问对比云端版本的回答质量。如果差异在你可接受范围内就定下来如果明显变差就往上提一档量化。不要盲目追求最高精度显存浪费了不说速度还慢。5.2 显存占用的构成拆解很多人以为显存只被模型权重占用其实不然。显存占用大致分三块模型权重、KV Cache、以及推理过程中的临时激活值。权重是固定的KV Cache 随上下文长度和并发数增长激活值则和 batch size 相关。理解了这一点你就能明白为什么模型能加载不等于能正常推理。有时候权重刚好塞进显存但一推理就 OOM就是因为 KV Cache 和激活值没算进去。留出至少 20% 的显存余量是安全线。5.3 RTX 5090 上的实测调优组合在 5090 上我最终稳定下来的一套配置是Q4_K_M 量化、上下文长度 8192、GPU 层数拉满、并行请求数适中。这套组合下单用户交互体验流畅小团队共享也不会明显卡顿。如果你显存更充裕可以尝试把上下文拉到 16384 甚至更高处理长文档会更从容。但要注意上下文翻倍KV Cache 也大致翻倍显存压力会明显上升。5.4 多模型共存的资源分配热词里有人问vllm 多个模型怎么搞。实际做法有两种一是起多个 vLLM 实例每个实例绑定不同的卡和端口二是在同一个实例里用 LoRA 适配器切换。前者资源隔离好但浪费显存后者省显存但配置复杂。如果几个模型都要常驻建议按卡的物理隔离来分配别让它们抢同一张卡。6. 常见报错与疑难杂症的排查手册部署过程中遇到的报错八成集中在几个地方。我把它们整理成一张排查表遇到问题先对号入座。报错现象可能原因排查方向识别不到 GPU驱动/版本不匹配检查驱动版本、框架 CUDA 支持模型加载 OOM量化档位过高换更低量化或减上下文推理中途 OOMKV Cache 超限降并发、减上下文长度生成速度极慢退化成 CPU 推理确认 GPU 层数是否拉满API 400 错误模型名不匹配核对调用的模型名称服务启动失败端口占用/依赖缺失换端口、补依赖关于那个api error: 400 the supported api model names are...的报错本质是你调用的模型名和服务端注册的模型名对不上。解决方法是先用列出模型的接口查一下服务端到底注册了哪些名字然后照着改你的调用参数。这个坑在切换不同部署方案时特别常见因为每个方案对模型的命名习惯不一样。还有一个高频问题是模型文件损坏或者下载不完整导致的加载失败。判断方法是对比文件大小和官方公布的大小差太多就是没下完。重新下载时务必用支持校验的方式。7. 从个人玩具到团队服务部署架构的演进思路最后聊聊架构层面的思考。个人用和团队用部署方式完全是两码事。个人用一台机器、一个 Ollama、一个模型齐活。团队用你得考虑服务的高可用、请求的负载均衡、模型的版本管理、以及访问的权限控制。这时候通常的做法是后端用 vLLM 起推理服务前面加一层网关做鉴权和限流再配一个监控看显存和吞吐。如果团队规模再大一点可能还要考虑多机部署把推理服务分散到几台机器上用统一的入口对外。这时候模型的分发、配置的同步、日志的收集都会变成新的问题。我的建议是不要一步到位。先用最简单的方案跑起来让团队用上收集真实反馈再根据瓶颈逐步演进。很多团队一上来就搭一套复杂的架构结果发现根本用不上维护成本还高。从 Ollama 起步遇到瓶颈再换 vLLM这个路径对大多数团队都是最优的。我个人在实际操作中的体会是本地部署这件事最难的不是技术本身而是想清楚你到底要什么。是想省钱还是想要数据安全还是想要低延迟还是纯粹想折腾目标不同方案选择天差地别。把这个问题想明白了剩下的都是查文档和试错的事。
DeepSeek-V4本地部署实战：Ollama、vLLM、llama.cpp与LM Studio四套方案全对比
1. 为什么要在本地跑 DeepSeek-V4从数据主权到推理成本的真实账本把 DeepSeek-V4 这种量级的模型塞进自己的机箱放在两年前还是件不太现实的事。但到了现在随着模型量化技术的成熟和消费级显卡显存的持续膨胀本地部署已经从极客玩具变成了很多团队认真评估的生产方案。我自己前前后后折腾过七八种部署路径从最早的纯 CPU 推理到现在的多卡张量并行踩过的坑足够写一本小册子。这篇就把我实测过的四套方案完整摊开讲包括每套方案适合谁、硬件门槛在哪、以及那些官方文档里不会写的细节。先说清楚一件事本地部署 DeepSeek-V4 的核心动机绝大多数情况下不是省钱。如果你只是偶尔用用云端 API 的按量计费远比买卡划算。真正驱动本地部署的是三个东西——数据不出内网、推理延迟可控、以及不受调用配额限制。尤其是涉及企业内部文档、代码库、客户资料的场景数据主权这条就足以一票否决云端方案。那成本账到底怎么算我拿 RTX 5090 实测的数据给你一个参考锚点。DeepSeek-V4 的 FP16 原始权重体积相当可观直接全精度加载对显存的要求会劝退大部分人。所以实际部署中量化是绕不开的一步。常见的量化档位和对应的显存占用大致是这样的量化精度权重体积约最低显存需求推理质量损失适用场景FP16基准 100%极高无多卡企业级INT8约 50%高极小单卡高配Q4_K_M约 27%中等轻微消费级主力Q4_0约 25%中等偏低可感知显存紧张Q3_K_M约 20%低明显极限压缩这张表是我自己反复测下来总结的经验值不同量化工具的具体数字会有出入但量级关系是稳的。关键判断点在于你要的是能跑起来还是跑得好。Q4_K_M 是我个人最推荐的平衡点质量损失在日常问答和代码补全场景下几乎感知不到而显存占用直接砍到四分之一左右。再说延迟。本地推理的首 token 延迟TTFT和吞吐量tokens/s跟硬件强相关。RTX 5090 单卡跑 Q4 量化的 DeepSeek-V4在 batch size 为 1 的情况下实测生成速度能稳定在一个相当可用的区间具体数字后面每套方案里我会分别给。这里先给个结论单卡 5090 跑量化版日常交互式使用完全够用但如果你要做批量推理或者多用户并发就得上多卡或者换 vLLM 这类高吞吐框架。还有一个容易被忽略的点模型加载时间。第一次加载几十 GB 的权重到显存冷启动可能要几分钟。如果你把它当成一个随时待命的服务就得考虑常驻内存而不是用完就卸载。这个细节直接影响到你选哪套方案——Ollama 这类工具默认会做模型保活而某些手动加载的方式每次都要重新读盘。2. 四套方案的全景对比先选路线再抠细节在动手之前我强烈建议你先花十分钟把四套方案的定位搞清楚。很多人一上来就照着某个教程装 Ollama结果发现自己的场景根本不适合白白浪费时间。这四套方案我按上手难度和可控程度两个维度排了个序你可以对号入座。方案一Ollama——开箱即用的入门首选。它的定位就是让本地跑模型像装个 App 一样简单。一条命令拉取模型一条命令启动服务自带 OpenAI 兼容的 API 接口。适合个人开发者、快速验证想法、以及对底层细节不感兴趣的用户。缺点是可控性有限量化档位、并行策略这些底层参数你基本插不上手。方案二LM Studio——带图形界面的桌面方案。如果你不习惯命令行LM Studio 提供了完整的 GUI模型下载、参数调节、对话测试都在一个界面里完成。它底层其实也是基于类似的推理引擎但把复杂度藏起来了。适合产品经理、设计师这类需要快速体验但不想碰终端的人群。方案三vLLM——生产级高吞吐引擎。这是真正给企业和服务端准备的方案。它的核心优势是 PagedAttention 和连续批处理continuous batching在高并发场景下的吞吐量能把 Ollama 甩开好几条街。支持张量并行可以跨多张卡部署大模型。代价是配置复杂对环境和显存管理的要求高。适合有运维能力的团队、需要支撑多用户的内部服务。方案四llama.cpp 手动编译——极致可控的硬核路线。如果你想榨干每一滴性能或者有特殊的量化需求直接上手 llama.cpp 是最灵活的。你可以自己决定量化方式、线程数、GPU 层数分配。缺点是全手动编译、转换、调参都得自己来。适合喜欢折腾、对性能有极致要求的工程师。为了让你一眼看清差异我把四套方案的关键指标拉了个对比维度OllamaLM StudiovLLMllama.cpp上手难度低极低高中高图形界面无有无无并发吞吐一般一般极强一般多卡支持有限有限完善部分量化灵活度低低中极高API 兼容OpenAIOpenAIOpenAI需自建适合人群个人/验证非技术团队/生产硬核玩家选路线的核心逻辑就一句话先问自己我要不要支撑多人同时用如果要直接上 vLLM别在 Ollama 上浪费时间如果只是自己用Ollama 或 LM Studio 足够如果对性能有执念llama.cpp 等你。3. Ollama 路线实操从安装到跑通 DeepSeek-V4 的完整链路Ollama 是我推荐给所有人的第一站哪怕你最终要用 vLLM也建议先用 Ollama 把模型跑起来感受一下确认硬件没问题、模型质量符合预期再去折腾复杂的方案。3.1 安装环节那些没人告诉你的坑Ollama 的安装本身很简单官网下载对应系统的安装包双击或者一行脚本搞定。但这里有几个实操细节值得单独拎出来说。第一安装路径问题。Windows 上默认装到 C 盘而模型文件默认也存放在用户目录下。DeepSeek-V4 量化后动辄几十 GBC 盘很容易被撑爆。解决办法是设置环境变量OLLAMA_MODELS指向一个大容量盘符。这个变量必须在启动 Ollama 服务之前设置好否则不生效。Linux 上则是通过 systemd 的 service 文件里配置Environment字段。第二下载慢的问题。这是国内用户最常遇到的。模型仓库的拉取速度受网络影响很大几十 GB 的模型可能下到一半就断了。我的经验是优先找国内的镜像源或者用支持断点续传的下载工具先把模型文件拉下来再手动导入。Ollama 支持从本地文件导入模型具体做法是写一个 Modelfile用FROM指向本地的 GGUF 文件然后ollama create创建。第三版本兼容性。Ollama 更新很频繁新版本对新型号显卡的支持往往更好。如果你用的是 RTX 5090 这类新卡务必确认 Ollama 版本足够新否则可能识别不到 GPU退化成纯 CPU 推理速度会慢到让你怀疑人生。3.2 拉取与运行 DeepSeek-V4安装完成后拉取模型就是一条命令的事。但这里有个关键选择拉哪个量化版本。Ollama 的模型库里通常会提供多个 tag对应不同的量化精度。默认 tag 一般是最通用的量化档但未必最适合你。我的建议是先用默认版本跑通确认能用之后再根据显存余量决定要不要换更高精度的版本。运行命令很简单ollama run deepseek-v4第一次运行会自动下载模型耐心等待。下载完成后会进入交互式对话界面你可以直接测试。如果要作为服务常驻用ollama serve这会在本地起一个服务默认监听 11434 端口提供 OpenAI 兼容的 API。你的其他应用就可以通过这个接口调用本地模型了。3.3 RTX 5090 实测数据与调优在 RTX 5090 单卡上跑 Q4 量化的 DeepSeek-V4我的实测结果是生成速度稳定在每秒几十个 token 的量级首 token 延迟在秒级以内。这个表现对于交互式对话完全够用打字的速度绝对跟不上模型生成的速度。但有几个调优点能进一步压榨性能。一是 GPU 层数。Ollama 会自动判断能卸载多少层到 GPU但有时候判断偏保守。你可以通过参数手动指定num_gpu层数把尽可能多的层塞进显存。二是上下文长度。上下文越长KV Cache 占用越大显存压力越高。如果发现显存吃紧适当调小上下文窗口能明显缓解。三是并行请求数。Ollama 默认的并行度不高如果你要同时服务多个请求需要调整OLLAMA_NUM_PARALLEL环境变量。提示调整任何参数后记得重启 Ollama 服务否则不生效。这是新手最容易犯的错。3.4 Ollama 的边界在哪里用了几个月 Ollama 之后我对它的能力边界有了清晰认识。它适合单用户、低并发、快速验证的场景。一旦你要支撑十几个人的团队同时使用或者要做批量文档处理它的吞吐瓶颈就会暴露出来。这时候不是调参能解决的而是架构层面的限制必须换 vLLM。另外Ollama 对多卡的支持比较有限它不像 vLLM 那样有成熟的张量并行方案。如果你有多张卡想一起用Ollama 更多是每张卡各跑各的而不是合力跑一个模型。这个区别在部署超大模型时很关键。4. vLLM 生产级部署多卡并行与高并发的正确打开方式当你决定上 vLLM说明你已经过了玩一玩的阶段开始认真考虑把它做成一个能扛住真实流量的服务。vLLM 的配置确实复杂但它的性能回报是实打实的。4.1 环境准备Python 生态的依赖管理vLLM 是 Python 生态的项目安装方式主要是 pip。但这里有个大坑PyTorch 版本和 CUDA 版本的匹配。vLLM 对底层依赖很敏感装错版本会导致各种莫名其妙的报错比如找不到 CUDA 设备、算子不支持等等。我的做法是先确认显卡驱动支持的 CUDA 版本然后去 PyTorch 官网找到对应的安装命令先装好 PyTorch再装 vLLM。不要直接pip install vllm就完事那样很可能拉到一个和你的环境不匹配的版本。用虚拟环境隔离是基本操作conda 或者 venv 都行别在系统 Python 里瞎搞。4.2 单机多卡部署的核心参数vLLM 最强大的能力之一就是张量并行Tensor Parallelism可以把一个大模型切分到多张卡上。启动命令里最关键的参数是--tensor-parallel-size它决定了用几张卡来跑。假设你有 4 张卡想全部用上vllm serve deepseek-v4 \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192这里每个参数都有讲究。--tensor-parallel-size 4表示把模型切成 4 份每张卡放一份。--gpu-memory-utilization 0.9表示允许 vLLM 使用 90% 的显存留一点给系统和其他进程。--max-model-len控制最大上下文长度这个值直接影响 KV Cache 的显存占用设太大容易 OOM。张量并行的卡数不是随便设的它通常需要能整除模型的注意力头数。如果设了一个不合适的值vLLM 启动时会直接报错。一般 2、4、8 是比较安全的选择。4.3 连续批处理带来的吞吐飞跃vLLM 真正的杀手锏是 PagedAttention 和连续批处理。简单说传统推理框架处理并发请求时要么排队一个个来要么把请求凑成一批一起算中间会有大量等待。而 vLLM 能把不同请求的 KV Cache 分页管理动态地把新请求插进正在进行的批次里让 GPU 始终处于满载状态。这个机制带来的吞吐提升在高并发下非常明显。我实测过同样的硬件Ollama 在十几个并发请求下就开始明显排队而 vLLM 能轻松扛住几十个并发还保持稳定输出。如果你的场景是团队共享或者对外提供服务这个差距就是决定性的。4.4 踩坑记录那些让服务起不来的报错vLLM 的报错信息有时候不太友好我整理几个最常见的。显存不足OOM最常见。解决办法是降低--gpu-memory-utilization、减小--max-model-len、或者换更激进的量化。有时候也是因为张量并行度设小了模型没切开。模型类找不到类似ValueError: model class ... not found这种通常是 vLLM 版本太旧不认识新的模型架构。升级 vLLM 到最新版一般能解决。CUDA 版本不匹配报错里会出现 CUDA 相关的字样。这时候要检查 PyTorch 的 CUDA 版本和系统驱动是否兼容。端口占用vLLM 默认监听 8000 端口如果被占用会启动失败。用--port换一个。注意vLLM 启动时会预分配显存所以启动瞬间显存占用就会拉满。别看到显存满了就以为出问题了那是正常行为。4.5 纯 CPU 模式的适用边界vLLM 也支持纯 CPU 模式但说实话用 CPU 跑 DeepSeek-V4 这种量级的模型体验只能用能跑但别指望来形容。生成速度会慢到每秒几个 token 甚至更低只适合做离线批处理或者对延迟完全不敏感的场景。如果你手上没有像样的 GPU与其硬上 vLLM CPU 模式不如考虑用 llama.cpp 的 CPU 优化版本效率会好一些。5. 量化、显存与性能的三角平衡把硬件吃干榨净这一节专门讲怎么在有限的硬件上把性能调到最优。这是区分能跑和跑得好的关键。5.1 量化档位怎么选才不后悔前面表格里给了量化档位的大致参考但实际选择时还要考虑你的具体用途。做代码补全和逻辑推理对量化损失更敏感建议用 Q4_K_M 及以上做文本摘要和简单问答Q4_0 甚至 Q3 都能接受。我的经验法则是先用一个中等量化档跑起来然后拿一批你熟悉的测试问题去问对比云端版本的回答质量。如果差异在你可接受范围内就定下来如果明显变差就往上提一档量化。不要盲目追求最高精度显存浪费了不说速度还慢。5.2 显存占用的构成拆解很多人以为显存只被模型权重占用其实不然。显存占用大致分三块模型权重、KV Cache、以及推理过程中的临时激活值。权重是固定的KV Cache 随上下文长度和并发数增长激活值则和 batch size 相关。理解了这一点你就能明白为什么模型能加载不等于能正常推理。有时候权重刚好塞进显存但一推理就 OOM就是因为 KV Cache 和激活值没算进去。留出至少 20% 的显存余量是安全线。5.3 RTX 5090 上的实测调优组合在 5090 上我最终稳定下来的一套配置是Q4_K_M 量化、上下文长度 8192、GPU 层数拉满、并行请求数适中。这套组合下单用户交互体验流畅小团队共享也不会明显卡顿。如果你显存更充裕可以尝试把上下文拉到 16384 甚至更高处理长文档会更从容。但要注意上下文翻倍KV Cache 也大致翻倍显存压力会明显上升。5.4 多模型共存的资源分配热词里有人问vllm 多个模型怎么搞。实际做法有两种一是起多个 vLLM 实例每个实例绑定不同的卡和端口二是在同一个实例里用 LoRA 适配器切换。前者资源隔离好但浪费显存后者省显存但配置复杂。如果几个模型都要常驻建议按卡的物理隔离来分配别让它们抢同一张卡。6. 常见报错与疑难杂症的排查手册部署过程中遇到的报错八成集中在几个地方。我把它们整理成一张排查表遇到问题先对号入座。报错现象可能原因排查方向识别不到 GPU驱动/版本不匹配检查驱动版本、框架 CUDA 支持模型加载 OOM量化档位过高换更低量化或减上下文推理中途 OOMKV Cache 超限降并发、减上下文长度生成速度极慢退化成 CPU 推理确认 GPU 层数是否拉满API 400 错误模型名不匹配核对调用的模型名称服务启动失败端口占用/依赖缺失换端口、补依赖关于那个api error: 400 the supported api model names are...的报错本质是你调用的模型名和服务端注册的模型名对不上。解决方法是先用列出模型的接口查一下服务端到底注册了哪些名字然后照着改你的调用参数。这个坑在切换不同部署方案时特别常见因为每个方案对模型的命名习惯不一样。还有一个高频问题是模型文件损坏或者下载不完整导致的加载失败。判断方法是对比文件大小和官方公布的大小差太多就是没下完。重新下载时务必用支持校验的方式。7. 从个人玩具到团队服务部署架构的演进思路最后聊聊架构层面的思考。个人用和团队用部署方式完全是两码事。个人用一台机器、一个 Ollama、一个模型齐活。团队用你得考虑服务的高可用、请求的负载均衡、模型的版本管理、以及访问的权限控制。这时候通常的做法是后端用 vLLM 起推理服务前面加一层网关做鉴权和限流再配一个监控看显存和吞吐。如果团队规模再大一点可能还要考虑多机部署把推理服务分散到几台机器上用统一的入口对外。这时候模型的分发、配置的同步、日志的收集都会变成新的问题。我的建议是不要一步到位。先用最简单的方案跑起来让团队用上收集真实反馈再根据瓶颈逐步演进。很多团队一上来就搭一套复杂的架构结果发现根本用不上维护成本还高。从 Ollama 起步遇到瓶颈再换 vLLM这个路径对大多数团队都是最优的。我个人在实际操作中的体会是本地部署这件事最难的不是技术本身而是想清楚你到底要什么。是想省钱还是想要数据安全还是想要低延迟还是纯粹想折腾目标不同方案选择天差地别。把这个问题想明白了剩下的都是查文档和试错的事。
代码包深度解析与实践指南)
