RTX 3090 如何跑 13B 级大模型推理？4-bit AWQ、vLLM 部署与并发调优实战

更新时间：2026 年 9 月 20 日
适用环境：Linux、NVIDIA RTX 3090 24GB、Docker、CUDA 驱动

可以，但不要用 FP16 硬塞。24GB RTX 3090 更适合运行 4-bit AWQ/GPTQ 量化的 13B～14B 级模型，再用 vLLM 限制上下文长度、并发数和显存占用。是否真正达到“生产可用”，最终要看 P95 延迟、错误率、KV Cache 余量和业务质量评测。

本文以 Qwen/Qwen2.5-14B-Instruct-AWQ 为例。它共有约 14.7B 参数，其中非嵌入参数约 13.1B，可以作为“13B 级模型”的实际部署样本。官方模型卡提供了 4-bit AWQ 权重和 vLLM 启动方式，并采用 Apache 2.0 许可证。Qwen2.5-14B-Instruct-AWQ 模型卡

一、为什么 3090 跑 13B 必须先算显存

RTX 3090 配备 24GB GDDR6X 显存，属于 NVIDIA Ampere 架构。NVIDIA RTX 3090 官方规格

仅计算权重，一个 13B～14.7B 模型大致需要：

这里的数字只是“参数量 × 每参数字节数”。实际运行还要占用：

• 量化比例尺和未量化层；
• CUDA Context 与推理框架工作区；
• KV Cache；
• 临时激活；
• 请求批处理产生的额外显存。

因此，“4-bit 权重只有 7GB 左右”不等于整个服务只占 7GB。生产部署不能把 24GB 全部分给模型权重。

二、AWQ、bitsandbytes 和 GGUF 怎么选

vLLM 当前支持 AWQ、GPTQ、bitsandbytes 和 GGUF 等量化格式；兼容表显示 AWQ、GPTQ 和 Marlin 可运行在 Ampere GPU 上。vLLM 量化兼容表

如果只是用 Transformers 验证模型，bitsandbytes 可以在加载时完成 4-bit 量化；但量化会改变模型的显存、性能和输出表现，仍然需要用业务数据重新评测。Transformers bitsandbytes 文档

三、部署前先检查环境

nvidia-smi

docker --version

docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 \
  nvidia-smi

至少确认以下项目：

1. nvidia-smi 能识别 RTX 3090 和约 24GB 显存；
2. Docker 容器能访问 GPU；
3. 系统盘或数据盘有足够空间保存模型缓存；
4. 服务启动前没有其他进程大量占用显存；
5. 模型许可证与业务用途相符。

如果容器看不到 GPU，先排查驱动和 NVIDIA Container Toolkit，不要直接修改模型参数。

四、用 vLLM 启动 4-bit AWQ 服务

下面使用固定版本镜像，避免 latest 更新后依赖发生变化。上线前仍应在自己的环境中锁定最终验证过的镜像摘要。

export VLLM_API_KEY='请替换为高强度随机字符串'

docker run -d \
  --name qwen14b-awq \
  --gpus '"device=0"' \
  --ipc=host \
  --restart unless-stopped \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.16.0 \
  --model Qwen/Qwen2.5-14B-Instruct-AWQ \
  --served-model-name qwen2.5-14b-awq \
  --quantization awq \
  --dtype half \
  --max-model-len 8192 \
  --max-num-seqs 4 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --api-key "$VLLM_API_KEY"

这几个参数决定了服务能否稳定运行：

• --max-model-len 8192：虽然模型支持更长上下文，但 3090 不应该一开始就开放最大长度。
• --max-num-seqs 4：先把并发上限控制在 4，再根据压测逐步调整。
• --gpu-memory-utilization 0.90：给系统和瞬时分配留出余量。
• --enable-prefix-caching：多个请求共享相同系统提示词或长前缀时，可以复用已有 KV Cache。它主要节省重复前缀的计算，不会让首次请求凭空变快。vLLM Prefix Caching 文档

查看启动日志：

docker logs -f qwen14b-awq

同时观察显存：

watch -n 1 nvidia-smi

如果模型加载后显存已经接近上限，先减小 max-model-len 或 max-num-seqs，不要直接把 gpu-memory-utilization 调到 0.99。

五、验证接口是否可用

vLLM 提供 OpenAI 风格的 HTTP 服务。vLLM OpenAI-Compatible Server 文档

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Authorization: Bearer $VLLM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5-14b-awq",
    "messages": [
      {
        "role": "system",
        "content": "你是一个简洁、准确的技术助手。"
      },
      {
        "role": "user",
        "content": "用三点说明什么是模型量化。"
      }
    ],
    "temperature": 0.2,
    "top_p": 0.8,
    "max_tokens": 256
  }'

最少检查四件事：

• HTTP 状态码是否为 200；
• 返回内容是否完整；
• finish_reason 是否符合预期；
• 日志中是否出现 OOM、请求超时或进程重启。

Qwen 官方建议显式传入采样参数，避免完全依赖服务默认值。Qwen vLLM 部署文档

六、“能回答”不等于“生产可用”

生产验收至少要覆盖以下指标：

不要照抄别人的“每秒多少 Token”。模型、提示词长度、输出长度、驱动、vLLM 版本、采样参数和并发数都会改变结果。

可用 vLLM 自带工具做第一轮压测：

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model qwen2.5-14b-awq \
  --dataset-name random \
  --input-len 1024 \
  --output-len 256 \
  --num-prompts 100 \
  --request-rate 1 \
  --max-concurrency 4 \
  --header "Authorization=Bearer $VLLM_API_KEY"

建议依次测试并发 1、2、4、8。当 P95 延迟突然上升、KV Cache 接近上限或错误率增加时，上一档通常更适合作为初始并发限制。具体参数可参考 vLLM Bench Serve 文档。

七、监控不能只盯着 nvidia-smi

vLLM 会通过 /metrics 暴露 Prometheus 指标，包括：

• vllm:kv_cache_usage_perc；
• vllm:num_requests_running；
• vllm:time_to_first_token_seconds；
• vllm:request_time_per_output_token_seconds；
• vllm:e2e_request_latency_seconds；
• vllm:request_success_total。

curl http://127.0.0.1:8000/metrics

这些指标可以接入 Prometheus 和 Grafana，用于建立延迟、错误率和 KV Cache 告警。vLLM Production Metrics 文档

需要特别注意：vLLM 官方明确提示，--api-key 不会保护服务的所有端点。因此不要把 vLLM 端口直接暴露到公网。生产环境至少应在前面增加反向代理，并配置 TLS、统一鉴权、限流、请求体大小限制和访问日志。

八、显存不足时按这个顺序调整

1. 先缩短上下文

8192 → 6144 → 4096

长上下文会持续占用 KV Cache。对知识库问答，应先优化检索结果和提示词，而不是默认把所有文档都塞给模型。

2. 再降低并发

max-num-seqs：4 → 2 → 1

如果单请求稳定、并发后才 OOM，问题通常不是权重，而是多条请求同时占用 KV Cache。

3. 限制单次输出

在网关或业务层限制 max_tokens。没有限制的长输出既增加延迟，也会持续占用计算资源。

4. 确认没有其他 GPU 进程

nvidia-smi

不要在同一张卡上同时运行推理服务、Notebook、训练脚本和桌面渲染任务。

5. 最后再考虑 CPU offload

CPU offload 可以换取额外容量，但推理过程中需要在 CPU 与 GPU 之间搬运数据。它更像应急手段，不应被当成免费的显存扩展。

九、以算家云 (suanjiayun.com) 为例操作演示

准备上线长期运行的推理服务时，可以在算家云创建实例页面实时核对 GPU 型号、显存、区域和可用卡数。库存属于动态信息：如果当时有 RTX 3090 24GB，可按本文参数启动；如果使用其他 24GB 卡型，需要重新压测，不能直接沿用 3090 的延迟结论。

按算家云官网当前定位：

• 专业版 Pro 面向长期生产、推理训练和稳定运行；
• 青春版 Air 面向短期学习、测试验证和低成本使用。

因此，本例的长期服务优先考察专业版 Pro；短时间验证镜像和参数时，再根据实际需求考虑测试型资源。这里引用的是产品定位，不等同于 SLA、库存保证或独立稳定性实测。

建议从下面这组保守参数开始：

模型：Qwen2.5-14B-Instruct-AWQ
量化：AWQ 4-bit
上下文：8192
最大并发序列：4
显存利用率上限：0.90
端口：仅监听本机
验收：完成并发1/2/4/8四档压测

完成 PoC 后保存：

• vLLM 镜像版本及摘要；
• 模型仓库 revision；
• 完整启动参数；
• 100 条以上业务评测题；
• 并发压测结果；
• OOM 和服务重启记录。

这比只保存一句“3090 可以跑 13B”更有复现价值。

十、3090 适合哪些生产场景

更适合：

• 小团队内部知识助手；
• 低并发 RAG；
• 开发、预发布和灰度环境；
• 有明确请求上限的垂直模型服务；
• 成本敏感、可以接受单卡容量边界的项目。

不适合直接照搬：

• 高峰流量不可预测的公网多租户服务；
• 要求单机容灾或严格高可用的业务；
• 大量 32K、64K 以上长上下文请求；
• 高并发、长输出任务；
• 未完成量化质量评测的高风险业务。

单张 3090 本质上仍是单点。真正的生产方案还需要网关、限流、超时、重试、监控、版本回滚和备用实例。

总结

RTX 3090 的 24GB 显存足以承载 4-bit 的 13B～14B 级模型，但正确的问题不是“模型能不能加载”，而是：

1. 权重加载后还剩多少 KV Cache；
2. 业务上下文和并发能否同时满足；
3. 量化后的回答质量是否通过评测；
4. 服务是否有鉴权、限流、监控和回滚；
5. 在目标负载下，P95 延迟和错误率是否达标。

从 AWQ 4-bit、8K 上下文、最大 4 条并发序列开始，完成真实业务压测后再逐步放大，是单张 3090 更稳妥的上线方式。

常见问题

RTX 3090 能直接加载 13B 模型的 FP16 权重吗？

通常不行。13B 参数仅 FP16 权重理论上就需要约 26GB，还没有计算 KV Cache 和运行时开销。

INT8 和 INT4 应该选哪个？

INT8 通常保留更多精度，但显存余量较少；单张 3090 如果还需要上下文和并发，4-bit AWQ/GPTQ 更容易留出运行空间。最终应以业务题集评测为准。

上下文长度越大越好吗？

不是。最大上下文会直接影响 KV Cache 和并发容量。RAG 服务应先优化检索和提示词，再决定是否扩大上下文。

3090 可以支撑多少并发？

没有脱离负载的固定答案。输入长度、输出长度、模型结构和延迟目标不同，并发结果也不同。建议用并发 1、2、4、8 逐级压测。

能把 vLLM 的 8000 端口直接开放到公网吗？

不建议。官方文档说明内置 API Key 不保护所有端点。应绑定本地地址，并通过反向代理统一处理 TLS、鉴权和限流。