AI Deploy大模型本地部署帮你部署

本地大模型部署方案选型指南

按模型规格、硬件条件、并发需求和预算边界整理 vLLM 部署步骤，并说明 `tensor_parallel_size` 可将模型拆到多张 GPU，以及量化兼容性和验证方法。

本地部署大模型应按“模型与显存、单卡或多卡、上下文与并发、量化兼容性”做选择，再把结论落成 vLLM 配置。先形成硬件与负载清单，再逐项验证并行、参数和量化方案；直接照抄现成参数，通常解释不了显存与延迟之间的取舍。

本地部署大模型的选型清单

安装前，把以下项目写进同一张方案表：

  • 模型：记录模型标识、checkpoint、原始精度或量化格式。
  • 硬件：核对 GPU 显存、互联方式、插槽、尺寸、供电和 CPU 条件。
  • 负载：写明输入与输出长度、并发序列数，以及优先关注首 token 时间、token 间延迟还是吞吐量。
  • 验收：列出服务启动、请求返回、KV cache 容量和抢占情况等检查项。
  • 预算：从实际供应商当前报价页抄录资源、使用和一次性费用，用“总预算＝各项报价之和”核算；本文不提供价格数字。

硬件先过物理检查

截至 2026-10-01，NVIDIA 的 GeForce RTX 4090 官方规格列出 24 GB GDDR6X 显存；Founders Edition 的总图形功耗为 450 W，要求系统供电 850 W，显卡为 3 槽，长 304 mm、宽 137 mm。这些数字只能完成机箱、供电与显存的初筛，不能代替模型、量化和上下文配置是否适配的检查。

单机、多卡还是多节点

单机内，vLLM 的并行与扩缩容文档说明，tensor parallelism 会在每层内把模型参数分到多张 GPU，是常见的单机策略；pipeline parallelism 则把不同模型层放到不同 GPU，并按顺序处理。多节点时，文档给出的对应关系是 tensor_parallel_size 等于每个节点的 GPU 数，pipeline_parallel_size 等于节点数；如果节点内 GPU 没有 NVLINK，例如 L40S，文档建议考虑 pipeline parallelism，以降低通信开销。

设备选择应设置 CUDA_VISIBLE_DEVICES，而不是在 vLLM 启动前调用 torch device functions。启用 tensor parallelism 时，每个进程都会读取完整 checkpoint 再切分，磁盘读取时间会随并行规模增加。vLLM 的显存配置说明

用 vllm serve 固定关键参数

按照 vllm serve CLI 参数说明，--max-model-len 表示输入与输出合计的上下文长度，未设置时从模型配置推导；--max-num-seqs 限制单轮处理的序列数，--max-num-batched-tokens 限制单轮处理的 token 数。--gpu-memory-utilization 是模型执行器使用的 GPU 显存比例，未指定时默认值为 0.92，且它是当前 vLLM 实例的限制。同一 CLI 参数说明

先用占位符建立可审查的命令，再逐项替换：

vllm serve YOUR_VALUE \
  --max-model-len YOUR_VALUE \
  --max-num-seqs YOUR_VALUE \
  --max-num-batched-tokens YOUR_VALUE \
  --gpu-memory-utilization YOUR_VALUE \
  --tensor-parallel-size YOUR_VALUE \
  --pipeline-parallel-size YOUR_VALUE

每个 YOUR_VALUE 都应对应方案表中的模型、上下文、负载、显存和并行选择，而不是直接沿用示例值。

量化方案必须匹配硬件

vLLM 的量化文档将量化描述为用模型精度换取更小显存占用，并把 LLM Compressor 作为起点；该库支持 FP8、INT8、INT4 等格式。

同一兼容性表显示，AWQ 不支持 Volta 和 AMD GPU，但支持 Turing、Ampere、Ada、Hopper、Intel GPU 与 x86 CPU；llm-compressor FP8 W8A8 的支持项则是 Ada、Hopper 和 AMD GPU。vLLM 的量化兼容性表该表会随支持范围变化，采购或部署前应重新核对。

启动后怎样验证

启动日志中的 GPU KV cache size 表示 GPU KV cache 一次可容纳的 token 总量，应把它记录到验收表中。vLLM 的并行与扩缩容文档

服务地址、请求方法和字段名必须从当前安装版本的官方文档逐项核对。发送能够表达真实输入形态的最小请求，确认返回结构符合该版本文档，再观察运行日志是否出现频繁 preemption。

常见出错点

为什么会出现频繁 preemption？

KV cache 空间耗尽时，vLLM 会抢占请求，并在空间恢复后重新计算。文档把提高 gpu_memory_utilization 列为首选处理方式，也可降低 max_num_seqs 或 max_num_batched_tokens，以减少每批并发请求和 KV cache 需求。vLLM 的优化与调优文档

max_num_batched_tokens 越大越好吗？

不是。较小的值，例如 2048，有利于改善 token 间延迟；较大的值有利于改善首 token 时间。若目标是吞吐量，文档建议将其设为大于 8192，尤其是模型较小且 GPU 较大的场景。vLLM 的优化与调优文档

以上步骤按正文所链接的官方文档整理，使用前请对照当前版本核对。

资料来源