ChatGLM-6B部署教程：GPU显存监控（nvidia-smi）与推理吞吐量测算

1. 为什么需要关注显存与吞吐量

当你第一次启动ChatGLM-6B服务，看到Gradio界面弹出来、输入“你好”就立刻收到回复时，可能会觉得——这不就是点个按钮的事吗？但如果你打算把它用在真实场景里，比如接入客服系统、批量处理用户提问，或者和多个模型并行运行，那光“能跑”远远不够。

真正决定它能不能长期稳定干活的，是两个看不见却至关重要的指标：GPU显存占用和推理吞吐量。
前者决定了你能不能同时加载更多模型、能不能在有限显卡上多开几个实例；后者决定了每秒能处理多少条用户请求，直接影响响应延迟和并发能力。

很多新手在部署后只测了一次“能对话”，就以为万事大吉，结果上线一小时后服务突然卡死——查日志没报错，重启又好了，过一会儿又挂。最后发现，是显存悄悄涨到了98%，PyTorch触发OOM（内存溢出）自动杀掉了进程。而吞吐量呢？有人测出单次推理要3秒，结果一算才发现：按这个速度，10个并发请求就得排队等半分钟。

这篇教程不讲怎么下载权重、不重复官方安装步骤，而是聚焦你真正需要动手验证的两件事：
怎么实时盯住GPU显存，一眼看出资源是否吃紧
怎么科学测算真实吞吐量，不是“感觉快”，而是“每秒处理X条”

全程基于你手头已有的CSDN镜像环境，命令即拷即用，结果可复现。

2. 显存监控：不只是看个数字，要看懂它在说什么

2.1 用 nvidia-smi 看清显存真实状态

CSDN镜像默认已安装CUDA 12.4和配套驱动，所以你不需要额外装任何工具。打开终端，直接执行：

nvidia-smi

你会看到类似这样的输出（为便于理解，我们拆解关键字段）：

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 535.129.03   Driver Version: 535.129.03   CUDA Version: 12.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  NVIDIA A10            On | 00000000:00:1E.0 Off |                    0 |
| 35%   52C    P0    62W / 150W |   5824MiB / 23028MiB |     12%      Default |
+-------------------------------+----------------------+----------------------+

重点看三行：

• Memory-Usage：5824MiB / 23028MiB —— 当前用了5.8GB，总显存23GB。这是最直观的“水位线”。
• GPU-Util：12% —— GPU计算单元利用率，低≠空闲，可能只是当前没在做密集计算。
• Pwr:Usage/Cap：62W / 150W —— 功耗，间接反映负载强度，长期高功耗可能伴随温度升高。

注意：nvidia-smi 默认每2秒刷新一次。如果想持续观察变化，加 -l 1 参数（每1秒刷新）：

nvidia-smi -l 1

按 Ctrl+C 可随时退出。

2.2 启动服务前后对比：识别“隐性显存增长”

很多人忽略一个关键点：模型加载完成 ≠ 显存稳定。PyTorch会在首次推理时做图优化、缓存kernel，导致显存“悄悄上涨”。

我们来实测一下：

第一步：服务未启动时，记录基线

nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits
# 输出示例：520

记下这个数字（单位是MiB），比如是520MiB。

第二步：启动ChatGLM服务

supervisorctl start chatglm-service

等待10秒，让模型完成初始化。

第三步：再次查看显存

nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits
# 输出示例：6240

这次是6240MiB。那么模型实际占用 ≈ 6240 − 520 = 5720MiB（约5.6GB）。

这个差值，才是ChatGLM-6B真正“驻留”的显存开销。它比官方文档写的“约6GB”更真实——因为包含了Python进程、Gradio前端、Supervisor守护进程的额外开销。

2.3 长期运行中如何防“显存泄漏”

你可能会遇到：服务跑了半天，显存从5.6GB慢慢涨到7GB、8GB，最后OOM崩溃。这不是模型本身的问题，而是WebUI交互中反复加载/卸载张量、缓存未清理导致的。

CSDN镜像已内置防护机制，但你可以主动验证：

• 持续运行 nvidia-smi -l 5（每5秒刷新）
• 在Gradio界面连续发起20轮不同长度的对话（比如从“你好”到一段200字的作文请求）
• 观察显存是否在每次对话后回落到接近初始值（±100MiB内）

如果显存阶梯式上升、不回落，说明存在泄漏风险。此时建议：

• 重启服务：supervisorctl restart chatglm-service
• 或启用轻量模式：编辑 /ChatGLM-Service/app.py，将 device_map="auto" 改为 device_map={"": "cuda:0"}，强制所有层绑定到单卡，减少跨设备调度开销。

3. 吞吐量测算：拒绝“拍脑袋”，用数据说话

3.1 吞吐量到底指什么？

别被术语吓到。这里说的吞吐量（Throughput），就是：
1秒钟内，你的ChatGLM-6B服务能完整处理多少条用户请求？
注意是“完整处理”——从收到输入、生成回答、返回结果，整个链路。

它和“单次响应时间”不同：

• 响应时间短（比如1.2秒），但只能串行处理，吞吐量仍是1 QPS（Queries Per Second）；
• 响应时间稍长（比如1.8秒），但支持并发5路，吞吐量就能到2.7 QPS。

CSDN镜像默认使用Gradio的queue=True，已开启请求队列，天然支持并发。我们要测的，就是它在真实负载下的极限吞吐。

3.2 用 curl + time 做轻量级压测（无需额外工具）

你不需要装ab、locust或JMeter。Linux自带的curl和time就能给出可靠结果。

准备一个标准测试请求体（保存为 test_input.json）：

{
  "prompt": "请用一句话解释量子计算的基本原理。",
  "history": [],
  "temperature": 0.7,
  "max_length": 512
}

执行单次请求并计时：

time curl -X POST "http://127.0.0.1:7860/api/predict/" \
  -H "Content-Type: application/json" \
  -d @test_input.json

你会看到类似输出：

{"result":"量子计算利用量子比特的叠加和纠缠特性..."}
real	0m1.423s
user	0m0.008s
sys	0m0.004s

这里的 real 0m1.423s 就是端到端耗时（1.423秒）。记下这个数字。

但单次不准！必须测多次取平均。

执行10次，并统计总耗时：

for i in {1..10}; do
  curl -s -X POST "http://127.0.0.1:7860/api/predict/" \
    -H "Content-Type: application/json" \
    -d @test_input.json > /dev/null
done 2>&1 | tail -n 1

更推荐用这个一行命令直接算出平均响应时间（单位：秒）：

(echo "scale=3"; for i in {1..10}; do time -p curl -s -X POST "http://127.0.0.1:7860/api/predict/" -H "Content-Type: application/json" -d @test_input.json > /dev/null 2>&1 | grep real | awk '{print $2}'; done) | bc -l | tail -n 1

假设结果是 1.482 秒，那么理论最大吞吐量 ≈ 1 / 1.482 ≈ 0.67 QPS（即每秒最多处理0.67条请求）。

但这只是串行情况。真实价值在于并发。

3.3 并发吞吐量实测：模拟10个用户同时提问

我们用parallel命令（如未安装，apt install parallel）发起10个并发请求：

# 安装（如需）
apt update && apt install -y parallel

# 发起10个并发请求，每个请求间隔0.1秒启动，避免瞬间洪峰
seq 10 | parallel -j 10 'curl -s -X POST "http://127.0.0.1:7860/api/predict/" -H "Content-Type: application/json" -d @test_input.json > /dev/null'

# 查看总耗时（从第一个请求发出到最后一个返回）
time (seq 10 | parallel -j 10 'curl -s -X POST "http://127.0.0.1:7860/api/predict/" -H "Content-Type: application/json" -d @test_input.json > /dev/null')

假设总耗时是 3.25 秒，那么：
实际并发吞吐量 = 10条请求 / 3.25秒 ≈ 3.08 QPS
平均响应时间 = 总耗时 / 并发数 = 3.25 / 10 = 0.325秒（注意：这是客户端视角的平均，服务端实际处理时间仍约1.4秒，队列分摊了等待）

这个3.08 QPS，才是你在生产中能稳定支撑的吞吐能力。

3.4 影响吞吐的关键变量与调优建议

你可能发现：同样配置，别人测出4 QPS，你只有2.5。别急，吞吐不是固定值，它受三个变量强影响：

变量	如何影响吞吐	CSDN镜像中可调整位置	建议值
max_length	输出越长，推理时间越久，吞吐越低	app.py 中 model.generate(..., max_length=...)	日常对话设为256–384；长文本摘要可提至512，但吞吐下降30%+
temperature	温度越高，采样越随机，解码步数可能增加	Gradio界面上滑块，或API参数	0.7–0.8平衡质量与速度；创意生成可提至0.95，但吞吐降15%
batch_size	当前镜像未启用批处理，单请求单处理	需修改app.py集成transformers.pipeline批处理逻辑	进阶：启用后吞吐可提升2–3倍，但需重写API接口

实操小贴士：

• 如果你只需要快速问答（如客服FAQ），把max_length从默认512降到128，吞吐能提升近一倍；
• 如果发现并发时显存暴涨（比如从5.6GB冲到9GB），说明Gradio队列缓存了太多中间张量，可在app.py中添加torch.cuda.empty_cache()在每次响应后调用。

4. 综合诊断：一张表看清你的服务健康度

光看显存或吞吐都不全面。我们整合两者，建立一个日常巡检表。每天上线前花1分钟执行，就能预判风险：

检查项	命令	健康阈值	风险信号	应对动作
基础显存占用	nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits	≤ 6500 MiB	> 7500 MiB	检查是否有其他进程占显存；重启服务
GPU利用率	nvidia-smi --query-gpu=utilization.gpu --format=csv,noheader,nounits	10%–40%（空闲） 40%–80%（正常负载）	持续>90%	检查是否在做长文本生成；降低max_length
单次响应时间	time curl ...（10次平均）	≤ 1.8 s	> 2.5 s	检查磁盘IO（iostat -x 1）；确认未被其他进程抢占CPU
并发吞吐量	parallel -j 10 ... 测10请求总耗时	≥ 2.5 QPS	< 1.5 QPS	检查网络延迟（ping 127.0.0.1）；确认Gradio未启auth增加开销

把这个表打印出来，贴在显示器边——它比任何监控图表都管用。

5. 总结：让ChatGLM-6B真正为你所用

部署一个大模型，从来不是“启动成功”就结束了。它像一辆刚提的新车：

• nvidia-smi 是你的油表和水温表，告诉你发动机是不是在安全区间运转；
• 吞吐量测试是路试，告诉你这车满载时最高能跑多快、过弯稳不稳。

在这篇教程里，你掌握了：
🔹 不依赖第三方工具，用原生命令精准抓取GPU显存真实占用；
🔹 区分“单次响应时间”和“并发吞吐量”，明白为什么后者才是业务指标；
🔹 用curl + parallel完成轻量但可靠的压测，数据可复现、结论可验证；
🔹 识别三个关键调优变量（max_length、temperature、batch_size），知道改哪里、为什么改；
🔹 一张5分钟巡检表，把模糊的“服务好像变慢了”变成明确的“显存超限，需重启”。

这些能力不会写在模型文档里，却是你把ChatGLM-6B从玩具变成生产力工具的关键一步。

下一步，你可以尝试：
→ 把吞吐测试脚本封装成定时任务，每小时自动运行并邮件告警；
→ 在app.py里加入psutil监控CPU和内存，构建全栈健康看板；
→ 对接Prometheus+Grafana，把nvidia-smi数据可视化。

真正的工程落地，永远始于对资源的敬畏和对数据的诚实。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。