企业官网建设流程全解析

GLM-4-9B-Chat这颗开源模型发布以后，我在自己机器上前前后后部署过不止一次，从最早的llama.cpp量化版，到后来的vLLM在线服务，再到压到8GB显存笔记本上的超低资源方案，折腾了一圈下来，踩过的坑基本都摸清了。这篇东西不聊理论，也不做跑分对比，就是把“本地跑起GLM”这件事掰开揉碎讲清楚：从硬件预算、环境准备，到模型下载、量化转换，再到推理引擎的选型和实际部署，最后到API调用和常见问题处理，全部按实操顺序走一遍。适合想在自己电脑上私有化部署大模型的开发者，或者正在评估开源模型落地方案的技术负责人。看完以后，你至少能在一台有NVIDIA显卡的机器上，把GLM-4-9B-Chat稳稳地跑起来。

1. 部署前规划：明确你的硬件边界和模型选型

1.1 GLM系列开源模型怎么选

GLM系列开源出来的模型不止一个版本，我实际部署过的主要有三代：第一代的GLM-6B，第二代GLM-2-6B，以及目前综合体验最成熟的GLM-4-9B-Chat。还有更轻的GLM-4-9B-0414，以及面向长文本微调的GLM-4-9B-Chat-1M，后者我把官方配置拉起来以后显存直接彪到接近26GB，普通桌面级显卡基本吃不消。

如果你手里的显卡是8GB显存，老实选用GLM-4-9B-Chat就够了。对应到Hugging Face上是zhipu/glm-4-9b-chat这个仓库名字，ModelScope上也有同步的镜像仓库。这个模型基础参数量是90亿，词表很大，V0版本可以直接支持128K上下文，日常对话、代码生成、知识问答都能覆盖。相比之下，GLM-4-9B-0414更像是“轻量化改进”版，数学和代码能力略有侧重，但通用对话场景我测下来不如标准Chat版本稳定。

如果显存在12GB以上，可以考虑关闭量化直接用16位精度跑，效果会好不少难。如果显存只有6GB，也不是完全没戏，可以试试GPTQ的4bit版或者GGUF的Q4_K_M档位，配合CPU offload也能勉强跑，只是速度会慢到能喝杯咖啡再看到回复。

1.2 硬件需求怎么估算

很多人在部署之前都纠结一个问题：我的电脑到底能不能跑？这里我给一个比较实用的估算公式。模型权重占用的显存，参数数量乘以权重精度，再乘1.2左右的运行时开销系数。以GLM-4-9B-Chat为例，全精度FP16下权重占用约18GB，加上KV Cache和中间激活值，实际推理时显存峰值在20到22GB之间。所以FP16推理需要至少24GB显存的显卡，也就是RTX 3090、4090或者A5000这个级别。

如果显存不够，量化是唯一的出路。Q4_K_M量化之后，权重压到约6GB，加上KV Cache，推理时的峰值大约在7到8GB，正好卡在RTX 3060、2070Super、4060这档8G显卡的可用范围内。如果再降到Q3_K_S，权重约5GB，6GB显存的老卡也可以勉强跑，但生成质量下降还是比较明显的，说话会偶尔前言不搭后语。

内存方面，一条经验法则：内存至少要有显存的两倍。因为模型加载、上下文拼接、CPU offload都要用到内存，8GB显存方案建议内存16GB起步，最好是32GB。CPU方面不用太焦虑，大部分计算在GPU上，CPU只负责数据搬运，但要注意AVX2指令集支持，2015年以后的主流CPU基本都没问题。

2. 环境准备：从零搭建推理基础

2.1 操作系统和显卡驱动

部署GLM并没有绑定某个特定操作系统。我在Ubuntu 22.04和Windows 11上分别跑通过，但强烈建议有条件的人用Linux，NVIDIA驱动、CUDA库、容器化部署都省心太多。如果你是Windows用户，也完全能跑，只是部分工具需要借助WSL2窗口来做。

Linux环境下装驱动，用nvidia-smi看一眼当前驱动版本，CUDA的Driver API版本要高于12.0才比较友好。这里有个容易忽略的点：很多人把NVIDIA驱动和CUDA Toolkit混为一谈，实际上推理框架通常只需要驱动支持对应的CUDA运行时版本就行，不需要额外装完整的CUDA Toolkit。驱动装好后，用python -c "import torch; print(torch.cuda.is_available())"验证PyTorch是否能正常调用GPU，这个验证是后面所有步骤的基础。

2.2 Python环境与基础依赖

我建议用conda单独开一个环境，不要和系统Python混在一起。命令很简单：

conda create -n glm-env python=3.10 conda activate glm-env

Python版本选3.10是目前兼容性最好的，3.11、3.12虽然也能用，但个别框架的预编译轮子不一定齐全。接下来装PyTorch，针对CUDA 12.1版本：

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

装完以后先跑一个小测试，确认GPU可用再往下走。很多部署失败的问题，根源都是PyTorch装成了CPU版本，程序确实能跑，但慢到怀疑人生，而且会在调用GPU时报各种莫名其妙的错误。测试代码很简单：

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

如果输出True和你的显卡型号，环境基本就稳了。

2.3 模型下载工具准备

Hugging Face官方推荐的huggingface-cli是通用的下载方式。国内用户如果访问困难，可以用ModelScope的modelscope库，它在国内有CDN加速，下载速度明显快很多。这两个工具准备一个即可，建议两个都装上，哪个快用哪个：

pip install huggingface_hub modelscope

下载模型不建议直接git clone整个仓库，模型仓库往往几十个GB，一旦中断整个目录都是脏的。用专门的下载工具带断点续传，才是靠谱的做法。这点在后面模型获取的章节细说。

3. 模型获取与量化转换：别在这一步省时间

3.1 实际下载流程演示

以Hugging Face上的zhipu/glm-4-9b-chat为例，用huggingface-cli下载：

huggingface-cli download zhipu/glm-4-9b-chat --local-dir ./models/glm-4-9b-chat --local-dir-use-symlinks False

这里有一个关键的坑要说明：--local-dir-use-symlinks False这个参数必须带上。原因很简单，Hugging Face的下载工具默认用symlinks做缓存，如果你下载到的是快照里的符号链接而不是实体文件，后续加载模型时路径会出问题。我最早部署的时候没注意这个，加载模型时报了一堆“file not found”，排查了半天才发现是软链问题。

如果走ModelScope：

modelscope download --model zhipu/glm-4-9b-chat --local_dir ./models/glm-4-9b-chat

下载完成后，检查目录下应该至少有model-00001-of-00002.safetensors这类分片权重文件、tokenizer.model、config.json，以及modeling_chatglm.py。GLM系列模型的建模文件是单独放在仓库里的，不能像其他模型那样直接套用通用的transformers结构，所以目录里的Python文件不要动。

3.2 量化参数怎么选

量化是本地部署最核心的决策点，直接决定你能不能在有限显存里跑起来。目前主流量化格式有三种：GPTQ、AWQ和GGUF，各有各的适用场景。

GPTQ和AWQ适合在用transformers或vLLM这类框架部署时使用，加载后直接跑在GPU上，但你需要额外装量化库，比如auto-gptq或autoawq。GGUF是llama.cpp系列专用的格式，优点是量化粒度更细、CPU和GPU混合推理的支持更成熟，文件也更容易管理。

对GLM-4-9B-Chat，我做了一次量化档位对比实验，数据大概如下：

这个表格可以当作一个参考基线。视觉上Q4_K_M和全精度差距很小，大部分测试用例中表现接近；Q3_K_S能在明显感觉能力缩水，尤其代码生成的逻辑连贯性会变差。如果条件允许，建议至少上Q5_K_M。

3.3 GGUF转换实操

如果你的原始模型是safetensors格式，想转成GGUF，需要用到llama.cpp的转换脚本。大致流程如下：

git clone https://github.com/ggml-org/llama.cpp cd llama.cpp pip install -r requirements.txt python convert_hf_to_gguf.py ../models/glm-4-9b-chat --outfile glm-4-9b-chat-f16.gguf --outtype f16

一次转换理论上能直接输出FP16的GGUF文件，但实际操作中，很多人的机器会在这个环节因为内存不足而崩溃。原因是这个转换过程需要把整个模型的所有权重一次性读入内存，90亿参数的FP16权重就是18GB的内存占用。内存不够的话，要么增加交换空间硬扛，要么直接去社区找已经量化好的GGUF文件，跳过这个步骤。网上能搜到现成的GLM-4-9B-Chat各档位量化文件，下载下来直接用是效率最高的方案。

转换完成后再执行量化：

./llama-quantize ./glm-4-9b-chat-f16.gguf ./glm-4-9b-chat-Q4_K_M.gguf Q4_K_M

这一步不需要太多内存，因为量化是按张量流式处理的。最终得到的Q4_K_M文件不到7GB，拷贝到哪都能用。

4. 推理引擎选型：llama.cpp、vLLM、Ollama还是transformers

4.1 三款主流引擎对比

部署大型语言模型，推理引擎决定了你能跑多快、能并发多少、接口长什么样。目前在GLM-4-9B上我实际用下来比较顺的有三个选项：llama.cpp、vLLM、Ollama。还有一个transformers原生加载的方式，如果是快速体验可以试试，但生产环境不建议，因为它速度太慢还占显存。

Ollama是这三者里门槛最低的，装完以后直接ollama run zhipu/glm4:9b就能把自己下载好的模型跑起来。但说实话，Ollama内部把模型处理和加载细节全部封装了，中途出了问题很难排查，适合不想折腾的人。如果你是想理解部署原理或者做二次开发，还是推荐llama.cpp或vLLM。

4.2 选型决策建议

我给出一个比较直接的决策路径。第一，你的目的是自己平时聊天、写代码，机器只有一张8GB显卡，那首选llama.cpp，配合Q4_K_M量化，体验和速度最平衡。第二，你所在的团队要把模型部署成服务，有多个用户同时请求，且机器显存不低于16GB，那直接上vLLM，OpenAI兼容的接口让业务方接入成本很低。第三，你完全是新手，连基础知识都还没建立起来，那先用Ollama把模型跑通，建立感知后再折腾细粒度配置。

这里想多说一句，有些人在部署时会硬上transformers加bitsandbytes的4bit加载方式。这种方式做实验没问题，但生产环境里速度太慢，而且多进程并发时CPU和GPU的负载都很难控制。我自己用它做过快速验证，最终正式跑服务还是切到了vLLM。

5. 完整部署实操：llama.cpp和vLLM双方案演示

5.1 llama.cpp部署GLM的完整命令

llama.cpp的部署流程相对透明，适合个人使用。先从GitHub克隆代码仓库，然后编译：

git clone https://github.com/ggml-org/llama.cpp cd llama.cpp mkdir build && cd build cmake .. -DGGML_CUDA=ON cmake --build . --config Release -j $(nproc)

编译过程中需要注意几点。-DGGML_CUDA=ON是开启CUDA后端的关键，否则会编译成纯CPU版本，速度差距几十倍。另外，如果你用的是比较老的GPU，有些同学会因为Compute Capability过低导致运行时失败，编译时可以用-DGGML_CUDA_MMV_Y=2这类参数降低兼容性门槛，但这里面的具体参数依赖显卡架构，不确定的话先从默认参数开始。

编译完成后，直接用命令行方式测试：

./llama-cli -m ../glm-4-9b-chat-Q4_K_M.gguf -p "你好，请介绍一下你自己" -n 256 -ngl 99

-ngl 99表示把全部层都塞进GPU，如果显存不够，系统会提示“failed to allocate”，这时候可以改成-ngl 20加-ngl 25一档档往下试，配合--cpu参数把部分层放在CPU上计算。实测下来，8GB显存的卡跑Q4_K_M时，-ngl 32是一个比较合理的值，既能利用GPU加速，又不会爆显存。

如果要把模型做成HTTP服务，llama.cpp也带了一个server程序：

./llama-server -m ../glm-4-9b-chat-Q4_K_M.gguf -ngl 99 --host 0.0.0.0 --port 8080

启动后访问http://127.0.0.1:8080就能看到LlamaServer的Web界面，可以直接在浏览器里对话。默认的OpenAI兼容接口地址是http://127.0.0.1:8080/v1/chat/completions，这对接后端应用很方便。

5.2 vLLM部署GLM的完整命令

vLLM的部署更符合服务化场景。先安装：

pip install vllm

然后一条命令启动服务：

vllm serve zhipu/glm-4-9b-chat --tensor-parallel-size 1 --max-model-len 8192 --gpu-memory-utilization 0.85

我第一次启动vLLM时踩了一个不小的坑：GLM-4-9B-Chat在vLLM里需要指定--trust-remote-code参数才能正常加载模型的建模代码。如果你报错KeyError: 'chatglm'之类的信息，多半就是漏了这段代码信任声明。加了之后就能正常加载。完整的命令应该长这样：

vllm serve zhipu/glm-4-9b-chat --trust-remote-code --tensor-parallel-size 1 --max-model-len 8192 --gpu-memory-utilization 0.85

启动成功后，vLLM会打印类似INFO: Started server process的日志，默认监听0.0.0.0:8000端口，接口路径是/v1/chat/completions。它的接口和OpenAI官方接口完全兼容，这意味着你之前基于OpenAI SDK写的代码只需要改一下base_url，就能切换到本地模型。

5.3 接口验证与调用示例

不管用哪个引擎，启动服务后用curl验证一下接口是否正常是最快的方式。以vLLM为例：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "zhipu/glm-4-9b-chat", "messages": [{"role": "user", "content": "写一段Python快排代码"}], "max_tokens": 512, "temperature": 0.7 }'

返回的JSON里包含choices字段，里面就是模型生成的内容。常见的调用方式还有利用OpenAI SDK：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) resp = client.chat.completions.create( model="zhipu/glm-4-9b-chat", messages=[{"role": "user", "content": "用Python写一个冒泡排序"}], max_tokens=512 ) print(resp.choices[0].message.content)

如果你用的是llama.cpp的server，同样可以按这个方式接入，只是api_key随便填一个占位符就行。

6. 可视化前端与日常使用优化

6.1 接入Open WebUI

模型服务起来了，但直接用curl或者SDK聊天体验太原始。想有一个像ChatGPT那样的界面，推荐接入Open WebUI。它会提供一个独立的Web服务，然后把你的本地模型的API地址挂进去。安装方式很简单：

pip install open-webui open-webui serve

在Open WebUI的设置页面里，把“OpenAI API”的地址填成http://127.0.0.1:8000/v1，模型名称填zhipu/glm-4-9b-chat，刷新页面就能在聊天界面里选择了。Open WebUI还自带简单的用户管理、历史记录和知识库上传功能，比直接自己写前端省太多时间。

6.2 上下文长度与生成参数调优

生产环境中，上下文长度和生成参数需要针对你的任务做调整。GLM-4-9B-Chat官方的训练上限是128K上下文，但是本地部署时不要盲目把--max-model-len拉满。因为上下文长度线性影响KV Cache的显存占用，128K的上下文在8GB显存上直接会把显存耗尽。个人使用建议控制在8K到16K之间。

温度参数也是一个值得细调的地方。代码生成任务建议temperature=0.2，top_p=0.85，这样输出稳定、少犯低级错误。日常聊天可以temperature=0.8，top_p=0.95，回答会更有发散性。如果遇到模型重复输出同一个句子循环不停，可以把frequency_penalty设为0.5，效果立竿见影。

6.3 构建简单的私有知识库对话

GLM本身不具备持久记忆，每次对话是独立的，但可以借助外挂知识库的方式让它“看起来”记得你的资料。最简单的方法是把文档内容作为上下文的一部分，在调用接口前做检索拼接。实践中，我用langchain加faiss做过一个小型知识库，流程是三段式：先用嵌入模型把文档向量化存入向量数据库，每次请求时做相似度检索，把TopK结果拼到Prompt里，再调用GLM生成回答。

这个方案跑起来之后，效果还算可以，但有两个需要注意的卡点。第一，检索相关性直接决定回答质量，嵌入模型选型不能太弱，至少要大于10亿参数级别的嵌入模型。第二，上下文拼接会快速消耗token额度，如果文档很长，要控制检索返回的文本长度，通常TopK文档总字数控制在1500字以内比较合适。

7. 常见问题与排查技巧实录

7.1 显存不够的应急方案

我遇到过最多的问题是启动时报显存不足。如果你已经用了Q4_K_M量化，还是OOM，有几个应急路径可以尝试。一是调低-ngl参数，把部分层放CPU，比如从-ngl 99改成-ngl 30，配合几个CPU线程，仍然能跑，只是速度会稍慢。二是使用更低的量化档位，比如Q3_K_S，但生成质量会再掉一点。三是压缩KV Cache的显存占用，llama.cpp可以在启动时加上--cache-type-k q8_0 --cache-type-v q8_0，KV Cache用8bit存储，能节省大约2到3GB显存，实际效果对质量影响不明显，我试过这个方案救回了一台只有6GB显存的笔记本。

7.2 模型加载后输出乱码或崩溃

GLM-4-9B-Chat用的是自研的tokenizer，和绝大多数模型的tokenizer不一样，如果你在非支持的加载方式下直接加载权重，很容易出现乱码。典型表现是回复一串正常的汉字但语义完全错乱。这种情况通常是因为你使用了一个不太兼容的加载脚本，或者依赖版本太旧。解决方法是确保llama.cpp版本在最新的稳定版之后，或者使用vLLM时加上--trust-remote-code参数。还有一种情况是加载了错误的量化文件，GGUF文件不匹配导致词表错位，重新下载对应版本的GGUF文件即可修复。

7.3 推理速度慢的排查思路

速度慢第一反应是看GPU利用率。在服务运行时输入nvidia-smi，如果GPU-Util一直低于50%，而CPU占用很高，说明模型推理主要卡在CPU的数据搬运上，优化方向是调低-ngl参数或购买更高带宽的内存。如果GPU-Util一直在95%以上但生成速度依然只有三四个token每秒，说明GPU算力本身不够，这时候可以尝试更激进的量化方案，或者换用更小的模型。

另外，批处理场景下vLLM的并发优势非常明显。我把同一个GLM-4-9B-Chat分别用llama.cpp和vLLM跑了一组对比，llama.cpp在单请求场景下延迟很低，而vLLM在连续多个并发请求时吞吐量是llama.cpp的三到五倍。所以如果你的场景是多个用户同时请求，不要犹豫，上vLLM。

7.4 常见问题速查表

8. 部署过程中的个人经验与建议

如果让我总结整个GLM本地化部署过程中最重要的三件事：第一，先把硬件边界想清楚，不要上来就下载全精度模型，8GB显存强行上FP16是灾难；第二，量化格式和推理引擎的选择，决定了后续所有的用户体验差异；第三，接口层的兼容性设计，尽量采用OpenAI规范格式，这样后续切换云端还是本地、换模型还是换引擎，代价都很小。

我个人实际跑下来，最喜欢的组合是：8GB显卡加GLM-4-9B-Chat的Q4_K_M量化版，通过llama.cpp的llama-server提供服务，再挂一个Open WebUI前端。这套组合，冷启动延迟大概一秒多，生成速度在流畅和稳定之间取得了很好的平衡，日常使用完全够用。换到公司那台24GB显存的机器上，我直接用了vLLM加FP16全精度，性能提升非常明显，尤其是代码生成类任务，能明显感觉到回复更严谨、逻辑更连贯。最后一句话总结我的体会：本地部署大模型，真正难的不是敲那几行命令，而是搞清楚每一步操作背后涉及的资源约束和取舍逻辑，明白这个，你就能举一反三，部署任何开源模型都不再发怵。