1. RTX 3090 单卡跑 7B为什么总在“差一点”上翻车如果你手上只有一张 RTX 309024GB 显存想稳定跑一个 7B 级别的对话模型大概率会遇到这种局面模型能加载、能出字但并发一上来就 OOM或者首 token 慢得让人怀疑人生。问题往往不在模型本身而在于显存分配、量化选型和并发参数这三件事没有一起调。RTX 3090 的显存带宽是 936 GB/s这个数字决定了 7B 模型在 BF16 精度下的 decode 阶段几乎必然撞到带宽墙。我实测下来BF16 的 TPOT每输出 token 耗时中位数在 19.7ms 左右显存带宽利用率已经逼近 76%纯靠调参榨不出更多性能。真正有效的动作只有两个把权重压到 INT4以及让 KV Cache 有足够空间承接并发。这篇是系列的收尾复盘不再做新实验而是把前面几篇的数据串成一份可以直接照做的部署清单。你会看到显存到底被谁吃掉了、AWQ 量化怎么选、并发参数怎么给、以及用 TaoToken 的统一 Key 把本地推理服务和外部 AI 工具串起来做连通性验证。目标很明确——你照着配完能跑出一个不 OOM、延迟可接受、并发能上 16 到 32 的 7B 服务。适合谁看手里有 3090 或同级 24GB 卡、想自己搭一套本地推理服务、又不想在参数里反复试错的开发者。下面所有配置都基于 vLLM 0.22 及以上版本命令可以直接复制。2. 先把 TaoToken 的 Key 和通道准备好本地推理服务跑起来之后你通常还需要一个统一的入口去调用它或者把它接到别的 AI 工具里做验证。TaoToken 在这里的角色是提供一个统一的 API Key 和兼容 OpenAI 协议的通道让你不用为每个工具单独配一套鉴权。注册和拿 Key 的入口在官网进去之后按提示完成账号流程即可https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content拿到 Key 之后控制台里可以管理你的 Key 和额度https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole如果你要单独创建或轮换 Key走这个页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keysAPI 的基础地址是下面这个注意它不带 UTM 参数配置到工具里时用这个https://taotoken.net/api这里要区分两个概念本地 vLLM 服务监听的是http://localhost:8000/v1而 TaoToken 的通道是https://taotoken.net/api。前者是你自己机器上的推理后端后者是统一接入层。做连通性验证时你可以先用 TaoToken 的模型对话页面确认 Key 有效再回到本地服务做压测。模型对话入口https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodels接入文档在这里配置参数不确定时对照着看https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc如果你后面要长期跑编码类任务或者 Agent可以考虑 Coding Plan它更适合高频、长上下文的场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan注意TaoToken 是统一 Key 和 API 通道不是用来替代本地推理引擎的。本地 3090 上的 vLLM 仍然是实际干活的推理后端TaoToken 负责的是鉴权统一和工具接入。3. 可复制的部署配置config.toml 与 settings.json 骨架这一节给你两份可以直接改的配置骨架。第一份是 vLLM 的启动参数我把它整理成config.toml的形式方便管理第二份是客户端侧的settings.json用于把工具指向本地服务或 TaoToken 通道。3.1 显存占用先算清楚在写配置之前先把 24GB 显存怎么分算明白。以 Qwen2.5-7B 为例项目BF16AWQ INT4模型权重~14 GB~4 GBKV Cache 可用~4.6 GB~13.9 GBKV Cache blocks530615839临界并发~88~265BF16 下权重吃掉 14GB留给 KV Cache 的只有 4.6GB 左右并发一高就排队甚至 OOM。换成 AWQ INT4 后权重降到 4GB省出来的 10GB 全部给 KV Cache容量扩大约 3 倍。这就是为什么量化在 3090 上是必选项而不是可选项。3.2 vLLM 启动配置 config.toml下面这份配置分两个场景实时对话和批量离线。你可以把它存成config.toml再用脚本读取后拼成启动命令。# config.toml # RTX 3090 7B AWQ 部署配置骨架 [model] path /root/autodl-tmp/models/qwen2.5-7b-instruct-awq served_name qwen2.5-7b dtype float16 quantization awq [server] host 0.0.0.0 port 8000 # 场景一实时对话低延迟优先 [realtime] gpu_memory_utilization 0.90 max_model_len 4096 max_num_seqs 16 enable_prefix_caching true enable_chunked_prefill true # 场景二批量离线吞吐优先 [batch] gpu_memory_utilization 0.95 max_model_len 4096 max_num_seqs 64 enable_prefix_caching true enable_chunked_prefill true对应的启动命令实时对话场景vllm serve /root/autodl-tmp/models/qwen2.5-7b-instruct-awq \ --served-model-name qwen2.5-7b \ --quantization awq \ --dtype float16 \ --gpu-memory-utilization 0.90 \ --max-model-len 4096 \ --max-num-seqs 16 \ --enable-prefix-caching \ --enable-chunked-prefill批量离线场景只改两个参数vllm serve /root/autodl-tmp/models/qwen2.5-7b-instruct-awq \ --served-model-name qwen2.5-7b \ --quantization awq \ --dtype float16 \ --gpu-memory-utilization 0.95 \ --max-model-len 4096 \ --max-num-seqs 64 \ --enable-prefix-caching \ --enable-chunked-prefill提示vLLM 0.22 中 Prefix Caching、Chunked Prefill、FlashInfer、torch.compile、CUDA Graph 多数已默认开启。上面显式写出--enable-prefix-caching和--enable-chunked-prefill是为了让配置自解释避免换版本后默认值变化导致行为不一致。3.3 客户端 settings.json 骨架客户端侧如果你用的是兼容 OpenAI 协议的工具配置大致长这样。把base_url指向本地 vLLM 服务{ provider: openai-compatible, base_url: http://localhost:8000/v1, api_key: EMPTY, model: qwen2.5-7b, max_tokens: 2048, temperature: 0.7, timeout: 120 }如果你要通过 TaoToken 的统一通道去调用把base_url和api_key换成 TaoToken 的{ provider: openai-compatible, base_url: https://taotoken.net/api, api_key: 你的_TaoToken_Key, model: qwen2.5-7b, max_tokens: 2048, temperature: 0.7, timeout: 120 }本地 vLLM 的api_key填EMPTY就行因为它默认不校验。TaoToken 通道则必须填真实 Key。两份配置的区别只在base_url和api_key其余参数一致方便你切换。4. 验证请求与成功结果配置写完先别急着压测按顺序做三步验证本地服务健康检查、单请求出字、并发压测。4.1 本地服务健康检查服务启动后先看模型列表接口是否正常返回curl -s http://localhost:8000/v1/models | python -m json.tool成功的话你会看到类似这样的输出id就是你在--served-model-name里指定的名字{ object: list, data: [ { id: qwen2.5-7b, object: model, created: 1730000000, owned_by: vllm } ] }如果这里报连接拒绝说明服务没起来回去看启动日志里的 OOM 或参数错误。4.2 单请求出字验证用 chat completions 接口发一条请求确认能正常出字curl -s http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [ {role: user, content: 用一句话解释什么是 KV Cache} ], max_tokens: 128, temperature: 0.7 } | python -m json.tool成功返回里choices[0].message.content会有内容usage里能看到 prompt 和 completion 的 token 数。这一步过了说明推理链路是通的。4.3 通过 TaoToken 通道做连通性验证如果你要用 TaoToken 的统一 Key 去接工具先用模型对话页面确认 Key 有效再用同样的请求格式打到 TaoToken 的通道curl -s https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的_TaoToken_Key \ -d { model: qwen2.5-7b, messages: [ {role: user, content: ping} ], max_tokens: 16 } | python -m json.tool返回结构正常、有内容输出就说明统一通道是通的。这一步的意义在于你后面无论换哪个客户端工具只要支持 OpenAI 兼容协议改base_url和api_key就能接上不用每个工具单独折腾鉴权。4.4 并发压测看关键指标单请求通了之后用 vLLM 自带的 benchmark 脚本压一下并发重点看 TPOT 和 Out_TPSpython -m vllm.entrypoints.openai.api_server \ --help /dev/null 21 python benchmarks/benchmark_serving.py \ --backend openai-chat \ --base-url http://localhost:8000 \ --model qwen2.5-7b \ --num-prompts 200 \ --request-rate 16 \ --max-concurrency 16预期结果对照表指标BF16 基线AWQ INT4变化TPOT P50 (conc1)19.7 ms6.84 ms-65%Out_TPS (conc32)978 tok/s2126 tok/s117%严格 SLO Goodput826 tok/s4547 tok/s450%生产甜点区conc8~16conc16~32—如果你压出来的 TPOT 明显高于 7ms先检查是不是没走 AWQ 量化或者gpu-memory-utilization给太低导致 KV Cache 池太小、请求频繁排队。5. 本篇常见报错排查这一节把 3090 上跑 7B 最容易撞到的几个报错列出来按现象、原因、处理三步走。5.1 CUDA out of memory现象启动时或并发上来后抛torch.cuda.OutOfMemoryError。原因通常是三个模型没量化、gpu-memory-utilization给太高、max-model-len设太大。BF16 权重 14GB 加上长上下文 KV Cache24GB 很容易爆。处理顺序先确认加载的是 AWQ 模型--quantization awq有没有生效再把gpu-memory-utilization从 0.95 降到 0.90最后把max-model-len从 8192 降到 4096。三步做完基本能起来。5.2 启动报 FP8 不支持现象日志里出现FP8 KV cache is not supported on this device或类似提示。原因是 RTX 3090 是 Ampere 架构不支持原生 FP8。FP8 KV Cache 需要 Ada LovelaceRTX 4090或 HopperH100及以上。这个不是配置问题是硬件代际门槛直接放弃 FP8 路线。5.3 INT8 KV Cache 精度崩塌现象服务能跑但评测分数断崖式下跌HellaSwag 从 80.5% 掉到 65.5%。原因是 KV Cache 对精度比权重更敏感INT8 量化在 KV Cache 上的损失远超预期。这个方案在当前阶段不可用别为了省显存去开。5.4 投机采样没有加速反而恶化现象加了 draft model 之后conc1 时 TPOT 几乎没变conc16 时 TPOT 反而涨了 7.4%TTFT P99 暴涨 25 倍。原因是单卡 7B 场景下接受率 γ 只有 0.20系统开销系数 c 达到 1.73代入加速公式 S α / (kγ c) 算出来只有 1.13 倍实际被开销抵消到约 1.0。单卡小模型本来 TPOT 就快投机采样的搬运开销盖过了收益。结论是 3090 7B 不要上投机采样。5.5 Prefix Caching 命中率低现象开了 Prefix Caching但 TTFT 没降多少。原因是请求之间没有共享前缀。Prefix Caching 的收益和共享前缀长度强相关1500 token 前缀大约降 18.5%4000 token 前缀能降 92.6%。如果你的请求都是随机独立内容命中率自然低。检查你的 system prompt 和 RAG 文档是不是每次都一样一样才有缓存价值。5.6 并发上不去请求排队现象max-num-seqs调到 64但实际并发到 20 多就开始排队。原因是 KV Cache 容量不够。AWQ 下 15839 blocks 对应临界并发约 265但这是理论上限实际受max-model-len和请求长度影响。把gpu-memory-utilization提到 0.95 能多挤一些 KV Cache 空间但要注意别触发 OOM。实时场景建议max-num-seqs控制在 16 到 32这是 SLO 友好区间。6. 收尾把统一 Key 接进你的日常工具链部署配好、压测过了之后最后一步是把它接进你日常用的工具里。TaoToken 的统一 Key 在这里的价值是你不需要为每个客户端单独维护一套鉴权配置改base_url和api_key就能切换。如果你主要做模型验证和对话测试用模型对话入口最快https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodels如果你要长期跑编码类任务或者 Agent走 Coding Plan 更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan配置参数拿不准的时候接入文档里有完整的字段说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdocKey 的管理和轮换在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole需要单独创建 Key 的话https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys回到 3090 7B 这件事本身最优解其实很朴素AWQ INT4 量化 Prefix Caching其余默认开启的别动硬件不支持的别碰场景不匹配的别试。把gpu-memory-utilization给到 0.90 到 0.95max-num-seqs按实时 16、离线 64 来分max-model-len控制在 4096这套组合在 24GB 卡上能稳定跑出 TPOT 7ms 左右、并发 16 到 32 的表现。知道什么时候不该做和知道该做什么一样重要。投机采样、FP8 KV Cache、INT8 KV Cache 这三条路在 3090 上已经用实验证明走不通别再花时间。把省下来的精力放在请求侧的前缀复用和并发调优上收益更实在。