2、大模型部署基础：常见部署方式（本地、云、容器）、推理服务端口与协议、API网关需求

大模型从训练完成到对外提供服务，中间隔着一条“最后一公里”的工程鸿沟。模型权重文件本身只是静态资产，真正让用户能够通过 HTTP 请求获得智能回复的，是一整套推理服务运行时、网络暴露策略和流量治理机制。本章聚焦于大模型部署的三大基础命题：部署形态选型、推理服务端口与协议规范、API 网关的引入必要性。理解这三者，是后续配置 Nginx 反向代理、实现负载均衡与安全隔离的前提。

大模型部署基础架构与流量链路 本地部署（裸机/工作站） GPU直通、低延迟、运维自管 适合研发调试、数据敏感场景 云服务器（ECS/GPU云） 弹性扩缩、按需付费、公网IP 适合生产环境、多租户隔离 容器化（Docker/K8s） 环境一致性、编排调度、快速迁移 适合微服务、弹性伸缩架构 推理服务运行时（vLLM / TGI / SGLang / FastAPI） 监听端口：8000 / 8080 / 5000 ｜ 协议：HTTP / gRPC / WebSocket HTTP REST /v1/chat/completions gRPC 流式/非流式推理 WebSocket 实时流式输出 API 网关（Nginx / Kong / APISIX）— 路由、限流、鉴权、负载均衡

上图展示了大模型从部署形态到对外暴露的完整链路。部署方式决定了资源边界和运维模式，推理服务端口与协议决定了 Nginx 如何转发流量，而 API 网关则是在推理服务之上叠加的一层治理能力。三者环环相扣，任何一层的设计失误都会在后续的并发压测或线上故障中暴露无遗。

2.1 常见部署方式：本地、云与容器的选型逻辑

核心原理：三种部署形态的本质差异

大模型的部署形态并非简单的“放哪里跑”的问题，而是涉及资源管理粒度、扩展性、故障隔离和成本模型的综合决策。本地部署（裸机或工作站）将 GPU 资源直接暴露给操作系统，性能损耗最小，但扩展性受限于物理硬件；云服务器（ECS/GPU 云实例）通过虚拟化层提供弹性资源，但存在轻微的虚拟化开销；容器化部署则在操作系统层面进行资源隔离，通过镜像打包环境依赖，实现“一次构建、处处运行”。

从资源利用率角度看，本地部署适合单机多卡场景，例如 8×A100 的研发工作站；云服务器适合需要公网访问、弹性扩缩的生产环境；容器化则是最推荐的部署形态，因为它天然适配 Kubernetes 的调度能力，可以按 GPU 显存大小进行资源配额管理。值得注意的是，容器化并不排斥本地或云——你完全可以在本地物理机上跑 Docker，也可以在云服务器上跑 Kubernetes。

判断方法：根据业务阶段选择部署形态

评估维度 本地裸机 云服务器 容器化（Docker/K8s）
GPU 利用率 最高（无虚拟化层） 较高（有轻微损耗） 高（共享宿主机内核）
扩展性 差（需采购硬件） 中（手动创建实例） 优（自动扩缩容）
环境一致性 差（依赖人工配置） 中（镜像模板） 优（Dockerfile 固化）
运维成本 高（硬件故障自管） 中（云厂商兜底硬件） 中（需管理编排系统）
适用场景 研发调试、数据合规 中小规模生产 大规模生产、微服务

判断的核心标准是“是否需要弹性”。如果业务流量平稳、GPU 资源固定，本地部署或云服务器即可；如果存在明显的波峰波谷（例如白天办公时段高并发、夜间低负载），容器化配合 K8s 的 HPA（Horizontal Pod Autoscaler）可以显著降低成本。另一个判断维度是团队运维能力——容器化引入了镜像构建、编排配置、存储卷等额外复杂度，小团队需要权衡学习成本。

实战场景：从本地调试迁移到容器化生产

某金融科技公司需要部署一个 70B 参数的对话模型，最初在 4×A100 的本地工作站上调试，使用 vLLM 作为推理引擎。调试阶段一切正常，但进入联调测试后，业务方要求提供公网 API 接口，且需要支持每秒 50 个并发请求。本地工作站无法满足公网访问需求，团队决定迁移到云容器环境。

具体操作流程如下：

  1. 将模型权重和推理代码打包为 Docker 镜像，基础镜像选用 nvidia/cuda:12.1-runtime-ubuntu22.04，安装 vLLM 0.4.2 及 Python 依赖。
  2. 在云厂商的 Kubernetes 集群中创建 Deployment，声明 GPU 资源请求为 nvidia.com/gpu: 4，并配置 Service 暴露 8000 端口。
  3. 使用 Nginx Ingress Controller 将外部 HTTPS 流量转发到 Service，并配置 60 秒的 proxy_read_timeout 以支持长文本生成。
  4. 压测结果显示，容器化部署的吞吐量达到本地部署的 92%，延迟增加约 8ms（主要来自网络开销），完全满足业务指标。

复盘经验：容器化迁移的最大风险在于 GPU 驱动版本与 CUDA 运行时的兼容性。团队在迁移过程中遇到一次 CUDA error: no kernel image is available 的报错，原因是宿主机 NVIDIA 驱动版本低于容器内 CUDA 要求。解决方案是统一使用云厂商提供的 GPU 优化型节点池，确保驱动版本一致。

风险提示：本地部署时，如果使用多张 GPU 卡，务必确认 PCIe 拓扑和 NVLink 连接方式。vLLM 等推理引擎默认使用张量并行（Tensor Parallelism），跨节点通信会显著增加延迟。容器化部署时，建议将同一模型的推理实例调度到同一节点，避免跨节点张量并行。

2.2 推理服务端口与协议：Nginx 转发的关键参数

核心原理：端口是服务的“门牌号”，协议是“对话语言”

大模型推理服务本质上是一个常驻内存的 HTTP/gRPC 服务进程。vLLM 默认监听 8000 端口，TGI（Text Generation Inference）默认监听 80 端口，SGLang 默认监听 30000 端口。这些端口号并非标准规定，而是各框架的默认约定。Nginx 反向代理的核心职责之一，就是将外部请求从 443/80 端口转发到这些内部端口。

协议层面，主流推理服务支持三种通信方式：HTTP REST（最通用，OpenAI 兼容格式）、gRPC（高性能，适合内部服务间调用）、WebSocket（支持双向流式通信，适合实时对话）。Nginx 对 HTTP 和 WebSocket 有原生支持，但对 gRPC 需要特殊配置（grpc_pass 指令）。

判断方法：如何确定正确的端口与协议配置

在配置 Nginx 之前，必须确认以下三个信息：

  • 推理服务实际监听端口：通过 netstat -tlnp | grep python 或查看服务启动日志确认。
  • API 路径前缀：vLLM 的 OpenAI 兼容接口路径为 /v1/chat/completions，TGI 的接口路径为 /generate 或 /v1/chat/completions。
  • 是否启用流式输出：如果业务需要打字机效果（Token 逐个返回），必须配置 Nginx 关闭缓冲（proxy_buffering off）并设置合适的超时时间。
# 典型的 vLLM 服务启动命令
python -m vllm.entrypoints.openai.api_server \
    --model /data/models/Qwen2.5-72B-Instruct \
    --tensor-parallel-size 4 \
    --host 0.0.0.0 \
    --port 8000 \
    --max-model-len 32768 \
    --enable-auto-tool-choice

上述命令启动后，服务监听所有网卡的 8000 端口。此时 Nginx 配置中的 proxy_pass http://127.0.0.1:8000; 即可完成转发。但需要注意，如果推理服务部署在 Docker 容器内，Nginx 不能直接使用 127.0.0.1，而应使用容器 IP 或 Docker 网络别名。

实战场景：流式输出场景下的 Nginx 超时配置

一个典型的流式对话场景中，用户发送问题后，模型需要 10-30 秒才能完整生成回复。如果 Nginx 默认的 proxy_read_timeout 60s 不够用，长文本生成（如 8K 上下文）可能超过 60 秒，导致连接被中断。此时需要调整以下参数：

location /v1/chat/completions {
    proxy_pass http://vllm-service:8000;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;          # 关闭缓冲，让流式数据实时转发
    proxy_cache off;              # 禁用缓存，避免污染动态响应
    proxy_read_timeout 300s;      # 5分钟超时，适配长文本生成
    proxy_send_timeout 300s;
    chunked_transfer_encoding on; # 启用分块传输
}

这里的关键是 proxy_buffering off。如果保持默认开启，Nginx 会等上游响应完全结束后才一次性转发给客户端，流式效果将完全失效。此外，proxy_http_version 1.1 和 Connection "" 是为了支持 keepalive 连接池，避免频繁重建 TCP 连接。

经验提醒：如果推理服务同时支持 HTTP 和 gRPC，建议在 Nginx 中分别配置两个 location——/v1/ 走 HTTP 转发，/grpc. 走 grpc_pass。不要试图用 HTTP 配置处理 gRPC 流量，否则会出现 upstream prematurely closed connection 错误。

2.3 API 网关需求：为什么 Nginx 不只是“转发器”

核心原理：网关是推理服务的“前置防火墙”与“流量调度中心”

裸奔的推理服务直接暴露公网是极其危险的。大模型推理服务通常没有内置的用户认证、速率限制和请求审计功能。API 网关在推理服务之前增加了一层统一治理：路由转发（将不同模型版本分发到不同后端）、认证鉴权（校验 API Key 或 JWT）、限流熔断（防止恶意请求打爆 GPU）、日志监控（记录每次调用的 Token 消耗和延迟）。

Nginx 作为 API 网关的优势在于轻量、高性能、配置灵活。相比 Kong 或 APISIX，Nginx 不依赖数据库，配置即代码，适合中小规模团队。但 Nginx 的限流能力相对基础（基于 limit_req 模块），如果需要复杂的按用户维度限流或动态路由，可能需要引入 Lua 脚本或选择更重的 API 网关。

判断方法：什么情况下必须引入 API 网关

业务需求 无网关（直连推理服务） 有 Nginx 网关
多模型共存 需手动管理多个端口 按 URL 路径路由到不同后端
用户认证 推理服务内自研 网关统一校验 API Key
突发流量控制 无法限制，GPU 可能 OOM 网关层限流，保护后端
灰度发布 不支持 按权重分流到新旧版本
访问日志 格式不统一 统一 JSON 格式日志

判断标准很简单：只要推理服务需要被多个客户端或团队共享，就必须引入 API 网关。即使只有一个模型，网关也能提供 TLS 终止、请求大小限制、IP 黑白名单等基础安全能力。

实战场景：多模型路由与限流配置

某 AI 创业公司同时部署了三个模型：Qwen2.5-72B（通用对话）、Llama-3.1-8B（轻量分类）、Embedding 模型（向量检索）。三个模型分别运行在三组不同的 GPU 实例上。通过 Nginx 网关实现统一入口：

upstream qwen_backend {
    server 10.0.1.10:8000;
    server 10.0.1.11:8000;
    keepalive 32;
}

upstream llama_backend {
    server 10.0.2.10:8000;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    # 统一认证
    auth_request /auth;

    location = /auth {
        internal;
        proxy_pass http://auth-service:8080/validate;
        proxy_pass_request_body off;
    }

    # 路由到 Qwen 模型
    location /v1/qwen/ {
        proxy_pass http://qwen_backend/v1/;
        limit_req zone=qwen_limit burst=20 nodelay;
    }

    # 路由到 Llama 模型
    location /v1/llama/ {
        proxy_pass http://llama_backend/v1/;
        limit_req zone=llama_limit burst=50 nodelay;
    }
}

该配置实现了三个关键能力：auth_request 在转发前调用认证服务校验用户身份；limit_req 对 Qwen 模型限制为每秒 10 个请求（burst 20），对 Llama 模型限制为每秒 50 个请求；URL 路径前缀实现模型路由。上线后，网关成功拦截了多次未授权访问，并将 Qwen 服务的 GPU 利用率稳定在 85% 以下，避免了 OOM 风险。

复盘要点：网关层限流必须配合后端推理服务的并发控制。vLLM 本身有 --max-num-seqs 参数控制最大并发序列数，Nginx 限流只是第一道防线。如果网关限流值设置得比后端并发上限高，突发流量仍然可能打满 GPU 显存。建议网关限流值设置为后端并发上限的 80%。

2.4 常见误区与总结复盘

误区一：端口号随意指定，导致 Nginx 转发失败

很多初学者在启动推理服务时使用 --port 8080，但 Nginx 配置中仍然写 proxy_pass http://127.0.0.1:8000;，导致 502 Bad Gateway。排查方法：先在本机用 curl http://127.0.0.1:8080/v1/models 验证服务是否可访问，再检查 Nginx 配置中的端口是否一致。

误区二：忽略 WebSocket 升级头

如果推理服务支持流式输出且客户端使用 WebSocket 连接，Nginx 必须配置：

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

缺少这两行配置，WebSocket 握手会失败，客户端报 Unexpected server response: 400。

误区三：网关层不做超时控制

推理服务的响应时间波动极大——简单问答可能 1 秒返回，长文档摘要可能 60 秒。如果 Nginx 的 proxy_read_timeout 设置过短，长任务会被误杀。建议根据模型最大输出 Token 数估算最坏情况耗时，并在此基础上增加 30% 余量。

总结：部署基础配置清单

  • 部署形态：优先容器化，确保 GPU 驱动与 CUDA 版本兼容。
  • 端口确认：启动服务后立即验证端口监听状态，记录实际端口号。
  • 协议匹配：HTTP 请求用 proxy_pass，gRPC 用 grpc_pass，WebSocket 需配置 Upgrade 头。
  • 网关策略：至少配置认证、限流、超时三项基础能力。
  • 日志监控：在 Nginx 层记录 $request_time 和 $upstream_response_time，用于识别慢请求。
← 上一章 📖 返回目录 下一章 →