1. 项目背景
某云计算团队从基础篇的单机单卡服务毕业后，接到了一个生产级需求：为公司的10个业务线提供统一的LLM推理服务，日均调用量约50万次，峰值QPS达到200。CTO批了4台A100-80GB服务器（每台8卡），要求"把这些GPU跑满"。
团队信心满满地用--tensor-parallel-size 8启动了vLLM——结果服务运行30分钟后，CPU被打到100%，GPU利用率只有35%。查日志发现：API Server进程（Uvicorn）的单线程事件循环无法处理200 QPS的HTTP请求解析；Engine Core的Scheduler因为CPU时间片不足，调度延迟从微秒级飙到了毫秒级；Tokenizer线程池的4个Worker处理不过来并发请求的Token化。
更糟糕的是，运维发现4台服务器上的8张GPU各自为战——每台机器上跑了一个全量模型副本（8卡TP），总共4个副本，但4个副本之间没有负载均衡，流量全部打到了第一台机器上。
痛点：多卡不等于高吞吐。vLLM的V1架构有明确的进程分工——API Server（HTTP接入）、Engine Core（调度决策）、GPU Worker（模型执行）、DP Coordinator（多实例协调）。如果不对这些进程做精确的资源sizing，就会出现"GPU闲着、CPU打满"或者"一张卡跑满、其余卡旁观"的尴尬局面。
本章将深入vLLM V1多进程架构，逐一剖析各进程的职责、通信方式和资源需求，并通过实验对比单卡/4卡TP/8卡DP+TP三种部署拓扑的性能差异。
