写在前面 在现代 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 配置（关键点） 在保持原有结构与注释的前提下，仅增加了模型内存常驻策略： …
本文记录一次在自托管环境中使用 OpenWebUI + Ollama 的实际配置与排查过程，重点包括： 全文基于实践总结，不涉及任何具体主机名、端口、路径等敏感信息。 一、模型存在 ≠ 用户可用：OpenWebUI 的权限设计 在 OpenWebUI 中，即使已经完成以下操作： 普通用户依然可能看到： 模型列表为空 这并不是部署错误，而是 OpenWebUI 的权限模型设计所致。 1. 两个容易混淆的概念 OpenWebUI 将模型拆分为两个维度： 维度 含义 Enable 模型在系统中可用 Access / Visibility 哪些用户可以看到并使用 启用模型 并不等于 普通用户可见。 二、正确的模型授权方式（全局放行） 推荐做法是：由管理员统一放行模型给所有用户。 操作路径（管理员账号） 完成后，模型将正常出现在普通用户的模型列表中。 三、为什么会这样设计？ 这种设计对自托管场景其实是合理的： 对于长期运行的私有实例，这是一个偏“企业级”的设计思路。 四、OpenWebUI 是否支持语音对话？ 简短结论 支持，但不是一键式语音助手。 OpenWebUI 的定位是： UI + 编排层，而不是语音模型本体。 五、语音能力的模块化拆分 …
本文记录一次在 Docker + Nginx 反向代理 场景下，部署 Open WebUI + Ollama 时，遇到 WebSocket 400 与前端解析异常的问题，以及完整的定位与修复过程。本文采用工程记录风格，省略与具体环境强绑定的细节（路径、域名、IP 已脱敏），可作为同类问题的参考模板。 一、问题现象 部署完成后，表现为： 直观感受是： 二、初步排查：确认不是服务本身的问题 1. 确认容器状态 2. 直接访问容器端口 通过本机或内网直接访问 WebUI 暴露端口： 说明： 问题不在 Open WebUI 或 Ollama 本身 三、确认问题边界：反代之后才出问题 当通过 Nginx 反代访问时： 结论很明确： 问题发生在 Nginx → Open WebUI 的反向代理层 四、问题本质分析 1. Open WebUI 使用了什么通信机制？ 2. …
本文记录一次从 Ollama 后端模型服务 到 Open WebUI 前端界面 的完整搭建过程，重点放在 Docker Compose 架构、数据卷持久化、模型管理与常见误区。文中已对主机名、IP、端口等私人信息做统一脱敏处理。 一、目标与前提 目标 前提环境 二、关键概念澄清 在开始之前，先澄清几个容易混淆的点。 1️⃣ Ollama 版本 ≠ 模型大小 二者是完全不同的层级，不要混为一谈。 2️⃣ 7B 是什么 3️⃣ WebUI 与 Ollama 的关系 三、Docker Compose 结构设计 设计原则 四、最终 Docker Compose 配置（脱敏版） 五、启动流程 1️⃣ 启动服务 确认两个容器均为 Up 状态。 2️⃣ 下载模型（重点） 模型必须通过运行中的 Ollama 容器下载，否则会报错。 下载完成后验证： …
摘要 本文记录了一套可复制、低风险的 Open WebUI + Ollama 自托管方案，重点讨论二者是否应部署在同一个 Docker Compose 中、认证与管理员模型的设计，以及符合最小权限原则的日常使用方式。本文面向已有 Docker / 反向代理经验的读者，采用工程化视角，避免与具体路径、端口、域名等敏感信息绑定。 1. Open WebUI 的定位 Open WebUI 是为大语言模型交互设计的通用前端（Chat UI 层）： 其职责聚焦在用户交互、会话管理、权限控制与系统配置，而非模型训练或推理本身。 2. 与 Ollama 放在同一个 Compose 中是否合理 2.1 结论 在“单机一体化服务”的使用场景下，将 Open WebUI 与 Ollama 放在同一个 Docker Compose 文件中是高度合理的默认选择。 2.2 合理性依据 生命周期一致 安全边界清晰 运维成本低 故障域符合依赖关系 2.3 何时不建议放在一起 3. Open …
一、背景与问题定义 在自托管大语言模型（LLM）的实践中，服务器硬件配置对可用模型规模与交互体验有决定性影响。本文以一台典型的企业级服务器为例： 核心问题包括： 本文围绕上述问题，给出工程化、可落地的分析结论。 二、无 GPU 情况下的模型能力边界 1. CPU 推理的本质限制 大语言模型推理的核心计算为大规模矩阵乘法与注意力计算，这类任务具备高度并行特征，但传统 CPU（即使是双路服务器）存在以下天然限制： 以 Xeon E5 v2 世代为例，其指令集通常仅支持 AVX，不支持 AVX2 / AVX-512，这会进一步放大与现代平台的性能差距。 2. 可运行模型规模（以内存为维度） 在使用 4-bit 量化（Q4）模型的前提下，大致内存占用如下： 模型规模 典型内存占用 7B 4–6 GB 14B 8–12 GB 32B 18–24 GB 70B 40–55 GB 从“是否能加载”角度看，128 GB 内存足以容纳 70B 量化模型；但从“是否可用”角度看，结论完全不同。 3. 实际可用档位 在无 GPU 情况下，7B–14B …
本文对比 Tabby 与 Termius 在 SSH 使用场景下的设计理念、安全模型与长期可维护性。文章不涉及具体个人环境细节，聚焦工具本身的结构性差异。 一、问题背景 在多主机运维、个人服务器或实验环境中，SSH 客户端往往会逐渐从“工具”演变为“基础设施的一部分”。 这时，一个关键问题会浮现： SSH 客户端应当只是 OpenSSH 的外壳，还是一个自成体系的连接管理平台？ Tabby 与 Termius，正好代表了这两种截然不同的路线。 二、核心设计理念对比 Tabby：OpenSSH 的 UI 外壳 Tabby 的核心定位非常克制： 换句话说： Tabby 不试图“接管 SSH”，而是选择“服从 SSH”。 Termius：自包含的 SSH 平台 Termius 的设计目标明显不同： 在 Termius 中： SSH 不再是系统能力，而是应用能力。 三、安全模型差异 Tabby 的安全边界 Tabby 的安全边界在操作系统层： Tabby 本身： 这意味着： Tabby 的安全性 …
背景 在现代 Linux 系统中，SSH 公钥认证已成为远程登录与自动化运维的基础设施之一。随着密码学实践的演进，Ed25519 已成为 OpenSSH 官方推荐的默认算法。本文记录在 Linux 环境下生成 Ed25519 SSH key 的最小且安全做法，并澄清若干常见误解，重点面向： 全文仅涉及事实与机制，不包含个人偏好或架构建议。 一、推荐的算法选择 当前时间节点（2025–2026 年前后），在 OpenSSH 环境中： 因此，以下示例均以 Ed25519 为前提。 二、生成 Ed25519 SSH Key 的标准命令 在 Linux 命令行下，生成一把偏安全取向的 Ed25519 key： 参数说明 执行后将生成： 三、关于 passphrase 生成过程中会提示输入 passphrase： 是否设置 passphrase 不影响 key 的数学有效性，但会影响私钥泄露后的风险等级。 四、公钥最后的“名字”是什么？ 典型的 Ed25519 公钥内容如下： 其结构为： 其中： …
目标：在 Android 平台上选择一个 长期可用、离线、可控 的 SSH 登录方案，避免云绑定、避免停更风险，并与桌面端使用习惯保持一致。 一、问题背景 在 Android 上寻找 SSH 客户端时，常见诉求包括： 部分流行客户端在实际使用中暴露出以下问题： 因此需要重新评估 Android 上 SSH 客户端的长期可行性。 二、评估维度 本文主要从以下维度进行筛选： 其中，前 3 条为硬条件。 三、常见方案分析 1. 商业型一体化客户端 特点： 问题： 结论： 不适合作为长期、可控的基础设施工具。 2. 已停止维护的 Android SSH 客户端 特点： 问题： 结论： 停更即不可用，应直接排除。 3. 终端型方案（如完整 Linux 用户态环境） 特点： 问题： 结论： 适合重度用户或统一桌面/移动端工作流，但不符合“轻量点击登录”的需求。 四、最终选择：轻量、离线、长期可用的 SSH …