2、大模型部署基础：大模型推理架构、常用部署框架（如vLLM、TGI）、GPU资源管理基础
大模型部署并非简单地将模型权重加载到GPU上运行，而是一个涉及推理引擎选型、显存规划、请求调度、并发控制与硬件资源管理的系统工程。在生产环境中，多租户隔离的挑战往往不是模型本身，而是底层推理架构的资源共享与隔离边界如何划定。本章从推理架构的宏观视图出发，剖析主流部署框架（vLLM、TGI）的调度机制与显存管理策略，并深入GPU资源管理的基础概念，为后续章节的多租户隔离设计奠定技术认知基础。
2.1 大模型推理架构的核心原理
大模型推理架构与传统深度学习推理有本质差异。传统CNN模型（如ResNet）前向传播一次即可得到结果，而大模型（Decoder-only架构）采用自回归生成方式：每生成一个token，需要将已生成的全部token作为输入重新计算。这种机制导致两个关键问题：一是计算量随序列长度线性增长，二是需要缓存历史token的Key-Value向量（即KV Cache）以避免重复计算。
从部署视角看，推理架构可拆解为四个核心模块：请求预处理（Tokenization、Padding、长度校验）、模型推理引擎（Transformer层计算、Attention机制、采样策略）、KV Cache管理（显存分配、复用、淘汰）、输出后处理（Detokenization、过滤、流式返回）。在多租户场景下，这四个模块都需要考虑资源隔离与公平调度。
2.2 主流部署框架对比：vLLM、TGI与TensorRT-LLM
当前生产环境最常用的开源推理框架包括vLLM、Hugging Face TGI（Text Generation Inference）和NVIDIA TensorRT-LLM。三者各有侧重，理解其差异是选择多租户隔离方案的前提。
| 维度 | vLLM | TGI | TensorRT-LLM |
|---|---|---|---|
| 核心机制 | PagedAttention（分页显存管理） | Continuous Batching（连续批处理） | TensorRT图优化 + 多精度量化 |
| 显存效率 | 极高（KV Cache按页分配，碎片率低） | 高（动态批大小调整） | 极高（编译期显存规划） |
| 多租户支持 | 原生支持多LoRA适配器，可做租户级隔离 | 支持多模型加载，但租户级隔离需二次开发 | 底层优化好，但需自行封装调度逻辑 |
| 量化支持 | GPTQ、AWQ、FP8 | GPTQ、AWQ、EETQ | INT4/INT8/FP8，权重量化最成熟 |
| 适用场景 | 高并发、多租户、动态长度请求 | Hugging Face生态集成、快速部署 | 极致性能、固定shape、生产级优化 |
2.2.1 vLLM的PagedAttention机制
vLLM的核心创新在于将操作系统虚拟内存的分页思想引入KV Cache管理。传统推理框架为每个请求预分配最大长度的连续显存，导致大量浪费。PagedAttention将KV Cache划分为固定大小的块（通常16个token），按需分配，块与块之间通过索引表连接。这种设计带来三个直接收益：显存利用率提升至90%以上、支持请求级抢占与恢复、天然支持多租户的显存配额管理。
# vLLM 多租户部署示例（伪代码）
from vllm import LLM, SamplingParams
# 租户A：低延迟配置
tenant_a_params = SamplingParams(max_tokens=512, temperature=0.1)
llm_a = LLM(model="Qwen2.5-7B", gpu_memory_utilization=0.4,
max_num_seqs=16, enable_prefix_caching=True)
# 租户B：高吞吐配置
tenant_b_params = SamplingParams(max_tokens=2048, temperature=0.8)
llm_b = LLM(model="Qwen2.5-7B", gpu_memory_utilization=0.4,
max_num_seqs=32, enable_prefix_caching=False)2.2.2 TGI的连续批处理与Token流式返回
TGI由Hugging Face维护，其核心优势在于Continuous Batching：不再等待一个batch全部生成完毕才释放资源，而是每完成一个序列就立即插入新请求。TGI还内置了Token流式返回（Server-Sent Events），对交互式应用友好。在多租户场景中，TGI的max_batch_prefill_tokens和max_batch_total_tokens参数可用于控制不同租户的资源占用上限。
2.3 GPU资源管理基础
GPU资源管理是多租户隔离的物理基础。需要从显存、算力、带宽三个维度理解资源边界。现代数据中心GPU（如A100、H100、L40S）均支持多种虚拟化与分区技术，为租户隔离提供硬件级支持。
2.3.1 显存管理：从静态分配到池化
传统部署中，每个模型实例独占整张GPU显存，资源利用率低。生产级方案通常采用显存池化策略：将多张GPU的显存统一管理，按需分配给不同租户的推理实例。vLLM的gpu_memory_utilization参数控制KV Cache可用的显存比例，剩余部分留给模型权重和激活值。在多租户场景，建议为每个租户设置独立的显存上限，并预留10-15%的冗余应对峰值。
2.3.2 算力隔离：MIG、时间片与MPS
- MIG（Multi-Instance GPU）：A100/H100专属，将GPU划分为多个硬件隔离实例，每个实例拥有独立的SM、显存带宽和L2缓存。隔离强度最高，适合对安全性和稳定性要求极高的租户。
- 时间片切分：多个租户共享同一GPU的SM，通过调度器轮转。实现简单但隔离性弱，一个租户的异常可能影响其他租户。
- MPS（Multi-Process Service）：NVIDIA提供的用户态进程调度，可限制每个进程的算力占比（通过CUDA_MPS_PINNED_DEVICE_MEM_LIMIT等环境变量）。适合中等隔离需求。
2.4 实战场景：基于vLLM的多租户GPU资源规划
某互联网公司需要为内部三个业务部门（客服、代码助手、内容生成）部署大模型服务，使用4张A100-80GB GPU。客服部门对延迟敏感（P95 < 500ms），代码助手需要长上下文（8K），内容生成追求吞吐量。初始方案是为每个部门独立部署一套vLLM实例，各占1张GPU，剩余1张作为冗余。
实际运行一周后发现：客服部门GPU利用率仅35%，内容生成部门在高峰期出现显存溢出（OOM），而代码助手部门因上下文长度波动大，KV Cache分配不均导致部分请求排队超时。分析根因：静态分配导致资源无法共享，且未考虑不同租户的负载特征差异。
优化方案调整为：
- 使用vLLM的
--multi-lora模式，在2张GPU上部署一个共享基础模型实例，通过LoRA适配器区分三个租户，显存利用率提升至75%。 - 为客服租户设置
max_num_seqs=8和max_tokens=256，保证低延迟；为代码助手租户开启enable_prefix_caching，利用前缀缓存加速重复代码片段；为内容生成租户设置max_num_seqs=64，最大化吞吐。 - 剩余2张GPU使用MIG切分为4个2实例+2个3实例，分别承载其他非核心业务和弹性扩容。
优化后，整体GPU利用率从52%提升至81%，客服P95延迟稳定在420ms，内容生成吞吐量提升2.3倍，且未再出现OOM。复盘经验：多租户部署的核心不是“分卡”，而是“分时、分显存、分优先级”，需要结合业务特征动态调整。
2.5 常见误区与总结复盘
- 误区一：认为模型越大越好。7B模型在A100上可支持高并发，70B模型则需多卡张量并行，显存占用和通信开销剧增。多租户场景应优先选择满足业务需求的最小模型。
- 误区二：忽略KV Cache的显存占用。仅按模型权重大小规划显存是常见错误。经验公式：KV Cache显存 ≈ 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 并发数 × 字节数（FP16为2字节）。
- 误区三：所有租户使用相同配置。不同业务的延迟要求、上下文长度、并发模式差异巨大，应通过框架参数（如
max_num_seqs、gpu_memory_utilization）做差异化配置。 - 误区四：忽略CPU内存与GPU显存的数据传输。当请求预处理（Tokenization）或后处理（Detokenization）成为瓶颈时，应使用CPU预取和异步流水线。