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

论文复现现场2026-09-21 13:31

更新时间：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 模型大致需要：

权重精度 14.7B 参数的理论权重体积 3090 部署判断
FP32 约 58.8GB 单卡不可行
FP16/BF16 约 29.4GB 权重本身已经超过 24GB
INT8 约 14.7GB 可能装入，但留给 KV Cache 的空间有限
INT4 约 7.35GB 更适合保留上下文和并发余量

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

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

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

二、AWQ、bitsandbytes 和 GGUF 怎么选

方案 更适合的场景 单卡服务建议
AWQ/GPTQ + vLLM Linux GPU 服务、多个并发请求、OpenAI 风格接口 本文推荐
bitsandbytes 4-bit 快速验证、Transformers 脚本、QLoRA 适合 PoC，不是本文的服务主线
GGUF + llama.cpp 桌面端、CPU/GPU 混合卸载、轻量本地工具 适合低并发和本地运行
FP16 + CPU offload 必须保留 FP16 权重，但能接受明显的传输开销 不作为 3090 生产首选

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

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

三、部署前先检查环境

bash 复制代码 
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 更新后依赖发生变化。上线前仍应在自己的环境中锁定最终验证过的镜像摘要。

bash 复制代码 
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 文档

查看启动日志：

bash 复制代码 
docker logs -f qwen14b-awq

同时观察显存：

bash 复制代码 
watch -n 1 nvidia-smi

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

五、验证接口是否可用

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

bash 复制代码 
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 部署文档

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

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

指标 需要记录什么 合格线怎么定
TTFT 首 Token 延迟的 P50、P95 按交互体验目标确定
TPOT 后续 Token 间隔 按生成速度目标确定
E2E 整个请求的 P95 延迟 按接口超时预算确定
错误率 5xx、超时、OOM、空响应 应低于业务容忍值
KV Cache 使用率及持续增长情况 峰值时仍需有余量
GPU 显存、利用率、温度、功耗 不出现持续降频或 OOM
质量 量化前后业务题集差异 达到业务验收标准

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

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

bash 复制代码 
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。
bash 复制代码 
curl http://127.0.0.1:8000/metrics

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

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

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

1. 先缩短上下文

text 复制代码 
8192 → 6144 → 4096

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

2. 再降低并发

text 复制代码 
max-num-seqs：4 → 2 → 1

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

3. 限制单次输出

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

4. 确认没有其他 GPU 进程

bash 复制代码 
nvidia-smi

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

5. 最后再考虑 CPU offload

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

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

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

按算家云官网当前定位：

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

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

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

text 复制代码 
模型：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、鉴权和限流。

相关推荐
一颗小树x1 天前
vLLM大模型推理：Jetson AGX Thor 的 GPU 共享内存清理实战
jetson·vllm·vlm·gpu内存清理
论文复现现场2 天前
Qwen3.8-27B 做 GRPO 需要几张 GPU？4×RTX 4090 与 8×RTX 4090 显存、vLLM 和 ZeRO-3 配置分析
deepspeed·qlora·大模型训练·vllm·rtx4090·grpo·qwen3.8
安易算力2 天前
昇腾生态开发深度实践：CANN算子库架构解析与MindSpore模型优化
网络·容器·架构·kubernetes·vllm
程序猿编码2 天前
零依赖纯手写：C++ 实现完整神经网络，张量反向传播全打通
c++·神经网络·transformer·大模型推理
SunnyRivers2 天前
vLLM 官方调优方案
优化·vllm
政企项目老覃3 天前
边缘 AI 推理部署：安防零售场景下的模型裁剪与端侧落地实践
人工智能·程序人生·算法·性能优化·vllm
赋创小助手3 天前
Qwen3.8-27B 本地推理 Benchmark 解析：llama.cpp、vLLM、SGLang 与长 Context 的性能差异
服务器·人工智能·大模型·qwen·vllm·sglang·context长度
论文复现现场3 天前
Llama/Qwen 70B 部署需要几张 RTX 4090？2卡、4卡、8卡显存、量化与 vLLM 选型
llama·qwen·vllm·大模型推理·大模型部署·rtx4090
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接03历年考研数学一、数学二、数学三真题试卷及答案PDF04GitHub 镜像站点05人工智能（AI）发展史：详细里程碑06微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？08ZCode 周末送额度活动开启：3 亿 Token 免费领取092026 爱知・名古屋亚运会怎么看？直播平台+赛程安排分享10数学公理体系大全:第六章 选择公理的等价形式及证明