GLM-4-9B-Chat本地部署全攻略：量化、推理引擎与API调用-北京尧图网络

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权重约5GB6GB显存的老卡也可以勉强跑但生成质量下降还是比较明显的说话会偶尔前言不搭后语。内存方面一条经验法则内存至少要有显存的两倍。因为模型加载、上下文拼接、CPU offload都要用到内存8GB显存方案建议内存16GB起步最好是32GB。CPU方面不用太焦虑大部分计算在GPU上CPU只负责数据搬运但要注意AVX2指令集支持2015年以后的主流CPU基本都没问题。2. 环境准备从零搭建推理基础2.1 操作系统和显卡驱动部署GLM并没有绑定某个特定操作系统。我在Ubuntu 22.04和Windows 11上分别跑通过但强烈建议有条件的人用LinuxNVIDIA驱动、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 python3.10 conda activate glm-envPython版本选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”排查了半天才发现是软链问题。如果走ModelScopemodelscope 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我做了一次量化档位对比实验数据大概如下量化档位文件大小显存占用相对全精度质量适用显卡FP16约18GB20GB以上100%24GB及以上Q8_0约9.8GB11GB左右98%12GBQ6_K约7.7GB9GB左右96%10GBQ4_K_M约6.1GB7.5GB左右92%8GBQ3_K_S约4.8GB6GB左右87%6GB这个表格可以当作一个参考基线。视觉上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还是transformers4.1 三款主流引擎对比部署大型语言模型推理引擎决定了你能跑多快、能并发多少、接口长什么样。目前在GLM-4-9B上我实际用下来比较顺的有三个选项llama.cpp、vLLM、Ollama。还有一个transformers原生加载的方式如果是快速体验可以试试但生产环境不建议因为它速度太慢还占显存。引擎优点缺点适合场景llama.cpp轻量、CPU可跑、量化支持好高并发能力弱、缺乏动态batching单人本地使用、低显存跑量化vLLM高吞吐、动态batching、兼容OpenAI API显存占用较高、配置略复杂多人服务、需要类OpenAI接口Ollama一键安装、上手最快自定义参数受限、debug困难快速体验、新手入门Ollama是这三者里门槛最低的装完以后直接ollama run zhipu/glm4:9b就能把自己下载好的模型跑起来。但说实话Ollama内部把模型处理和加载细节全部封装了中途出了问题很难排查适合不想折腾的人。如果你是想理解部署原理或者做二次开发还是推荐llama.cpp或vLLM。4.2 选型决策建议我给出一个比较直接的决策路径。第一你的目的是自己平时聊天、写代码机器只有一张8GB显卡那首选llama.cpp配合Q4_K_M量化体验和速度最平衡。第二你所在的团队要把模型部署成服务有多个用户同时请求且机器显存不低于16GB那直接上vLLMOpenAI兼容的接口让业务方接入成本很低。第三你完全是新手连基础知识都还没建立起来那先用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_CUDAON cmake --build . --config Release -j $(nproc)编译过程中需要注意几点。-DGGML_CUDAON是开启CUDA后端的关键否则会编译成纯CPU版本速度差距几十倍。另外如果你用的是比较老的GPU有些同学会因为Compute Capability过低导致运行时失败编译时可以用-DGGML_CUDA_MMV_Y2这类参数降低兼容性门槛但这里面的具体参数依赖显卡架构不确定的话先从默认参数开始。编译完成后直接用命令行方式测试./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 SDKfrom openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) resp client.chat.completions.create( modelzhipu/glm-4-9b-chat, messages[{role: user, content: 用Python写一个冒泡排序}], max_tokens512 ) 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之间。温度参数也是一个值得细调的地方。代码生成任务建议temperature0.2top_p0.85这样输出稳定、少犯低级错误。日常聊天可以temperature0.8top_p0.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_0KV 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 常见问题速查表现象原因解决方案加载时提示cuda out of memory显存不足以容纳模型权重和KV Cache降低量化档位、减少-ngl层数、压缩KV Cache精度生成内容全是乱码tokenizer加载错误或GGUF文件不匹配检查加载脚本、更新推理框架版本、重新下载GGUF文件启动服务后长时间没有响应模型首次加载需要时间或Python版本太旧等待初始化完成检查nvidia-smi确认GPU在运作API返回400错误请求格式不符合OpenAI规范检查messages字段格式确认model名称与启动时一致回答质量明显差于官方API量化损失过大或采样参数不合适采用更高量化档位调低温度参数并发请求时排队严重阻塞引擎不支持动态batching切换到vLLM开启--tensor-parallel-size下载模型总是中断网络不稳定使用ModelScope下载设断点续传8. 部署过程中的个人经验与建议如果让我总结整个GLM本地化部署过程中最重要的三件事第一先把硬件边界想清楚不要上来就下载全精度模型8GB显存强行上FP16是灾难第二量化格式和推理引擎的选择决定了后续所有的用户体验差异第三接口层的兼容性设计尽量采用OpenAI规范格式这样后续切换云端还是本地、换模型还是换引擎代价都很小。我个人实际跑下来最喜欢的组合是8GB显卡加GLM-4-9B-Chat的Q4_K_M量化版通过llama.cpp的llama-server提供服务再挂一个Open WebUI前端。这套组合冷启动延迟大概一秒多生成速度在流畅和稳定之间取得了很好的平衡日常使用完全够用。换到公司那台24GB显存的机器上我直接用了vLLM加FP16全精度性能提升非常明显尤其是代码生成类任务能明显感觉到回复更严谨、逻辑更连贯。最后一句话总结我的体会本地部署大模型真正难的不是敲那几行命令而是搞清楚每一步操作背后涉及的资源约束和取舍逻辑明白这个你就能举一反三部署任何开源模型都不再发怵。

GLM-4-9B-Chat本地部署全攻略：量化、推理引擎与API调用

相关推荐

Windows蓝屏STOP代码解析：从误判陷阱到根因定位

庖丁解牛Linux进程排查：ps aux按CPU排序的底层逻辑与实战

从零搭建语义搜索引擎：向量化、Faiss与精排实战

更多资讯

深入理解Linux Netlink：内核与用户态通信的协议与实战

TCP吞吐量上不去？抓包实测排查带宽跑不满的实战指南

Linux VM内核参数调优：内存管理、脏页回写与OOM实践

【跟踪】跟踪篇(4)--对于MOT16 Benchmark的理解

STM32F103与AT24C02的I2C读写实战：时序、硬件与调试避坑指南

YOLOv6工业视觉检测优化与部署实战：从能检出到敢上线

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？