企业官网建设流程全解析

手里如果只有一张 8GB 显存的显卡，你会怎么看待 vLLM？说实话，我之前也差点被劝退。网上一搜，教程里动不动就是 24GB、48GB 的显存环境，仿佛小显存用户不配碰大模型推理引擎。但我自己在一台 8GB 显存的机器上，把模型部署、并发压测、显存调优这一整套流程完整跑下来之后，发现这事的关键根本不在于“能不能跑”，而在于“怎么克制地分配资源，把它稳在最佳工作点”。

这篇文章是给和我一样，手头只有小显存卡、但又不甘心只跑点玩具 Demo 的人。内容会围绕 vLLM 在 8GB 显卡上的实际落地展开：先用真实显存预算说服你“有戏”，再给一份可以直接抄的部署命令，接着用压测数据把并发和显存的关系讲透，最后总结一批我调优时踩过的坑和排查方法。如果你也想在这类小卡上把 vLLM 用起来，这篇应该能省你不少试错时间。

1. 8GB 显存跑 vLLM：先算清楚这笔显存账

1.1 为什么 8GB 显卡也能跑：关键在量化模型

很多人一听 vLLM 就想到大显存，其实是被“全精度模型”吓住了。一个 70 亿参数的模型，如果用 FP16 精度加载，光权重就要占大约 14GB 显存，8GB 卡当然装不下。但问题是我们根本不需要用 FP16 硬扛。模型量化技术能把权重压到 4bit 甚至 8bit，同样一个 7B 模型，4bit 量化后权重只需要大约 4GB 左右。这样剩下的 4GB 显存，足够给它安排 KV cache、CUDA context 和各种临时缓冲了。

我用的是一台 8GB 显存的机器，模型是一个 7B 级别的开源对话模型，量化格式选择的是 AWQ 4bit。启动后显存占用稳定在 7.1GB 左右，能正常提供 OpenAI 兼容接口服务，并发请求数跑到 8 也没有出现 OOM。这个配置在小显存环境里是很典型的“甜点位”。

不过你也要明白边界：8GB 显卡适合跑 7B 级别的量化模型，或者更小的模型。如果你想跑 13B 甚至 32B 的量化模型，即使权重被压缩得很小，KV cache 和中间激活值依然可能把显存打满，体验会非常挣扎。认清这个边界，调优才有意义。

1.2 vLLM 在小显存环境下的优势与代价

vLLM 最大的卖点是 PagedAttention 和 Continuous Batching。简单说，PagedAttention 把 KV cache 切成分页块来管理，减少了显存碎片和浪费；Continuous Batching 允许模型在同一个 batch 里动态处理新请求和生成中的请求，而不是等上一批生成完再接收下一批。这两个机制叠加起来，在并发场景下的吞吐量明显优于传统 Transformers 推理方式。

但代价也很现实：vLLM 默认开启 CUDA graph 捕获，这个功能需要占一部分额外显存；同时为了高性能，它会为 KV cache 预留池化显存。在小显存环境里，这些“额外开销”会挤压模型可用的空间，所以“开箱即用”的默认配置不一定适合 8GB 卡。需要手动调整几个关键参数，这也是本文后面要展开的重点。

你可能会想：那我用 Ollama 或者 llama.cpp 不就行了吗？当然可以。但如果你需要高并发 API 服务、需要兼容 OpenAI 接口、需要精细控制调度参数，vLLM 依然是更合适的选择。它和小显存不是“绝缘”的，只是需要你多懂一点资源分配的逻辑。

2. 部署前的准备：选对模型、量化格式和环境

2.1 显存预算表：权重、KV cache 和临时开销怎么分

在部署前，我建议你先算算显存账。8GB 看起来挺大，但对于大模型推理来说，每一 MB 都得精打细算。显存开销可以粗略分成三块：

• 模型权重：7B FP16 约 14GB，INT8 约 7GB，INT4 约 3.5-4GB。
• KV cache：取决于模型层数、注意力头数和上下文长度。上下文越长，每个请求的 KV cache 越大。
• 临时激活值和 CUDA context：这部分容易被忽略，实际会占几百 MB 到 1GB 左右。

我给一个简单计算公式：KV cache 大小约等于2 * 层数 * 头维度 * 序列长度 * 并发序列数 * 每个 KV 字节数。不同模型结构不太一样，你不需要精确计算，只要知道“上下文长度”和“并发序列数”这两个数字会成倍影响显存占用就够了。

实际分配时，我通常把 8GB 当成 7GB 用，预留一定余量给 CUDA context 和驱逐误差。比如模型权重占 4GB，KV cache 预算 2.5GB，剩下 0.5GB 给临时开销。这样大概能覆盖一个 7B AWQ 量化模型 + 4096 上下文 + 少量并发请求。

2.2 量化格式选择：AWQ 还是 GPTQ

vLLM 支持多种量化格式，我用得比较多的是 AWQ 和 GPTQ。二者都属于权重量化，但 AWQ 在 vLLM 里的集成更成熟，启动参数也更简单，加载速度快，显存占用表现稳定。GPTQ 同样可用，但个别版本对 kernel 的要求会高一点。

我的建议是：优先选 AWQ 量化格式。如果模型仓库只提供了 GPTQ 版本，也可以直接用，只是要注意在启动时通过--quantization显式指定量化方式，避免 vLLM 自动识别出错。

还有一个小提示：8GB 显存环境下，用 GGUF 格式也不是不行，但 vLLM 对 GGUF 的支持更晚一些，性能表现和稳定性通常不如直接用 AWQ/GPTQ。如果你想在 vLLM 里省心，尽量避开 GGUF 路线。

2.3 环境安装：别急着源码编译

vLLM 依赖特定版本的 CUDA、PyTorch 和 Python。老实说，如果你不是要二次开发，千万别去源码编译，直接安装官方发布过的 wheel 包就能省掉大量麻烦。我建议用干净的 Python 3.10 环境，先确认 GPU 驱动和 CUDA 版本匹配，再执行pip install vllm。安装完成后跑一下python -c "import vllm"，能正常导入就说明基础环境没问题。

8GB 显存机器在安装阶段最大的坑是显存不足。如果你同时开着其他 GUI 程序或者另一个 Python 进程，显存被占满，vLLM 启动时会直接报 CUDA OOM。所以安装好依赖后，我习惯先把无关进程全部清掉，再启动服务。另外，不要用--dtype=float16这种手动指定方式去覆盖量化模型的精度，小显存环境禁不起这种浪费。

3. 部署实操：启动一个 OpenAI 兼容服务

3.1 最小可运行命令：每个参数都知道自己在干嘛

部署 vLLM 最直接的方式是启动自带的 OpenAI 兼容 API 服务。我用的是这样一条命令：

python -m vllm.entrypoints.openai.api_server \ --model your-model-path \ --quantization awq \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --max-num-seqs 8 \ --host 0.0.0.0 \ --port 8000

简单解读一下关键参数：

• --gpu-memory-utilization 0.85：允许 vLLM 最多使用显卡 85% 的显存，而不是全部。这个是上限，不是固定占用。设成 0.95 看起来更激进，但很可能让 CUDA context 没地方放，导致启动失败。
• --max-model-len 4096：限制最大上下文长度。8GB 显存不是让你狂拉上下文长度的。设成 4096 已经够很多业务场景用了，如果你非要把 32K 上下文塞进 8GB 卡，那 OOM 几乎是必然的。
• --max-num-seqs 8：限制同时调度的请求序列数量。这个值决定了 Continuous Batching 的窗口大小，后面压测部分会细说。

启动日志里会出现模型加载进度、量化方式、KV cache 预留情况等关键信息。看到类似“Available KV cache memory”的字段，你就知道 vLLM 已经帮你算好了 KV cache 池子大小。等日志稳定输出，说明服务已经就绪。

服务启动后，先用一个最简单的 curl 请求验证能不能正常回答：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "your-model-path", "messages": [{"role": "user", "content": "你好，介绍一下你自己"}], "max_tokens": 128}'

如果返回了正常的 JSON 响应，说明服务已经跑通，接下来才值得做压测和调优。

3.2 小显存最该调的三个参数组合

我自己在 8GB 卡上反复试过几组参数，最终发现“模型权重 4GB + 上下文 4096 + 并发序列 8”是一个比较稳的组合。如果你遇到显存不足，不要先降--gpu-memory-utilization，而是要优先降低--max-model-len和--max-num-seqs。道理很简单：模型权重是刚性开销，KV cache 才是动态开销里的大头，降低并发和上下文长度才是真正省钱的地方。

给你一个参照表：

如果你的业务里单次请求的输入输出 token 总数基本不会超过 2048，那--max-model-len 2048是个好选择，这样可以腾出更多显存给 KV cache 池，支持更高的并发序列数。我压测时发现，牺牲一点单请求长度，换取更高的并发吞吐，在很多 AI 产品场景里是划算的。

3.3 启动后立刻遇到的“假 OOM”现场

我第一次启动 vLLM 时，因为桌面环境里还开着不少程序，显存本来就被占了一部分，结果 vLLM 反复报 CUDA OOM。后来把显存清干净再启动，一切正常。这不是 vLLM 本身的问题，而是 8GB 卡“家底太薄”，任何一个无意的占用都可能让部署失败。

另外，第一次请求会很慢。这是因为 vLLM 要完成模型权重加载、CUDA graph 捕获以及 KV cache 预热，这个过程不是 bug，耐心等几秒就好了。很多新手在这时候以为服务卡死了，其实它只是在做“暖身”。

4. 并发压测：用数据找最舒服的工作点

4.1 压测工具怎么选：自带脚本和通用压测工具

部署好后，不要凭感觉调参，要用数据说话。vLLM 项目自带了benchmark_serving.py脚本，专门用来压测 OpenAI 兼容服务。它会自动构造一批 prompt，并发打到服务上，统计吞吐、时延、首 token 延迟等指标。我一般这样用：

python benchmark_serving.py \ --model your-model-path \ --dataset-name sharegpt \ --num-prompts 200 \ --request-rate 10

如果只是想快速看看服务扛不扛得住，也可以直接上通用压测工具 hey。比如模拟 8 个并发请求，连续打 30 秒：

hey -z 30s -c 8 -m POST \ -H "Content-Type: application/json" \ -d '{"model":"your-model-path","messages":[{"role":"user","content":"写一段关于秋天的描述"}],"max_tokens":200}' \ http://localhost:8000/v1/chat/completions

压测时重点看三个指标：

• 吞吐率（requests/s）：每秒能处理多少请求，决定服务容量。
• TTFT（Time to First Token）：从发出请求到收到第一个 token 的时间，决定用户体感。
• TPOT（Time Per Output Token）：每生成一个 token 的时间，决定生成速度。

4.2 并发数越高越好吗：KV cache 的显存之墙

我第一次压测就直接把并发拉到了 32，结果吞吐率没有线性提升，反而很多请求排在等待队列里，TTFT 猛涨。这是因为 vLLM 的--max-num-seqs决定了同时调度的序列上限，并发请求数超过这个值后，多出来的请求只能在队列里等着。也就是说，并发压测的数字再高，如果调度窗口不够大，吞吐也不会无限上升。

想让调度窗口变大，就得提高--max-num-seqs，但这又会直接放大 KV cache 显存占用。8GB 显卡在这里遇到了一堵“显存之墙”：max-num-seqs和 KV cache 是此消彼长的关系。

我在几组配置下测到过这样一张结果表（你可以参考趋势，数字会因显卡和模型不同有差异）：

从这张趋势表你能看出来，从 8 提到 16 后，吞吐几乎没涨，但 TTFT 翻倍。这就是显存之墙造成的排队效应。8GB 环境里，与其无脑调高并发数，不如找到吞吐和延迟的平衡点。

4.3 如何结合 vLLM 暴露的实时指标做判断

vLLM 默认会暴露一个/metrics端点，里面有一堆 Prometheus 格式的指标。小显存调优时，我最关注的是vllm:gpu_cache_usage_perc和vllm:num_requests_waiting。

vllm:gpu_cache_usage_perc表示 KV cache 池的使用率。如果这个值长期接近 1.0，说明 KV cache 已经打满，请求会开始阻塞或溢出，这时候要么降低上下文长度，要么降低最大并发序列数。vllm:num_requests_waiting则直接告诉你有没有请求在排队。等待数持续大于 0，说明调度窗口不够用，但先别急着加max-num-seqs，回到显存预算表看看还挤不挤得出来。

压测不是一次性工作。我习惯跑三组并发，比如 4、8、16，记录每组指标，然后画出趋势来选型。整个过程不需要复杂工具，一个记录表、几次命令、一组指标，就够了。

5. 显存调优进阶：从“能跑”到“跑得舒服”

5.1 PagedAttention 为什么能在小显存里帮你省钱

很多人对显存调优的理解就是“量化 + 调低并发”，其实 vLLM 内部的 PagedAttention 才是这轮调优的核心基础。传统推理引擎为每个请求预留连续的 KV cache，很容易因为请求长度变化产生碎片。PagedAttention 把 KV cache 按块切分，有点像操作系统里的分页内存，需要的时候按块分配，不用再担心“缝隙”浪费。

这带来一个实际好处：你不需要每个请求都预留一整段固定大小连续显存，vLLM 可以更密实地使用显存。在 8GB 卡上，这个机制的差距尤其明显，同等显存下能服务的并发请求数会更多。理解这一点，你就能明白为什么要时刻关注 KV cache 池的使用率：它才是决定并发天花板的核心资源。

5.2 几个低成本的显存调优再下一步

除了调整max-model-len和max-num-seqs，还有几个参数在 8GB 卡上也值得尝试：

• --enforce-eager：关闭 CUDA graph 捕获。默认的 CUDA graph 虽然能减少 kernel 启动开销，但会额外占显存。8GB 卡显存吃紧时，开启这个参数能省出几百 MB，同时吞吐会下降一些，属于用速度换空间的选项。
• --swap-space：允许把一部分 KV cache 换到 CPU 内存。这个机制能在显存溢出时避免服务崩溃，但也会让生成变慢。适合“必须稳住服务”的场景，不适合追求性能的场景。
• --enable-prefix-caching：当多个请求带有相同前缀时，可以共享 KV cache 块，减少重复计算和显存占用。在调试 API、反复请求相同系统提示词时很实用。

我实际使用时，在默认配置下先开--enable-prefix-caching，再尝试--enforce-eager，看显存占用下降多少、吞吐损失多少，再做取舍。每次只改一个参数，别一股脑全开，否则出了问题根本不知道是哪一项引起的。

5.3 实测对比示例：一次参数调整的完整记录

我做过一次比较典型的调优实验，同一个 7B AWQ 模型，在 8GB 显卡上，从默认参数到最终推荐参数，显存占用、吞吐和 TTFT 都变了。记录大致如下：

这个实验明确告诉我，8GB 卡的显存调优本质是“按需分配”而不是“压榨极限”。每次都留一点余量，反而能换来更稳定的服务表现。

6. 常见问题排查：小显存踩坑实录

6.1 故障速查表：现象、原因、解法

把我在使用过程中遇到过的典型问题整理成一张表，方便你直接对照：

6.2 几个提高排查效率的小习惯

我在折腾小显存 vLLM 时养成了几个习惯：

第一，写一个小脚本或直接用nvidia-smi -l 2实时刷新显存占用，观察启动和压测时显存的变化曲线。这样能清楚看到模型加载、KV cache 分配、请求并发上升时各自占了多少显存。

第二，每一次压测后都留一个简单记录，包括 max-model-len、max-num-seqs、gpu-memory-utilization、显存占用、吞吐、TTFT 这六个字段。有了记录，调参就不再是靠拍脑袋，而是有依据地找最优区间。

第三，不要迷信网上的“万能参数”。不同型号的 8GB 显卡，算力、带宽、显存速度都不一样；不同模型结构，KV cache 的计算方式和量化格式也不同。别人的参数只能当起点，最终一定要在自己机器上跑一轮压测再定稿。

6.3 一个特别让我揪心的坑：停服务不等于释放显存

8GB 显存本来就紧，如果你用 Ctrl+C 停掉一个 vLLM 服务，立刻又启动另一个，很可能会发现显存没完全释放。这是因为 Python 进程退出后显存释放有一定延迟，或者你用了某种方式让旧进程成了孤儿进程。我的处理方法是：启动新服务前，先执行nvidia-smi看看显存是否归零，没有归零就先查进程再杀掉。用这种方式，能解决很多“刚才还能跑，现在突然 OOM”的诡异问题。

小显存调优的过程有点像整理一个极小的房间：东西本身不多，但每件物品的位置都得刚刚好。模型权重是固定家具，KV cache 是活动空间，并发请求就是房间里同时走动的人。三者之间怎么平衡，就是你调优时真正要思考的事。

如果让我给一个最务实的建议，那就是在 8GB 显卡上，先别追所谓的最新技术参数，也先别羡慕别人动辄上万的吞吐数字。把 7B 量化模型在 4096 上下文、8 并发、0.85 显存利用率的组合下跑稳，再去考虑前缀共享、更激进的并发调度这些高阶玩法。等你把这条基础链路彻底吃透，小显存的 vLLM 就不再是“能不能用”的问题，而是“怎么用得顺手”的问题了。