单卡RTX4090跑通DeepSeek-R1量化蒸馏与vLLM流式代理实战

4次阅读

共计 3885 个字符，预计需要花费 10 分钟才能阅读完成。

最近不少朋友都在折腾 DeepSeek-R1 的本地化落地。满血 671B 的 MoE 架构固然强悍，但对于个人开发者或者中小技术团队来说，租借 8 张 H800 的成本足以劝退大多数非核心业务场景。更多时候，我们手头能自由支配的算力，往往就是一台挂着单张 RTX 4090（24GB 显存）的本地深度学习主机，或者内网的小型工作站。

退而求其次选择官方蒸馏模型（如 DeepSeek-R1-Distill-Qwen 系列）是性价比最高的解法。但我发现很多同学在用单卡跑 14B/32B 模型时，要么直接撞 OOM（Out Of Memory），要么并发一高就卡死在显存碎片上，长上下文甚至直接把吞吐拖垮到个位数。今天这篇文章，我把最近两周在单卡 4090 上搭建高并发推理引擎与 OpenAI 兼容代理的完整方案、踩坑点和压测数据毫无保留地复盘一遍。

搞本地推理，第一步就是算清显存账本，不能抱有任何侥幸心理。以 14B 模型（如 DeepSeek-R1-Distill-Qwen-14B）为例：

BF16/FP16 原生精度： 权重本身占用约 14 × 2 = 28GB。单张 4090（24GB）根本连模型权重都加载不进去，直接 OOM。
AWQ/GPTQ 4-bit 量化： 权重压缩至约 14 × 0.6 ≈ 8.4GB。剩下的 15GB 显存可以完全划拨给 KV Cache，支撑 8k~16k 的长上下文并发。
GGUF（Ollama 方案）：Ollama 上手容易，但在处理高并发批处理（Continuous Batching）和细粒度显存控制时，吞吐性能相比 vLLM 仍有明显差距。

因此，对于要接入业务系统、提供标准 API 服务的场景，最佳组合是：vLLM + 4-bit AWQ 模型 + 外部轻量代理网关 。

虽然 vLLM 的 PagedAttention 机制大幅缓解了显存碎片，但如果不调整默认参数，单卡依然很容易崩溃。先看我的启动脚本配置：

#!/usr/bin/env bash
# run_vllm.sh
export CUDA_VISIBLE_DEVICES=0

# 推荐使用官方量化版或 HuggingFace 社区高赞的 AWQ 权重
MODEL_NAME="deepseek-ai/DeepSeek-R1-Distill-Qwen-14B"
QUANT_MODEL="casperhansen/deepseek-r1-distill-qwen-14b-awq"

vllm serve ${QUANT_MODEL} \
    --host 127.0.0.1 \
    --port 8000 \
    --quantization awq \
    --dtype float16 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 8192 \
    --max-num-seqs 16 \
    --enforce-eager \
    --trust-remote-code \
    --api-key "nassky-local-secret"

--gpu-memory-utilization 0.90：强烈建议设为 0.90 甚至 0.88，千万别贪心设 0.98。Linux 桌面环境、PyTorch 的 context 切换都需要少量显存缓冲，设得过死随时被 CUDA driver 强杀。
--max-model-len 8192：如果不指定，vLLM 默认会尝试拉满模型配置中的最大长度（有些模型是 32k 或 131k），这会导致初始化预分配 KV Cache 时直接爆显存。根据实际业务裁剪至 8k 或 16k 是最稳妥的。
--enforce-eager：4090 在启用 CUDA Graph（默认开启）时，面对动态长上下文有时会出现极难复现的内存泄漏。如果你只追求极端推理稳定性，加上此参数关闭 CUDA Graph，虽然会轻微牺牲 5%~10% 的短文本时延，但连续跑几天都不会宕机。

在实际落地时，我们绝不能把 vLLM 的端口直接暴露给外网或前端应用。一方面需要做限流、审计、Token 计费，另一方面 DeepSeek-R1 模型独特的思维链 <think>...</think> 标签，有时需要根据客户端需求进行过滤或分流解析。

这里给出一个基于 FastAPI 和 httpx 的轻量异步流式反向代理骨架：

# gateway.py
import json
import httpx
from fastapi import FastAPI, Request, HTTPException
from fastapi.responses import StreamingResponse

app = FastAPI(title="DeepSeek Stream Gateway")

VLLM_BACKEND_URL = "http://127.0.0.1:8000/v1/chat/completions"
INTERNAL_API_KEY = "nassky-local-secret"

client = httpx.AsyncClient(timeout=httpx.Timeout(120.0, connect=10.0))

@app.post("/v1/chat/completions")
async def chat_proxy(request: Request):
    try:
        body = await request.json()
    except Exception:
        raise HTTPException(status_code=400, detail="Invalid JSON payload")

    # 强制启用流式输出，减少客户端 TTFT (Time To First Token) 延迟感
    body["stream"] = True

    headers = {"Authorization": f"Bearer {INTERNAL_API_KEY}",
        "Content-Type": "application/json"
    }

    async def stream_generator():
        try:
            async with client.stream("POST", VLLM_BACKEND_URL, json=body, headers=headers) as upstream:
                if upstream.status_code != 200:
                    yield f"data: {json.dumps({'error':'Upstream engine error'})}\n\n"
                    return

                async for line in upstream.aiter_lines():
                    if not line:
                        continue
                    # 针对长文本可在此处做正则清洗或分段统计
                    yield f"{line}\n\n"
        except httpx.RequestError as exc:
            yield f"data: {json.dumps({'error': f'Gateway transport failed: {str(exc)}'})}\n\n"

    return StreamingResponse(stream_generator(), media_type="text/event-stream")

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8080, workers=2)

我们用 locust 对单卡 4090 上的不同部署形态进行了基准压测，输入 Prompt 平均 1500 Tokens，要求生成 800 Tokens（包含 R1 的推理推理过程）。测试并发设定为 4、8、16 持续请求 10 分钟：

方案架构	并发量 (Concurrency)	首字延迟 (TTFT P95)	平均吞吐 (Tokens/s)	显存占用
Ollama (Q4_K_M)	4 并发	1.45 s	42.1 tok/s	10.2 GB
Ollama (Q4_K_M)	16 并发	6.80 s（排队严重）	38.4 tok/s	16.8 GB
vLLM (AWQ 4-bit)	4 并发	0.62 s	94.6 tok/s	21.6 GB（预分配）
vLLM (AWQ 4-bit)	16 并发	1.85 s	148.2 tok/s	21.6 GB（动态批处理）

从实测数据可以非常直观地看出：当场景演变为多用户或 Agent 多轮调用时，vLLM 的 Continuous Batching 展现出压倒性优势。在 16 并发下，总吞吐量达到了 148 tok/s，几乎跑满了 4090 的显存带宽极限，且 TTFT 依然压在 2 秒以内。

别把推理卡当训练卡配： 消费级显卡（RTX 4090）最大的软肋不是算力，而是 PCIe 带宽（如果插在副槽跑 x4/x8 会严重影响模型重载速度）以及缺少 ECC 纠错。生产环境务必监控 nvidia-smi dmon，留意总线利用率。
严控最大长度：DeepSeek-R1 这类推理模型极度嗜好输出 Token，一旦遇到复杂逻辑题，思维链很容易打满 4000+ Tokens。服务端一定要配置 max_tokens 截断，否则单个恶性请求就能把整张卡的 KV Cache 挤爆，直接导致后续请求降级排队。
监控不可缺位：vLLM 原生暴露 Prometheus 指标（/metrics），其中 vllm:num_requests_waiting 和 vllm:gpu_cache_usage_factor 是核心生命线，一旦 Cache Usage 长期超过 95%，就必须横向扩充显卡或触发上层限流。

单卡 4090 配合调优后的 vLLM，完全足以支撑起一个垂直领域内部知识库、中小型代码审查 Agent 的全部日常流量。把显存账本算细，剩下的交给量化与批处理调度即可。

正文完