vLLM多进程与多线程并发优化实践

1. 多进程与多线程的本质差异

在vLLM这类大模型推理框架中，并发模型的选择直接影响系统吞吐量和响应延迟。多进程（Multiprocessing）和多线程（Multithreading）虽然都能实现并发，但底层机制存在根本区别：

1.1 内存与隔离性

多进程模式下，每个进程拥有独立的虚拟地址空间和Python解释器实例。这意味着：

• 进程间变量默认不共享，需要通过IPC（如管道、共享内存）通信
• 单个进程崩溃不会影响其他进程（高容错性）
• 适用于CPU密集型任务，可充分利用多核优势

多线程则共享同一进程的内存空间：

• 所有线程访问相同全局变量，数据共享更方便
• 需要谨慎处理线程安全（GIL限制在CPython中尤为突出）
• 更适合I/O密集型任务，避免GIL导致的性能瓶颈

关键经验：vLLM中模型权重通常占用数十GB内存，多进程会引发内存冗余。实测显示加载7B模型时，多进程模式内存消耗约为线程模式的N倍（N=进程数）

1.2 GIL的影响机制

Python的全局解释器锁（GIL）导致线程仅在I/O等待时释放锁。在vLLM的典型工作流中：

python复制# 多线程处理请求的伪代码
def process_request(request):
    with gil:  # 获取GIL
        tokens = tokenizer.encode(request)  # CPU密集型操作
    with gil:
        outputs = model.generate(tokens)  # 大部分时间被GIL阻塞
    return outputs

而多进程方案中，每个进程有独立GIL，能真正并行执行计算。但当处理HTTP请求时，线程模式在I/O等待时的优势更明显：

python复制# FastAPI中多线程处理请求
@app.post("/generate")
async def generate_text(request: Request):
    await request.body()  # I/O等待期间自动释放GIL
    tokens = tokenizer.encode(request.text)  # 短暂获取GIL
    return Streamin