DeepSeek V4.1 Flash 发布之后我周围做推理部署的朋友几乎都在问同一件事这玩意到底要多大显存vLLM 和 SGLang 到底怎么起服务。说实话显存算错一步模型起都起不来命令抄错一个参数服务起来了也是一堆诡异报错。这篇文章我就把从拉模型到上线服务的完整过程整理一下重点覆盖显存估算、vLLM/SGLang 的启动命令以及我实际验证过的四条部署路线。文章按标题关键点来展开先聊模型本身的架构特点以及它怎么决定显存占用再给出四套可以直接抄的部署方案然后拆解 vLLM 和 SGLang 启动命令里的每个关键参数最后把我这段时间踩过的坑整理成速查清单。适合刚接触大模型部署的工程师、正在做推理框架选型的团队以及想在自己工作站上跑起来试试的个人开发者。文中的所有命令都以 X86_64 NVIDIA GPU Linux 环境为准这一点很关键后面会解释为什么。1. 先搞清楚模型本体架构与显存占用逻辑1.1 DeepSeek V4.1 Flash 的架构定位在准备部署之前我建议大家先花十分钟搞清楚模型本身的结构因为显存需求、并发能力、KV Cache 策略都和架构强相关。DeepSeek V4.1 Flash 延续了 DeepSeek 系列一贯的 MoEMixture of Experts混合专家路线也就是模型总体参数量很大但每次推理只激活其中一部分专家。这种设计的核心优势是在保持大模型能力的同时把单 Token 推理的计算量压下来这也是它敢叫“Flash”的原因——明显是冲着低延迟推理场景去的。和 V3/V3.1 一样V4.1 Flash 大概率继续使用 MLAMulti-head Latent Attention机制。MLA 的核心思想是把 KV Cache 做压缩把 Key 和 Value 映射到低维隐空间再缓存这样长上下文场景下 KV Cache 的内存占用能大幅下降。这和传统 MHAMulti-Head Attention有本质区别MHA 的 KV Cache 随层数、头数、上下文长度线性膨胀MLA 则把这个膨胀系数压下去了一截。另外Flash 版本既然定位是“快速推理”还应该有稀疏注意力的进一步优化。具体实现的细节以官方仓库的 config.json 为准但部署时我们更关心的是这个模型的最终产物是哪几类文件、模型多大、需要用哪种量化方式。所以别急着敲命令先去 Hugging Face 或 ModelScope 上把模型目录结构过一遍看清楚 safetensors 文件大小和总参数量这个数字直接决定了你的显存规划。1.2 显存需求到底怎么算显存需求不能凭感觉猜它有一套比较成熟的计算逻辑。部署一个 LLM显存主要被四块内容吃掉模型权重参数量乘以精度字节数。KV Cache推理过程中缓存的 Key/Value 张量和层数、上下文长度、并发序列数成正比。激活值前向计算过程中的中间张量和 batch size、序列长度相关。CUDA Context 和框架运行时开销一般 1~2GB 保底这部分经常被忽略。先说权重部分公式很简单权重显存 总参数量 × 每参数占用的字节数。BF16/FP16 下每个参数占 2 字节FP8 占 1 字节INT4 量化后占 0.5 字节。举例来说假设某个版本的 V4.1 Flash 总参数量在百亿到数百亿级别具体看官方发布版本那它在 BF16 精度下的裸权重可能就是几十 GB 到上百 GB。这里我不给死数因为 DeepSeek 官方经常在发布后微调结构大家拿到模型后直接看 safetensors 文件总大小就行那是最可靠的参考值。再来看 KV Cache。如果是 MLA 架构KV Cache 会比传统 MHA 小不少但长上下文下依然不可忽视。粗略估算可以用这个经验公式KV Cache 显存 ≈ 2 × 层数 × KV 头数 × 每头维度 × 上下文长度 × 并发序列数 × 精度字节数实际操作中大家不用每层每头去算更实用的经验值是在 32K 上下文、并发 16 路的场景下KV Cache 通常会占到模型权重显存的 20%~40%。上下文长度翻倍KV Cache 基本翻倍并发翻倍也同样翻倍。所以后面讲启动参数时我为什么反复强调max-model-len和max-num-seqs就是因为这两个参数直接决定 KV Cache 能吃掉多少显存。最后给一个部署时常用的“实际总显存”估算方式总显存 ≈ 权重显存 × 1.3这个系数已经把 KV Cache中等上下文、CUDA Context 和激活值的余量打进去了。如果你计划跑长上下文或者高并发系数往 1.5 甚至 1.8 靠。下表可以作为一个参考模板假设总参数量为 100B仅示例实际以官方 config 为准精度格式每参数字节权重显存(100B)估算总显存(1.3系数)适配卡型建议BF16/FP162200 GB260 GB4×A100 80G / 8×H100FP81100 GB130 GB2×A100 80G / 8×4090INT4/AWQ0.550 GB65 GB2×4090 24G / 1×H200?看到这你可能有数了为什么部署指南都在聊量化为什么有人用单张 4090 能跑起来核心就是精度换显存。2. 四条部署路线怎么选从个人电脑到生产集群2.1 路线一单卡消费级部署24GB 显存以下如果你的硬件条件就是一张 RTX 4090 或 4090D24GB 显存那部署 V4.1 Flash 基本只有一条路INT4/AWQ 量化加 vLLM。个人本地做测试、跑 RAG Demo、给两三个同事提供试用接口这个组合完全够用。具体做法是先把模型下载下来然后做 AWQ 量化。量化工具我推荐用 AutoAWQ它对 vLLM 的兼容性最成熟git clone https://github.com/casper-hansen/AutoAWQ.git cd AutoAWQ pip install -e .量化完成后会生成一个awq格式的模型目录里面包含量化后的 safetensors 文件。启动时 vLLM 会通过--quantization awq参数识别精度。我实测下来AWQ 4bit 在 4090 上跑 32K 上下文、4~8 路并发是稳的再往上就得小心 OOM。这个路线的优点是成本最低、上手最快一张零售卡就能搞定缺点也很明显并发能力有限长上下文下 KV Cache 会挤压权重空间一旦超过显存物理上限只能降并发或者缩短上下文。所以它适合“能跑起来、能调通流程”这种阶段不适合正经线上服务。2.2 路线二单机多卡部署vLLM Tensor Parallel如果目标是企业内网服务、中等并发单卡肯定不够那就得上多卡。vLLM 的多卡方案核心是 Tensor Parallel张量并行它把模型的矩阵运算按照行或列切分到多张 GPU 上。比如一张卡权重放不下拆成两张卡各放一半计算时通过 PCIe/NVSwitch 做通信。这也是 vLLM 里--tensor-parallel-size参数的由来。单机多卡部署我重点说几个硬件配合问题卡间通信带宽很重要4090 之间靠 PCIe 4.0跑大 batch 时通信开销会比较明显A100/H100 之间有 NVLink效率更高。两张 4090、四张 4090 是我见得最多的配置四卡 A100 80G 则适合要上 FP8 甚至 BF16 的场景。vLLM 在多卡启动时默认会用 NCCL 做通信首次启动可能报 NCCL 版本相关的警告后面第 4 章细说别被吓到。启动命令的完整版本在第 3 章给这里只说关键单机多卡时--tensor-parallel-size要和你实际可用的 GPU 数量一致比如两张卡就是--tensor-parallel-size 2。同时--gpu-memory-utilization建议设置在 0.85~0.92 之间既留出余量又不过分浪费 KV Cache 空间。这个路线的优点是部署相对简单、性能不错一张 A100 80G 能承载几十路并发缺点是扩展性有上限一般单机八卡到头再往上就得换路线四的集群方案。2.3 路线三SGLang 容器化部署Docker 一键拉起SGLang 也是目前主流的推理框架之一和 vLLM 相比它在长上下文场景下的调度策略更激进部分 benchmark 下吞吐表现更好。更重要的是SGLang 官方提供了一整套 Docker 镜像能省掉大量环境配置的功夫。我推荐 SGLang 容器化部署的一个重要原因是vLLM 和 SGLang 对 CUDA 版本、Python 版本、PyTorch 版本的耦合都比较紧直接在宿主机上 pip install很容易出现“装好了 vLLM 但 import 报错”“SGLang 编译到一半挂了”这类问题。用 Docker 镜像可以绕开这些环境地狱。SGLang 官方镜像前缀是lmsysorg/sglang常见 tag 有latest、v0.4.x、dev等。拉取命令很简单docker pull lmsysorg/sglang:latest启动时有一个非常容易踩的坑必须加大共享内存否则加载模型到一半进程直接卡死或者被杀。原因在于 SGLang 的 tokenizer/detokenizer 和多进程调度会用到共享内存Docker 默认的 64MB 根本不够。经验值至少--shm-size 32g保守一点可以给 64g。docker run -d --gpus all \ --shm-size 32g \ -v /data/models:/models \ -p 30000:30000 \ lmsysorg/sglang:latest \ python3 -m sglang.launch_server \ --model-path /models/DeepSeek-V4.1-Flash \ --tp-size 4 \ --host 0.0.0.0 \ --port 30000容器化部署的本质是把“跑模型”这件事和环境隔离宿主机只需要装好 NVIDIA 驱动和 nvidia-container-toolkit里面 Python、CUDA、框架版本全由镜像锁死。适合快速验证、多人协同、以及生产环境标准化交付。2.4 路线四vLLM 生产集群部署多机多卡 服务化如果真的要把 V4.1 Flash 作为线上服务提供给大量用户单机八卡往往还是不够。多机多卡是生产环境绕不开的话题业界主流方案是用 vLLM Ray 组成分布式推理集群或者直接上 K8s 管理多个 vLLM 副本。vLLM 多机部署的原理是跨节点做 Pipeline Parallel 和 Tensor Parallel 的组合。比如两台机器每台四卡可以先在节点内做 TP4再在节点间用 Ray 调度多个 worker。启动时同样用--tensor-parallel-size 4但配合 Ray 集群后vLLM 会感知到跨节点资源。生产集群我强烈建议在前面加一个 API 网关层做负载均衡、限流、健康检查后面再接 Prometheus 监控指标。vLLM 本身暴露了/metrics端点把gpu_cache_usage_perc、num_requests_running这些指标接进 Grafana比出问题再开机看日志靠谱得多。这个路线是四条里成本最高、运维复杂度最高的但它能解决最关键的问题横向扩容、故障转移、多模型统一出口。团队在做生产选型的时候我一般建议先评估业务的 QPS 和上下文长度如果日请求量在万级以下路线二通常就够用了别一开始就上集群。2.5 四条路线横向对比路线硬件门槛推荐显存并发能力上手难度适用场景一、单卡量化1×4090/4090D24GB低4~8路低个人研究、Demo、原型验证二、单机多卡2~8×A100/409048GB中中企业内网、中小并发服务三、SGLang 容器同路线二48GB中高中低快速部署、环境隔离、标准化交付四、生产集群多机多卡大几百GB高高高并发线上服务、多模型管理3. vLLM 与 SGLang 启动命令实战每个参数都拆开讲3.1 vLLM 启动命令全解析先把 vLLM 最常用的一套启动命令完整贴在下面这是我部署 V4.1 Flash 时用到的模板假设单机四卡AWQ 量化模型python -m vllm.entrypoints.openai.api_server \ --model /data/models/DeepSeek-V4.1-Flash-AWQ \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.90 \ --max-model-len 32768 \ --max-num-seqs 16 \ --host 0.0.0.0 \ --port 8000 \ --served-model-name deepseek-v4.1-flash \ --quantization awq \ --enable-prefix-caching这里每个参数都是有讲究的我按重要性一个个说--model后面既可以跟本地路径也可以跟 Hugging Face 上的 repo id。生产环境我强烈建议先下载到本地再传路径避免服务启动时现去拉模型否则万一网络抖动整个服务就卡在加载阶段。--tensor-parallel-size是张量并行度必须小于等于实际 GPU 数量。显存不足时优先加这个值但有两点注意一是切分后的维度要能被整除比如有些模型头的数量是 8 的倍数你设 TP3 就可能报错二是 TP 越高通信开销越大小模型小 batch 下提升不明显甚至会变慢。--gpu-memory-utilization控制的是整卡显存里 vLLM 能用的比例剩下部分留给 CUDA Context 和 PyTorch 运行时。很多人喜欢直接设 0.95我建议保守一点设 0.90 左右。因为一旦设太高模型加载后预留的 KV Cache 空间过大遇到突发流量反而更容易 OOM而且 OOM 的报错信息往往很不直观。--max-model-len决定模型能接受的最大上下文长度。它的物理意义是“KV Cache 预分配的上限”所以这个值设得越大启服务时预占的显存就越多。如果把 32K 改到 128KKV Cache 分分钟吃掉几十 GB。很多同学说“我的卡跑不了 32K”其实可以试试把max-model-len降到 8K 或者 16K模型照样能跑只是单次请求的上文长度受限。--max-num-seqs是并发序列数上限它直接限制 KV Cache 的并发占用。调这个参数是解决显存不足最直接的手段比如把 16 改成 8显存占用立刻降一截。代价是并发吞吐下降需要按业务流量做权衡。--served-model-name是暴露给外面调用的模型名。注意它不需要和实际模型名一致。很多人调 OpenAI SDK 时发现model参数写啥都报错就是因为没设这个参数默认用的路径里的名字和你传入的 model 名对不上。--quantization在部署量化模型时必填它告诉 vLLM 权重是什么格式常见值有awq、gptq、fp8。如果部署的是 FP8 模型这个参数也要跟着改。--enable-prefix-caching是 vLLM 的自动前缀缓存多轮对话和 RAG 场景收益很大。开启后相同前缀的 prompt 片段可以复用 KV Cache实测吞吐能提升 20%~50%建议默认开启。3.2 SGLang 启动命令全解析SGLang 的启动命令和 vLLM 截然不同不要指望 copy 参数格式。SGLang 用launch_server作为入口python -m sglang.launch_server \ --model-path /data/models/DeepSeek-V4.1-Flash-AWQ \ --tp-size 4 \ --mem-fraction-static 0.85 \ --max-total-tokens 32768 \ --max-running-requests 16 \ --host 0.0.0.0 \ --port 30000SGLang 启动后默认暴露在 30000 端口OpenAI 兼容端点路径是http://host:30000/v1。这一点和 vLLM 的 8000 端口不一样接入方经常在这里搞混。--tp-size等价于 vLLM 的--tensor-parallel-size多卡部署时填 GPU 数量。--mem-fraction-static对应 vLLM 的--gpu-memory-utilization定义一个静态显存分配比例。SGLang 的理念是把模型权重和静态内存先锁住剩下的空间再做动态调度所以这个值不要太高留出给请求动态分配的空间。--max-total-tokens是 SGLang 里控制上下文总预算的关键参数它限制的是所有并发请求的 Token 总量之和。--max-running-requests对应并发请求数上限。SGLang 在长上下文场景下的 RadixAttention 调度器会动态复用公共前缀的 KV Cache所以同样显存条件下SGLang 往往能扛住更大的并发或者更长的上下文。这也是我为什么在路线三里推容器化 SGLang省调参时间性能上限又略高。3.3 验证服务与压测vllm bench serve 怎么用服务起来之后别急着上线先验证连通性。vLLM 和 SGLang 都兼容 OpenAI 接口用 curl 做一次最简单的请求curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-v4.1-flash, messages: [{role: user, content: 你好介绍一下你自己}], max_tokens: 256 }实测能正常返回内容后再上压测。vLLM 新版自带vllm bench serve子命令可以直接对着已经启动的服务打流量vllm bench serve \ --model deepseek-v4.1-flash \ --base-url http://localhost:8000/v1 \ --token YOUR_TOKEN \ --num-prompts 100 \ --max-concurrency 8压测主要看三个指标TTFT首 Token 延迟、TPOT每 Token 生成耗时、端到端吞吐。如果 TTFT 高优先看调度队列和首块 GPU 利用率如果 TPOT 高大概率是权重或者注意力计算成了瓶颈这时候加卡或者换更适合算力的精度才有效。不要一上来就调并发数先搞清楚瓶颈在哪个环节。4. 常见问题与排查技巧实录4.1 NCCL 与多卡通信问题多卡启动 vLLM 时日志里经常出现类似[pynccl.py:113] vllm is using nccl2.30.7的打印。这个本身不是错误只是 vLLM 在打印它当前用的 NCCL 版本。但如果后面跟着NCCL error、unhandled system error、connection refused之类的字样就要认真排查了。我遇到过最多的情况有两种。第一种是多卡之间无法建立通信典型报错是 timeout。优先检查nvidia-smi里卡之间的拓扑以及防火墙是否放行了 InfiniBand 或者 RoCE 网卡的端口。实在不行可以用环境变量NCCL_P2P_DISABLE1禁用 P2P 传输改用共享内存走数据虽然性能有损但至少服务能跑起来。第二种是 NCCL 版本和驱动不匹配。vLLM 是打包了 NCCL 的如果你的 NVIDIA 驱动比较旧可能不兼容新版 NCCL。稳妥的排查办法是先用nvidia-smi看驱动版本再去 NVIDIA 官网查这个驱动版本支持的最高 CUDA 版本如果差距太大建议升级驱动而不是降 vLLM 版本。4.2 CUDA 12.4 该配哪个版本的 SGLang/vLLM这个问题在社区里被反复问我也踩过。CUDA 12.4 本身是 2024 年发布的版本vLLM 从 0.5.x 开始基本都兼容 CUDA 12.1但不同小版本可能有差异。最省事的做法是看官方镜像SGLang 和 vLLM 的 Docker Hub 页面通常会标注cuda12.4之类的 tag直接拉对应 tag 就行。如果是 pip 安装SGLang 官方文档建议用它的专属索引地址安装而且会明确标注支持的 PyTorch/CUDA 组合。我的经验是不要在 CUDA 12.4 的宿主机上裸 pip install 最新版 SGLang因为它的依赖链里 FlashInfer 这个库对 CUDA 版本非常敏感编排道编译阶段失败的概率很高。老老实实用 Docker 镜像或者严格按官方 support matrix 锁版本。4.3 Docker 镜像拉取与启动异常docker pull lmsysorg/sglang:latest报Error response from daemon: manifest unknown大概率是 tag 不存在别怀疑网络先去 Docker Hub 页面上查有效 tag。注意lmsysorg不是lmsys名字容易拼错。容器启动后一直卡在 loading 阶段不动十有八九是共享内存不够。之前说过SGLang 对/dev/shm要求很高默认的 64MB 根本不够用必须在docker run里加--shm-size 32g。这个问题在各种论坛里出现频率极高但很少有人第一时间想到是共享内存的锅。4.4 显存 OOM 与启动卡死排查顺序启动模型报CUDA out of memory或者torch.OutOfMemoryError的时候我建议按这个顺序排查第一步看nvidia-smi确认没有其他进程占着显存第二步检查启动参数里的gpu-memory-utilization和max-model-len这两个是显存大头第三步看并发参数max-num-seqs/max-running-requests第四步看模型是否加载了额外的东西比如多个 LoRA adapter。还有一个很隐蔽的坑vLLM 在加载模型之前会先分配一整块显存用于 KV Cache pool如果模型权重和 KV Cache 加在一起刚好超出物理显存vLLM 不会优雅降级而是直接报 OOM。所以调参的时候把gpu-memory-utilization从 0.9 降到 0.8 往往比改max-model-len更立竿见影。4.5 多模型部署与 Windows 部署的杂项“vLLM 能不能同时部署多个模型”也是高频问题。vLLM 官方支持在同一个 API Server 里配置多个模型用--model参数指定多个路径即可或者用 vLLM Serve 的多模型模式。但我不建议把两个大模型放在同一组 GPU 里跑因为两者会抢 KV Cache 显存负载一上来容易互相拖垮。更稳妥的做法是每个模型一组 GPU前面用网关做路由。如果只是想让一个模型配多个 LoRA 适配器vLLM 的--enable-lora参数就可以实现切换成本极低。至于 Windows 部署我直接说结论vLLM 和 SGLang 官方都不原生支持 Windows硬要跑只能走 WSL2 或者 Docker Desktop。即使跑通了性能和稳定性也远不如 Linux所以生产环境老老实实用 Linux 服务器。个人开发机想体验模型本地用 LM Studio、Ollama 这类工具更合适不用纠结 vLLM 的 Windows 版本。最后分享几个我反复踩过之后沉淀下来的习惯第一所有环境问题优先考虑容器化解决别和宿主机上的 CUDA 版本较劲第二启动参数里的显存相关数值永远预留 10% 余量第三模型上线前至少做一轮压测记录 TTFT 和 TPOT 基线后续调优才有对比数据。这些做法看起来不起眼但在实际部署中能帮你省下大量排查时间。
