北京
大语言模型上线后，最头疼的问题往往不是模型本身，而是推理阶段的性能瓶颈。连续的内存分配、串行的请求处理、Python层面的内核调度开销——这三座大山压在每个部署者的头上。SitePoint 最近发布的一份生产环境部署指南，给出了一个务实的解法：在 Docker Compose 栈里跑带 TorchDynamo CUDA 图重放的 vLLM。
这套方案的核心思路并不复杂：让 GPU 内存利用率逼近满配，同时把内核启动的开销压到最低。指南里没有玄学，全是可落地的配置和参数。
PagedAttention：把连续内存换成按需分页
传统推理框架在分配 KV-cache（键值缓存）时，习惯按最大序列长度一次性划出连续内存块。这种做法的代价是填充浪费——实际用不到的空间也被占着，VRAM 利用率上不去。
vLLM 的做法借鉴了操作系统虚拟内存的思想。它把 KV-cache 切成固定大小的块（默认 16 个 token），按需分配，用多少给多少。这带来的直接收益是 GPU 内存利用率接近满配，而且在高并发下不会出现有效批量大小退化的问题。
指南里给了一个关键数据：如果没有分页分配，当并发序列超过约 64 时，碎片化可能导致有效批量大小直接减半。这意味着你花了同样的钱买了 GPU，实际吞吐量却打了对折。
TorchDynamo：在分发器层面截住计算图
解码步骤的耗时里，内核启动开销占了不小比例。在短序列场景下，这个比例可以达到 5-15%。对于自回归工作负载来说，这部分开销是实打实的吞吐量损失。
TorchDynamo 的解法是在 PyTorch 分发器层面拦截 Python 字节码，捕获计算图，然后以 CUDA 图的形式重放。这样一来，Python 到 CUDA 的分发路径被绕开了，内核启动的开销被大幅压缩。
需要澄清一点：这里说的是 PyTorch 的 TorchDynamo，不是 NVIDIA 那个独立的 Dynamo 推理框架。两者名字相近，但完全是两回事。
版本锁定：混用驱动可能触发静默回退
生产环境里最隐蔽的坑，是 CUDA 主机驱动和容器构建版本混用。这可能导致 TorchDynamo 静默回退到 eager 模式——你的代码还在跑，但性能已经悄悄回到了老样子。
指南给出的版本矩阵是 CUDA 12.1+ 搭配匹配的 PyTorch/vLLM 版本对。这个组合是经过验证的，别随意改动。
密钥管理同样有讲究。Hugging Face token 必须通过挂载在 /run/secrets 的 Docker secrets 注入，而不是环境变量。原因很直接：环境变量会通过 docker inspect 泄露，secrets 不会。
多 GPU 张量并行：必须开 ipc:host
当 TENSOR_PARALLEL_SIZE 大于 1 时，Docker 默认的 IPC 命名空间隔离会导致 NCCL 报错。解决办法是在 docker-compose.yml 里设置 ipc: host，这是节点内 GPU 通信的必要条件。
GPU 分配通过 deploy.resources.reservations.devices 控制，count 参数必须和 TENSOR_PARALLEL_SIZE 保持一致。这个对应关系搞错了，并行设置就会出问题。
两个容易踩的调试坑
第一个是 CUDA_LAUNCH_BLOCKING。这个环境变量在生产环境必须保持关闭——启用它会串行化所有 CUDA 操作，彻底破坏吞吐量。它只应该用于调试阶段。
第二个是 --gpu-memory-utilization 参数。指南建议设为 0.90，意思是加载模型权重后，把剩余 GPU 内存的 90% 分配给 KV-cache 池，留出 10% 给 CUDA 上下文开销和碎片缓冲空间。这个余量是必要的，别贪心。
这份指南覆盖了 GPU 直通、内存调优和多 GPU 张量并行三个核心模块，docker-compose.yml 的完整注释版本也一并提供。不过文章在多 GPU 部分中途截断，承诺的可观测性、基准测试和故障排除章节尚未完成。对于想快速上手生产部署的团队来说，现有内容已经足够跑通一条主线了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
