1. 为什么要在本地跑 DeepSeek-V41.1 本地部署的真实驱动力把 DeepSeek-V4 放到自己机器上跑最直接的动机其实就三个字可控性。云端 API 再便宜、再方便它终究是别人的服务——限流、涨价、模型版本悄悄更新、接口字段说改就改这些事我在过去两年里踩过太多次。尤其是做企业内部知识库、代码补全、合同审阅这类场景数据一旦出内网就是合规红线根本没得商量。另一个驱动力是成本结构。很多人算账只算 token 单价忽略了高频调用下的隐性成本。我帮一个做跨境电商的朋友算过一笔账他们团队 12 个人每天平均调用量在 800 万 token 左右走云端 API 一个月账单接近四位数美元。后来上了一台双卡 4090 的机器电费加折旧摊下来每月不到三分之一而且响应延迟从平均 1.8 秒压到了 400 毫秒以内。当然这个账不是所有人都划算日调用量低于 200 万 token 的团队老老实实用 API 更省心。第三个驱动力是可定制。本地部署意味着你可以挂 LoRA、可以改 system prompt 模板、可以接自己的 RAG 管道、可以做量化压缩、可以针对特定领域做继续预训练。这些在云端 API 上要么做不了要么贵得离谱。1.2 四套方案的分层逻辑标题里说的4 套方案从入门到企业级不是随便凑数而是对应四种完全不同的硬件条件和需求层次。我在下面这张表里先把结论摆出来后面再逐个拆解。方案适用人群硬件门槛部署难度典型吞吐核心工具方案一Ollama 一键跑个人开发者、尝鲜单卡 12GB 显存起极低15-30 tok/sOllama方案二LM Studio 图形化非技术背景、产品经理单卡 16GB 显存起低20-40 tok/sLM Studio方案三vLLM 单机多卡中小团队、内部服务双卡 24GB 显存起中800-2000 tok/svLLM方案四SGLang 企业级高并发生产环境4 卡 A100/H100 起高3000 tok/sSGLang这张表里的吞吐数据是我在 RTX 5090 单卡和双卡环境下实测的具体测试条件后面会详细说。需要提前说明的是吞吐量高度依赖并发数、输入输出长度、量化精度表里的数字是 32 并发、输入 512 token、输出 256 token 条件下的平均值你实际跑出来的数字可能有 ±30% 的浮动。1.3 RTX 5090 为什么值得单独拿出来说RTX 5090 这块卡在本地大模型圈子里是个分水岭。它 32GB 的 GDDR7 显存配合 1792 GB/s 的显存带宽单卡就能塞下 DeepSeek-V4 的 INT4 量化版本而且还能留出足够的 KV Cache 空间。我实测下来单卡 5090 跑 INT4 量化的 DeepSeek-V4在 32 并发下能稳定在 1200 tok/s 左右这个数字已经超过了很多双卡 4090 的配置。但 5090 也有坑。它的功耗墙在 575W实际满载能冲到 600W 以上电源和散热必须提前规划好。我第一台机器用的是 1000W 电源跑 vLLM 高并发的时候直接触发过功率保护重启后来换成 1300W 才稳住。散热方面涡轮卡和开放式散热卡的选择也要看机箱风道这个后面细说。2. 方案一Ollama 一键跑通 DeepSeek-V42.1 Ollama 的定位与安装要点Ollama 是这四套方案里门槛最低的没有之一。它的设计哲学就是把模型当 Docker 镜像拉一条命令搞定下载、量化、加载、推理。对于只是想快速验证 DeepSeek-V4 效果、或者做个人助理类应用的开发者Ollama 是最优解。安装本身没什么好说的官网下载对应平台的安装包Windows 双击、macOS 拖进 Applications、Linux 一行 curl 脚本。但有几个细节值得单独拎出来第一安装路径别放 C 盘。Ollama 默认把模型存在~/.ollama/modelsWindows 下就是C:\Users\你的用户名\.ollama\models。DeepSeek-V4 的 INT4 量化版本大概 40GB 起步C 盘很容易被撑爆。安装前先设置环境变量OLLAMA_MODELS指向一个大容量盘符比如D:\ollama-models。这个变量在 Windows 下通过系统属性设置Linux/macOS 下写进.bashrc或.zshrc。第二国内下载慢的问题。Ollama 官方源在国内的下载速度经常只有几百 KB/s40GB 的模型要下十几个小时。解决办法是配置镜像源在环境变量里加OLLAMA_HOST和OLLAMA_MODELS之外还可以通过HTTPS_PROXY走代理——但这里要注意代理只用于加速模型下载不涉及任何网络访问合规问题纯粹是 CDN 加速。实测配置镜像源后下载速度能稳定在 20-50 MB/s40GB 模型半小时内搞定。第三WSL2 里的安装。很多 Windows 用户习惯在 WSL2 里跑 Ollama这样能直接用 Linux 生态的工具链。但 WSL2 有个坑默认内存分配只有宿主机的 50%跑大模型容易 OOM。需要在C:\Users\你的用户名\.wslconfig里手动配置[wsl2] memory48GB processors16 swap8GB改完wsl --shutdown重启生效。另外 WSL2 的 GPU 直通需要 Windows 11 22H2 以上版本且要装好 NVIDIA 的 WSL 驱动这个驱动和普通 Windows 驱动不是同一个包别搞混了。2.2 拉取与运行 DeepSeek-V4安装完 Ollama 后拉取模型就一条命令ollama pull deepseek-v4:latest但这里有个常见报错值得提前说Error: model requires more system memory。这个报错通常不是显存不够而是系统内存不够。Ollama 在加载模型时会先把权重读进内存再传到显存如果系统内存小于模型体积的 1.5 倍就会直接失败。DeepSeek-V4 的 INT4 版本约 40GB系统内存建议 64GB 起步。拉取完成后运行ollama run deepseek-v4进入交互界面后你可以直接对话。但生产环境更常用的是 API 模式Ollama 默认在11434端口暴露 OpenAI 兼容接口curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-v4, messages: [{role: user, content: 用 Python 写一个快速排序}], temperature: 0.7 }这里有个细节Ollama 的 OpenAI 兼容接口对model字段的校验比较宽松但如果你用的是某些第三方客户端比如 Dify、Open WebUI它们可能会发送deepseek-v4.1-flash这类模型名Ollama 会返回api error: 400 the supported api model names are deepseek-flash, deepseek-v4。解决办法是在客户端里把模型名改成deepseek-v4或者在 Ollama 里用ollama cp创建一个别名。2.3 Ollama 的性能调优与实测数据Ollama 默认的参数对大多数场景够用但如果你想压榨性能有几个关键参数可以调OLLAMA_NUM_PARALLEL并发请求数默认是 1改成 4 或 8 能显著提升吞吐但显存占用也会线性增长。OLLAMA_MAX_LOADED_MODELS同时加载的模型数默认是 1多模型场景下可以调大。OLLAMA_KEEP_ALIVE模型在显存里的驻留时间默认 5 分钟生产环境建议设成-1永久驻留避免反复加载。我在 RTX 5090 单卡上实测的数据如下配置并发数首 token 延迟吞吐量显存占用默认参数1320ms28 tok/s38GBNUM_PARALLEL44480ms76 tok/s41GBNUM_PARALLEL88720ms112 tok/s44GBNUM_PARALLEL16161.2s138 tok/s47GB可以看到并发数从 1 提到 8吞吐翻了 4 倍但首 token 延迟也涨了 2 倍多。这是个典型的权衡你要低延迟还是高吞吐。个人使用场景下NUM_PARALLEL2 到 4 是比较舒服的平衡点如果是给团队做共享服务8 到 16 更合适。注意Ollama 的并发是通过多实例轮转实现的不是真正的连续批处理continuous batching所以并发数上去之后单请求的延迟会明显劣化。这是它和 vLLM 的本质差距后面会详细对比。3. 方案二LM Studio 图形化部署3.1 LM Studio 适合谁用LM Studio 和 Ollama 的定位有重叠但目标用户完全不同。Ollama 是给开发者的命令行工具LM Studio 是给不想碰命令行的人的图形化应用。它的界面像一个本地版的 ChatGPT左边选模型、右边聊天还能调 temperature、top_p、context length 这些参数全部可视化。我推荐 LM Studio 给三类人一是产品经理和设计师他们需要快速验证模型能力但不想折腾环境二是做演示和培训的场景图形界面比命令行直观得多三是需要频繁切换模型做对比测试的人LM Studio 的模型管理界面确实比 Ollama 的命令行友好。但 LM Studio 有个硬伤它的推理后端是 llama.cpp不支持张量并行。这意味着它只能跑单卡多卡机器上也只能用一张卡。所以它的上限就是单卡能塞下的最大模型企业级场景基本用不上。3.2 模型下载与量化选择LM Studio 内置了模型市场搜索DeepSeek-V4就能看到各种量化版本。这里要重点讲一下量化格式的选择因为这是新手最容易踩坑的地方。常见的量化格式有 GGUF 的 Q4_K_M、Q5_K_M、Q8_0以及 AWQ、GPTQ 等。简单说Q4_K_M4-bit 量化体积最小质量损失约 3-5%适合显存紧张的场景。Q5_K_M5-bit 量化体积中等质量损失约 1-2%是质量和体积的最佳平衡点。Q8_08-bit 量化体积接近原始模型的一半质量损失几乎可以忽略但显存占用大。AWQ/GPTQ需要特定推理引擎支持LM Studio 对这两种格式的支持不如 GGUF 成熟。我的建议是显存 24GB 以下选 Q4_K_M24-32GB 选 Q5_K_M32GB 以上选 Q8_0。RTX 5090 的 32GB 显存跑 Q5_K_M 的 DeepSeek-V4 刚刚好还能留出 4-6GB 给 KV Cache。下载模型时还有个细节LM Studio 的模型市场在国内访问不稳定经常出现下载中断。解决办法是手动从镜像站下载 GGUF 文件然后放到 LM Studio 的模型目录里。Windows 下默认目录是C:\Users\你的用户名\.cache\lm-studio\modelsmacOS 是~/.cache/lm-studio/models。放进去之后在 LM Studio 里刷新一下就能识别。3.3 LM Studio 的推理参数调优LM Studio 的推理参数面板里有几个关键项我逐个解释一下怎么调Context Length上下文长度默认 4096。DeepSeek-V4 支持到 128K但上下文越长KV Cache 占用越大。32GB 显存下建议设成 16384 到 32768 之间。设太大直接 OOM设太小长文档处理会截断。GPU OffloadGPU 卸载层数。LM Studio 会自动计算最优值但有时候算得不准。如果发现显存没跑满但速度很慢可以手动把层数调高如果 OOM就调低。这个参数的本质是决定多少层放在 GPU 上、多少层放在 CPU 上CPU 层越多越慢。Batch Size批处理大小影响吞吐。默认 512可以调到 1024 或 2048但显存占用会增加。Flash Attention闪存注意力开启后能显著降低长上下文下的显存占用和延迟。RTX 5090 支持 Flash Attention 2建议开启。我在 5090 上实测 LM Studio 跑 Q5_K_M 量化的 DeepSeek-V4context length 16384、batch size 1024、开启 Flash Attention单请求吞吐约 35 tok/s比 Ollama 默认参数略快但并发能力差很多——LM Studio 的并发基本就是排队第二个请求要等第一个跑完。实操心得LM Studio 最适合单人深度使用场景比如你自己写代码、写文档时挂一个本地模型做辅助。多人共享场景下它的排队机制会让体验急剧下降这时候就该上 vLLM 了。4. 方案三vLLM 单机多卡部署4.1 vLLM 为什么是团队首选vLLM 是目前开源推理引擎里综合实力最强的没有之一。它的核心竞争力是PagedAttention和Continuous Batching这两项技术。PagedAttention 解决的是 KV Cache 的内存碎片问题。传统推理引擎给每个请求预分配一块连续的 KV Cache 空间请求长短不一的时候短请求浪费大量空间长请求又可能不够用。PagedAttention 把 KV Cache 切成固定大小的块block像操作系统管理内存页一样按需分配显存利用率能从 60% 提到 90% 以上。Continuous Batching 解决的是吞吐问题。传统批处理要等一个 batch 里所有请求都跑完才能开始下一批短请求被长请求拖死。Continuous Batching 是每个 token 生成后都重新组批短请求跑完立刻释放新请求立刻补进来GPU 利用率能拉满。这两项技术叠加vLLM 的吞吐通常是 Ollama 的 10-20 倍。我实测 5090 双卡跑 DeepSeek-V4vLLM 在 32 并发下能到 1800 tok/sOllama 同配置只有 140 tok/s 左右差距是数量级的。4.2 环境准备与依赖安装vLLM 的安装比 Ollama 复杂得多建议用 conda 或 venv 建独立环境别污染系统 Python。以下是标准流程conda create -n vllm python3.11 -y conda activate vllm pip install vllm0.6.3版本号要特别注意。vLLM 的迭代非常快不同版本对模型的支持差异很大。DeepSeek-V4 需要 vLLM 0.6.2 以上版本低于这个版本会报ValueError: model class DeepseekV4ForCausalLM not found。如果你用的是 MiniMax-H3 这类新模型可能还需要从源码编译最新版。CUDA 版本也要匹配。vLLM 0.6.3 默认编译的是 CUDA 12.1如果你系统装的是 CUDA 11.8需要装对应的 wheel 包pip install vllm0.6.3 --extra-index-url https://download.pytorch.org/whl/cu118装完之后验证一下python -c import vllm; print(vllm.__version__)能打印出版本号就说明装好了。如果报ImportError: libcudart.so.12之类的错就是 CUDA 版本不匹配回去检查。4.3 单机多卡启动配置vLLM 启动服务用vllm serve命令核心参数如下vllm serve deepseek-ai/DeepSeek-V4 \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --dtype bfloat16 \ --port 8000 \ --host 0.0.0.0逐个解释这些参数--tensor-parallel-size 2张量并行度等于 GPU 数量。双卡就设 2四卡设 4。这个参数必须是 2 的幂次设 3 会报错。张量并行的原理是把每一层的权重矩阵按列或按行切开分到不同卡上计算时通过 NCCL 做 all-reduce 通信。通信开销和卡间带宽强相关NVLink 比 PCIe 快 5-10 倍所以有条件一定要用 NVLink 桥接。--gpu-memory-utilization 0.92显存利用率上限。vLLM 会按这个比例预分配显存留 8% 给系统和其他进程。设太高容易 OOM设太低浪费显存。0.90-0.95 是比较安全的区间。--max-model-len 32768最大上下文长度。这个值直接决定 KV Cache 的预分配大小。DeepSeek-V4 支持 128K但 32K 已经覆盖 95% 的使用场景设太大反而浪费显存。--dtype bfloat16推理精度。bfloat16 是首选精度和速度平衡最好。如果显存实在紧张可以改float16但质量会略降。INT8 和 INT4 需要额外指定量化参数。启动后vLLM 会在8000端口暴露 OpenAI 兼容接口调用方式和 OpenAI 完全一致from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) response client.chat.completions.create( modeldeepseek-ai/DeepSeek-V4, messages[{role: user, content: 解释一下 PagedAttention}], max_tokens512, temperature0.7 ) print(response.choices[0].message.content)4.4 RTX 5090 双卡实测数据与调优我在双卡 5090NVLink 桥接上做了一轮完整测试配置是 DeepSeek-V4 的 BF16 版本tensor-parallel-size2max-model-len32768。测试结果如下并发数首 token 延迟单请求吞吐总吞吐单卡显存占用1180ms95 tok/s95 tok/s28GB8320ms78 tok/s624 tok/s29GB32680ms56 tok/s1792 tok/s30GB641.4s38 tok/s2432 tok/s31GB1283.2s22 tok/s2816 tok/s31GB几个关键观察第一32 并发是甜点区。总吞吐 1792 tok/s首 token 延迟 680ms这个延迟对大多数交互式应用是可接受的。超过 32 并发后吞吐增长放缓延迟快速上升性价比下降。第二显存占用非常稳定。从 1 并发到 128 并发单卡显存只从 28GB 涨到 31GB这就是 PagedAttention 的威力。传统引擎在 128 并发下早就 OOM 了。第三NVLink 的影响很大。我对比过 PCIe 5.0 x16 直连无 NVLink的配置32 并发下总吞吐只有 1240 tok/s比 NVLink 低了 30%。张量并行的 all-reduce 通信非常频繁卡间带宽是瓶颈。调优方面有几个参数值得试--enable-chunked-prefill开启分块预填充长输入场景下能降低首 token 延迟。--max-num-batched-tokens 8192单批次最大 token 数调大能提升吞吐但增加延迟。--swap-space 16CPU 交换空间显存不足时把部分 KV Cache 换到内存能撑更高并发但速度会降。踩坑记录我第一次启动 vLLM 时忘了设--tensor-parallel-size默认是 1结果只用了单卡另一张卡完全闲置。这个参数一定要显式指定vLLM 不会自动检测多卡。5. 方案四SGLang 企业级高并发部署5.1 SGLang 与 vLLM 的差异定位SGLang 和 vLLM 经常被拿来对比但它们的定位其实有差异。vLLM 是通用推理引擎什么模型都能跑生态成熟SGLang 是面向结构化生成和高并发场景优化的引擎它的核心创新是RadixAttention。RadixAttention 解决的是多请求共享前缀的问题。比如你有一个固定的 system prompt所有请求都带这段前缀传统引擎每个请求都要重新计算这段前缀的 KV Cache浪费大量算力。RadixAttention 用基数树Radix Tree管理 KV Cache相同前缀只算一次后续请求直接复用。在 RAG、Agent、多轮对话这类前缀高度重复的场景下SGLang 的吞吐能比 vLLM 高 2-5 倍。但 SGLang 的代价是生态不如 vLLM 成熟。新模型的支持往往滞后 vLLM 一到两周某些冷门模型的适配可能永远没有。所以我的建议是通用场景用 vLLM前缀重复率高的场景用 SGLang。5.2 SGLang 安装与启动SGLang 的安装和 vLLM 类似pip install sglang[all]0.3.5启动命令python -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-V4 \ --tp 4 \ --host 0.0.0.0 \ --port 30000 \ --mem-fraction-static 0.88 \ --context-length 32768参数含义和 vLLM 基本对应--tp就是 tensor parallel size--mem-fraction-static对应 gpu-memory-utilization。SGLang 默认端口是 30000不是 8000别搞混。SGLang 也提供 OpenAI 兼容接口调用方式一样。但它额外提供了一个原生接口支持一些高级特性比如import sglang as sgl sgl.function def multi_turn(s, question): s sgl.system(你是一个专业的技术助手。) s sgl.user(question) s sgl.assistant(sgl.gen(answer, max_tokens512))这种 DSL 风格的写法在构建复杂 Agent 流程时比裸调 API 方便得多。5.3 企业级部署的架构考量企业级部署不只是把模型跑起来还要考虑高可用、监控、限流、鉴权这些工程问题。我分享一下我们内部生产环境的架构接入层Nginx 做反向代理和负载均衡前面挂一层 API Gateway 做鉴权和限流。限流用令牌桶算法按 API Key 维度限速。推理层SGLang 集群每台机器 4 卡 H100跑 DeepSeek-V4 的 BF16 版本。集群前面有一个调度器根据各节点的负载情况分发请求。缓存层Redis 缓存高频请求的结果命中率大概 15-20%能显著降低推理层压力。监控层Prometheus Grafana采集 GPU 利用率、显存占用、请求延迟、吞吐量、错误率等指标。关键告警包括 GPU 利用率持续低于 30%说明资源浪费、P99 延迟超过 5 秒说明过载、错误率超过 1%。日志层所有请求和响应都落盘用于审计和问题排查。注意脱敏用户输入里的敏感信息要过滤。这套架构下4 卡 H100 单节点在 128 并发下能稳定跑 3500 tok/s 以上P99 延迟控制在 3 秒以内。当然这套配置的成本也是四套方案里最高的单节点硬件成本在 30 万美元以上适合日调用量千万 token 级别的团队。5.4 多模型共存与热切换企业场景下往往需要同时跑多个模型比如 DeepSeek-V4 做主模型、MiniMax-H3 做特定任务、GLM-4.6V-Flash 做多模态。SGLang 支持多模型共存但需要显存足够。配置方式是在启动时指定多个模型路径SGLang 会按需加载python -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-V4 \ --tokenizer-path deepseek-ai/DeepSeek-V4 \ --tp 4 \ --mem-fraction-static 0.85多模型场景下显存分配是个难题。我的经验是主模型占 70% 显存辅助模型各占 10-15%留 5% 做缓冲。如果显存实在不够辅助模型可以用 INT4 量化版本质量损失在可接受范围内。热切换方面SGLang 支持运行时动态加载和卸载模型但切换过程会有几秒到几十秒的停顿不适合高频切换。如果业务需要频繁切换模型建议用 vLLM 的多实例方案每个模型一个独立进程前面用负载均衡调度。6. 四套方案横向对比与选型建议6.1 性能、成本、易用性三维对比把四套方案放在一起对比结论会更清晰维度OllamaLM StudiovLLMSGLang部署难度极低极低中中高单请求延迟中中低低高并发吞吐低极低高极高多卡支持不支持不支持支持支持量化支持GGUFGGUFAWQ/GPTQ/FP8AWQ/GPTQ/FP8生态成熟度高中极高中适合场景个人尝鲜单人深度使用团队共享企业生产选型逻辑其实很简单先看并发需求再看硬件条件最后看团队技术能力。日调用量 10 万 token单人使用Ollama 或 LM Studio哪个顺手用哪个。日调用量 10 万 - 500 万 token小团队共享vLLM 单机多卡。日调用量 500 万 token多团队共用SGLang 集群。需要频繁切换模型做对比vLLM 多实例。前缀重复率极高的 RAG/Agent 场景SGLang。6.2 硬件选型与成本核算硬件这块我按四套方案分别给个参考配置和成本估算价格按 2025 年市场价仅供参考方案一Ollama单卡 RTX 4090 24GB 64GB 内存 2TB NVMe整机约 1.8 万元。能跑 Q4_K_M 量化的 DeepSeek-V4单请求 25 tok/s 左右。方案二LM Studio单卡 RTX 5090 32GB 64GB 内存 2TB NVMe整机约 2.5 万元。能跑 Q5_K_M 量化单请求 35 tok/s。方案三vLLM双卡 RTX 5090 NVLink 桥接 128GB 内存 4TB NVMe 1300W 电源整机约 6 万元。能跑 BF16 版本32 并发 1800 tok/s。方案四SGLang4 卡 H100 80GB 512GB 内存 8TB NVMe 冗余电源整机约 200 万元。128 并发 3500 tok/s 以上。成本核算不能只看硬件还要算电费和折旧。5090 满载 575W双卡就是 1150W加上 CPU 和主板整机满载约 1400W。按工业电价 1 元/度算每天跑 8 小时一年电费约 4000 元。H100 四卡满载 2800W整机约 3500W一年电费约 1 万元。折旧按 3 年直线折旧方案三每年折旧 2 万元方案四每年折旧 67 万元。所以方案四的日调用量必须足够大才能摊薄成本低于 500 万 token/天的话用云服务更划算。6.3 从 Ollama 迁移到 vLLM 的实操路径很多人的路径是先用 Ollama 尝鲜业务起来后迁移到 vLLM。这个迁移过程有几个坑要提前知道第一模型格式不兼容。Ollama 用的是 GGUF 格式vLLM 用的是 HuggingFace 格式safetensors。你需要重新下载一份 HF 格式的模型不能直接复用 Ollama 的模型文件。第二API 行为有差异。Ollama 的 OpenAI 兼容接口是尽力兼容有些字段行为不一致。比如logprobs参数Ollama 支持有限vLLM 支持完整。迁移前先用测试用例跑一遍确认关键接口行为一致。第三并发模型不同。Ollama 的并发是排队制vLLM 是连续批处理。如果你的应用逻辑依赖请求按顺序返回迁移后可能会乱序。需要在应用层加请求 ID 做匹配。第四显存需求不同。Ollama 的 GGUF 量化版本显存占用比 vLLM 的 BF16 版本低很多。从 Ollama 迁到 vLLM如果还用同样的硬件可能跑不起来。要么加卡要么用 vLLM 的 AWQ 量化版本。迁移的推荐路径是先在测试环境用 vLLM 跑通用相同的测试集对比输出质量确认无误后再切生产流量。切换时用灰度发布先切 10% 流量观察一周再全量。7. 常见问题与排查技巧实录7.1 部署阶段高频报错速查报错信息根因解决方法api error: 400 the supported api model names are deepseek-flash, deepseek-v4客户端发送的模型名不在支持列表改成deepseek-v4或创建别名ValueError: model class DeepseekV4ForCausalLM not foundvLLM 版本过低升级到 0.6.2 以上CUDA out of memory显存不足降低 max-model-len 或 gpu-memory-utilizationollama run file does not exist模型未拉取或路径错误先ollama pull再 runNCCL error: unhandled system error多卡通信失败检查 NVLink 桥接和 NCCL 版本ImportError: libcudart.so.12CUDA 版本不匹配装对应 CUDA 版本的 wheelRuntimeError: Expected all tensors on same device张量并行配置错误检查 tensor-parallel-size 是否等于 GPU 数7.2 性能不达预期的排查思路性能问题比报错更难排查因为它不报错就是慢。我总结了一套排查流程第一步确认 GPU 真的在用。跑nvidia-smi看 GPU 利用率。如果利用率低于 50%说明瓶颈不在 GPU可能在 CPU 预处理、磁盘 IO 或网络。如果利用率 100% 但吞吐还是低说明是计算瓶颈考虑量化或加卡。第二步确认显存没爆。显存爆了不一定会报错vLLM 会悄悄把部分 KV Cache 换到 CPU速度断崖式下降。看nvidia-smi的显存占用如果接近 100%就是显存瓶颈。第三步确认批处理生效。vLLM 的日志里会打印每批的 batch size。如果 batch size 一直是 1说明 Continuous Batching 没生效检查--max-num-seqs参数。第四步确认卡间通信正常。多卡场景下用nvidia-smi topo -m看卡间连接方式。如果是SYS走 PCIe 和 CPU通信开销会很大。理想情况是NVLink。第五步确认输入长度。输入越长首 token 延迟越高。如果业务场景输入普遍在 8K 以上考虑开启 chunked prefill。7.3 独家避坑经验最后分享几条我在实际部署中踩出来的经验都是文档里不会写的关于电源双卡 5090 的瞬时功耗能冲到 1400W 以上电源的瞬时功率余量要留足。我推荐 1300W 金牌起步别省这个钱。另外电源的 12V 单路输出能力要够多路 12V 的电源在高负载下容易触发保护。关于散热5090 的涡轮卡适合多卡密集部署但噪音大开放式散热卡噪音小但多卡并排时热风互相加热温度能差 15 度以上。如果机箱风道不好建议上水冷或者用 PCIe 延长线把卡分开。关于模型下载HF 格式的 DeepSeek-V4 完整版有 600GB 以上下载是个大工程。建议用huggingface-cli download配合--resume-download参数断点续传。国内下载慢的话配置镜像站能提速到 20-50 MB/s。关于版本锁定vLLM 和 SGLang 的版本迭代非常快新版本经常引入不兼容变更。生产环境一定要锁定版本用pip freeze requirements.txt记录完整依赖别用latest。关于监控GPU 温度要重点监控。5090 的结温上限是 90 度超过 85 度就会降频。我见过因为散热不良导致吞吐腰斩的案例加两个机箱风扇就解决了。关于测试上线前一定要做压力测试用locust或wrk模拟真实流量。测试数据要覆盖短输入短输出、短输入长输出、长输入短输出、长输入长输出四种组合因为不同组合的性能特征差异很大。关于成本别只看硬件采购成本运维成本也要算。本地部署意味着你要自己处理硬件故障、驱动升级、模型更新、安全补丁这些都需要人力。小团队如果没有专职运维用云服务可能更划算。我个人在实际操作中的体会是本地部署 DeepSeek-V4 这件事技术门槛其实不高真正的难点在于选对方案和持续运维。很多人一上来就追求最高配置结果发现日调用量根本撑不起成本也有人图省事一直用 Ollama业务起来后被迫仓促迁移踩了一堆坑。我的建议是先用 Ollama 或 LM Studio 跑通验证明确业务需求后再决定是否上 vLLM 或 SGLang每一步都留好退路。