企业官网建设流程全解析

1. RTX 3090 单卡跑 7B，为什么总在“差一点”上翻车

如果你手上只有一张 RTX 3090（24GB 显存），想稳定跑一个 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_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=

拿到 Key 之后，控制台里可以管理你的 Key 和额度：

https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=console

如果你要单独创建或轮换 Key，走这个页面：

https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys

API 的基础地址是下面这个，注意它不带 UTM 参数，配置到工具里时用这个：

https://taotoken.net/api

这里要区分两个概念：本地 vLLM 服务监听的是http://localhost:8000/v1，而 TaoToken 的通道是https://taotoken.net/api。前者是你自己机器上的推理后端，后者是统一接入层。做连通性验证时，你可以先用 TaoToken 的模型对话页面确认 Key 有效，再回到本地服务做压测。

模型对话入口：

https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=models

接入文档在这里，配置参数不确定时对照着看：

https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc

如果你后面要长期跑编码类任务或者 Agent，可以考虑 Coding Plan，它更适合高频、长上下文的场景：

https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding-plan

注意：TaoToken 是统一 Key 和 API 通道，不是用来替代本地推理引擎的。本地 3090 上的 vLLM 仍然是实际干活的推理后端，TaoToken 负责的是鉴权统一和工具接入。

3. 可复制的部署配置：config.toml 与 settings.json 骨架

这一节给你两份可以直接改的配置骨架。第一份是 vLLM 的启动参数，我把它整理成config.toml的形式方便管理；第二份是客户端侧的settings.json，用于把工具指向本地服务或 TaoToken 通道。

3.1 显存占用先算清楚

在写配置之前，先把 24GB 显存怎么分算明白。以 Qwen2.5-7B 为例：

BF16 下权重吃掉 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_TPS：

python -m vllm.entrypoints.openai.api_server \ --help > /dev/null 2>&1 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

预期结果对照表：

如果你压出来的 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 Cache，24GB 很容易爆。

处理顺序：先确认加载的是 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 Lovelace（RTX 4090）或 Hopper（H100）及以上。这个不是配置问题，是硬件代际门槛，直接放弃 FP8 路线。

5.3 INT8 KV Cache 精度崩塌

现象：服务能跑，但评测分数断崖式下跌，HellaSwag 从 80.5% 掉到 65.5%。

原因是 KV Cache 对精度比权重更敏感，INT8 量化在 KV Cache 上的损失远超预期。这个方案在当前阶段不可用，别为了省显存去开。

5.4 投机采样没有加速反而恶化

现象：加了 draft model 之后，conc=1 时 TPOT 几乎没变，conc=16 时 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_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=models

如果你要长期跑编码类任务或者 Agent，走 Coding Plan 更合适：

https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding-plan

配置参数拿不准的时候，接入文档里有完整的字段说明：

https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc

Key 的管理和轮换在控制台：

https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=console

需要单独创建 Key 的话：

https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys

回到 3090 + 7B 这件事本身，最优解其实很朴素：AWQ INT4 量化 + Prefix Caching，其余默认开启的别动，硬件不支持的别碰，场景不匹配的别试。把gpu-memory-utilization给到 0.90 到 0.95，max-num-seqs按实时 16、离线 64 来分，max-model-len控制在 4096，这套组合在 24GB 卡上能稳定跑出 TPOT 7ms 左右、并发 16 到 32 的表现。

知道什么时候不该做，和知道该做什么一样重要。投机采样、FP8 KV Cache、INT8 KV Cache 这三条路，在 3090 上已经用实验证明走不通，别再花时间。把省下来的精力放在请求侧的前缀复用和并发调优上，收益更实在。