一、问题背景（抽象化） 在一台长期运行的 Linux 主机上，使用 Docker Compose 部署了多个应用栈。随着时间推移，出现了以下典型问题： 目标不是改变 Docker 的存储机制，而是： 在不破坏 Docker 设计的前提下，让数据卷“可读、可控、可迁移”。 二、总体设计原则（通用） 1. 不强行迁移 Docker 根目录 2. 明确区分三类数据 类型 处理方式 Compose / 配置文件 保留在用户可读目录 运行期业务数据 使用 命名 volume 临时 / 缓存数据 允许 Docker 自动管理 3. 通过“命名 volume”解决可读性问题 三、问题定位方法（通用步骤） 1. 列出系统中所有 volume 2. 反向确认 volume 与容器的挂载关系 通过该方式，可以明确： 四、数据迁移的通用流程 步骤 …
背景 在 OpenWebUI 中同时接入本地模型（Ollama）与云端模型（OpenAI External）后，模型列表会显著膨胀，包含大量历史版本、兼容别名与专用用途模型。本文记录一种低心智负担、可长期使用的配置与使用方式，并解释多模态能力的实际用法。 一、为什么模型会“突然变多” 当 OpenWebUI 的 OpenAI 连接中 Model IDs 留空 时，系统会直接拉取 OpenAI /v1/models 的全量结果，其中包含： 这是 API 工程级清单，并非“用户选择列表”。数量增加并不代表配置错误。 二、真正需要关注的模型类别 1. 日常文本与思考 覆盖绝大多数文本任务。 2. 多模态（图文理解） 用法：在对话中拖入图片，配合文字提问即可完成“看图说话”。 3. 图像生成（文 → 图） 说明：该模型为单向生成模型，仅用于画图，不用于聊天或分析。 4. 可忽略的模型 这些模型不影响日常使用，可完全忽略。 三、两种可行的模型管理策略 策略 A：自动更新（省心） 适合：不想维护配置、只关心可用性。 策略 B：极简清单（推荐） 在 Settings → Connections → OpenAI → Model …
一、背景说明 在本地或自托管环境中同时部署 OpenWebUI 与 Dify 时，二者都会涉及对 OpenAI API 的调用。如果使用同一个 API Key： 因此，更合理的做法是：为不同服务分别创建并使用独立的 API Key。 二、API Key 是否可以免费创建 OpenAI 平台允许用户： 但需要注意的是： 因此，创建多个 Key 并不会带来额外的免费调用额度。 三、是否可以创建多个 API Key 结论很明确： 这使得 API Key 可以作为逻辑隔离工具，而不是计费隔离工具。 四、推荐的 Key 划分方案 针对常见的自托管 AI 使用场景，推荐至少划分如下两类： 使用场景 API Key OpenWebUI（交互式对话） openwebui Dify（应用 / Workflow / Agent） dify 原则非常简单： 一服务一 …
一、两个体系的本质区别 1. 官方 ChatGPT 官方 ChatGPT 是一个面向终端用户的一体化产品，核心特点是： 用户只需登录账号，即可直接使用文字、语音、图片、文件等能力，无需关心模型选择、上下文管理或计费细节。 2. ChatGPT API ChatGPT API 是一个面向开发者和系统构建者的能力接口，核心特点是： API 更像“发动机”，而不是“整车”。 二、账号与计费体系 账号关系 计费关系 两者可以同时使用，互不替代。 三、能力对比（模型层 vs 产品层） 模型能力 在模型层面： 差异主要来自产品层封装，而非模型本身。 四、多模态能力（图片 / 文档 / 截图） 官方 ChatGPT 的表现 这些能力对用户而言是“无感”的。 API 的实际情况 当前 OpenAI 的新一代 API 已原生支持多模态： 但需要注意： API 只提供能力，不提供完整交互体验 是否“好用”，高度依赖前端是否支持： 这也是为什么多数开源前端在体验上仍与官方存在差距。 五、语音能力 官方 ChatGPT …
一、结论先行：Dify 是什么？ 一句话概括： Dify 是一个“将大模型封装为应用”的平台。 它本身并不提供模型推理能力，也不是单纯的聊天界面，而是位于模型之上的应用与编排层，主要作用包括： 在常见的本地 LLM 架构中，其角色可以抽象为： 简化理解： 交互层解决“如何对话” Dify 解决“让 AI 持续按同一规则工作” 二、什么时候需要 Dify？ 不适合引入 Dify 的情况 当使用目标主要是： 此时，引入额外的应用层意义不大。 Dify 的适用场景 Dify 更适合以下需求： 其核心价值在于：长期一致性与可控性。 三、学习 Dify 的正确主线 应用 → 行为规则（Prompt） → 数据接入 学习顺序非常关键。 不建议一开始接触复杂功能，应先理解 Dify 的最小工作模型。 四、第一步：创建最小可用应用 目标不是“功能完整”，而是： 核心原则 当应用能够正常调用模型并完成基本对话，即达到该阶段目标。 五、第二步：通过系统指令固定行为 Dify 的关键能力在于系统级指令。 系统指令的作用不是提示，而是长期生效的行为约束。 其价值在于： 示例结构（抽象）： 只要系统指令保持不变，模型行为就具有可重复性。 …
背景 在单机环境中使用 Docker Compose 同时运行 Ollama（推理核心）与 Open-WebUI（交互界面）是一个常见做法。初期将两者放在同一个 compose 文件中管理较为方便，但随着系统逐步演进，这种方式会带来以下问题： 因此，本次实践的目标是： 在不丢失任何既有数据的前提下，将 Ollama 与 Open-WebUI 拆分为两个独立的 Docker Compose 栈，并通过一个核心网络进行连接。 设计原则 原始状态分析 在最初的一体化部署中，Docker 会自动为服务创建数据卷。拆分为多个栈后，如果未显式指定旧数据卷名称，Docker 会为新栈创建新的空卷，从而导致“历史数据消失”的错觉。 需要明确的是： 数据通常并未被删除，而是新容器未挂载到正确的旧数据卷。 因此，拆分过程中最关键的工作并不是服务启动顺序，而是数据卷的精确绑定。 拆分思路概述 整体架构被拆分为两类栈： 所有服务间通信均通过 Docker 内部网络完成，核心服务不直接对外暴露。 核心栈配置要点（示意） 核心栈的职责包括： 配置示意（省略非关键字段）： 外围栈配置要点（示意） 外围栈的职责包括： 配置示意（省略非关键字段）： 常见问题与判断方法 为什么拆分后看起来“数据没了”？ 如何判断旧数据卷是否仍然存在？ 可通过 Docker 的卷列表与磁盘占用信息进行判断。通常： 最终状态 在完成拆分与修正后，系统应达到以下状态： 总结 本次实践的核心经验可以归纳为一句话： Docker 不会替用户判断应当使用哪个历史数据卷，所有关键数据都必须显式绑定。 通过明确： …
背景 在长期运行的 Docker 环境中，随着容器的反复创建、删除与重建，系统中可能残留未被任何容器使用的卷（volume）。这些卷如果不加区分地清理，存在误删有效数据的风险；如果完全不清理，又会造成系统状态不透明。 本文记录一次严格、可验证的 Docker 卷清理过程，目标是： 一、初步筛选：dangling volume Docker 提供了对“悬空卷（dangling volume）”的定义： 未被任何容器引用的卷 使用以下命令列出： 输出结果为两个卷 ID： 该步骤只能说明： 这些卷当前没有被容器引用 但仍需要进一步验证它们的空间占用与引用状态。 二、空间与引用状态交叉验证 通过 docker system df -v 查看本地卷的使用情况，并重点关注两项信息： 关键结果如下（节选）： 可以确认： 三、判断结论 综合两次验证结果： 卷 ID LINKS SIZE 状态 14ab1c74859f… 0 7.7 kB 未被使用 ebd2fa33478… 0 90 kB 未被使用 结论： 四、安全删除方式 明确目标卷后，采用精确删除而非批量清理： 该方式的优点是： 五、实践原则总结 …
一、问题背景 在一台长期稳定运行的 Linux 服务器上，近期观察到以下现象： 初步判断：瓶颈不在 CPU 和内存，而可能在磁盘 I/O。 二、第一步：整体负载判断（top） 通过 top 观察系统整体状态，发现： 这类特征通常意味着： CPU 有空闲，但进程在等待磁盘 I/O 完成。 此时需要进入磁盘层面分析。 三、第二步：磁盘层分析（iostat） 使用： 重点关注以下指标： 关键观测结果 这说明： 磁盘并非被“大流量读写”压满，而是被 高频小块 I/O（IOPS） 打满。 这是数据库 + 元数据密集型负载的典型特征。 四、第三步：进程级定位（iotop） 使用： 该工具可以实时展示 哪些进程在进行磁盘读写。 观察到的主要 I/O 来源 系统级进程（日志、容器运行时等）均处于正常噪音水平。 五、负载模式分析 综合 top、iostat、iotop 的结果，可以得到完整因果链： 这是一个教科书级的磁盘 I/O 瓶颈案例。 六、可能的直接诱因：文件同步行为 进一步结合业务场景，发现一个高度相关的可能性： 用户正在进行文件同步操作（如私有云客户端同步） 这类同步具有以下特征： 其表现形式与当前监控数据完全一致。 …
写在前面 在现代 Linux（systemd 已成为事实标准）的环境下，很多关机命令在结果上是等价的，但在语义、设计出发点和适用场景上仍然存在差异。本文以实际使用为导向，梳理 systemctl poweroff 与 shutdown now 之间的关系与区别。 结论先行：在 systemd 系统中，它们最终走的是同一条关机路径，但入口不同。 一句话结论 systemctl poweroff：systemd 的原生方式 本质 systemd 实际执行流程 特点 适用场景 shutdown now：传统命令的 systemd 实现 在 systemd 系统中发生了什么 在现代发行版中： 也就是说： shutdown 的额外能力 这是它仍然存在的主要原因： 特点 等价关系整理（systemd 系统） 在 Arch / Debian / Ubuntu / RHEL 7+ 等 systemd 发行版中： 最终效果是相同的：系统正常关机并断电。 …
背景与目标 在无 GPU、仅依赖 CPU 的环境中运行本地大模型，核心目标并不是追求参数规模，而是可长期运行、响应稳定、不干扰其他服务。本文记录了一套经过验证的实践方案：使用 Ollama 作为推理引擎，配合 Open WebUI 提供交互界面，并围绕模型体量、内存常驻、容器健康状态等关键点进行取舍与优化。 运行环境与约束条件 在该条件下，7B 级模型可以加载，但并不适合作为日常默认模型，会带来明显的加载延迟与系统压力。 模型选择策略（按体量与用途分层） 推荐的本地模型梯度 体量 模型示例 主要用途 评价 ~1.5B Qwen2.5 1.5B 兜底、系统繁忙时 极轻量，可长期常驻 ~2B Phi-3 Mini 默认工程模型 推理快、代码/脚本稳定 ~3B Qwen2.5 3B 中文/日语表达 语言自然度更好 ~7B Qwen2.5 7B 实验/对比 不建议常驻 结论：在 CPU-only 环境中，3B 以内是“甜点区间”，7B 更适合作为偶尔实验而非常驻。 部署架构概览 模型文件统一存放在持久化卷中，支持多模型并存，下载一次即可长期复用。 Docker Compose 配置（关键点） 在保持原有结构与注释的前提下，仅增加了模型内存常驻策略： …