围绕DeepSeek模型特性、vLLM核心机制、多卡并行配置与生产调优，给出可落地的部署路径与性能优化方法。
DeepSeek-V3与DeepSeek-R1把MoE和MLA带到主流推理场景，671B总参数、37B激活参数的结构在控制计算量的同时，对显存容量、专家通信和KV cache管理提出更高要求。vLLM的PagedAttention、连续批处理和OpenAI兼容接口降低了服务化门槛，但真正高效部署需要把模型结构、硬件拓扑、并行参数和线上指标放在同一张工程图中校准。
1. DeepSeek模型结构与显存预算。
部署DeepSeek的第一步不是直接拉取镜像启动服务，而是先核算模型权重、KV cache和运行时开销的显存占用。DeepSeek-V3与R1采用671B总参数、37B激活参数的MoE结构，包含61层、7168隐藏维度、256个路由专家和1个共享专家，每个token激活8个路由专家。FP8权重约671GB，BF16权重约1.34TB，4bit量化权重约335GB。单机8×H100 80GB共640GB显存，在FP8下容量偏紧，通常需要AWQ或GPTQ 4bit量化，或者采用双节点部署；8×H200 141GB共1128GB显存则更适合FP8全量权重。8×H20 96GB在容量上可以容纳FP8权重，但算力与互联带宽较弱，需要更保守的并发规划。
MLA结构是DeepSeek显存规划中的关键变量。它通过低秩压缩和矩阵吸收降低每token的KV cache开销，使长上下文服务比传统MHA更节省显存，但高并发和32K以上上下文仍会让KV cache快速膨胀。实际预算要覆盖权重、KV cache、激活值、CUDA Graph、通信缓冲和框架预留，不能只按权重占用做判断。以32K上下文、并发128为例，KV cache占用会随序列长度和批大小线性增长，部署前应结合vLLM的gpu-memory-utilization参数留出10%到15%余量，避免启动后因缓存不足频繁抢占或排队。
量化方案需要与业务精度要求一起评估。FP8在Hopper和较新GPU上具备较好吞吐与精度平衡，适合R1这类推理模型；4bit量化能显著降低显存门槛，但对数学推理、代码生成和长文档问答的精度影响需要通过业务集回归验证。MoE模型的专家权重分布不均，量化后还要关注路由是否稳定、是否出现专家负载倾斜。对于教学和项目交付场景，建议先以FP8建立基线，再用相同评测集对比4bit版本的准确率、首token延迟和吞吐，避免为了单卡跑通而牺牲线上可用性。
2. vLLM核心机制与DeepSeek适配。
vLLM高效部署DeepSeek的核心在于PagedAttention和连续批处理。PagedAttention把KV cache切分为固定大小的block，通过块表把逻辑序列映射到非连续物理块，减少长上下文场景下的显存碎片，并支持前缀共享。连续批处理让不同请求的prefill和decode阶段动态拼批，避免传统静态批处理中短请求等待长请求的问题。chunked prefill则把长prompt切块调度，控制首token延迟和decode抖动。对于DeepSeek的MLA，vLLM需要通过专门kernel处理压缩KV和矩阵吸收，避免按传统MHA展开缓存；对于MoE，路由kernel和专家权重加载直接影响多卡通信效率。
模型适配层需要注意版本和配置。DeepSeek-V3与R1需要较新的vLLM版本才能获得稳定的MLA、MoE和FP8支持，启动时要确认tokenizer、chat template、RoPE配置和max-model-len与模型卡一致。OpenAI兼容接口适合快速接入现有应用，但生产环境要设置served-model-name、api-key和请求超时，避免客户端把推理服务当成无限并发接口。prefix caching对系统提示词较长的Agent和客服场景收益明显，命中后可跳过重复prefill，降低首token延迟；但缓存会占用显存，需要结合请求特征评估命中率和驱逐策略。
DeepSeek的MoE结构还要求关注专家并行和批处理上限。TP切分时注意力头数和专家数需要能被并行度整除，专家路由产生的all-to-all通信在跨节点部署时容易成为瓶颈。max-num-seqs设置过高会增加KV cache压力和调度开销，设置过低则浪费GPU算力；max-num-batched-tokens同样需要在吞吐和延迟之间折中。实践中可以先以较小并发建立稳定基线，再逐步提高批处理上限，观察KV cache使用率、等待队列和TPOT变化。投机解码并非默认选项，DeepSeek场景下草稿模型与主模型的接受率不确定，未经验证开启可能反而增加延迟。
3. 多卡并行参数配置实战。
多卡部署DeepSeek要先确定拓扑。单机8卡H200或H20可优先采用张量并行，TP=8能覆盖128个注意力头和256个路由专家的切分需求，NVLink互联可降低层内通信开销。单机8×H100在FP8权重下容量不足时，可选择4bit量化单机部署，或采用双节点TP=16、PP=2的组合。跨节点部署必须确认InfiniBand或高速以太网带宽，MoE的专家通信对延迟敏感，网络不足会让TP扩展失去线性收益。启动参数上，–tensor-parallel-size要与GPU数和模型头数匹配，–max-model-len按业务最长上下文设置，–gpu-memory-utilization通常从0.85到0.90起步，–enable-prefix-caching适合长系统提示场景，–kv-cache-dtype fp8需要经过精度评测后再启用。
以8×H200部署DeepSeek-R1 FP8为例，可采用TP=8、max-model-len=32768、gpu-memory-utilization=0.90、max-num-seqs=128、max-num-batched-tokens=8192的初始配置，并通过OpenAI兼容端口暴露服务。若业务以短问答为主，可降低max-model-len释放KV cache空间，提高max-num-seqs；若以长文档分析为主，则应保留较长上下文，降低并发上限并开启chunked prefill控制首token延迟。对于8×H100环境，FP8全量权重容量不足时不要强行提高gpu-memory-utilization，否则启动阶段就会因权重加载失败退出，应改用4bit量化或双节点方案。
参数配置还要与调度策略联动。max-num-batched-tokens过大会让长prompt占用过多计算预算，导致decode请求等待；过小则降低prefill吞吐。max-num-seqs过高会让KV cache迅速达到上限，vLLM开始排队后TTFT明显上升。生产环境建议为在线请求和离线批处理拆成不同实例，在线实例优先保障P95 TTFT，离线实例提高批大小追求吞吐。多副本部署时要在网关层做负载均衡和限流，避免单副本过载后拖垮整体服务。对教学团队而言，保留一套可复现的启动参数和硬件清单，比单纯追求最大并发更有交付价值。
4. 压测调优与生产运维。
压测要围绕TTFT、TPOT、吞吐和goodput展开。TTFT反映用户等待首字的时间，TPOT反映逐token生成流畅度，吞吐体现单位时间生成的token数，goodput则把满足SLA的请求计入有效产出。可以使用vLLM自带的benchmark_serving，用固定输入输出长度和真实业务分布分别压测，观察不同并发下的P50与P95指标。压测时同步记录GPU利用率、HBM占用、KV cache使用率、等待队列长度和NVLink或IB流量，判断瓶颈在计算、显存还是网络。对于32K上下文在线问答场景，可先将max-num-batched-tokens设为4096到8192，逐步提高并发，直到P95 TTFT接近SLA上限，再回退一档作为生产配置。
线上监控应覆盖vLLM暴露的Prometheus指标，包括运行中请求数、等待请求数、KV cache使用率、首token延迟和逐token延迟。KV cache使用率长期高于90%且等待队列上升，说明并发或上下文长度超出容量，需要降低max-model-len、减少max-num-seqs或增加副本。prefix cache命中率低时，应检查系统提示是否稳定、请求前缀是否一致，避免缓存策略形同虚设。GPU侧要关注功耗、温度和显存增长趋势，MoE服务在专家负载不均时可能出现单卡利用率偏高，需要结合路由统计调整并行策略。日志中要保留请求长度、生成长度、排队时间和错误码，便于定位长尾请求。
生产运维还要处理版本升级、限流和安全。vLLM版本升级可能改变调度行为或模型支持范围，滚动升级前应在影子环境用相同压测集验证TTFT、TPOT和精度回归。网关层按租户和API key限流，设置最大输入长度和最大输出长度，防止单个长请求挤占KV cache。Kubernetes部署要配置readiness和liveness探针，探针应检查模型是否完成加载和接口是否可推理，而不是只检查端口存活。对于R1这类推理模型，业务评测集要覆盖数学、代码和长文档问答，量化版本与FP8版本分别留档。以一套8×H200在线服务为例，通过prefix caching和chunked prefill把P95 TTFT压到1.5秒以内，再将离线批处理实例的max-num-seqs提高，可以在同一套模型权重上兼顾交互体验与批量吞吐。
