大模型开发实战：从本地部署到生产级API服务的全流程搭建

大模型开发已经从实验阶段进入工程化落地期。把一个大语言模型跑起来不难，难的是让它稳定地服务线上业务。这篇文章覆盖从模型选型、本地推理、API封装到生产部署的完整链路，每一步都给出可操作的配置。

大模型部署的硬件与选型决策

选模型之前先看硬件。显存决定了你能跑什么规模的模型，以下是经验值：

• 7B模型（如Qwen2-7B、Llama3-8B）：单张A10(24GB)或RTX 4090即可，FP16推理需要约14-16GB显存
• 14B模型（如Qwen2-14B）：单张A100(80GB)或两张RTX 4090，FP16需约28-30GB
• 72B模型（如Qwen2-72B）：至少两张A100-80GB，推荐4张以上做张量并行

量化能大幅降低显存需求。GPTQ/AWQ 4bit量化后，7B模型只需约5GB显存，72B模型单机8卡可跑。但量化有精度损失，对代码生成、数学推理类任务需要做评估。

本地推理引擎选型与配置

vLLM是当前生产环境的首选推理引擎，核心优势是PagedAttention内存管理和continuous batching，吞吐量远高于原生transformers。

安装与启动：

pip install vllm

# 启动OpenAI兼容API服务
python -m vllm.entrypoints.openai.api_server   --model Qwen/Qwen2-7B-Instruct   --served-model-name qwen2-7b   --host 0.0.0.0   --port 8000   --tensor-parallel-size 1   --gpu-memory-utilization 0.9   --max-model-len 8192   --dtype auto

关键参数说明：

• --gpu-memory-utilization：显存使用比例，0.9表示预留10%给系统，避免OOM
• --max-model-len：最大上下文长度，直接影响KV Cache占用的显存
• --tensor-parallel-size：张量并行度，多卡场景设为卡数

API服务封装与负载均衡

vLLM自带OpenAI兼容接口，业务方可以零改迁移。但生产环境需要额外处理：限流、鉴权、多实例负载均衡。

用Nginx做负载均衡示例：

upstream vllm_backends {
    least_conn;
    server 10.0.0.1:8000;
    server 10.0.0.2:8000;
    server 10.0.0.3:8000;
}

server {
    listen 80;
    location /v1/ {
        proxy_pass http://vllm_backends;
        proxy_set_header Host $host;
        proxy_read_timeout 300s;
    }
}

鉴权层建议放在API Gateway（如Kong或自研网关），在转发到vLLM之前做Token校验和速率限制。不要把鉴权逻辑塞进vLLM本身。

健康检查与自动恢复

vLLM进程偶尔会因为显存碎片或异常请求崩溃。生产部署必须加健康检查：

import requests
import subprocess
import time

VLLM_HEALTH_URL = "http://localhost:8000/health"

def check_and_restart():
    while True:
        try:
            resp = requests.get(VLLM_HEALTH_URL, timeout=5)
            if resp.status_code != 200:
                raise Exception(f"health check failed: {resp.status_code}")
        except Exception as e:
            print(f"[ALERT] vLLM unhealthy: {e}, restarting...")
            subprocess.run(["bash", "/opt/scripts/start_vllm.sh"])
        time.sleep(30)

if __name__ == "__main__":
    check_and_restart()

性能监控指标采集

vLLM暴露了Prometheus格式的metrics端点/metrics，关键指标：

• vllm:num_requests_running：当前运行中的请求数
• vllm:num_requests_waiting：排队等待的请求数
• vllm:gpu_cache_usage_perc：KV Cache使用率
• vllm:avg_generation_throughput：平均生成吞吐量（tokens/s）

当gpu_cache_usage_perc持续超过85%，说明显存压力大，排队会加剧，考虑扩容或降低max_model_len。当waiting队列长期不为0，说明并发量超过处理能力，需要增加实例。

常见问题诊断

Q: 启动时报CUDA Out of Memory怎么办？
降低--gpu-memory-utilization到0.8，或减小--max-model-len。如果还不行，检查是否有其他进程占显存（nvidia-smi确认），以及模型是否量化版本。

Q: 推理速度远低于预期？
检查是否开启了--enforce-eager（关闭CUDA Graph），检查输入输出长度分布，长输出场景吞吐量会明显下降。多卡场景确认tensor_parallel_size与实际GPU数一致。

Q: 请求偶尔超时？
vLLM的continuous batching在高并发下有调度延迟。检查waiting队列长度，适当调大Nginx的proxy_read_timeout，或在客户端加指数退避重试。

从测试到上线的检查清单

1. 模型量化前后精度评估通过（用业务数据集跑benchmark）
2. 单实例压测：P99延迟和吞吐量满足SLA
3. 多实例负载均衡验证：摘除一个节点后流量自动切换
4. 健康检查与自动恢复验证：kill进程后30秒内恢复
5. 监控告警配置：KV Cache使用率>85%、waiting队列>10 触发告警
6. API鉴权与限流策略生效

大模型部署不是终点，持续监控和调优才是日常。把上面这些环节串起来，才能让大模型服务从”能跑”变成”能扛”。