ChatGLM-6B实战教程：日志查看与故障排查步骤
1. 为什么需要掌握日志与排查能力
你刚启动ChatGLM-6B服务，浏览器打开http://127.0.0.1:7860却显示“无法连接”；或者对话框里一直转圈、没反应；又或者输入问题后返回空白、报错信息一闪而过——这些都不是模型“不聪明”，而是服务运行过程中出现了可定位、可修复的问题。
很多新手会卡在这一步：模型明明装好了，Web界面也启动了，但就是用不了。其实，90%以上的使用障碍，根本不需要重装镜像、不用改代码、更不用调参数。只要学会看日志、懂几个关键命令、知道从哪下手查问题，5分钟内就能定位并解决。
这篇教程不讲模型原理，不堆技术术语，只聚焦一件事：当你遇到ChatGLM-6B用不了、反应慢、报错、崩溃时，下一步该敲什么命令、看哪行日志、怎么判断问题在哪、怎么快速恢复服务。所有操作都在终端里完成，每一步都有明确反馈，小白也能照着做成功。
2. 服务运行基础：理解Supervisor与日志机制
2.1 Supervisor不是“可有可无”的工具，而是你的服务管家
ChatGLM-6B镜像没有用python app.py这种裸跑方式，而是通过Supervisor来管理服务进程。这意味着：
- 它不是简单地“启动就完事”，而是持续监控进程是否存活；
- 如果程序意外退出（比如显存爆了、Python报错崩溃），Supervisor会在几秒内自动拉起新进程；
- 所有标准输出（print）、错误信息（traceback）、加载提示（如“Loading model…”）都会被统一捕获，写入到指定日志文件中。
所以，当你发现Web界面打不开，第一反应不该是“重装”，而应是：“Supervisor有没有把服务真正跑起来？它在日志里说了什么？”
2.2 日志文件在哪？它记录了什么？
镜像中所有关键运行信息都集中写入一个文件：
/var/log/chatglm-service.log这个文件不是临时缓存，也不是调试开关打开才有的——它是默认开启、持续追加、永不覆盖的“服务日记”。里面包含：
- 模型加载全过程（权重读取、分词器初始化、GPU显存分配）；
- 每次HTTP请求的进入与响应（含耗时、输入文本、生成结果）；
- 报错堆栈（如
CUDA out of memory、OSError: unable to load weights）； - Supervisor自身的状态变更（如“started process”，“process exited unexpectedly”）。
记住：只要服务动过，日志就有记录；只要报错发生，日志必留痕迹。
3. 四步故障排查法：从启动失败到响应异常
3.1 第一步：确认服务是否真的在运行
别急着开浏览器，先问自己：Supervisor说它在跑，它真的在跑吗？
执行这条命令：
supervisorctl status chatglm-service你会看到类似这样的输出：
chatglm-service RUNNING pid 1234, uptime 0:05:23正常状态关键词：RUNNING+ 有具体pid号 +uptime大于0
异常状态示例：
STARTING：还在加载，等30秒再查；STOPPED：服务被手动停了，或启动失败后没自动重试；FATAL：启动过程出致命错误，必须看日志；BACKOFF：反复启动失败，已放弃重试。
如果看到STOPPED或FATAL，直接跳到第3.3步查日志；如果是RUNNING但网页打不开，请继续往下看。
3.2 第二步：验证端口是否真正监听
RUNNING只代表Python进程活着，不代表它成功绑定了7860端口。常见陷阱是：Gradio启动时端口被占、权限不足、或配置写错。
执行这行命令，检查7860端口是否被占用且由正确进程监听：
netstat -tuln | grep :7860正常应看到类似：
tcp6 0 0 :::7860 :::* LISTEN 1234/python关键点：LISTEN状态 + 进程名是python（不是node、nginx或其他）
常见异常：
- 无任何输出 → Gradio根本没监听端口（大概率启动失败，回看日志）；
- 显示
:::7860但进程是1234/nginx→ 端口被Nginx占了，需先停Nginx； - 显示
127.0.0.1:7860而非:::7860→ Gradio只监听本地回环，SSH隧道能通，但其他机器连不上（本教程场景下不影响）。
小技巧：如果
netstat命令不存在，可用ss -tuln | grep :7860替代，效果一致。
3.3 第三步：实时追踪日志，抓住第一手线索
这是最核心的排查动作。不要等出问题再翻日志，养成启动后立刻盯住日志的习惯：
tail -f /var/log/chatglm-service.log这个命令会持续滚动输出最新日志。此时你可以：
- 在另一终端执行
supervisorctl restart chatglm-service，观察日志里是否出现“Loading model…”、“Launching Gradio app…”； - 在浏览器访问
http://127.0.0.1:7860，看日志里是否打印GET /、POST /run及后续响应； - 输入一个问题并发送，看日志里是否出现
input: "你好"、output: "你好！我是ChatGLM..."，或突然中断、报错。
重点识别三类日志信号：
| 类型 | 典型内容 | 说明 |
|---|---|---|
| 加载成功信号 | Model loaded successfully,Gradio app launched on http://0.0.0.0:7860 | 服务已就绪，可正常使用 |
| 内存不足信号 | CUDA out of memory,torch.cuda.OutOfMemoryError | GPU显存不够，需降低batch_size或关闭其他进程 |
| 路径/权限错误 | FileNotFoundError: model_weights/...,Permission denied: /var/log/... | 模型文件缺失或日志目录无写入权限 |
注意：
tail -f不会自动退出，按Ctrl+C可中止跟踪。
3.4 第四步：针对性重启与清理缓存
有时候问题不是出在代码或模型，而是临时状态错乱：比如上次崩溃残留的锁文件、Gradio缓存损坏、或Supervisor内部状态不同步。
这时不要暴力重装，试试这两个轻量操作：
① 强制清除Gradio缓存（解决界面白屏、按钮失灵）
rm -rf /root/.cache/gradio/ supervisorctl restart chatglm-service② 重置Supervisor状态（解决BACKOFF卡死、FATAL不重试）
supervisorctl reread supervisorctl update supervisorctl restart chatglm-service这两套组合拳覆盖了80%的“莫名奇妙无法使用”场景，比重装镜像快10倍，且不丢失任何配置。
4. 高频问题速查表：症状→原因→解法
| 症状 | 可能原因 | 快速验证命令 | 解决方案 |
|---|---|---|---|
supervisorctl status显示FATAL | 模型权重文件损坏或路径错误 | ls -l /ChatGLM-Service/model_weights/ | 检查目录是否存在、是否有.bin或.safetensors文件；若为空，联系镜像提供方重新部署 |
日志里反复出现CUDA out of memory | GPU显存被其他进程占用 | nvidia-smi | kill -9 <PID>杀掉无关进程；或在app.py中添加--device-map auto参数（需修改启动脚本） |
浏览器打开空白页，日志无任何GET记录 | Gradio未监听公网/回环地址 | grep "launching" /var/log/chatglm-service.log | 查看日志中Gradio启动行，确认是否含server_name=0.0.0.0；若为127.0.0.1，需改app.py中launch(..., server_name="0.0.0.0") |
输入问题后长时间无响应，日志卡在input: | 模型加载完成但推理卡住 | nvidia-smi观察GPU利用率 | 若GPU利用率为0%，说明推理线程阻塞，尝试重启服务；若持续100%，说明显存满载，需减少max_length参数 |
SSH隧道连上后，浏览器提示ERR_CONNECTION_REFUSED | 本地7860端口被占用 | lsof -i :7860（Mac/Linux）或netstat -ano | findstr :7860（Windows） | 杀掉占用进程，或换端口映射：ssh -L 8888:127.0.0.1:7860 ...，然后访问http://127.0.0.1:8888 |
提示：所有解决方案都无需修改模型权重、不涉及CUDA编译、不依赖外部网络——全部基于镜像内置能力，开箱即用。
5. 日志进阶技巧：过滤关键信息，提升排查效率
面对几千行日志，逐行翻找效率极低。学会用grep精准定位，能将排查时间从10分钟压缩到30秒。
5.1 快速定位错误（Error/Exception）
grep -i "error\|exception\|traceback" /var/log/chatglm-service.log | tail -n 20这条命令会提取最近20条含错误关键词的日志，直击问题根源。
5.2 查看模型加载耗时（判断是否卡在权重加载）
grep -A 5 "Loading model" /var/log/chatglm-service.log-A 5表示匹配行及之后5行，可看到从开始加载到完成的完整过程，判断是否因网络或磁盘慢导致超时。
5.3 监控实时请求（确认服务是否真在响应）
tail -f /var/log/chatglm-service.log | grep "POST /run"当你在Web界面点击“提交”，这条命令会立即输出类似：
INFO: 127.0.0.1:56789 - "POST /run HTTP/1.1" 200 OK有这条记录，说明请求已抵达服务端；若无，则问题出在前端、网络或反向代理层。
6. 总结：建立属于你的故障响应清单
你不需要记住所有命令，但值得把这五件事变成肌肉记忆：
- 每次启动后，第一件事是
supervisorctl status—— 确认服务状态，不盲目开网页； - 只要界面异常，立刻
tail -f /var/log/chatglm-service.log—— 日志是唯一真相来源； - 看到报错，复制关键词（如
CUDA out of memory）直接搜索—— 同类问题已有成熟解法； - 重启前先清Gradio缓存—— 解决80%的前端交互异常；
- 善用
grep过滤日志—— 把大海捞针变成定点爆破。
ChatGLM-6B不是黑盒，它每一行日志都在说话。你只需要学会听——而这篇教程，就是帮你听懂的第一本“翻译手册”。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
