Ollama迁移到vLLM：高并发AI服务生产化重构指南

1. 项目概述：从单机玩具到万人并发的AI服务，这趟迁移不是升级，是重构

你有没有过这种体验：深夜两点，咖啡凉透，键盘上还沾着泡面碎屑，你刚用 Ollama 拉下来一个llama3:8b，本地跑通了聊天接口，输入“今天心情不好”，模型回了句带点哲理又不失温度的话——那一刻，你觉得自己离 AGI 就差一个 Dockerfile。第二天晨会，产品总监推了推眼镜：“用户反馈太好了，下周起全公司 10,000 名员工都要用上这个助手，HR、IT、法务、销售，全部接入钉钉和飞书。”会议室安静得能听见空调外机嗡嗡声。你低头看了眼自己那台顶配 M3 Max 笔记本上正跑着的ollama serve进程，内存占用 92%，GPU 温度 87℃，而压测脚本刚发出去 50 个并发请求，响应延迟就从 320ms 跳到了 4.7s，第 53 个请求直接返回502 Bad Gateway。这不是夸张，这是我去年在一家中型 SaaS 公司真实踩过的坑。Ollama 是极好的本地开发伴侣，它把大模型拉取、运行、调试的门槛压到了地板以下；但它的设计哲学里根本没写“高并发”“低延迟”“热更新”“资源隔离”这几个词。vLLM 则完全不同——它不是另一个“更好用的 Ollama”，它是为生产环境里那些冷酷的 SLA（比如 P99 延迟 ≤ 800ms，可用性 99.95%）而生的推理引擎。这次迁移，表面看是换了个命令行工具，实质是一次系统级重构：从“我能让它跑起来”转向“它必须在我看不见的地方，持续、稳定、高效地跑下去”。本文不讲虚的架构图，不堆术语，只说我在三轮灰度上线、两次紧急回滚、七次配置调优后，亲手验证过的每一步操作、每一个参数背后的物理意义、每一处报错背后的真实原因。如果你正站在那个“老板拍板了，但服务器还没买”的十字路口，这篇文章就是你该打印出来贴在显示器边框上的操作手册。

2. 核心思路拆解：为什么不是“Ollama + vLLM”，而是“Ollama → vLLM”

2.1 本质差异：玩具枪与工业级机床的底层逻辑

很多人第一反应是“能不能让 Ollama 和 vLLM 共存？比如 Ollama 做开发，vLLM 做生产，API 层统一调度”。这个想法很自然，但落地时会撞上三堵墙，而且全是承重墙。

第一堵墙叫内存模型不可调和。Ollama 的核心是llama.cpp的量化推理路径，它把整个模型权重加载进 CPU 内存（即使你开了 GPU 加速，也常是 CPU+GPU 混合），采用的是朴素的 KV Cache 管理——每次新 token 生成，就申请一块新内存存 KV 对，旧的等 GC 回收。这在单用户、低频交互下完全没问题。但 vLLM 的灵魂是PagedAttention。它把 KV Cache 拆成固定大小的“页”（默认 16KB），像操作系统管理物理内存页一样，由一个全局的“KV 缓存池”统一调度。当 100 个用户同时发起请求，每个请求的上下文长度不同，vLLM 不需要为每个请求预分配最大可能的 KV 内存，而是按需从池子里借页、还页。实测数据：同样部署Qwen2-7B-Instruct，Ollama 在 32GB 显存的 A10 上，最大并发数卡在 23；vLLM 同配置下轻松支撑 89 并发，显存占用反而低 18%。这不是优化，是范式革命。

第二堵墙是服务模型不可兼容。Ollama 提供的是类 REST 的简易 API（POST /api/chat），但它没有真正的连接池、没有请求队列、没有超时熔断。它的/api/generate接口甚至不支持stream: true的标准 SSE 流式响应头，而是用\n分隔的 JSONL。而 vLLM 的 OpenAI 兼容 API（/v1/chat/completions）严格遵循 OpenAI 的协议规范：支持stream: true、max_tokens、temperature、top_p等全部字段，返回标准的data: {...}SSE 流。这意味着，如果你前端代码里写的是fetch('/ollama/api/chat', { body: JSON.stringify({model: 'llama3', messages: [...]}) })，迁移到 vLLM 后，你必须改写为fetch('/vllm/v1/chat/completions', { headers: {'Authorization': 'Bearer sk-xxx'}, body: JSON.stringify({model: 'qwen2-7b', messages: [...], stream: true}) })。这不是 URL 替换，是协议栈的彻底切换。我们曾试图用 Nginx 做反向代理做字段映射，结果发现 Ollama 的keep_alive字段和 vLLM 的presence_penalty语义完全不同，硬桥接只会制造更难排查的幽灵 Bug。

第三堵墙最致命：可观测性与运维能力归零。Ollama 的ollama list只告诉你“有哪些模型”，ollama ps只告诉你“哪个模型在跑”，但它不告诉你当前有多少请求排队、平均首 token 延迟是多少、GPU 利用率峰值出现在哪一秒、某个请求是否因 OOM 被 kill。而 vLLM 内置 Prometheus 指标端点（/metrics），暴露超过 40 个关键指标：vllm:request_success_total（成功请求数）、vllm:time_per_output_token_seconds（每输出 token 耗时）、vllm:gpu_cache_usage_ratio（GPU 缓存使用率）。我们上线后第一周，就是靠rate(vllm:request_success_total[5m]) < 0.99这个告警，提前 17 分钟发现了某批新训练的微调模型存在隐式死循环，避免了一次全量服务中断。Ollama 给不了这个能力，不是它不想，是它的基因里没有“被监控”这个设计目标。

提示：迁移决策的核心判断标准只有一个——你的 SLA 要求是否超过了 Ollama 的设计边界。如果只是个人项目、小团队内部工具、演示原型，Ollama 是神兵利器；一旦涉及付费用户、合同约定的响应时间、或需要写进运维 SOP 的服务，就必须切换。这不是技术洁癖，是工程责任。

2.2 迁移不是替换，是分层解耦与能力补全

看清了本质差异，迁移路径就清晰了：这不是“把 Ollama 命令换成 vLLM 命令”，而是将原来揉在一起的“模型加载+推理+API 服务+日志”四件事，拆解成独立可治理的模块。

• 模型层：Ollama 的Modelfile是声明式构建，但 vLLM 不接受 Modelfile。你需要将 Ollama 模型导出为标准 Hugging Face 格式。这里有个关键细节：Ollama 默认使用gguf量化格式（如Q4_K_M），而 vLLM 原生支持的是safetensors或pytorch_model.bin。直接cp是不行的。正确做法是用llama.cpp的convert-hf-to-gguf.py工具反向转换，或者更稳妥的——从 Hugging Face Hub 重新下载原始 FP16 模型，再用 vLLM 自带的量化工具（如vllm.quantization.awq）做一次 AWQ 量化。我们试过直接加载 gguf，结果在长上下文（>8K tokens）时出现精度漂移，生成内容逻辑断裂，根源就是量化格式的 kernel 实现差异。

• 服务层：Ollama 的ollama run是单进程单模型，vLLM 的vllm.entrypoints.api_server支持多模型注册（--model-path可指定多个）、动态加载/卸载（POST /v1/models/load）、权重共享（同一基础模型的不同 LoRA 适配器可共用主干权重）。这意味着，原来为每个业务线单独部署一个 Ollama 实例的方案，在 vLLM 下可以收敛到 1-2 个高配实例，通过路由规则分发请求，资源利用率提升 3.2 倍。

• API 层：这是前端改造最重的部分。Ollama 的响应体是扁平 JSON：

  { "model": "llama3", "created_at": "2025-08-28T03:14:22.123Z", "message": {"role": "assistant", "content": "你好！"}, "done": true }

  vLLM 的 OpenAI 兼容响应是嵌套结构，且流式响应需解析data:行：

  data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","created":1724815234,"model":"qwen2-7b","choices":[{"index":0,"delta":{"role":"assistant","content":"你好"},"finish_reason":null}]} data: [DONE]

  我们封装了一个轻量级适配中间件（仅 127 行 Python），它监听 vLLM 的/v1/chat/completions，接收请求，转换字段（如messages数组转为 vLLM 所需格式），再转发，并将 vLLM 的 SSE 流实时转换为 Ollama 风格的 JSONL 流。这样前端代码几乎不用动，为业务争取了宝贵的灰度期。

• 运维层：Ollama 的日志是 stdout 直出，grep 查错效率极低。vLLM 支持结构化日志（--log-level DEBUG --log-format json），每条日志自带request_id、model_name、prompt_len、output_len字段。我们将其接入 ELK，用 Kibana 做实时看板，能一眼看出“哪个模型的首 token 延迟突增”“哪个用户的 prompt 触发了异常长的 prefill 阶段”。

3. 实操细节与关键配置：从裸金属到生产就绪的每一步

3.1 环境准备：硬件选型不是越贵越好，是匹配 workload 特征

别急着pip install vllm。先问自己三个问题：

1. 你的典型请求是什么样的？
   是客服场景（短 prompt + 短回复，平均 120 tokens）？还是法律合同分析（长 prompt + 中等回复，平均 3200 tokens）？或是代码生成（中等 prompt + 长回复，平均 1800 tokens）？这决定了你对prefill 吞吐量（处理 prompt 的速度）和decode 吞吐量（生成 token 的速度）的需求权重。前者吃 GPU 显存带宽和计算密度，后者吃 GPU Tensor Core 利用率。

2. 你的并发压力峰值是多少？
   不是“平均 100 QPS”，而是“促销活动期间，前 5 分钟内瞬时峰值 1200 QPS，其中 30% 请求带 8K 上下文”。这决定了你是否需要开启--enable-prefix-caching（前缀缓存），以及--max-num-seqs（最大并发序列数）的设置。

3. 你的模型有多大？量化后显存占用多少？
   别信官网写的“7B 模型只需 6GB 显存”。那是理想 FP16 状态。实际 AWQ 量化后，Qwen2-7B占用约 5.2GB，但加上 KV Cache、临时 buffer、CUDA context，安全起见要预留 20% 余量。我们用这张表做快速决策：

注意：A10 是性价比之王，但它的 PCIe 4.0 x16 带宽（64GB/s）比 A100 的 2039GB/s（NVLink）低两个数量级。如果你的 workload 是大量小请求（<500 tokens），A10 表现惊艳；如果是少量超长请求（>16K tokens），A100 的 NVLink 优势会放大。我们做过对比测试：处理 12K tokens 的法律文书摘要，A100 比 A10 快 3.8 倍。

安装步骤（以 Ubuntu 22.04 + A10 为例）：

# 1. 更新系统并安装 CUDA 驱动（vLLM 0.4.2 要求 CUDA 12.1+） sudo apt update && sudo apt upgrade -y sudo apt install -y nvidia-driver-535-server # 官方推荐驱动版本 sudo reboot # 2. 验证 GPU 状态 nvidia-smi # 应显示 A10，Driver Version: 535.129.03 # 3. 创建虚拟环境（强烈建议，避免依赖冲突） python3 -m venv vllm-env source vllm-env/bin/activate pip install --upgrade pip # 4. 安装 vLLM（关键：指定 CUDA 版本，避免编译耗时） pip install vllm==0.4.2 --extra-index-url https://download.pytorch.org/whl/cu121 # 5. 验证安装（此命令会触发 JIT 编译，首次运行较慢） python -c "from vllm import LLM; llm = LLM(model='facebook/opt-125m'); print('Success!')"

如果最后一步报CUDA out of memory，别慌，这是 opt-125m 模型在初始化时申请了过多显存。用nvidia-smi查看，你会发现 vLLM 进程占用了约 1.2GB，这是正常的预分配。真正的问题在后续。

3.2 模型准备：从 Ollama 仓库到 vLLM 可用格式的完整链路

Ollama 的模型藏在~/.ollama/models/blobs/下，是一堆 SHA256 命名的二进制文件。直接用？不行。vLLM 需要标准的 Hugging Face 格式（含config.json,tokenizer.json,model.safetensors）。以下是经过生产验证的四步法：

Step 1：定位并导出 Ollama 模型的原始来源
运行ollama show --modelfile <your-model-name>，你会看到类似：

FROM qwen/qwen2-7b-instruct:latest ...

这说明它源自 Hugging Face 的qwen/qwen2-7b-instruct。记下这个 ID。

Step 2：从 HF Hub 下载原始 FP16 模型（非 gguf）

# 安装 huggingface-hub pip install huggingface-hub # 使用 hf_hub_download 下载（比 git clone 更快，只下必要文件） from huggingface_hub import hf_hub_download import os model_id = "qwen/qwen2-7b-instruct" local_dir = "/models/qwen2-7b-instruct" # 下载 tokenizer hf_hub_download(repo_id=model_id, filename="tokenizer.model", local_dir=local_dir) hf_hub_download(repo_id=model_id, filename="tokenizer_config.json", local_dir=local_dir) hf_hub_download(repo_id=model_id, filename="special_tokens_map.json", local_dir=local_dir) # 下载模型权重（safetensors 格式） hf_hub_download(repo_id=model_id, filename="model.safetensors.index.json", local_dir=local_dir) # 注意：index.json 会指引下载所有分片，vLLM 会自动处理

Step 3：选择量化策略并执行（关键决策点）
vLLM 支持多种量化：

• awq：精度损失最小，适合对生成质量敏感的场景（如客服话术），但启动稍慢。
• gptq：平衡精度与速度，社区模型多为此格式。
• fp8：H100 专属，速度最快，但需确保模型已做 FP8 校准。

我们选awq，因为业务要求生成内容逻辑严谨。量化命令：

# 使用 vLLM 自带的量化脚本（需安装 transformers>=4.40） python -m vllm.quantization.awq.awq_quantize \ --model /models/qwen2-7b-instruct \ --quantized-model /models/qwen2-7b-instruct-awq \ --weight-dtype int4 \ --group-size 128 \ --zero-point \ --q_group_size 128

参数解释：

• --weight-dtype int4：权重量化为 4-bit，是精度与显存的黄金平衡点。
• --group-size 128：每 128 个权重共享一个 scale，太小（32）精度高但开销大，太大（256）易失真。
• --zero-point：启用零点偏移，对非对称分布权重（如 attention 输出）至关重要。

Step 4：验证量化后模型的完整性

# 启动一个最小化 vLLM 服务 vllm.entrypoints.api_server \ --model /models/qwen2-7b-instruct-awq \ --tensor-parallel-size 1 \ --dtype half \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000

然后用 curl 测试：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2-7b-instruct-awq", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 50 }'

如果返回正常 JSON，且usage字段中的prompt_tokens和completion_tokens合理（如 prompt 2 tokens，completion 15 tokens），说明模型加载成功。此时nvidia-smi应显示显存占用约 5.3GB，与预期一致。

3.3 启动服务与核心参数调优：让 vLLM 发挥 120% 性能

vLLM 的启动命令远不止--model一个参数。生产环境必须精细调控。以下是我们的黄金配置模板（A10 服务器）：

vllm.entrypoints.api_server \ --model /models/qwen2-7b-instruct-awq \ --tensor-parallel-size 1 \ # A10 单卡，设为 1；A100 2卡则设为 2 --pipeline-parallel-size 1 \ # 当前不支持 pipeline 并行，保持 1 --dtype half \ # 使用半精度，平衡速度与精度 --gpu-memory-utilization 0.85 \ # 关键！留 15% 显存给 KV Cache 和临时 buffer --max-model-len 8192 \ # 模型最大上下文，必须 <= 模型原生支持（Qwen2 是 32K，但 8K 更稳） --max-num-batched-tokens 4096 \ # 批处理总 token 数上限，防 OOM --max-num-seqs 256 \ # 最大并发请求数，根据 QPS 预估 --enforce-eager \ # 开发调试时加，禁用 CUDA Graph，方便 debug；生产环境务必删除！ --enable-prefix-caching \ # 开启前缀缓存，对重复 prompt（如系统指令）提速 40% --block-size 16 \ # PagedAttention 页大小，16KB 是默认且最优值 --swap-space 4 \ # 交换空间（GB），当显存不足时，将部分 KV Cache 换到 CPU 内存 --disable-log-requests \ # 生产环境关闭请求日志，减少 IO --log-level INFO \ --host 0.0.0.0 \ --port 8000 \ --api-key "sk-prod-xxxxxxxx" # 强制 API Key，安全基线

逐参数深度解读：

• --gpu-memory-utilization 0.85：这是血泪教训。设为 0.95，看似压榨了资源，但当突发流量涌入，KV Cache 池瞬间涨满，vLLM 会触发OutOfMemoryError并 kill 进程。0.85 是经过 72 小时压力测试后的安全阈值，它保证在 95% 的请求下，GPU 显存利用率在 78%-83% 波动，留有充足缓冲。

• --max-num-batched-tokens 4096：这个值不是越大越好。它定义了“一个 batch 最多包含多少 tokens”。如果设为 8192，一个 8K 上下文的请求就会独占整个 batch，其他请求只能干等。我们测算过：对于平均 120 tokens 的客服请求，设为 4096，batch size 平均能达到 32，吞吐量最高；设为 8192，batch size 降为 12，吞吐量反降 28%。

• --enable-prefix-caching：这是针对“系统提示词（system prompt）高度重复”的场景的核武器。我们的客服机器人，90% 的请求都带着相同的 system prompt：“你是一个专业的 IT 支持助手，请用中文回答，简洁明了，不要使用 markdown。” 开启此选项后，vLLM 会将这段 prompt 的 KV Cache 固化，后续所有请求只需计算 user message 部分的 KV，首 token 延迟从 420ms 降至 180ms，降幅达 57%。

• --swap-space 4：不要以为这是“性能杀手”。在 A10 上，当并发从 200 涨到 250，显存确实会触顶。此时 swap-space 让 vLLM 把“最久未访问”的 KV Cache 页换出到 CPU 内存。实测：开启后，250 并发下的 P99 延迟仅比 200 并发时高 110ms（从 720ms 到 830ms），而关闭则直接 502。代价是 CPU 内存多占 3.2GB，但换来的是服务不中断。

启动后，务必验证健康状态：

# 检查服务是否存活 curl http://localhost:8000/health # 查看暴露的指标（Prometheus 格式） curl http://localhost:8000/metrics | grep -E "(request_success|time_per_output_token|gpu_cache_usage)" # 查看当前加载的模型 curl http://localhost:8000/v1/models

3.4 API 对接与前端适配：最小改动，平滑过渡

前端代码不能大改，这是铁律。我们的策略是：在 vLLM 前加一层薄薄的适配网关（Adapter Gateway），它只做三件事：请求字段转换、响应格式转换、错误码映射。

Python FastAPI 实现（adapter_gateway.py）：

from fastapi import FastAPI, Request, HTTPException from starlette.responses import StreamingResponse import httpx import json app = FastAPI() VLLM_URL = "http://localhost:8000/v1/chat/completions" VLLM_API_KEY = "sk-prod-xxxxxxxx" @app.post("/api/chat") async def ollama_compatible_chat(request: Request): # 1. 解析 Ollama 风格请求体 ollama_body = await request.json() # 提取关键字段 model_name = ollama_body.get("model", "qwen2-7b-instruct-awq") messages = ollama_body.get("messages", []) stream = ollama_body.get("stream", False) # 2. 构造 vLLM 兼容请求体 vllm_body = { "model": model_name, "messages": messages, "stream": stream, "max_tokens": ollama_body.get("options", {}).get("num_predict", 512), "temperature": ollama_body.get("options", {}).get("temperature", 0.7), "top_p": ollama_body.get("options", {}).get("top_p", 0.95) } # 3. 转发请求到 vLLM async with httpx.AsyncClient() as client: try: vllm_response = await client.post( VLLM_URL, json=vllm_body, headers={"Authorization": f"Bearer {VLLM_API_KEY}"}, timeout=60.0 ) if vllm_response.status_code != 200: raise HTTPException(status_code=vllm_response.status_code, detail=vllm_response.text) # 4. 响应转换：vLLM SSE -> Ollama JSONL if stream: return StreamingResponse( convert_sse_to_jsonl(vllm_response.aiter_bytes()), media_type="application/x-ndjson" ) else: # 非流式：直接转换 JSON vllm_json = vllm_response.json() ollama_json = convert_vllm_to_ollama(vllm_json) return ollama_json except httpx.TimeoutException: raise HTTPException(status_code=504, detail="Gateway Timeout") async def convert_sse_to_jsonl(sse_stream): """将 vLLM 的 SSE 流转换为 Ollama 风格的 JSONL 流""" async for line in sse_stream: if line.startswith(b"data: "): data = line[6:].strip() if data == b"[DONE]": yield b'{"model":"","created_at":"","message":{"role":"","content":""},"done":true}\n' else: try: chunk = json.loads(data) # 提取 content content = chunk["choices"][0]["delta"].get("content", "") done = chunk["choices"][0].get("finish_reason") is not None ollama_chunk = { "model": chunk.get("model", ""), "created_at": "", # Ollama 时间戳在服务端生成，此处省略 "message": {"role": "assistant", "content": content}, "done": done } yield json.dumps(ollama_chunk, ensure_ascii=False).encode() + b"\n" except json.JSONDecodeError: continue def convert_vllm_to_ollama(vllm_json): """转换非流式响应""" choices = vllm_json.get("choices", []) if not choices: return {"error": "No choices returned"} message = choices[0]["message"] return { "model": vllm_json.get("model", ""), "created_at": "", # 省略 "message": {"role": message["role"], "content": message["content"]}, "done": True, "context": [] # Ollama 的 context 字段，vLLM 不提供，设为空 } if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8080)

部署此网关后，前端代码完全无需修改：

// 原来的 Ollama 调用（不变） fetch('/api/chat', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ model: 'qwen2-7b-instruct-awq', messages: [{role: 'user', content: '怎么重置密码？'}], stream: true }) }) .then(response => response.body.getReader()) .then(reader => { // 处理 Ollama 风格的 JSONL 流 });

4. 常见问题与实战排障：那些文档里不会写的坑

4.1 “Connection refused” 与 “502 Bad Gateway”：网络与代理的隐形战场

现象：vLLM 服务nvidia-smi显示正常，curl http://localhost:8000/health返回{"status":"ok"}，但前端调用adapter_gateway时，Nginx 日志报upstream prematurely closed connection while reading response header from upstream，浏览器 Network 面板显示net::ERR_CONNECTION_REFUSED。

排查路径：

1. 确认 adapter_gateway 是否真的在监听：ss -tuln | grep :8080，看是否有LISTEN状态。如果没有，检查adapter_gateway.py是否因httpx版本冲突而静默崩溃（常见于httpx>=0.25与uvicorn<0.24不兼容）。
2. 检查 Nginx 配置：这是最高频的坑。Nginx 默认proxy_read_timeout是 60 秒，而 vLLM 处理一个长 prompt 可能需要 90 秒。必须在location /api/chat块中添加：

   proxy_read_timeout 120; proxy_send_timeout 120; proxy_connect_timeout 120; # 关键：SSE 流需要特殊头 proxy_buffering off; proxy_cache off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade';

3. 检查防火墙：sudo ufw status，确保 8080（gateway）和 8000（vLLM）端口开放。sudo ufw allow 8080 && sudo ufw allow 8000。

实操心得：我们曾为此折腾 8 小时。最终发现是云服务器厂商的安全组规则里，只放行了 80/443，忘了加 8000 和 8080。教训：任何网络问题，第一步永远是telnet localhost 8000和telnet localhost 8080，确认端口可达性。

4.2 “CUDA out of memory”：不是显存不够，是配置错了

现象：启动 vLLM 时，报错RuntimeError: CUDA out of memory. Tried to allocate ...，但nvidia-smi显示显存占用才 30%。

根因与解法：

• 根因 1：--max-model-len设得过大。例如，模型原生支持 32K，你设--max-model-len 32768，vLLM 会为 KV Cache 预分配巨大空间。解法：保守设为8192或16384，够用就好。
• 根因 2：--max-num-seqs与--max-num-batched-tokens不匹配。例如，设--max-num-seqs 512但--max-num-batched-tokens 2048，意味着每个请求平均只能分到 4 个 tokens，这会导致大量碎片化内存分配，引发 OOM。解法：用公式--max-num-batched-tokens >= --max-num-seqs * avg_prompt_len，其中avg_prompt_len是你业务的平均 prompt 长度（用日志统计）。
• 根因 3：--gpu-memory-utilization设得太高，且--swap-space为 0。解法：降低 utilization 至 0.85，并设置--swap-space 4。

快速诊断命令：

# 查看 vLLM 启动时的显存预分配详情 vllm.entrypoints.api_server --model /models/qwen2-7b-instruct-awq --verbose 2>&1 | grep -i "memory\|cache" # 输出会显示 "Total KV cache blocks: XXXX" 和 "Estimated GPU memory usage: XX.X GB"

4.3 “Slow first token”：首 token 延迟高的 5 个真相

现象：P99 首 token 延迟高达 1200ms，远超 800ms SLA。

真相与对策表：