企业官网建设流程全解析

GLM-Image WebUI部署教程：硬盘50GB空间规划+模型缓存分区策略

1. 为什么需要专门规划50GB空间和缓存分区

很多人第一次部署GLM-Image WebUI时，只关注显卡和Python版本，却忽略了最实际的问题：硬盘空间怎么分才不踩坑？
模型本身34GB，加上Hugging Face缓存、PyTorch临时文件、生成图像存储，零散堆积下来，很容易在某次生成后突然提示“磁盘空间不足”，服务直接崩溃。
更麻烦的是，如果所有缓存默认写进系统盘（比如/root/.cache），不仅占满系统空间影响稳定性，下次重装环境还会重复下载34GB模型——浪费时间又耗带宽。

这不是理论风险，而是真实发生过的高频问题：

• 用户A把模型下在/home目录，结果/根分区只剩2GB，系统日志写不进去，WebUI反复报错重启
• 用户B没改缓存路径，huggingface/hub自动创建在用户主目录，34GB模型+中间缓存塞爆了家目录
• 用户C生成几百张图后发现outputs/目录膨胀到15GB，但根本找不到它在哪，清理无从下手

所以这篇教程不讲“怎么启动”，而是聚焦一个工程落地中最容易被忽视的实操细节：如何用50GB硬盘空间，干净利落地跑稳GLM-Image WebUI。
你会学到：

• 空间怎么切分才合理（模型/缓存/输出各留多少）
• 为什么必须把Hugging Face缓存单独挂载到项目目录
• 如何让每次启动都走预设路径，彻底告别“找不到缓存”的抓狂
• 生成的图自动存哪、按什么规则命名、多久清理一次

全程不用改系统配置，不碰/etc/fstab，纯靠脚本和环境变量控制，小白照着做就能落地。

2. 硬盘空间50GB的科学分配方案

别再随便建个/glm-image就往里扔文件。50GB不是随便凑够就行，得按数据生命周期分层管理。我们按使用频率和可清理性，把空间拆成三块：

2.1 模型区：34GB（固定占用，不可删）

这是GLM-Image模型本体，来自Hugging Face仓库zai-org/GLM-Image，解压后实测33.7GB。它必须完整保留，删了就无法加载模型。
关键操作：

• 不要让它存在默认缓存路径（如~/.cache/huggingface/hub）
• 强制指定到项目内专用目录：/root/build/cache/huggingface/hub/models--zai-org--GLM-Image
• 部署时用HF_ENDPOINT=https://hf-mirror.com加速下载，避免因网络中断导致下载一半卡住

小技巧：首次下载前先执行mkdir -p /root/build/cache/huggingface/hub，再运行启动脚本。这样模型会直接落盘到目标路径，省去后续移动的麻烦。

2.2 缓存区：10GB（动态变化，可定期清理）

这部分存的是模型推理过程中的临时文件：

• PyTorch的CUDA kernel缓存（/root/build/cache/torch/）
• Diffusers的预编译图（/root/build/cache/diffusers/）
• Gradio的静态资源缓存（/root/build/cache/gradio/）

它们的特点是：
第一次运行后体积最大，后续基本稳定
可安全删除，重启服务会自动重建
但不能和模型区混放——否则清理缓存时可能误删模型

推荐分配：

• TORCH_HOME=/root/build/cache/torch→ 占用约3GB
• DIFFUSERS_CACHE=/root/build/cache/diffusers→ 占用约2GB
• GRADIO_TEMP_DIR=/root/build/cache/gradio→ 占用约1GB
• 剩余4GB作为缓冲，应对大分辨率（2048x2048）生成时的峰值内存映射

2.3 输出区：6GB（持续增长，需主动管理）

所有你点击“生成图像”后产出的图片，都存在这里：/root/build/outputs/。
按默认设置，每张图约8-15MB（PNG格式，未压缩）。算一笔账：

• 生成100张1024x1024图 → 约1.2GB
• 生成500张 → 约6GB（刚好用完预留空间）

必须做的两件事：

1. 命名规则看懂：文件名形如20260118_142305_123456789.png，前8位是日期，中间6位是时间，后9位是随机种子。这样你一眼能分辨哪张是哪次生成的。
2. 设置自动清理：在/root/build/start.sh末尾加一行：

find /root/build/outputs/ -name "*.png" -mtime +7 -delete

意思是：自动删除7天前的PNG文件。既保留下手调试的近期图，又防空间被撑爆。

总结空间分配表（单位：GB）：

区域	路径	大小	是否可删	清理建议
模型区	/root/build/cache/huggingface/hub/models--zai-org--GLM-Image	34	否	永不删除
缓存区	/root/build/cache/torch/+/diffusers/+/gradio/	10	是	每月手动rm -rf /root/build/cache/*
输出区	/root/build/outputs/	6	是	用find命令自动清理7天前文件

3. 模型缓存分区的实操配置

光知道分几块没用，得让系统“听话”。GLM-Image WebUI依赖三个核心缓存路径，必须全部重定向到/root/build/cache/下，否则脚本一运行，缓存还是偷偷写进系统默认位置。

3.1 三步锁定缓存路径

所有配置都在启动脚本/root/build/start.sh里完成，无需动Python代码或环境变量文件。

第一步：修改启动脚本头部
打开/root/build/start.sh，在#!/bin/bash下面添加：

# 强制指定所有缓存路径到项目目录 export HF_HOME="/root/build/cache/huggingface" export HUGGINGFACE_HUB_CACHE="/root/build/cache/huggingface/hub" export TORCH_HOME="/root/build/cache/torch" export DIFFUSERS_CACHE="/root/build/cache/diffusers" export GRADIO_TEMP_DIR="/root/build/cache/gradio"

第二步：确保Hugging Face镜像生效
在同一脚本中，找到调用python webui.py的行，在前面加：

# 使用国内镜像源，避免下载超时 export HF_ENDPOINT="https://hf-mirror.com"

第三步：验证路径是否生效
启动后，在WebUI界面点开「终端」标签页（如果有），执行：

echo $HF_HOME ls -lh /root/build/cache/huggingface/hub/

如果看到models--zai-org--GLM-Image目录且大小接近34GB，说明模型已正确落盘。

3.2 为什么不能只改HF_HOME？

因为GLM-Image底层用的是Diffusers库，而Diffusers会优先读DIFFUSERS_CACHE，不是HF_HOME。
同样，PyTorch的CUDA kernel缓存由TORCH_HOME控制，Gradio的临时文件由GRADIO_TEMP_DIR控制。
漏掉任何一个，都会导致缓存“逃逸”到默认路径，比如：

• TORCH_HOME没设 → 缓存写进/root/.cache/torch/
• GRADIO_TEMP_DIR没设 → 临时文件塞满/tmp/，而/tmp通常只是内存盘，重启就丢

所以必须三管齐下，一个都不能少。

4. 一键部署与空间检查脚本

别再手动敲一堆export命令。我们把所有空间管理逻辑打包进启动脚本，做到“一键启动，自动分区”。

4.1 升级后的start.sh完整内容

以下是优化后的/root/build/start.sh（已适配50GB空间策略）：

#!/bin/bash # ========== 空间安全检查 ========== echo " 正在检查硬盘空间..." ROOT_SPACE=$(df /root/build | awk 'NR==2 {print $5}' | sed 's/%//') if [ "$ROOT_SPACE" -gt 90 ]; then echo " 警告：/root/build所在分区使用率超过90%！请清理空间后重试" exit 1 fi # ========== 缓存路径强制重定向 ========== export HF_HOME="/root/build/cache/huggingface" export HUGGINGFACE_HUB_CACHE="/root/build/cache/huggingface/hub" export TORCH_HOME="/root/build/cache/torch" export DIFFUSERS_CACHE="/root/build/cache/diffusers" export GRADIO_TEMP_DIR="/root/build/cache/gradio" export HF_ENDPOINT="https://hf-mirror.com" # ========== 创建必要目录 ========== mkdir -p /root/build/cache/huggingface/hub mkdir -p /root/build/cache/torch mkdir -p /root/build/cache/diffusers mkdir -p /root/build/cache/gradio mkdir -p /root/build/outputs # ========== 启动WebUI ========== echo " 启动GLM-Image WebUI..." cd /root/build python webui.py --port 7860 "$@"

4.2 首次运行时的关键观察点

运行bash /root/build/start.sh后，盯住终端输出，确认三件事：

1. 下载阶段：看到Downloading model.safetensors时，路径显示为/root/build/cache/huggingface/hub/models--zai-org--GLM-Image/，而不是~/.cache/...
2. 缓存生成：启动完成后，执行du -sh /root/build/cache/*，应看到：

   33G /root/build/cache/huggingface 3.2G /root/build/cache/torch 1.8G /root/build/cache/diffusers 456M /root/build/cache/gradio

3. 输出验证：生成一张图后，ls /root/build/outputs/能看到带时间戳的PNG文件

如果任一环节异常，立刻停掉服务，检查start.sh里的export语句是否拼写错误。

5. 常见空间问题排查指南

即使按教程做了，也可能遇到意外情况。以下是高频问题的直给解法：

5.1 问题：模型下载一半中断，再次启动却说“模型已存在但损坏”

原因：Hugging Face校验失败，但残缺文件留在了缓存目录。
解法：

# 彻底清理模型缓存（注意：这会删掉已下载的34GB，但下次启动会重新下） rm -rf /root/build/cache/huggingface/hub/models--zai-org--GLM-Image # 清空PyTorch和Diffusers缓存（安全，不影响模型） rm -rf /root/build/cache/torch/* rm -rf /root/build/cache/diffusers/*

5.2 问题：生成图像时提示“OSError: No space left on device”

不要急着删文件！先定位源头：

# 查看哪个目录占满 df -h /root/build # 如果是outputs/满了，直接清空旧图 find /root/build/outputs/ -name "*.png" -mtime +3 -delete # 如果是cache/下的某个子目录异常膨胀（比如torch/超过5GB） du -sh /root/build/cache/* | sort -hr | head -5

5.3 问题：WebUI启动后，界面上看不到“加载模型”按钮

大概率是缓存路径没生效，模型根本没加载：

• 检查/root/build/cache/huggingface/hub/下是否有models--zai-org--GLM-Image目录
• 如果没有，说明HF_HOME没生效，回看start.sh里export语句是否在python webui.py之前
• 如果有但为空，说明下载被中断，按5.1方法清理重试

记住：所有问题根源，90%出在缓存路径没锁死。只要/root/build/cache/下三个核心目录（huggingface/torch/diffusers）都有内容，服务就一定能起来。

6. 总结：50GB空间用好，比换显卡更重要

部署GLM-Image WebUI，显卡决定“能不能跑”，而硬盘空间规划决定“能不能稳”。
这篇教程没讲一句模型原理，只解决一个工程师每天都会面对的现实问题：如何让34GB模型、10GB缓存、6GB输出，在50GB空间里井然有序，不打架、不抢地、不崩溃。

你真正掌握的是：
一套可复用的空间分层思维（模型/缓存/输出）
三行export命令锁死所有缓存路径的硬核技巧
一个自带空间检查的启动脚本，杜绝“磁盘满”导致的服务宕机
面对报错时，快速定位是模型、缓存还是输出的问题

下次再部署类似项目（比如SDXL、Stable Video Diffusion），这套方法论依然适用——毕竟，所有大模型的共性，就是“吃硬盘”。

现在，你可以放心启动bash /root/build/start.sh了。这一次，空间不会拖后腿。

获取更多AI镜像

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