共计 2609 个字符，预计需要花费 7 分钟才能阅读完成。
背景痛点：为什么自托管 LLM 如此具有挑战性？
在尝试将 ChatGPT 类模型部署到自有服务器时，开发者常会遇到几个典型问题：
- 显存溢出(OOM)：即使是最小的 GPT- 2 模型，全精度加载也需要超过 4GB 显存，而 175B 参数的模型更是需要数百 GB
- 响应延迟高：单个请求处理时间可能长达数秒，无法满足实时对话需求
- 并发能力弱：原生实现通常只能处理个位数并发请求
- 硬件成本高：需要配备多张高端 GPU 才能维持基本服务
这些问题本质上源于 LLM 的两个特性：巨大的参数量（Model Parameters）和自回归生成（Autoregressive Generation）的计算模式。
技术选型：主流推理框架横向对比
目前较成熟的 LLM 推理方案主要有三种：
- 原生 Transformers
- 优点：官方支持最好，功能最全
- 缺点：内存效率低，缺乏生产级优化
-
实测：6B 模型在 A10G 上 QPS 约 2
-
vLLM
- 优点：支持 PagedAttention，显存利用率提升 4 倍
- 缺点：对模型架构有限制
-
实测：相同硬件 QPS 可达 15+
-
Text Generation Inference(TGI)
- 优点：内置动态批处理，支持多 GPU
- 缺点：部署复杂度较高
- 实测：批量处理时 QPS 可达 30+
对于大多数场景，推荐 vLLM 作为平衡易用性和性能的选择。当需要处理高并发时，TGI 是更好的选择。
核心实现：从容器化到 API 服务
使用 Docker 部署量化模型
# vLLM 专用镜像
FROM nvidia/cuda:12.1-base
RUN apt-get update && apt-get install -y \
python3-pip \
&& rm -rf /var/lib/apt/lists/*
RUN pip3 install vllm==0.2.0 fastapi uvicorn
EXPOSE 8000
CMD ["python3", "-m", "vllm.entrypoints.api_server", "--model", "facebook/opt-6.7b", "--quantization", "awq"]配套的 docker-compose.yml：
version: '3.8'
services:
vllm:
build: .
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
ports:
- "8000:8000"
environment:
- "CUDA_VISIBLE_DEVICES=0"FastAPI 接口优化
实现流式响应和动态批处理的关键代码：
from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse
from vllm import SamplingParams
app = FastAPI()
@app.post("/generate")
async def generate(request: Request):
data = await request.json()
prompt = data["prompt"]
sampling_params = SamplingParams(
temperature=0.8,
top_p=0.95,
max_tokens=1024
)
async def stream_results():
async for output in request.app.state.llm.generate(
prompt,
sampling_params,
request_id=str(uuid.uuid4())
):
yield output.text
return StreamingResponse(stream_results())性能优化：从理论到实践
Batch Size 与吞吐量关系
我们在 A100 40GB 上测试不同 batch_size 下的表现：
| Batch Size | 显存占用 | QPS | 平均延迟 |
|---|---|---|---|
| 1 | 12GB | 18 | 55ms |
| 4 | 15GB | 42 | 95ms |
| 8 | 18GB | 68 | 118ms |
| 16 | 22GB | 89 | 180ms |
可见适当增加 batch_size 能显著提升吞吐量，但要注意延迟的 trade-off。
PagedAttention 原理
传统 Attention 计算需要将整个 KV 缓存保存在连续内存中，而 PagedAttention 借鉴操作系统分页思想：
- 将 KV 缓存划分为固定大小的块（如 256 个 token）
- 维护逻辑块到物理块的映射表
- 按需分配物理块
这使得显存利用率从不足 20% 提升到 70% 以上。
避坑指南：血泪经验总结
CUDA 版本冲突
典型错误：
CUDA error: no kernel image is available for execution on the device解决方案：
1. 使用 nvidia-smi 查看驱动支持的 CUDA 最高版本
2. 确保 docker 镜像、PyTorch、推理框架的 CUDA 版本一致
3. 推荐使用预编译的官方 Docker 镜像
长文本处理
当输入超过模型上下文长度时：
- 滑动窗口：保留最近 N 个 token
- 关键信息提取：先用小模型提取摘要
- 层次化处理：将长文档分块后递归处理
安全防护
防范 prompt 注入攻击：
def sanitize_prompt(text: str) -> str:
blacklist = ["system", "sudo", "rm -rf"]
for word in blacklist:
text = text.replace(word, "[REDACTED]")
return text[:2000] # 长度限制延伸思考：如何更进一步？
-
LoRA 微调：用少量数据适配垂直领域
from peft import LoraConfig, get_peft_model config = LoraConfig( r=8, target_modules=["q_proj", "v_proj"], ) model = get_peft_model(model, config) -
LangChain 集成：构建复杂 AI 工作流
from langchain.llms import VLLM llm = VLLM( model="facebook/opt-6.7b", temperature=0.7 ) -
多 GPU 扩展：通过 Tensor Parallelism 实现横向扩展
部署 LLM 就像驯服一头巨兽，需要理解它的脾气秉性。希望这篇指南能帮你少走弯路，快速搭建出高性能的对话服务。记住：没有银弹，最适合的方案永远取决于你的具体场景。
