本地跑大模型这件事我前后折腾了小半年最早是在一台轻薄本上用 CPU 硬扛 7B 模型一句回答要等十几秒风扇转得像要起飞后来换到一台带独显的机器用 Docker 把 Ollama 和 Open WebUI 一起拉起来才算真正跑通了一套能天天用的私有化部署方案。这套组合的价值不在于炫技而在于它把模型权重、对话记录、文档数据全部留在自己机器上同时保留了接近商业产品的网页交互体验。gemma、llama2、qwen 这几个系列的开源模型恰好覆盖了从低配到中配的不同硬件档位让一键部署不至于变成一键失败。如果你手里有一台 16GB 内存以上的机器愿意花半小时跟着敲几行命令就能得到一个属于自己的 AI 对话入口不用注册、不用联网、不怕断服如果你已经在用云端接口但被调用额度、数据外流、响应不稳定折腾过这篇内容应该能帮你把整套服务搬到本地。下面我从选型思路、环境准备、编排文件、模型挑选、界面配置到故障排查把这条链路完整走一遍中间该踩的坑我会提前标出来。1. 私有化部署到底在解决什么问题1.1 三类最真实的需求场景很多人第一次接触私有化部署是出于好奇但能让这套东西长期活下去的一定是具体场景。我总结下来大致分三类而且每一类对配置的要求完全不同。第一类是数据不能出门。比如需要把内部的技术文档、会议记录、故障报告丢给模型做总结和检索这些材料天然不适合上传到第三方接口。这种情况下模型能力反而不是第一位数据是否留在本机才是硬指标7B 级别的量化模型完全够用。第二类是高频调用、成本敏感。当你的使用频率从一天问十次变成脚本自动调用几千次按量计费的开销会迅速失控本地跑一个模型边际成本接近于零只剩电费。第三类是离线与可控性。有些机器根本不允许连外网或者网络条件很差本地部署是唯一选择还有些场景需要固定模型版本云端接口随时可能升级换代行为漂移会直接影响下游流程。提醒一句如果你的需求只是偶尔问几个问题本地部署其实性价比不高下载模型就要占掉十几 GB 硬盘。真正值得动手的是有持续使用、有数据顾虑、或者需要接口化的场景。1.2 为什么是 Docker Ollama Open WebUI 这个组合这套组合之所以流行是因为它把三件本来很麻烦的事拆开、各自解决再用容器粘起来。Ollama负责模型这一层。它把模型的下载、量化格式加载、推理调度、显存分配全部封装好对外只暴露一个 HTTP 接口默认 11434 端口。以前你要自己编译推理框架、手动转换模型格式、调参数现在一句ollama run就完事。它还自带模型注册表gemma、llama2、qwen 这些系列都能按标签直接拉标签里带的量化等级比如q4_0、q4_K_M决定了体积和质量。Open WebUI负责交互这一层。它本质上是一个前端应用把 Ollama 的接口包装成类似商业产品的界面多轮对话、模型切换、多用户账号、文档上传问答、会话历史。默认监听 3000 端口。Docker Compose负责把它们粘在一起。两个容器放进同一个自定义网络Open WebUI 用服务名访问 Ollama不需要暴露 Ollama 的端口到宿主机。数据通过 volume 挂载到宿主机目录容器删了重建模型和聊天记录都还在。这个分层的妙处在于替换成本极低。哪天你想换个前端或者想在 Ollama 前面加一层网关做限流各层互不影响。相比把所有东西装在一台机器上跑裸服务的做法容器的隔离性让你可以放心地折腾大不了docker compose down重来。1.3 先算账你的机器到底能跑多大的模型这一步很多人跳过结果下了一晚上模型跑起来直接爆显存。动手前花两分钟算一下能省掉大量返工。模型占用显存大致分两块权重和KV Cache。权重的算法很简单参数量 × 每参数字节数。以 7B 模型为例Q4 量化的每参数字节数约 0.55算下来约 3.9GBQ8 约 1.06 字节/参数约 7.4GBFP16 是 2 字节/参数约 14GB。实际文件会比理论值大一点因为还有元数据和部分非量化层。KV Cache 常被忽略但它随上下文长度线性增长公式是2 × 层数 × 隐藏维度 × 上下文长度 × 2 字节FP16。一个 7B 模型在 4096 上下文下KV Cache 通常要 1~2GB上下文拉到 8192直接翻倍。下面这张表是我实测的经验值覆盖常见档位给个大致参考模型规模量化等级权重显存4K 上下文 KV建议显存纯 CPU 可行性2B~3BQ4_K_M约 2GB约 0.5GB4GB可行速度可接受7B~8BQ4_K_M约 4.5GB约 1.5GB8GB可行但慢约 3~6 token/s13B~14BQ4_K_M约 8GB约 2GB12GB勉强体验较差30B~34BQ4_K_M约 19GB约 3GB24GB不推荐70BQ4_K_M约 40GB约 5GB48GB不可行内存不是显存也要留够一般建议不少于模型文件大小的 1.5 倍因为加载过程中会有临时缓冲。硬盘方面一个 7B 的 Q4 模型大约 4~5GB同时留三个不同模型20GB 空间是要的。2. 动手之前的环境准备2.1 系统与 Docker 引擎的安装要点系统层面没有太多讲究主流 Linux 发行版、较新版本的开箱即用如果是桌面系统建议在虚拟机上跑避免和宿主环境抢资源。内核版本不要太老否则 GPU 直通和 cgroup 相关的支持会出问题。Docker 引擎的安装我建议走官方脚本或发行版仓库不要用桌面版自带的 Docker Desktop。桌面版在资源调度、GPU 支持、网络模式上和引擎版差异不小尤其是 GPU 直通经常出现宿主机能看到显卡、容器里识别不到的情况。安装完成后先做两件事把当前用户加进 docker 组避免每条命令都 sudo然后确认docker compose version能输出 v2 版本号——注意是docker compose而不是老的docker-compose两者参数不完全兼容。# 确认引擎与 compose 版本 docker version docker compose version # 把当前用户加入 docker 组重新登录后生效 sudo usermod -aG docker $USER这里有个小坑加入 docker 组后必须重新登录或者执行newgrp docker否则当前 shell 的组信息还是旧的会继续提示权限不足很多人以为没生效就放弃了这个步骤。另外顺手检查一下磁盘空间和 inotify 上限。模型文件动辄几 GB空间不够会在拉取中途失败inotify 上限太低则可能导致容器内文件监控失效影响日志和热更新。df -h /var/lib/docker cat /proc/sys/fs/inotify/max_user_watches2.2 目录规划把数据和应用分开容器部署最容易犯的错误是把数据留在容器里。容器一删模型和聊天记录全没了。我的做法是在宿主机上建两个明确的数据目录通过 volume 挂进去sudo mkdir -p /data/ollama/models sudo mkdir -p /data/openwebui/data sudo chown -R 1000:1000 /data/openwebui/data两个目录的权限要求不一样这点值得单独说。Ollama 容器默认以 root 运行/data/ollama/models保持 root 属主即可。Open WebUI 容器内部则用非 root 用户通常是 uid 1000写数据如果宿主机目录属主不对启动后会看到大量权限报错界面能打开但上传文档、保存会话全部失败。我第一次部署时就卡在这里日志里刷了一屏Permission denied翻了好几页才定位到问题。目录分开还有一个好处备份粒度清晰。模型文件体积大但可以重新下载聊天记录和知识库数据体积小但不可再生备份策略完全不同。2.3 GPU 直通的两条路线如果你的机器有独立显卡走 GPU 加速体验会有质的差别。NVIDIA 显卡的容器直通需要装container toolkit装完后配上运行时再重启 Docker# 配置容器运行时 sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker # 验证 GPU 是否能在容器里被看到 docker run --rm --gpus all 基础镜像 nvidia-smi最后那条验证命令的输出里如果能看到显卡型号和显存占用说明直通成功。如果报could not select device driver之类的错误九成是 toolkit 没装好或者 Docker 没重启。没有独显、或者显卡显存小于 6GB 的情况直接用 CPU 模式就行。Ollama 的容器镜像本身同时包含 CPU 和 GPU 推理能力不加--gpus参数就自动走 CPU不需要换镜像。CPU 模式下 7B Q4 模型在桌面级处理器上大概能跑到每秒 3~6 个 token对话能感觉到慢但用起来是可以接受的尤其是做后台批处理任务时差别不明显。3. 编排文件怎么写一次启动两个容器3.1 docker-compose.yml 逐段拆解这是整套部署的核心。我把它拆成两段看Ollama 服务和 Open WebUI 服务。services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: - /data/ollama/models:/root/.ollama environment: - OLLAMA_KEEP_ALIVE24h - OLLAMA_NUM_PARALLEL2 - OLLAMA_MAX_LOADED_MODELS2 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] networks: - ai-net openwebui: image: ghcr.io/open-webui/open-webui:main container_name: openwebui restart: unless-stopped depends_on: - ollama ports: - 3000:8080 volumes: - /data/openwebui/data:/app/backend/data environment: - OLLAMA_BASE_URLhttp://ollama:11434 - WEBUI_SECRET_KEY换成你自己的随机字符串 - ENABLE_SIGNUPfalse networks: - ai-net networks: ai-net: driver: bridge逐段说关键点。OLLAMA_BASE_URLhttp://ollama:11434里的ollama是服务名靠 Compose 自动创建的 DNS 解析到容器 IP所以不要写成 localhost——在容器里 localhost 指的是容器自己不是宿主机。WEBUI_SECRET_KEY必须改。这个是会话签名密钥用默认值意味着任何人知道你部署了这套服务理论上就能伪造会话。生成方法很简单openssl rand -hex 32输出一串就行。ENABLE_SIGNUPfalse建议在创建完第一个管理员账号之后再设为 false。首次启动需要注册账号注册的第一个用户自动成为管理员之后就关掉注册入口防止别人登进来用你的算力。OLLAMA_KEEP_ALIVE24h控制模型在内存里驻留多久。默认只有 5 分钟闲置一会儿模型就被卸载下次提问又要重新加载7B 模型加载一次大概 3~10 秒体验很差。设成 24 小时意味着模型常驻代价是显存一直被占着。如果你的显存紧张、需要频繁切换模型可以调小到30m让不用的模型及时释放。OLLAMA_MAX_LOADED_MODELS决定同时驻留几个模型。设成 2 的前提是显存够两个 7B Q4 模型加起来要 12GB 左右显存不够就设 1切换模型时会卸载旧的。3.2 启动、验证与首次访问文件保存为docker-compose.yml在同目录执行docker compose up -d docker compose ps docker compose logs -f ollamadocker compose ps里两个服务的状态都应该是running。如果 openwebui 反复重启先看日志八成是数据目录权限或者OLLAMA_BASE_URL写错。Ollama 启动后先单独验证一下接口通不通docker exec -it ollama ollama list curl http://localhost:11434/api/tags第二条命令需要 Ollama 端口映射到宿主机才能用。我通常不把 11434 暴露到宿主机容器间走内网就够了减少一个攻击面。需要调试时用docker exec进容器执行 curl 更方便。浏览器访问http://宿主机IP:3000第一次会要求创建管理员账号。注册完进去右上角设置里能看到 Ollama 连接状态是绿的模型列表是空的——因为还没拉模型下一步就是干这个。3.3 参数调优端口、上下文与并发几个容易忽略但影响很大的参数。端口方面3000 是 Open WebUI 的默认映射如果被占用比如某些开发环境默认起在 3000改成3001:8080之类即可容器内监听端口不用动。检查占用用ss -lntp | grep 3000。上下文长度默认是 2048这个值对现在的使用习惯来说偏小一段稍长的文档就超了。可以通过环境变量或者模型参数调整但要注意上下文和显存是正相关翻倍就意味着 KV Cache 翻倍。我的经验是 4096 是 8GB 显存的安全线再往上就要盯着nvidia-smi看了。并发由OLLAMA_NUM_PARALLEL控制。设成 2 意味着同一个模型可以同时处理两个请求代价是 KV Cache 也要翻倍显存占用直接上涨。多人共用的场景值得开单人使用设成 1 更省资源。参数默认值常用调法影响OLLAMA_KEEP_ALIVE5m24h / 30m模型驻留时间影响首次响应速度OLLAMA_NUM_PARALLEL11~4并发请求数成倍吃 KV CacheOLLAMA_MAX_LOADED_MODELS11~2常驻模型数吃总显存num_ctx模型级20484096~8192上下文窗口线性吃显存4. 模型选型gemma、llama2、qwen 各自适合谁4.1 三个系列的定位差异这三个系列是本地部署里最常见的选择但它们的脾气完全不一样选错了会觉得这东西根本没法用。gemma系列体积控制得比较好2B 版本在低配机器上能跑出流畅体验7B 版本在 8GB 显存下也很舒服。它的风格偏简洁指令跟随做得不错适合做摘要、改写、结构化输出这类任务。缺点是中文表现一般用它处理中文长文本时偶尔会出现表达生硬的情况。llama2是老资历生态最成熟各种微调版本、工具链支持最全。7B 和 13B 都比较常见13B 在 12GB 显存上能跑质量比 7B 有明显提升。它的特点是稳知识面广但中文能力同样是短板而且对提示词的格式比较敏感需要按它习惯的模板来组织指令。qwen系列在中文场景下优势明显7B 和 14B 两个档位覆盖了大部分需求。它对中文长文本、专业术语、中文语境下的指令理解都更自然做中文文档问答、中文客服语料处理时效果明显好于前两个。代价是同等参数量下中文词表会让模型的 embedding 层更大一些文件体积略大。我的实际搭配是qwen 7B 做日常中文对话和文档处理gemma 2B 做轻量任务和快速验证llama2 留着做英文任务和工具链兼容测试。三个模型加起来不到 20GB在 12GB 显存的机器上通过OLLAMA_MAX_LOADED_MODELS1轮换加载即可。4.2 量化等级体积、速度、质量的三方平衡同一个模型名后面的标签如q4_0、q4_K_M、q5_K_M、q8_0就是量化等级。数字越小体积越小、质量损失越大。q4_0是最早的四位量化压缩率最高但质量损失比较明显长回答里偶尔会出现逻辑断裂。q4_K_M是目前最推荐的平衡点把部分关键层保留在更高精度体积比q4_0大一点点但质量提升显著。q5_K_M再往上一档质量更接近原始模型体积增加约 20%。q8_0基本可以视作无损但体积接近 FP16 的一半以上除非你的显存真的很宽裕否则不划算。量化等级相对体积质量评价适用场景q4_0最小可用长文本偶有瑕疵极限压缩、低配机器q4_K_M小推荐性价比最高绝大多数场景q5_K_M中质量接近原版显存有余量时升级q8_0大基本无损高精度要求、显存充足选择逻辑很简单先按显存算出能放下的最大量化等级然后往下降一档留余量。比如 8GB 显存跑 7BFP16 要 14GB 放不下q8 要 7.4GB 加上 KV Cache 就爆了q5_K_M 约 5.5GB 加上 KV 刚好卡在边缘q4_K_M 约 4.5GB 就很从容。所以 7B 8GB 显存的正确答案是 q4_K_M。4.3 拉取、导入与多模型共存的目录管理拉模型在容器里执行docker exec -it ollama ollama pull qwen:7b docker exec -it ollama ollama pull gemma:7b docker exec -it ollama ollama pull llama2:13b docker exec -it ollama ollama list拉取速度取决于网络几 GB 的文件慢的时候要等挺久。建议一次只拉一个拉完确认能用再拉下一个避免磁盘写满或者中途失败留下不完整的层。离线导入是更实用的技能。如果目标机器不能联网可以在能联网的机器上把模型导出成文件再拷过去# 有网机器上导出 docker exec -it ollama ollama pull qwen:7b docker cp ollama:/root/.ollama/models /tmp/ollama-models tar -czf ollama-models.tar.gz -C /tmp ollama-models # 目标机器解压到挂载目录后重启容器 tar -xzf ollama-models.tar.gz -C /data/ollama/ docker compose restart ollamaOllama 的模型目录结构是blobs存权重和元数据manifests存版本索引只要这两个目录完整拷过去ollama list就能识别。自定义模型用 Modelfile 实现这是很多人不知道的功能。比如你想给 qwen 加一段固定的系统提示词、调整默认参数可以这样写FROM qwen:7b PARAMETER num_ctx 8192 PARAMETER temperature 0.7 SYSTEM 你是一个严谨的技术文档助手回答时优先给出结论再补充依据。保存为Modelfile然后在容器内执行ollama create my-qwen -f Modelfile就会生成一个名为my-qwen的新模型。这个做法特别适合把常用的提示词工程固化下来团队里所有人用的都是同一个调教过的模型不用每次手动粘贴一大段前缀。注意自定义模型本质上是对基础模型的一层引用不会复制权重所以磁盘占用增加很少。但如果基础模型被删除自定义模型会失效。5. 把 Web UI 用起来账号、知识库与接口5.1 多用户、权限与首启动配置Open WebUI 的多用户做得很完整。第一个注册的账号是管理员可以在管理面板里创建其他用户、设角色管理员/普通用户/待审核、限制可用模型。实际团队使用时我建议这样配普通用户只开放 1~2 个模型避免所有人乱切模型把显存挤爆模型访问权限按组分配做敏感数据处理的人才能用大模型关闭自助注册账号由管理员统一创建。这几项都在管理面板的设置里图形化操作不用改配置文件。会话记录的可见性也要注意。默认情况下用户只能看自己的对话管理员能看到全部。如果团队对隐私敏感可以在管理面板里调整这块策略或者在部署时就把WEBUI_SECRET_KEY设为唯一值确保会话隔离生效。5.2 文档问答的嵌入模型怎么选Open WebUI 的文档问答RAG是它最实用的功能之一上传一个 PDF 或者一堆 Markdown它自动切片、向量化、存进内置的向量库提问时检索相关片段再喂给模型。这里有个关键选择嵌入模型用哪个。默认会用一个内置的小型嵌入模型好处是开箱即用坏处是中文语义理解一般。更好的做法是单独拉一个嵌入模型挂到 Ollama 上然后在设置里指向它docker exec -it ollama ollama pull nomic-embed-text然后在 Open WebUI 的设置里把嵌入引擎切到 Ollama选择这个模型。中文场景下专门的嵌入模型对语义相似度的判断明显更准检索到的片段相关性也会提升。文档切片的参数也值得调。默认的块大小对技术文档来说偏大一个块里塞了太多无关内容模型容易被干扰。我的经验是把块大小调到 500~800 字符、重叠 50~100 字符这样既有上下文连贯性又不会引入太多噪音。一个真实教训向量库和原始文档都存放在/app/backend/data里如果这个目录没做持久化挂载容器一重建所有知识库内容全丢。这一条我强调过很多次但还是一直有人踩。5.3 OpenAI 兼容接口的接入要点Ollama 提供了一套 OpenAI 兼容的接口路径是/v1/chat/completions这意味着现有的很多工具、SDK、脚本可以几乎零改动地指向本地服务。调用方式curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer ollama \ -d { model: qwen:7b, messages: [{role: user, content: 用三句话解释什么是向量数据库}], temperature: 0.7 }Authorization头随便填本地服务不校验。注意这个接口需要把 11434 端口映射到宿主机如果只在内网用把调用方也放进同一个网络即可。如果要暴露给外部程序强烈建议中间加一层反向代理做鉴权、限流和日志。裸着开放一个能无限调用的推理接口等于把算力送给任何人。反向代理只做最基本的 Key 校验就能挡掉绝大部分问题。另外提醒一点Open WebUI 自己也有接口层但它和 Ollama 的接口在参数上不完全一致混用会出现莫名其妙的报错。做自动化调用时我一般统一走 Ollama 的/v1路径行为更可预测。6. 常见故障排查实录6.1 容器起不来、端口冲突、网络不通症状一openwebui 反复重启日志里一堆 Permission denied。原因基本是数据目录属主不对。容器内进程用 uid 1000 写入宿主机目录如果属于 root就会失败。修复sudo chown -R 1000:1000 /data/openwebui/data docker compose restart openwebui症状二界面能打开但模型列表一直转圈报连接失败。先确认 Ollama 服务本身活着docker exec -it ollama ollama list。如果这个能跑问题就在网络。检查OLLAMA_BASE_URL是不是写成了localhost或者127.0.0.1——这是最高频的错误容器里没有 host 网络时localhost 指向自己。正确写法是服务名http://ollama:11434。两个容器必须在同一个networks下。症状三端口被占用docker compose up报 bind 失败。ss -lntp | grep -E 3000|11434找到占用进程要么停掉要么改映射端口。改的时候只改冒号左边右边的容器内端口不要动。症状四拉模型时报 TLS 超时或连接重置。检查容器内的 DNS 和出网能力。可以进容器 exec 一个 curl 测一下或者临时改宿主机的 Docker DNS 配置。企业内网环境还有可能是防火墙策略挡了 CFA 类对象存储的域名需要找运维放行。6.2 模型加载慢与显存溢出的定位方法现象提问后要等十几秒才开始出字出字后速度正常。这是典型的模型未驻留每次都要重新加载。检查OLLAMA_KEEP_ALIVE是否设得太短或者显存不够导致模型被反复换入换出。用nvidia-smi观察如果提问瞬间显存飙升、回答结束后迅速回落说明模型没留住。现象回答到一半突然中断或者直接报错。先看是不是上下文超限。num_ctx设成 8192 但显存只够 4K跑到后面 KV Cache 分配失败就会崩。降上下文或者升量化二选一。定位显存问题的标准流程# 实时看显存 watch -n 1 nvidia-smi # 看 Ollama 日志里的加载信息 docker compose logs -f ollama | grep -i load\|memory\|gpu日志里会明确写出模型被加载到 GPU 还是 CPU。如果看到offloaded 0/33 layers to GPU这种输出说明几乎全跑在 CPU 上检查--gpus参数和 toolkit 配置。现象多用户同时提问后到的请求一直排队。OLLAMA_NUM_PARALLEL设成了 1所有请求串行处理。显存允许的话调到 2~4但要同步留意显存峰值。6.3 常见问题速查表现象最可能原因快速验证修复动作容器反复重启数据目录权限docker compose logs openwebui看 Permission deniedchown -R 1000:1000数据目录模型列表为空接口地址写错进容器 curl Ollama改成服务名而非 localhost首次回答极慢模型未驻留nvidia-smi看显存是否波动调大 KEEP_ALIVE回答中途中断上下文超显存日志找 allocation 报错降 num_ctx 或降量化全跑 CPU未启用 GPU 直通日志看 offloaded 层数装 toolkit 加 --gpus上传文档失败向量库目录不可写看后端日志修权限 确认挂载拉模型超时DNS 或出网限制容器内 curl 测试改 DNS / 放行域名并发卡死并行数设为 1看请求是否串行调整 NUM_PARALLEL7. 长期维护备份、升级与回滚7.1 数据备份与版本固定跑起来之后最容易被忽略的是版本固定。compose 文件里如果写的是:latest某天重启容器可能就拉到一个行为完全不同的新版本接口变了、配置项改了服务直接起不来。我的做法是部署稳定后立刻把镜像标签改成具体的 digest 或版本号。# 查看当前运行的镜像 digest docker inspect --format{{index .RepoDigests 0}} ollama # compose 里改成固定版本 # image: ollama/ollama:0.1.32备份分两块。数据备份是重点模型目录可以重下/data/openwebui/data里的会话、知识库、用户配置不可再生建议定期打包tar -czf /backup/openwebui-$(date %F).tar.gz -C /data/openwebui data升级流程要按顺序来先备份数据 → 拉新镜像 → 改 compose 标签 →docker compose up -d→ 验证界面和对话 → 有问题立即回滚标签。回滚就是改回旧版本标签再 up因为数据目录独立挂载回滚不会丢数据但要注意新版本可能升级了数据结构跨大版本回滚前先确认兼容性必要时连数据一起回滚。7.2 我踩过的几个坑坑一把 Ollama 端口映射到宿主机后没做任何限制。某天发现请求日志里有大量陌生 IP 的调用记录算力被人白嫖了好几天。后来改成只在内网暴露需要外网调用时走反向代理加 Key 校验。这是最容易忽视的安全问题。坑二OLLAMA_MAX_LOADED_MODELS设成 3结果一直在换页。三个 7B 模型加起来显存超了系统开始疯狂卸载重载看起来像是模型加载特别慢。改回 1 之后恢复正常。显存不够时多模型常驻不但没好处还会拖慢一切。坑三默认嵌入选模型中文检索效果差。知识库里明明有相关内容问出来就是答非所问。换成专门的嵌入模型后召回率提升非常明显。这个改动成本很低收益很高建议一开始就做。坑四不设WEBUI_SECRET_KEY重建容器后所有人被登出。密钥变了原有 session 全部失效。虽然是小事但团队里每个人都要重新登录一次体验很差。第一次部署就把密钥固定下来。坑五磁盘写满导致服务假死。模型拉多了把磁盘塞满Ollama 写临时文件失败进程还在但接口全挂。加一个定时检查磁盘占用的脚本比事后救火省事得多。这套东西我前后调了大概两周现在跑在一台 12GB 显存、32GB 内存的机器上日常挂着 qwen 7B 做中文处理需要时切 gemma 做轻量任务团队里几个人共用一个入口用了大半年没出过大问题。配置本身不复杂真正花时间的是那些看起来能跑但就是不对的细节——权限、网络、显存、驻留时间每一个都值得单独确认一遍。如果你准备动手我建议先按最简配置跑通一次完整对话确认整条链路通了再逐个加参数优化别一上来就把所有配置项堆满出问题的时候根本不知道是哪一项导致的。