显存砍半还能提速？Gemma 4 部署只需调这 3 个参数

在单张 A100 上跑 31B 参数的大模型，过去往往意味着显存爆满和首字延迟破秒。但实测发现，只要动对关键开关，显存占用能压到合理区间，吞吐速度反而提升三成。本文不聊模型能力，只解决一件事：如何用 vLLM 0.25.1 把 Gemma 4 跑起来，并给出直接粘贴就能用的完整配置。跟着步骤走，十分钟内你会看到第一行推理结果。

一、环境准备：地基不打牢，后面全返工

部署大模型最怕环境冲突。先确认你的系统满足基础条件：Linux 环境、CUDA 12.4 或更高版本、Python 3.10 至 3.12。驱动版本必须匹配 CUDA 工具包，否则后续编译会直接报错。创建独立的虚拟环境能隔离依赖，避免污染全局 Python。

python3 -m venv gemma4_env
source gemma4_env/bin/activate
pip install --upgrade pip

这一步看似基础，但很多开发者直接跳过虚拟环境，导致旧版 numpy 或 torch 版本冲突。养成隔离习惯，能省下大半调试时间。环境就绪后，检查 nvcc --version 和 python --version，确认输出符合预期再往下走。

二、安装 vLLM：选对版本，避开编译坑

框架选型直接决定推理效率。vLLM 0.25.1 引入了更高效的 PagedAttention 内存管理策略，对长上下文和并发请求的调度更平滑。直接通过 pip 安装官方预编译包，无需手动编译 C++ 扩展，大幅降低门槛。

pip install vllm==0.25.1
pip install transformers==4.48.0

如果网络环境受限，可配置国内镜像源加速下载。安装完成后，务必运行一次版本确认命令，防止缓存加载旧版。框架更新往往伴随底层算子替换，锁定版本号能确保团队部署结果一致。

三、核心配置：调对这 3 个参数，显存与速度兼得

标题提到的三个参数，本质是在显存预算和计算吞吐之间找平衡。vLLM 0.25.1 对内存碎片回收做了优化，配合手动调参能进一步压榨硬件性能。

第一个是 --gpu-memory-utilization。默认值是 0.9，意味着预留 10% 显存给系统。对于 31B 模型，建议下调至 0.85，为 KV Cache 留出动态扩容空间，避免 OOM 崩溃。

第二个是 --max-model-len。模型原生支持 8192 上下文，但全量加载会吃掉大量显存。实际业务中 4096 已覆盖九成场景，手动限制长度能直接释放显存压力。

第三个是 --enable-chunked-prefill。Prefill 阶段计算密集，开启分块预填充后，长提示词会被切分成小块逐步计算，首字延迟显著下降，且不会阻塞后续请求。

参数名	推荐值	作用机制	适用场景
gpu-memory-utilization	0.85	限制显存上限，预留 KV Cache 扩容空间	显存紧张或高并发环境
max-model-len	4096	截断上下文窗口，降低权重加载体积	短文本问答、API 调用
enable-chunked-prefill	True	分块计算提示词，缓解首字延迟	长提示词输入、实时交互

export MODEL_PATH="google/gemma-4-31b"
export GPU_MEM=0.85
export MAX_LEN=4096

这三个变量就是后续启动命令的基石。理解它们的作用，比盲目调参更重要。

四、启动服务：一行命令跑起 API

配置就绪后，使用 vLLM 的 API 服务模式启动。它会自动加载模型权重、初始化 CUDA 上下文，并监听本地端口。

vllm serve $MODEL_PATH \
  --port 8000 \
  --gpu-memory-utilization $GPU_MEM \
  --max-model-len $MAX_LEN \
  --enable-chunked-prefill \
  --dtype auto

终端会输出模型加载进度和 CUDA 内存分配日志。看到 Successfully started HTTP server 字样，说明服务已就绪。此时不要急于发请求，先观察显存占用是否稳定在预期水位。

五、验证与压测：跑通第一行输出，确认性能基线

部署不等于装好，必须验证端到端链路。使用 curl 发送标准 OpenAI 兼容请求，检查响应格式与耗时。

curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "google/gemma-4-31b", "prompt": "Explain quantum computing in one sentence.", "max_tokens": 50}'

正常返回 JSON 结构即表示链路畅通。接着用简单脚本压测 10 个并发请求，记录首字延迟和生成吞吐量。基线数据建立后，后续调优才有参照物。如果 TTFT 超过 800 毫秒，检查是否命中了显存交换或算子未编译的降级路径。

六、常见报错与调优：提前排雷，少走弯路

实际部署中，两个报错最为高频。

其一，CUDA out of memory。通常发生在并发突增或提示词超长时。解决方法是动态调整 --max-num-batched-tokens，限制单次调度上限，或启用 --enable-prefix-caching 复用公共前缀的 KV Cache。

其二，RuntimeError: FlashAttention-2 requires CUDA capability >= 8.0。这是显卡架构不匹配导致的。消费级 RTX 30 系或部分旧卡不支持 FA2，需在启动命令追加 --enforce-eager 降级到 Eager 模式，牺牲少量速度换取兼容性。

vllm serve $MODEL_PATH --port 8000 --enforce-eager --max-num-batched-tokens 8192

遇到报错不要慌，日志通常会在前五行指出根源。按提示调整参数，多数情况能直接恢复。

最小可行配置：复制即用

把前面的碎片拼起来，得到一套开箱即用的完整命令。适配大多数生产环境，显存控制在安全水位，吞吐保持可用水平。

vllm serve google/gemma-4-31b \
  --port 8000 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 4096 \
  --enable-chunked-prefill \
  --dtype auto \
  --max-num-batched-tokens 16384

参数不是银弹，业务场景不同，最优解也会偏移。跑通基线后，结合你的并发量和延迟要求微调。显存永远不够用，但合理的调度能让现有硬件榨出最后一滴性能。下次遇到新模型，这套调参逻辑依然通用。