百川2-13B-Chat WebUI v1.0 故障排查手册：网页打不开、响应慢、中断不完整等6大问题解决

优质文章学习记录

— 16 min read

百川2-13B-Chat WebUI v1.0 故障排查手册：网页打不开、响应慢、中断不完整等6大问题解决

你是不是也遇到过这种情况：兴致勃勃地部署好了百川2-13B-Chat WebUI，准备大展身手，结果浏览器一打开——网页死活打不开。或者好不容易进去了，问个问题等半天没反应，好不容易有反应了，回答到一半又断了。

别急，这些问题我都遇到过。今天我就把自己踩过的坑和解决方法整理出来，帮你快速定位和解决百川2-13B-Chat WebUI v1.0的常见问题。无论你是刚部署完的新手，还是用了一段时间遇到突发状况，这份手册都能帮到你。

1. 问题一：网页打不开，显示“无法访问此网站”

这是最常见的问题，通常有几种可能的原因。咱们一步步来排查。

1.1 检查服务是否真的在运行

首先，打开终端，运行状态检查脚本：

/root/baichuan2-13b-webui/check.sh

你会看到类似这样的输出：

╔══════════════════════════════════════════════════════════════╗ ║ 百川2-13B-Chat WebUI 状态检查 ║ ╚══════════════════════════════════════════════════════════════╝ 【服务状态】 ❌ 未运行 baichuan-webui STOPPED Not started 【端口监听】 ❌ 7860 端口未监听 【GPU 状态】 型号: NVIDIA GeForce RTX 4090 D 显存: 500 MiB / 24576 MiB (2.0%) 利用率: 0% 【WebUI 访问】 ❌ 不可访问 URL: http://0.0.0.0:7860 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ❌ 发现问题：服务未运行！ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

如果看到“服务未运行”，那就简单了，启动它：

supervisorctl start baichuan-webui

等个10-20秒，再运行一次检查脚本，应该就能看到“运行中”了。

1.2 检查端口是否被占用

有时候服务启动了，但端口被其他程序占用了。检查一下：

netstat -tulpn | grep 7860

如果看到类似这样的输出：

tcp 0 0 0.0.0.0:7860 0.0.0.0:* LISTEN 12345/python

说明端口正常监听。如果什么都没输出，或者输出显示的是其他进程，那可能就是端口问题。

解决方法：

重新启动服务：

supervisorctl start baichuan-webui

检查并杀掉占用7860端口的进程：

# 查看哪个进程占用了7860端口 sudo lsof -i :7860 # 如果确实有其他进程占用，杀掉它（注意：确认不是重要服务） sudo kill -9 <进程ID>

先停止服务：

supervisorctl stop baichuan-webui

1.3 检查防火墙设置

如果你的服务器有防火墙，可能需要开放7860端口：

# 对于Ubuntu/Debian系统（使用ufw） sudo ufw allow 7860 sudo ufw reload # 对于CentOS/RHEL系统（使用firewalld） sudo firewall-cmd --permanent --add-port=7860/tcp sudo firewall-cmd --reload # 临时开放端口（测试用） sudo iptables -I INPUT -p tcp --dport 7860 -j ACCEPT

1.4 检查浏览器缓存和代理

有时候问题不在服务器，而在你的浏览器：

  1. 清除浏览器缓存：按Ctrl+Shift+Delete（Windows/Linux）或Cmd+Shift+Delete（Mac）
  2. 禁用浏览器扩展：特别是广告拦截器、安全插件等
  3. 检查代理设置：确保没有设置代理或代理配置正确
  4. 尝试无痕模式：用浏览器的无痕/隐私模式访问

1.5 检查IP地址是否正确

如果你在远程服务器上部署，确保你访问的是正确的IP地址：

# 查看服务器的IP地址 ip addr show # 或 hostname -I

然后在浏览器中输入：http://你的服务器IP:7860

注意：如果你在云服务器上，还需要检查安全组规则是否允许7860端口入站。

2. 问题二：响应速度慢，等半天才有回复

这个问题最让人着急，明明看到GPU在跑，就是不出结果。原因可能有好几种。

2.1 首次加载需要时间

重要提醒：第一次启动服务或长时间未使用后，模型需要重新加载到GPU显存中，这个过程大约需要30-60秒。

怎么判断是不是首次加载？

  • 查看GPU显存占用：如果显存占用很低（比如只有2-3GB），说明模型还没加载
  • 查看日志：模型加载时会有明显的日志输出
# 查看服务日志，看模型加载进度 tail -f /root/baichuan2-13b-webui/logs/error.log

正常加载过程你会看到类似这样的日志：

Loading model from /root/models/baichuan2-13b-chat-4bits... Loading tokenizer... Loading model weights... Model loaded successfully! Time: 32.5s

耐心等待：首次加载完成后，后续的响应就会快很多（通常1-3秒）。

2.2 GPU被其他任务占用

检查一下是不是有其他程序在占用GPU：

nvidia-smi

正常情况应该只看到baichuan-webui相关的进程：

+-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | 0 N/A N/A 12345 C .../python baichuan-webui 21000MiB | +-----------------------------------------------------------------------------+

如果看到其他进程占用了大量显存，比如：

  • python 训练脚本
  • jupyter 笔记本
  • 其他AI服务

你可能需要：

  1. 停止不必要的GPU进程
  2. 或者重启服务器释放显存

2.3 参数设置不合理导致速度慢

检查你的生成参数，特别是这两个：

  1. Max Tokens（最大生成长度）设置过大建议：日常使用设为512，需要长回答时再临时调高。
    • 默认512就够用了
    • 如果设为2048，生成时间会显著增加
  2. Temperature（温度）设置过低建议：日常对话设为0.7，需要稳定输出（如代码生成）时再调低。
    • 温度越低，模型越“谨慎”，生成速度可能稍慢
    • 温度0.1-0.3时，模型会反复计算最优选择

2.4 服务器资源不足

虽然百川2-13B-4bits版本对显存要求不高（约10GB），但如果服务器整体资源紧张，也会影响速度：

# 检查CPU使用率 top # 检查内存使用 free -h # 检查磁盘IO iostat -x 1

如果发现：

  • CPU使用率持续90%以上
  • 内存使用率超过80%
  • 磁盘IO等待时间高

可能需要：

  1. 关闭其他不必要的服务
  2. 增加服务器配置
  3. 优化系统参数

2.5 网络延迟问题

如果你从远程访问，网络延迟也会影响体验：

# 测试到服务器的网络延迟 ping 你的服务器IP # 测试端口连通性 telnet 你的服务器IP 7860 # 或 nc -zv 你的服务器IP 7860

如果延迟高（>100ms）或丢包，考虑：

  1. 使用离你更近的服务器节点
  2. 优化网络路由
  3. 本地部署（如果条件允许）

3. 问题三：回复中断或不完整

这个问题很常见，明明问题还没回答完，模型就停住了。通常有以下几个原因。

3.1 Max Tokens设置太小

这是最常见的原因。Max Tokens限制了模型一次生成的最大长度。

举个例子：

  • 你问：“请详细解释机器学习的工作原理”
  • Max Tokens设为256
  • 模型生成了250个token后，还剩6个token的空间，但完整的回答需要500个token
  • 结果：回答在中间被截断了

解决方法：

  1. 增加Max Tokens值（如从512改为1024或2048）
  2. 或者让模型继续生成：
用户：请继续写完上面的回答。

3.2 模型遇到停止标记

大语言模型有预设的停止标记（如<|endoftext|>、\n\n等），遇到这些标记就会停止生成。

有时候模型可能误判，提前停止了。

解决方法：

或者使用继续指令：

继续。 
请接着上面的话说完。

在提问时明确要求：

请完整回答，不要中途停止。

3.3 显存不足导致中断

虽然4bits量化版本显存占用较低，但如果同时运行其他任务，也可能出现显存不足：

# 检查显存使用情况 nvidia-smi

如果显存使用接近100%，模型可能会中断生成。

解决方法：

  1. 减少同时运行的AI任务
  2. 如果经常出现，考虑升级GPU

重启服务释放显存：

supervisorctl restart baichuan-webui

3.4 请求超时

如果生成时间过长，可能会触发超时设置：

# 查看服务超时设置 cat /root/baichuan2-13b-webui/config.py | grep timeout

默认超时时间：通常是30-60秒

如果生成复杂回答超过这个时间，连接可能会断开。

解决方法：

  1. 对于复杂问题，拆分成多个小问题
  2. 或者调整服务配置（需要修改代码）

4. 问题四：GPU内存不足或OOM（内存溢出）

虽然百川2-13B-4bits版本只需要约10GB显存，但在某些情况下还是可能遇到内存问题。

4.1 检查当前显存使用

nvidia-smi

正常情况：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 535.161.07 Driver Version: 535.161.07 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. | | | | MIG M. | |===============================+======================+======================| | 0 NVIDIA RTX 4090 D Off| 00000000:01:00.0 Off | Off | | 0% 45C P8 30W / 450W| 10500MiB / 24576MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+

如果看到显存使用接近24GB（或你的GPU最大显存），说明可能有问题。

4.2 常见的内存问题场景

场景1：模型加载失败

错误信息：CUDA out of memory. Tried to allocate...

原因：可能有其他进程占用了显存。

解决步骤：

重启百川服务：

supervisorctl restart baichuan-webui

停止不必要的进程：

# 找到占用显存的进程ID nvidia-smi # 停止进程（谨慎操作，确认不是重要服务） kill -9 <进程ID>

查看所有GPU进程：

fuser -v /dev/nvidia*

场景2：对话历史过长 每次对话，模型都会将历史记录保存在内存中。如果对话轮次太多，可能积累大量token。

解决方法：

  1. 定期点击“新建对话”或“清除历史”

或者在提问时说明：

（请忽略之前的对话，重新开始） 我的问题是：...

场景3：批量处理时内存不足 如果你尝试同时处理多个请求，或者输入文本过长。

解决方法：

  1. 减少单次输入的文本长度
  2. 逐个处理，不要并发
  3. 使用流式输出（如果支持）

4.3 预防内存问题的建议

  1. 设置使用限制（如果支持）： 在服务配置中限制最大显存使用。
  2. 使用内存优化技巧：
    • 及时清理对话历史
    • 避免过长的单次输入
    • 对于长文档，分段处理

定期重启服务：

# 每天凌晨自动重启（通过crontab） 0 3 * * * supervisorctl restart baichuan-webui

监控显存使用：

# 实时监控GPU状态 watch -n 1 nvidia-smi

5. 问题五：服务自动停止或频繁重启

有时候服务运行着运行着就自己停了，或者频繁重启。

5.1 检查服务状态和日志

# 查看服务状态 supervisorctl status baichuan-webui # 查看详细日志 tail -100 /root/baichuan2-13b-webui/logs/error.log

常见错误信息：

错误1：端口冲突

Error: [Errno 98] Address already in use

解决：修改服务端口或杀掉占用进程。

错误2：模型文件损坏

Error loading model weights: File corrupted

解决：重新下载模型文件。

错误3：CUDA错误

CUDA error: out of memory CUDA error: illegal memory access

解决：重启服务，检查GPU状态。

5.2 Supervisor配置问题

Supervisor是管理服务的工具，配置不当可能导致问题：

# 检查Supervisor配置 cat /etc/supervisor/conf.d/baichuan-webui.conf

关键配置项：

[program:baichuan-webui] command=python app.py # 启动命令 directory=/root/baichuan2-13b-webui # 工作目录 autostart=true # 是否自动启动 autorestart=true # 是否自动重启 startretries=3 # 启动重试次数 stderr_logfile=/root/baichuan2-13b-webui/logs/error.log # 错误日志 stdout_logfile=/root/baichuan2-13b-webui/logs/access.log # 访问日志

常见问题：

  1. autorestart=true但startretries太小 → 失败几次后就放弃了
  2. 日志文件权限问题 → 无法写入日志导致失败
  3. 内存限制设置过小 → 进程被系统杀死

5.3 系统资源限制

检查系统资源限制：

# 查看进程限制 cat /proc/$(pgrep -f baichuan-webui)/limits # 查看系统日志（可能记录OOM killer） dmesg | tail -50

如果看到Out of memory: Killed process，说明系统内存不足，触发了OOM Killer。

解决方法：

  1. 增加服务器内存
  2. 调整OOM Killer参数（谨慎操作）
  3. 限制服务内存使用

5.4 定期维护建议

为了避免服务意外停止，建议：

定期重启释放资源：

# 每周重启一次 0 4 * * 0 supervisorctl restart baichuan-webui

设置监控告警：

# 简单的监控脚本 #!/bin/bash STATUS=$(supervisorctl status baichuan-webui | awk '{print $2}') if [ "$STATUS" != "RUNNING" ]; then echo "百川服务异常！状态：$STATUS" # 可以发送邮件或微信通知 supervisorctl restart baichuan-webui fi

定期检查日志：

# 每天检查一次错误日志 grep -i error /root/baichuan2-13b-webui/logs/error.log | tail -20

6. 问题六：回答质量下降或输出乱码

有时候服务运行正常，但回答质量明显下降，或者出现乱码。

6.1 模型加载不完整

如果模型文件没有完全加载，或者加载过程中出错，可能导致模型性能下降。

检查方法：

检查模型文件完整性：

# 检查模型文件大小 du -sh /root/models/baichuan2-13b-chat-4bits/ # 应该有几个GB的大小 # 如果大小异常，可能需要重新下载

查看模型加载日志：

grep -A5 -B5 "Loading model" /root/baichuan2-13b-webui/logs/error.log

解决方法：

  1. 重启服务，观察加载过程

如果怀疑模型文件损坏，重新下载：

# 备份原有模型 mv /root/models/baichuan2-13b-chat-4bits /root/models/baichuan2-13b-chat-4bits.backup # 重新下载（根据实际下载命令） # 这里需要根据你的实际下载方式调整

6.2 参数设置不当

生成参数对回答质量影响很大：

Temperature（温度）问题：

  • 温度太高（>1.5）：回答可能随机、混乱
  • 温度太低（<0.1）：回答可能重复、缺乏创意

Top-p（核采样）问题：

  • Top-p太低（<0.5）：回答可能过于保守、重复
  • Top-p太高（=1.0）：可能包含不合适的内容

推荐设置：

  • 日常对话：Temperature=0.7, Top-p=0.9
  • 创意写作：Temperature=1.0-1.2, Top-p=0.95
  • 代码生成：Temperature=0.2-0.3, Top-p=0.8

6.3 提示词（Prompt）问题

同样的模型，不同的提问方式，得到的结果可能天差地别。

不好的提问方式：

写代码 
翻译 
解释一下

好的提问方式：

请用Python写一个快速排序算法，要求： 1. 包含详细的注释说明每一步 2. 包含3个测试用例 3. 分析时间复杂度和空间复杂度 
请将以下英文技术文档翻译成中文，要求： 1. 专业术语翻译准确 2. 保持技术文档的严谨性 3. 语句通顺符合中文表达习惯 [英文文档内容] 
请用通俗易懂的方式解释什么是神经网络，要求： 1. 用生活中的例子类比 2. 避免使用复杂数学公式 3. 说明核心思想和工作原理

6.4 编码问题导致乱码

如果出现乱码，可能是编码问题：

检查编码设置：

# 查看系统编码 echo $LANG # 查看Python编码 python -c "import locale; print(locale.getpreferredencoding())"

解决方法：

  1. 确保输入文本是UTF-8编码

在服务启动脚本中添加编码设置：

import locale locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')

设置正确的编码环境变量：

export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8

6.5 对话历史污染

如果之前的对话中包含错误信息或混乱内容，可能影响后续回答。

解决方法：

  1. 点击“新建对话”开始新的对话
  2. 或者手动清除对话历史

在提问时明确要求：

（请忽略之前的所有对话，重新开始） 我的问题是：...

7. 总结：快速排查流程图

遇到问题时，可以按照这个流程图快速定位：

网页打不开？ ├─ 服务是否运行？ → 否 → 启动服务 │ 是 ├─ 端口是否监听？ → 否 → 检查端口占用 │ 是 ├─ 防火墙是否阻挡？ → 是 → 开放端口 │ 否 └─ 浏览器/网络问题？ → 是 → 清除缓存/检查网络 
响应速度慢？ ├─ 是否是首次加载？ → 是 → 等待30-60秒 │ 否 ├─ GPU是否被占用？ → 是 → 停止其他任务 │ 否 ├─ 参数设置是否合理？ → 否 → 调整参数 │ 是 └─ 服务器资源是否充足？ → 否 → 优化/升级 
回复中断？ ├─ Max Tokens是否太小？ → 是 → 增大设置 │ 否 ├─ 是否遇到停止标记？ → 是 → 使用继续指令 │ 否 ├─ 显存是否不足？ → 是 → 重启服务/清理历史 │ 否 └─ 是否请求超时？ → 是 → 拆分问题/调整配置 
内存不足？ ├─ 检查当前显存使用 → 接近100% → 重启服务 │ 正常 ├─ 是否有其他进程？ → 是 → 停止不必要进程 │ 否 ├─ 对话历史是否过长？ → 是 → 清理历史 │ 否 └─ 是否批量处理？ → 是 → 改为逐个处理

记住几个关键命令，大部分问题都能快速解决：

  1. 检查状态：/root/baichuan2-13b-webui/check.sh
  2. 查看日志：tail -f /root/baichuan2-13b-webui/logs/error.log
  3. 重启服务：supervisorctl restart baichuan-webui
  4. 检查GPU：nvidia-smi

最后，如果所有方法都试过了还是不行，可以查看更详细的日志：

# 查看完整的错误日志 cat /root/baichuan2-13b-webui/logs/error.log # 查看系统日志 journalctl -u supervisor.service --since "1 hour ago" # 查看内核日志（可能有关OOM） dmesg | tail -100

大多数问题都能通过重启服务、调整参数、清理资源来解决。百川2-13B-Chat WebUI v1.0整体来说还是很稳定的，遇到问题不要慌，按步骤排查，很快就能恢复正常。

获取更多AI镜像

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

Read more

STM32 ADC+DMA多通道采集系统设计与实现

1. ADC+DMA多通道数据采集系统设计与实现 在嵌入式物联网终端中，温湿度、气体浓度、火焰等模拟量传感器的数据采集是核心功能模块。传统轮询式ADC读取方式存在CPU占用率高、采样间隔不均匀、多通道切换时序难以精确控制等问题。本节将基于STM32F103C8T6平台，构建一套稳定、高效、可扩展的ADC+DMA多通道自动采集系统，为后续MQTT数据上行提供可靠的数据源。 1.1 硬件资源规划与通道映射 STM32F103C8T6集成单路12位ADC（ADC1），支持最多18个外部输入通道（IN0–IN17）和2个内部通道（温度传感器、VREFINT）。根据项目需求，需同时采集4类传感器信号： * MQ-2气体传感器 ：检测LPG、丙烷、氢气等可燃气体，输出模拟电压随气体浓度升高而降低 * MQ-4气体传感器 ：专用于甲烷、天然气检测，响应特性与MQ-2互补 * MQ-7气体传感器 ：对一氧化碳（CO）具有高灵敏度，适用于厨房煤气泄漏预警 * 火焰传感器 ：基于红外光敏元件，输出模拟电压随火焰强度增强而升高 四路传感器分别接入ADC1的四个独立通道，形成确定性映射关系：
【计算机网络】websockeet是怎么支持全双工的

【计算机网络】websockeet是怎么支持全双工的

文章目录 * 一、先理清基础：HTTP为什么不支持全双工？ * 二、WebSocket升级的核心流程：从HTTP到全双工的“切换” * 1. 第一步：HTTP握手（协议升级请求） * 2. 第二步：服务端确认升级 * 3. 第三步：协议切换完成，TCP连接“复用”为WebSocket连接 * 三、WebSocket实现全双工的核心设计 * 1. 底层依赖：TCP的全双工特性（基础） * 2. 帧化设计：打破“请求-响应”的边界 * 3. 无“请求-响应”绑定：主动推送能力 * 4. 持久连接：避免重复握手 * 四、关键对比：HTTP vs WebSocket（全双工维度） * 五、总结 要理解WebSocket通过HTTP升级后实现 全双工通信的核心逻辑，

WebP与Photoshop的格式革新：WebPShop插件全方位解析

WebP与Photoshop的格式革新：WebPShop插件全方位解析 【免费下载链接】WebPShopPhotoshop plug-in for opening and saving WebP images 项目地址: https://gitcode.com/gh_mirrors/we/WebPShop WebP格式支持与Photoshop插件的结合，为设计师带来了高效处理现代图像格式的全新可能。WebPShop作为一款开源插件，彻底打破了Photoshop对WebP格式的兼容性限制，让专业设计流程与现代图像格式无缝衔接。本文将从基础认知、进阶应用到问题解决，全面介绍这款工具如何重塑WebP图像处理流程。 基础认知：WebPShop插件核心价值 插件功能实现：从格式支持到完整工作流 WebPShop插件的核心价值在于实现了Photoshop与WebP格式的深度整合。通过安装该插件，设计师可以直接在Photoshop中打开、编辑和保存WebP图像文件，无需进行格式转换。这种原生级别的支持不仅简化了工作流程，还确保了图像质量在处理过程中不会受损。 WebP作为一种现代图像格

Nanbeige4.1-3B实操手册：webui.py源码关键修改点——支持历史会话持久化

Nanbeige4.1-3B实操手册：webui.py源码关键修改点——支持历史会话持久化 1. 引言：为什么需要历史会话持久化？ 想象一下这个场景：你正在和Nanbeige4.1-3B模型进行一场深入的对话，讨论一个复杂的技术问题。聊了十几轮，模型给出了很多有价值的见解，你正准备把这些内容整理成文档。突然，浏览器崩溃了，或者你需要重启WebUI服务。当你重新打开页面时，发现刚才所有的对话记录都消失了——那种感觉，是不是特别让人抓狂？ 这就是我们今天要解决的问题。 Nanbeige4.1-3B自带的WebUI界面功能很强大，但它有一个明显的短板：不支持历史会话的持久化保存。每次刷新页面或重启服务，所有的对话记录都会丢失。对于需要长期跟踪对话、积累知识库、或者进行多轮调试的用户来说，这无疑是一个巨大的痛点。 好消息是，这个问题完全可以通过修改webui.py源码来解决。在本文中，我将带你一步步分析源码，找到关键修改点，实现历史会话的自动保存和加载功能。无论你是Python新手还是有经验的开发者，都能跟着这个教程，让你的Nanbeige4.1-3B WebUI变得更加强大和实用