用 Docker 部署 GLM 5.2：自托管与 vLLM API 搭建

GLM 5.2 的 MIT 开放权重许可是它最大的优势之一——它赋予你在自有基础设施上运行完整 753B 参数模型的合法权利，没有任何使用限制，也不会向任何外部服务回传数据。这对隔离网络环境、数据驻留合规和高吞吐生产负载来说意义重大。诚实的提醒：GLM 5.2 是一个 753B 参数的混合专家（MoE）模型，每次前向传播激活 40B 参数，自托管的硬件门槛确实极高。对大多数工程团队来说，Z.ai 云 API（输入 $1.40/M、输出 $4.40/M tokens）要实用得多。本指南既介绍了有硬件条件的团队如何用 Docker 搭建，也给出了你决定走哪条路所需的现实数据。

硬件需求

GLM 5.2 采用稀疏 MoE 架构，能降低每次推理的计算量，但并不会减少加载全部参数所需的显存。下面是你需要了解的各量化级别的情况：

量化级别	模型显存	最低 GPU 配置	现实可行吗？
BF16（全精度）	约 1,500 GB	19+ 张 H100 80GB	仅限研究 / 企业
INT8	约 750 GB	10 张 H100 80GB	大型企业集群
Q4_K_M（4-bit）	约 380 GB	5 张 H100 80GB	最低可行配置
GLM-4-9B（BF16）	约 18 GB	1 张 RTX 4090 或 A100	大多数团队可用

如果你只有单台工作站或小型 GPU 集群，Hugging Face 上的 GLM-4-9B 是现实得多的目标。完整的 GLM 5.2 需要多节点 GPU 集群，这正是云 API 存在的原因。

用 vLLM 进行 Docker 部署

vLLM 是大型模型推荐的服务框架。它提供 OpenAI 兼容的 REST API、面向长上下文的高效 paged attention，以及跨多张 GPU 的直白张量并行。官方 Docker 镜像打包了你需要的一切。

首先拉取镜像：

docker pull vllm/vllm-openai:latest

然后启动服务。下面的命令假设有 8 张 GPU，并将上下文窗口限制为 32,768 tokens——这对大多数工作负载是实用的上限，也能避免在完整 1,048,576-token 上下文长度下出现 KV cache 内存激增：

docker run --gpus all \
  --shm-size=8g \
  -p 8000:8000 \
  -e HUGGING_FACE_HUB_TOKEN=your_hf_token_here \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:latest \
  --model THUDM/GLM-5.2 \
  --tensor-parallel-size 8 \
  --max-model-len 32768 \
  --dtype bfloat16

使用张量并行时，--shm-size=8g 标志是跨 GPU 共享内存所必需的。根据你的 GPU 数量调整 --tensor-parallel-size。模型权重会在首次运行时自动从 Hugging Face 下载——完整检查点有数百 GB，请根据你的网络条件预留几个小时。

API 配置

容器启动后，vLLM 会在 http://localhost:8000 暴露 OpenAI 兼容的 API。你可以把任何 OpenAI SDK 客户端直接指向这个端点，无需其他改动：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-required"  # vLLM does not enforce API keys by default
)

response = client.chat.completions.create(
    model="THUDM/GLM-5.2",
    messages=[
        {"role": "user", "content": "Explain mixture-of-experts architecture."}
    ],
    max_tokens=512,
    temperature=0.7
)

print(response.choices[0].message.content)

发送请求前，先验证服务是否健康：

curl http://localhost:8000/health
curl http://localhost:8000/v1/models

生产环境配置

生产部署建议用 docker-compose.yml 来管理 GPU 分配、环境变量、卷挂载和健康检查：

version: '3.8'

services:
  glm52-api:
    image: vllm/vllm-openai:latest
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    shm_size: '8gb'
    ports:
      - "8000:8000"
    environment:
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
      - VLLM_WORKER_MULTIPROC_METHOD=spawn
    volumes:
      - huggingface_cache:/root/.cache/huggingface
    command: >
      --model THUDM/GLM-5.2
      --tensor-parallel-size 8
      --max-model-len 32768
      --dtype bfloat16
      --max-num-seqs 16
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 600s
    restart: unless-stopped

volumes:
  huggingface_cache:

在 compose 文件旁放一个 .env 文件设置你的 Hugging Face token（HF_TOKEN=hf_...）。start_period: 600s 的健康检查延迟很重要——模型加载进显存需要几分钟，之后才能开始服务请求。--max-num-seqs 16 限制并发序列数，避免高负载下的 OOM 错误；请根据你的可用内存余量调整。

量化选项

如果你的硬件达不到完整 753B 模型的 Q4 需求，在 Docker 里运行 llama.cpp 配合 GGUF 量化文件是更轻量的替代方案。对拥有 4–8 张消费级 GPU 的团队来说，这是务实的路径：

docker run --gpus all \
  -p 8080:8080 \
  -v /path/to/models:/models \
  ghcr.io/ggerganov/llama.cpp:server \
  -m /models/glm-5.2.Q4_K_M.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -ngl 99 \
  --ctx-size 8192

-ngl 99 标志把所有层卸载到 GPU。GLM 5.2 的 GGUF 文件在量化工作定稿后可从 Hugging Face 社区获取。llama.cpp server 也会在 8080 端口暴露 OpenAI 兼容 API，所以你的客户端代码无需改动即可使用。

什么时候自托管才有意义

按 Z.ai 输入 $1.40/M、输出 $4.40/M tokens 的定价，云 API 对大多数工作负载来说成本极低。自托管的盈亏平衡计算几乎完全取决于吞吐量。

在主流云厂商上，10 张 H100 的集群每小时大约 $30–35。按 $4.40/M 输出 token 计算，你需要持续、全天候地每小时生成约 700 万输出 token，自托管才会比 API 便宜。这大约是每秒 2,000 输出 token，需要相当大的并发流量。

在以下场景中，自托管在经济上才说得通：

隔离网络或合规环境——无论成本如何，数据都不能离开你的网络
超高吞吐推理（每天稳定数千万 token）——你拥有硬件而不是租用
研究或微调——需要直接访问模型并能够修改权重

其他所有情况——原型开发、中等流量的生产应用，或没有 GPU 集群经验的团队——Z.ai API 都更快上手、更便宜运维。

常见问题

运行 GLM 5.2 绝对最低的硬件要求是什么？ 五张 H100 80GB GPU（合计 400GB 显存），配合 Q4 量化。低于这个配置，你无法加载完整的 753B 参数模型。硬件更小的场合，请用 GLM-4-9B——它只需约 18GB 显存，单张 A100 或高端消费级 GPU 即可运行。

自托管的延迟一定比云 API 低吗？ 不一定。Z.ai 的基础设施针对 GLM 5.2 优化，运行速度达到每秒 158 tokens。自托管集群如果网络优化不足、GPU 更少，实际可能更慢，尤其是在低批大小下。延迟很大程度上取决于你的集群配置。

MIT 许可允许商业使用吗？ 允许。MIT 许可对商业使用、微调、再分发或修改没有任何限制。你需要保留许可声明，除此之外可以自由地在任何产品或服务中使用该模型。

GLM 5.2 能跑在消费级 GPU 上吗？ 完整的 753B 模型不行。即使激进量化，你也需要专业级多 GPU 基础设施。如果你只有消费级硬件（例如 RTX 4090），请改用 GLM-4-9B——它只需约 18GB 显存，而且能力相当强。

生产环境用 llama.cpp 替代 vLLM 可行吗？ 对较小模型或缺乏深度 ML 基础设施经验的团队，可行。llama.cpp 搭建更简单，支持更多量化格式。vLLM 在大规模生产流量下吞吐更高、并发更好，但需要更多显存和更复杂的配置。

超过我在 Docker 命令里设置的 32,768 token 上下文窗口会怎样？ vLLM 会拒绝请求并返回错误。你可以把 --max-model-len 提高到 1,048,576——GLM 5.2 的完整上下文——但每提高一次，KV cache 内存需求都会显著增加。先从保守值开始，再根据实际负载向上调。

结论

凭借 MIT 许可，GLM 5.2 在法律和技术上都可以自托管，而 vLLM + Docker 为你在自有基础设施上搭建 OpenAI 兼容 API 提供了一条干净的路。硬件门槛极高：加载量化权重至少需要五张 H100 80GB，而更现实的生产集群每月的租用成本是数万美元。对绝大多数团队来说，Z.ai 云 API（输入 $1.40/M、输出 $4.40/M tokens）是合适的起点——只有当隔离网络环境、严格的数据驻留要求或超大持续推理量出现时，自托管才值得承担运维复杂度。

试用 GLM 5.2——无需 API key：glm5.app/chat