企业官网建设流程全解析

最近好几个朋友来问大模型私有化部署的问题，焦点几乎都落在“GL 系列 4.7（FP8）”这个版本上。这类提问在技术群里的出现频率，已经赶超“哪个模型更强”了——因为模型能力基本都心里有数，真正把人卡住的是环境配置、显存估算、量化格式选型和推理框架调优这一整套流程。

这篇指南就围绕一件事：在一台单卡工作站上，把 GL 系列 4.7（FP8）完整私有化跑起来。我会把部署前怎么算显存、环境怎么搭、服务怎么起、性能怎么调、踩过哪些坑全部写出来，不会只丢给你几条命令就完事。目标是让你看完之后，不需要再翻第二篇教程，就能照着做出一个能稳定服务、能接业务调用的私有化大模型推理服务。

这篇内容适合两类人：一是刚接触大模型部署、手里有 24GB 显存显卡，想把开源模型真正用起来的开发者；二是已经在用云 API，但是因为数据敏感性或成本问题，准备把模型收回到内网做私有化的工程团队。前者的重点是“跑起来”，后者的重点是“跑得稳”，我都会覆盖到。

1. 部署前必须想清楚的事：模型选型与显存数学

很多人拿到部署教程就直接复制命令，结果跑起来才发现显存不够、磁盘不够、推理慢到没法用。问题往往不是命令错了，而是部署前没有算清楚账。这一节先把四件事理清楚：为什么选 FP8、FP8 相比其他量化格式有什么优势、显存到底怎么算、硬件怎么选。

1.1 为什么是 4.7（FP8）：精度、显存、性能三者的平衡点

GL 系列 4.7 这个规模，在开源对话模型里属于一个很巧妙的位置。参数不到 5B，单卡能跑，但能力又明显强于更小的 1B、2B 级别模型。配合 FP8 量化之后，权重文件只要不到 5GB 的大小，很多消费级显卡和中端工作站都能轻松容纳。

选 FP8 而不是 INT4、INT8，核心原因是精度和部署难度的平衡。

INT4 虽然能把显存压得更低，但需要做比较重的校准和量化调参，一旦校准数据选得不好，模型输出的质量下滑会比较明显，尤其在数学推理和代码生成这种对数值敏感的任务上。INT8 的部署工具链相对成熟，但相比 FP8 少了原生硬件加速的加持。FP8 则是当前新一代 GPU 张量核心原生支持的格式，推理框架对它的支持也越来越好，算法上不需要像 INT4 那样大规模重训或微调，很多模型仓库直接提供 FP8 权重，下载下来就能用。

用生活化的话说：INT4 像是一个压缩过头的大箱子，装是装得下，但拿出来的时候有概率变形；FP8 像是稍微大一点的箱子，成本和变形率都更低，而且搬运工具（推理框架）是原厂配套的。对于要把模型长期投入生产环境的人来说，FP8 的“省心”价值很高。

1.2 显存估算：不只是“权重放得下就行”

部署大模型最常见的错误，就是只算权重显存，忽略了推理过程中的 KV Cache 和激活值。模型加载进去能跑第一步，但上下文一长、并发一上来，显存立刻爆掉。我习惯用下面这个公式做事前估算：

总显存 ≈ 权重显存 + KV Cache 显存 + 激活/临时缓冲 + CUDA Context 开销

以 4.7B 模型、FP8 格式为例：参数量 47 亿，每参数占用 1 字节（FP8），权重显存约 4.7GB。如果原始权重是 BF16，那就是约 9.4GB。这一部分没有什么悬念。

KV Cache 才是隐形大头。它的计算方式大致是：

KV Cache 显存 = 2（K 和 V 两组） × 层数 × KV 头数 × 每头维度 × 字节数（默认 FP16 即 2 字节）× 当前 Token 数 × 并发请求数

假设这个模型有 32 层 Transformer 解码层，使用 GQA 架构，KV 头数 8，每头维度 128。那么每个 Token 的 KV Cache 占用为：

2 × 32 × 8 × 128 × 2 字节 = 131,072 字节 = 128 KB / Token

如果把上下文长度设置成 32K，单并发时的 KV Cache 是：

128 KB × 32768 = 4,194,304 KB ≈ 4.1 GB

如果并发数提到 8，这一个 KV Cache 就可能吃掉 33GB 显存。这就是为什么很多人在单卡 24GB 上跑 4.7B 模型时，短上下文很流畅，一旦开长上下文就立刻 OOM。

下表给出了不同上下文长度下的估算数据（权重 FP8 约 4.7GB，KV 用 FP16）：

上表只是权重和 KV Cache 两项，还没算激活值、中间缓冲和 CUDA 上下文的固定开销。实际部署时，我建议在估算结果上再留 2GB 到 4GB 的余量。

1.3 硬件选型建议：单卡、双卡与 CPU 内存

如果你的模型就是 4.7B FP8，那么一张 24GB 显存的显卡是目前最舒服的配置。常见的有 3090、4090 以及对应的专业卡。24GB 显存能让你在 32K 上下文、低并发下稳定运行；如果只开 8K 上下文，16GB 也能顶住。

预算再低一些，12GB 显存也不是完全不能跑，但需要把 KV Cache 精度降到 FP8，并且把最大上下文锁到 8K 以内。再低就不建议了，因为你会花大量时间在踩显存边界，而不是调服务和业务。

双卡乃至多卡部署这套 4.7B 模型不是不行，但收益很有限。因为单卡已经能放下，多卡反而会引入通信开销。真正需要双卡的场景，是你在同一台机器上还要并行跑其他模型，或者你要部署的是一个 70B 量级的大模型。这时候就要考虑张量并行，把权重切到多张卡上。

CPU 内存同样不能忽视。模型权重加载进显存之前，会先读进 CPU 内存。如果 CPU 内存不够，系统会走 swap，加载速度慢到怀疑人生。我的经验值是：CPU 内存至少要有模型权重的 2 倍，4.7B FP8 建议 16GB 起，32GB 更稳。

2. 环境准备：从空机器到能跑模型的四个步骤

硬件到位之后，环境配置这块反而劝退了最多人。大模型部署不像普通 Web 服务，它对 CUDA 版本、Python 版本、算子库版本都很敏感。版本不匹配的典型表现是：框架日志打出来了，服务也起来了，但一推理就报算子不存在或者非法内存访问。

2.1 操作系统与驱动基线

操作系统优先选 Linux。Ubuntu 22.04 LTS 是我用的最多的，兼容性和社区支持都最稳。Desktop 版和 Server 版都可以，但 Server 版少了桌面环境，资源占用更干净。

驱动版本建议选 545 或更新的版本，CUDA 运行时则建议 12.1 以上。不要直接在宿主机上裸装一套错综复杂的 CUDA 环境，后面很容易出现/usr/local/cuda路径混乱的问题。我推荐在根目录下建一个/data/models专门放权重，建一个/data/services专门放部署代码，隔离清晰。

如果你一定要用 Docker，也请确认 Docker 的 GPU 运行时已经配置好。具体检查命令是：

nvidia-smi

如果容器内能看到显卡信息，说明 GPU 透传正常；如果显示couldn't find libnvidia-ml.so之类的报错，那就是容器运行时没有装好 Nvidia Container Toolkit。

2.2 创建 Python 环境并安装依赖

我习惯用 Conda 管理 Python 环境，因为大模型部署经常要在不同项目之间切换，环境隔离比什么都重要。建议用 Python 3.10 或 3.11，Python 3.8 太旧，部分新版本的推理框架已经不再支持。

创建环境的命令很简单：

conda create -n glm-deploy python=3.10 -y conda activate glm-deploy

接下来安装 PyTorch。这一步要看你的 CUDA 版本，直接上官方给出的安装命令。以 CUDA 12.1 为例，安装命令大致如下（以实际官方源为准）：

pip install torch --index-url https://download.pytorch.org/whl/cu121

注意这里特别容易踩坑：如果直接用默认源装 PyTorch，装下来常常是 CPU 版本，或者 CUDA 版本不匹配。装完一定要验证一下：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

输出True和你的显卡名称，才算通过。

之后安装基础依赖：

pip install transformers accelerate sentencepiece safetensors

还需要装 flash-attn 这类加速算子库。这个库的安装比较耗时，而且对 CUDA 版本很敏感。如果编译失败，优先检查是否用的 PyTorch 版本与算子库要求的版本一致。pyproject 编译要求ninja和gcc，缺了也会报错。

2.3 获取与校验模型权重：FP8 仓库还是 BF16 转量化

模型权重获取我建议直接下载官方发布或社区维护的 FP8 版本。如果你所在地区访问公共模型仓库不稳定，可以用国内主流的模型托管平台下载，这些平台一般提供了完整的文件列表和下载工具。

下载之前先确认文件列表的完整性。一个标准的模型仓库应该包含：

config.json tokenizer.model tokenizer_config.json model.safetensors.index.json model-00001-of-0000X.safetensors ...

如果仓库提供了 sha256 校验文件，务必下载下来逐文件验证。模型分片文件看起来大小差不多，但哪怕有一个字节不对，加载时都可能报safetensors_rust::SafetensorsError之类的错误。

如果你拿到的只是 BF16 原始权重，想转成 FP8，需要用到模型自带的转换工具或者量化工具链。我通常的做法是先跑一遍转换脚本，把 BF16 权重转换成 FP8 格式，再放进推理框架。一个典型的转换流程示例：

python scripts/convert_to_fp8.py \ --input /data/models/glm-4.7-bf16 \ --output /data/models/glm-4.7-fp8 \ --quantization-algo fp8

注意：转换工具对输入的权重精度有要求。BF16 转 FP8 是常见路径，但如果你手上的原始权重是 FP16，部分工具链会直接拒绝转换或者给出质量警告。我建议优先寻找 BF16 原始权重，这是最标准的中间格式。

2.4 三个我常用的环境检查命令

每次部署前我都会跑一遍下面的“体检”，看似简单，但能救你很多次：

nvidia-smi nvcc --version python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.cuda.is_available())"

这三个命令分别确认显卡驱动、CUDA 工具链版本、PyTorch 与 CUDA 的匹配情况。三者的版本号不需要完全一致，但兼容范围要合理。比如驱动 545 支持 CUDA 12.1 运行时没问题；PyTorch 的 CUDA 版本是 12.1，系统里即使没有单独装 CUDA Toolkit 也能跑，因为 PyTorch 自带 CUDA 运行时。

如果这三个命令结果都正常，但模型加载还是报错，再看模型目录的磁盘剩余空间。别笑，我遇到过不止一次，权重下载到一半磁盘满了，下载工具还不报错，结果加载时才发现文件不完整。

3. 正式部署：把模型“跑起来”的完整流程

环境就绪、权重就位之后，进入正式部署阶段。这一节我会以当前社区使用最广泛的一类高性能 LLM 推理框架为例，它的特点是支持连续批处理（Continuous Batching）、Paged Attention 和量化格式原生推理。这类框架的命令和参数大同小异，理解了一个，换到另一个框架也很快。

3.1 启动服务前的参数清单

启动推理服务之前，有几个关键参数必须先想清楚。第一个是--max-model-len，它直接决定 KV Cache 上限。前面算过，4.7B 模型的 KV Cache 在 32K 上下文下约 4GB，你要是设成 128K，单请求就把 24GB 显存吃穿。我建议第一次部署先用 8K 或 16K 打通流程，成功后再逐步往上调。

第二个是--gpu-memory-utilization。这个参数控制推理框架能占用多少比例的总显存，通常设置 0.90 到 0.93。为什么不设成 0.99？因为显卡显示设备、渲染输出这些都要留一点显存，而且 PyTorch 的 CUDA Context 本身也要占空间。设太高，启动时看着还剩几 MB 显存，跑起来直接 OOM。

第三个是--served-model-name。这是对外暴露的模型名称，你可以随意指定。实际上，这个名字只影响 API 调用时的model字段，不影响内部真正的模型文件。但建议起一个和业务相关的名称，方便下游系统识别。

3.2 一次性启动：一个可复制的命令模板

下面是一份基于 24GB 显卡、32K 上下文的启动命令示例：

python -m llm_serving.serve \ --model-path /data/models/glm-4.7-fp8 \ --served-model-name glm-4.7-fp8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --trust-remote-code \ --host 0.0.0.0 \ --port 8000

启动之后，日志会逐条打印加载过程。重点看几个标志性输出：

Loading safetensors checkpoint shards: 100% Kwargs passed to the model are not used by the model: ... Starting vLLM api server on http://0.0.0.0:8000

出现Starting ... api server才表示 HTTP 服务真正起来了。如果日志停在加载权重阶段，说明模型文件读取有问题；如果停在初始化阶段，大概率是显存或算子库的问题。

注意--trust-remote-code参数。很多模型仓库会附带自定义的模型实现代码，推理框架默认不信任远程代码，需要显式打开。如果不开，通常会直接报raise ValueError: ... trust_remote_code之类的错误。这个参数有一定风险，只对可信仓库开启，不要什么都加。

3.3 用 OpenAI 兼容接口做冒烟测试

现在主流推理框架都会提供 OpenAI 兼容的 HTTP 接口，路径一般是/v1/chat/completions。这意味着你原来对接云厂商 API 的代码，几乎不用改就能切换到私有化服务上。这是私有化部署很大的价值点：业务代码不重写。

先做一个最简单的冒烟测试：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "glm-4.7-fp8", "messages": [{"role": "user", "content": "你好，请简述一下大模型部署的基本流程。"}], "max_tokens": 256, "temperature": 0.7 }'

正常情况下会返回一个 JSON，里面包含choices、usage等字段。重点看usage里的prompt_tokens和completion_tokens，确认输入输出 token 数统计正常。

冒烟测试时我还会顺手测一下首 Token 延迟。用 curl 的-N参数流式输出：

curl -N http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "glm-4.7-fp8", "messages": [{"role":"user","content":"写一篇关于大模型的短文"}], "max_tokens": 100, "stream": true}'

如果秒回第一个 token，说明模型整体链路是通的；如果等了很久才开始吐字，问题可能不在显存，而在数据处理或模型预热阶段。首次请求通常比后续请求慢，因为要初始化 CUDA kernel 和分配 KV Cache，这个是正常现象。

4. 性能调优与稳定性治理：从能跑到跑得好

服务能起来了，只是第一步。真正放到生产环境，你还要回答三个问题：并发高了会不会崩？延迟能不能接受？长时间运行会不会越跑越慢？这一节讲我实测下来的调优路径。

4.1 先明确指标：首 Token 延迟、吞吐量和端到端延迟

部署优化不能凭感觉，得先建指标。我主要看三个：

• TTFT（Time to First Token）：从请求发出到收到第一个 token 的时间，反映模型“开始干活”的速度。
• TPOT（Time Per Output Token）：输出一个 token 的平均耗时，反映生成的速度。
• 吞吐量：单位时间能处理的请求数或 token 数，反映系统在并发下的处理能力。

这四个指标对应不同的调优方向。TTFT 偏高，通常是预处理慢或者排队太长；TPOT 偏高，可能是显存带宽瓶颈或者采样参数不当；吞吐量上不去，大概率是批处理没有跑满。

建议第一次压测时用 1 并发、8 并发、16 并发三档分别测。1 并发看单请求延迟上限；8 并发看常规业务负载下的表现；16 并发看系统是否稳定。不要一上来就 100 并发，到时代码还没干出什么事，服务先被压垮了，日志全是 OOM，很难定位问题。

4.2 动态批处理与连续 Batching：提升吞吐的关键

大模型推理和传统 Web 服务不一样，它不能高效地同时处理任意并发请求。老式做法是等一批请求都到了再一起算，短的请求也要等长的跑完。现代推理框架采用连续批处理，每一层计算完后就释放已完成请求的显存，空出来的位置立刻被新请求顶上，队列利用率大幅提高。

对应的关键参数一般是--max-num-seqs，它限制一次最多并行解码多少条序列。太低了，并发浪费；太高了，KV Cache 快速挤爆。4.7B FP8 这种模型，在 24GB 显卡上，我建议从 8 到 16 之间起调。如果你的业务请求普遍很短（比如几百 token），可以偏大一点；如果普遍生成很长（比如几千 token），就要偏小。

压测发现吞吐瓶颈时，我推荐按这个顺序排查：

1. 看 GPU 利用率是否接近满负荷（watch -n1 nvidia-smi）
2. 若利用率低，先调大--max-num-seqs
3. 若利用率高但吞吐不行，可能到了算力上限，不要再无限加并发，否则延迟会飙升
4. 若显存占用接近上限但该利用率低，说明 KV Cache 碎片化严重，重启服务释放碎片后重新压测

4.3 长上下文的显存杀手：KV Cache 调优

长上下文是私有化部署最容易爆显存的地方。前面算过，同样一个模型，4K 上下文和 32K 上下文，KV Cache 占用差距接近 8 倍。如果你的业务场景主要是文档问答、长文本总结，建议把 KV Cache 精度也从 FP16 降为 FP8。

部分推理框架支持--kv-cache-dtype fp8这类参数，可以把 KV Cache 的存储精度降到 8 位浮点。这个选项对显存占用立竿见影，理论上能把 KV Cache 内存砍一半。精度损失在大多数文本任务上几乎感觉不到，但如果你做的是精确数值抽取类任务，建议还是保留 FP16。

深度体验下来，长上下文另一大隐患是max-model-len设得过大但实际命中率低。很多人为了“保险”，直接把最大上下文设成 128K，结果显存全被 KV Cache 预留占光，实际请求平均只有几千 token。我建议按业务 P99 请求长度再乘 1.2 到 1.5 倍来设置，而不是无脑拉满。

4.4 给服务加一层日志、监控和优雅退出

生产环境最怕的不是性能差，而是出了故障不知道。我把自己常用的监控三板斧列出来：

• watch -n1 nvidia-smi：看显存和利用率
• tail -f /data/services/glm_deploy.log：看推理框架日志
• python scripts/health_check.py：每隔 30 秒调一次健康接口，记录返回状态和响应时间

如果是容器部署，重启策略要设成失败自动拉起，但注意大模型服务冷启动很慢，自动拉起期间业务会短暂不可用。更稳的方案是前面架一层负载均衡，部署两个服务实例做滚动重启，但这对于单机部署来说成本较高。

还有一个很多人忽略的细节：推理服务对 SIGTERM 信号的处理。直接kill -9会导致正在推理的请求全部丢失，而且显存里的 KV Cache 没法正常回收，下次启动可能残留异常状态。框架一般有优雅停机机制，收到退出信号后会等正在生成的请求结束再退出。发信号用kill <PID>，不要用kill -9。

5. 我在部署中遇到过的 7 个问题（附排查思路）

这一节把最常遇到的部署问题整理成速查表。排查顺序一般先看硬件状态，再看日志，最后看代码。

上面每一条我都实际踩过，展开讲几条。

显存问题的判断有个细节：显存占用不是匀速上升的，而是在请求开始后在某个瞬间突然跳高。如果你看到曲线是每次请求后升高一点、结束后不降下来，那不是泄漏，而是框架在预处理时提前分配了 KV Cache 块。这种情况不需要重启，继续跑一段时间后显存会趋于稳定。

加载权重时报“file not found”但文件明明存在，这种十有八九是路径写错了。模型路径里不要带波浪号~，部分框架运行时不会自动展开用户目录。我统一把路径写绝对路径，比如/data/models/glm-4.7-fp8。

乱码问题除了采样参数，还有一种可能是 tokenizer 与模型权重不匹配。下载时如果只拿了model-*.safetensors，而忘了tokenizer.model和相关的配置文件，模型能跑但输出的是根本无法阅读的乱 token 串。确保完整下载整个仓库而不是只下载权重文件。

写到最后的一点个人体会

这套部署流程我在单卡 24GB 上反复验证了很多次，从最初翻车到后来形成固定套路，最大的体会是：私有大模型部署这件事，功夫在模型之外。显存估算、上下文设计、并发控制、日志监控，每一个环节都值得多想一步。不要试图把所有参数一次调到位，先用最保守的配置跑通，再逐项放宽，这是最省时间的路径。

最后再分享一个小技巧：部署完成后，把完整的环境依赖、启动命令、关键参数都固化到一个部署文档里。大模型服务之后一定会面临升级、换卡、换权重，有一份记录了“当初为什么这么设”的文档，比任何自动化脚本都更能帮你后续做决策。

如果需要进一步把这个模型接入业务，下一步可以从 RAG（检索增强生成）和工具调用两个方向入手。模型部署只是地基，上面的应用生态才是真正产生价值的地方。但地基能不能打牢，就看这一篇的功夫到不到位了。