用 SGLang 自托管 GLM 推理接口

把 GLM-4.5-Air 部署到独立 GPU 服务器上，再通过 OpenAI-compatible API 调用，是这份教程的主线。作者选择 FP8 权重和 SGLang，给出了从 Ubuntu 环境准备到接口验证的最短路径。

它的价值在于串起部署流程，让现有调用代码有机会接入自托管模型。但原文是精简版，没有完整硬件配置、性能测试和运维文件，适合用来理解路线，不能直接当成生产部署验收标准。

12B 活跃参数，不代表只需装下 12B 权重

GLM-4.5-Air 是面向推理、编程和 agent 任务的混合专家模型（MoE），总参数约 106B，每次推理激活约 12B 参数。教程使用的权重是 zai-org/GLM-4.5-Air-FP8。

这里要分清计算量与模型存储：每次只激活部分专家，不代表其余专家的权重可以不占空间。不能拿 12B 活跃参数，直接估算整套模型的显存需求。

原文提到 Z.ai 提供了 NVIDIA 硬件配置参考，但所给内容没有列出具体 GPU 型号、数量和显存。它只保留了完整功能条件中的几项要求：系统内存超过 1TB、batch size 不超过 8，并且不使用 CPU offloading，也就是不把部分模型计算或权重转移到 CPU 一侧。

作者明确说，这些是参考条件，不是通用最低配置。因此，不能据此断言「低于 1TB 内存一定跑不了」，也不能推断某张消费级显卡一定够用。

从装环境到启动，哪些配置真正影响接入

准备过程先更新 Ubuntu、安装基础工具，再通过 ubuntu-drivers devices 查看驱动建议，执行 sudo ubuntu-drivers install 并重启。随后用 nvidia-smi、nvidia-smi -L 和 nvidia-smi topo -m 检查 GPU、设备列表及连接拓扑。

Python 环境使用 uv：通过 uv venv --python 3.12 创建环境，激活后运行 uv pip install --prerelease=allow sglang。这里允许安装预发布版本，但原文没有固定 SGLang 版本，后续复现可能遇到依赖差异。

模型缓存则通过 HF_HOME=/data/huggingface 指向大容量磁盘，并写入 ~/.bashrc。这一步解决的是权重下载位置，不能替代显存和系统内存规划。

下面这段命令负责加载模型、指定客户端使用的名称，并启动服务：

python -m sglang.launch_server \
    --model-path zai-org/GLM-4.5-Air-FP8 \
    --served-model-name glm-4.5-air-fp8 \
    --host 127.0.0.1 \
    --port 30000

重点看 --served-model-name 和 --host：前者决定请求里的模型名，后者把服务限制在本机接口。命令没有展示多卡并行、上下文长度等配置，不能把它理解成适用于所有 GPU 服务器的完整启动方案。

API 能调用，与服务能上线是两件事

启动后，作者先用 curl http://127.0.0.1:30000/v1/models 检查模型接口，再通过 OpenAI Python SDK 发起请求。

下面这段代码展示了现有 SDK 如何连接本地推理服务：

from openai import OpenAI

client = OpenAI(api_key="local-development", base_url="http://127.0.0.1:30000/v1")

response = client.chat.completions.create(
    model="glm-4.5-air-fp8",
    messages=[{"role": "user", "content": "Explain the role of GPU memory in LLM inference."}],
    max_tokens=300,
)
print(response.choices[0].message.content)

要留意 base_url 中的 /v1，以及与启动参数一致的 model。max_tokens=300 限制本次生成长度；示例中的 api_key="local-development" 只是客户端传入的值，原文没有展示服务端密钥校验配置。

这也是教程最后强调运维边界的原因。作者建议用 systemd 保持服务运行、失败后重启；远程访问则通过带认证的 HTTPS 反向代理、防火墙和私有网络完成，不能把无认证的推理接口直接暴露到互联网。

不过，systemd unit、监控建议和故障排查表都没有出现在这份精简内容中，读者仍需补齐。

我的判断

这条路线合理的地方，是把模型运行、SDK 接入和远程访问分开处理。对于已有 OpenAI SDK 调用代码的项目，兼容接口提供了清晰的接入入口。

但「接口兼容」不能证明模型效果、吞吐和延迟满足业务需求。原文提供的是部署步骤和调用示例，没有可核验的实测结果，也没有与托管 API、其他推理框架的对照数据。因此，不能据此判断 SGLang 更快，或者独立 GPU 服务器更省钱。

自托管换来环境、模型配置和 API 访问控制权，同时也把驱动、依赖、资源规划和服务恢复交给团队。是否值得，取决于这些控制需求有多强，以及团队能否承担维护工作。

能拿来做什么

• 已有 AI 编程或问答调用代码的团队，可以先验证自定义 base_url 和模型名能否接通，再单独检查实际使用的接口能力。
• 评估服务器前，先补齐 GPU 型号、数量、显存和并行配置，不要仅凭 12B 活跃参数或 FP8 格式判断硬件够不够。
• 复现成功后，记录实际安装的 SGLang 版本及依赖，避免一直依赖 --prerelease=allow 带来的浮动安装结果。
• 需要远程访问时，补齐认证代理和 systemd 配置，并验证请求能否通过认证、进程退出后能否恢复。