OpenWebUI

OpenWebUI + Ollama 的模型权限与语音能力整理

本文记录一次在自托管环境中使用 OpenWebUI + Ollama 的实际配置与排查过程，重点包括： 全文基于实践总结，不涉及任何具体主机名、端口、路径等敏感信息。 一、模型存在 ≠ 用户可用：OpenWebUI 的权限设计 在 OpenWebUI 中，即使已经完成以下操作： 普通用户依然可能看到： 模型列表为空 这并不是部署错误，而是 OpenWebUI 的权限模型设计所致。 1. 两个容易混淆的概念 OpenWebUI 将模型拆分为两个维度： 维度 含义 Enable 模型在系统中可用 Access / Visibility 哪些用户可以看到并使用 启用模型 并不等于 普通用户可见。 二、正确的模型授权方式（全局放行） 推荐做法是：由管理员统一放行模型给所有用户。 操作路径（管理员账号） 完成后，模型将正常出现在普通用户的模型列表中。 三、为什么会这样设计？ 这种设计对自托管场景其实是合理的： 对于长期运行的私有实例，这是一个偏“企业级”的设计思路。 四、OpenWebUI 是否支持语音对话？ 简短结论 支持，但不是一键式语音助手。 OpenWebUI 的定位是： UI + 编排层，而不是语音模型本体。 五、语音能力的模块化拆分 …

OpenWebUI

Open WebUI + Ollama 反代与 WebSocket 400 问题排查记录

本文记录一次在 Docker + Nginx 反向代理 场景下，部署 Open WebUI + Ollama 时，遇到 WebSocket 400 与前端解析异常的问题，以及完整的定位与修复过程。本文采用工程记录风格，省略与具体环境强绑定的细节（路径、域名、IP 已脱敏），可作为同类问题的参考模板。 一、问题现象 部署完成后，表现为： 直观感受是： 二、初步排查：确认不是服务本身的问题 1. 确认容器状态 2. 直接访问容器端口 通过本机或内网直接访问 WebUI 暴露端口： 说明： 问题不在 Open WebUI 或 Ollama 本身 三、确认问题边界：反代之后才出问题 当通过 Nginx 反代访问时： 结论很明确： 问题发生在 Nginx → Open WebUI 的反向代理层 四、问题本质分析 1. Open WebUI 使用了什么通信机制？ 2. …

OpenWebUI

自托管 Ollama + Open WebUI 实战记录（Docker Compose）

本文记录一次从 Ollama 后端模型服务 到 Open WebUI 前端界面 的完整搭建过程，重点放在 Docker Compose 架构、数据卷持久化、模型管理与常见误区。文中已对主机名、IP、端口等私人信息做统一脱敏处理。 一、目标与前提 目标 前提环境 二、关键概念澄清 在开始之前，先澄清几个容易混淆的点。 1️⃣ Ollama 版本 ≠ 模型大小 二者是完全不同的层级，不要混为一谈。 2️⃣ 7B 是什么 3️⃣ WebUI 与 Ollama 的关系 三、Docker Compose 结构设计 设计原则 四、最终 Docker Compose 配置（脱敏版） 五、启动流程 1️⃣ 启动服务 确认两个容器均为 Up 状态。 2️⃣ 下载模型（重点） 模型必须通过运行中的 Ollama 容器下载，否则会报错。 下载完成后验证： …

OpenWebUI

Open WebUI 与 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 …

GPU

R720 服务器本地大模型选型与 GPU 加速分析

一、背景与问题定义 在自托管大语言模型（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 …

SSH

Tabby vs Termius：SSH 客户端的两种设计哲学

本文对比 Tabby 与 Termius 在 SSH 使用场景下的设计理念、安全模型与长期可维护性。文章不涉及具体个人环境细节，聚焦工具本身的结构性差异。 一、问题背景 在多主机运维、个人服务器或实验环境中，SSH 客户端往往会逐渐从“工具”演变为“基础设施的一部分”。 这时，一个关键问题会浮现： SSH 客户端应当只是 OpenSSH 的外壳，还是一个自成体系的连接管理平台？ Tabby 与 Termius，正好代表了这两种截然不同的路线。 二、核心设计理念对比 Tabby：OpenSSH 的 UI 外壳 Tabby 的核心定位非常克制： 换句话说： Tabby 不试图“接管 SSH”，而是选择“服从 SSH”。 Termius：自包含的 SSH 平台 Termius 的设计目标明显不同： 在 Termius 中： SSH 不再是系统能力，而是应用能力。 三、安全模型差异 Tabby 的安全边界 Tabby 的安全边界在操作系统层： Tabby 本身： 这意味着： Tabby 的安全性 …

SSH

Linux 下生成与管理 Ed25519 SSH Key 的实践笔记

背景 在现代 Linux 系统中，SSH 公钥认证已成为远程登录与自动化运维的基础设施之一。随着密码学实践的演进，Ed25519 已成为 OpenSSH 官方推荐的默认算法。本文记录在 Linux 环境下生成 Ed25519 SSH key 的最小且安全做法，并澄清若干常见误解，重点面向： 全文仅涉及事实与机制，不包含个人偏好或架构建议。 一、推荐的算法选择 当前时间节点（2025–2026 年前后），在 OpenSSH 环境中： 因此，以下示例均以 Ed25519 为前提。 二、生成 Ed25519 SSH Key 的标准命令 在 Linux 命令行下，生成一把偏安全取向的 Ed25519 key： 参数说明 执行后将生成： 三、关于 passphrase 生成过程中会提示输入 passphrase： 是否设置 passphrase 不影响 key 的数学有效性，但会影响私钥泄露后的风险等级。 四、公钥最后的“名字”是什么？ 典型的 Ed25519 公钥内容如下： 其结构为： 其中： …

SSH

Android SSH 客户端选择与长期可控方案

目标：在 Android 平台上选择一个 长期可用、离线、可控 的 SSH 登录方案，避免云绑定、避免停更风险，并与桌面端使用习惯保持一致。 一、问题背景 在 Android 上寻找 SSH 客户端时，常见诉求包括： 部分流行客户端在实际使用中暴露出以下问题： 因此需要重新评估 Android 上 SSH 客户端的长期可行性。 二、评估维度 本文主要从以下维度进行筛选： 其中，前 3 条为硬条件。 三、常见方案分析 1. 商业型一体化客户端 特点： 问题： 结论： 不适合作为长期、可控的基础设施工具。 2. 已停止维护的 Android SSH 客户端 特点： 问题： 结论： 停更即不可用，应直接排除。 3. 终端型方案（如完整 Linux 用户态环境） 特点： 问题： 结论： 适合重度用户或统一桌面/移动端工作流，但不符合“轻量点击登录”的需求。 四、最终选择：轻量、离线、长期可用的 SSH …

LocalLLM

在低功耗服务器上自托管 Qwen 7B 并通过公网安全访问

随着大模型能力的提升，将语言模型部署到本地服务器（self-hosted）已成为追求数据自治、隐私保护与长期可控性用户的一种现实选择。本文以 Qwen 7B 为例，记录了一种在中低配置服务器上，通过 Docker + Web UI + 公网反向代理 的方式，构建“类似 ChatGPT 的网页使用体验”的完整方案。全文不包含任何真实路径、端口或域名等敏感信息，仅保留通用架构与可复现的工程思路。 一、为什么选择本地部署 Qwen 7B 选择本地部署而非完全依赖云端模型，主要基于以下考虑： 需要明确的是，本地 7B 级模型并非用来“对标”云端超大模型，而是作为一个稳定、可控、随时可用的本地认知工具。 二、硬件与资源需求（现实可行范围） 本文方案基于一台低功耗小型服务器，而非专业 GPU 服务器。 推荐最低配置（CPU-only） 虚拟化场景下的资源分配 在虚拟化环境中（如 PVE / KVM）： 该资源条件下，可长期运行： 三、整体架构设计（不暴露 AI 节点） 核心设计原则 逻辑拓扑（文字描述） 四、容器化部署思路（Docker） 组件拆分 两者均通过 Docker 容器运行，数据通过 volume 持久化。 设计要点 五、公网访问的安全策略 反向代理职责 反向代理服务器承担所有“对外风险”： 必须具备的安全措施 通过该方式，即使域名被扫描，攻击面也仅限于反代层。 六、实际使用体验与定位 …

Proxmox

PVE 宿主网络随机掉线问题的定位与解决（虚拟化宿主通用案例）

适用对象：使用常见集成型以太网控制器的 Proxmox VE 虚拟化宿主机 问题特征：宿主网络随机掉线、时间不固定；重启 networking 后宿主恢复，但虚拟机仍需 stop/start 才能恢复；虚拟机内部 reboot 无效 结论摘要：关闭网卡 offload + 关闭 EEE（Energy Efficient Ethernet），并进行 systemd 永久化，是当前该问题族成功率最高、代价最低、可复现性最强的解决方案之一。 1. 问题现象（行为级描述） 在长期运行的虚拟化环境中，宿主机会出现随机网络中断，具有如下共同特征： 这些现象往往容易被误判为虚拟机、应用或网络配置问题，但多次验证表明：真正进入异常状态的是宿主机网络路径本身。 2. 架构与关键前提 该问题通常出现在如下环境组合中： 与台式机或服务器上常见的独立 PCIe 网卡不同，集成型以太网控制器在电源管理（EEE / ASPM / C-state）与 CPU之间存在更强的耦合，这一差异是问题产生的重要边界条件。 3. 关键认知纠偏 3.1 虚拟机并非问题源头 当宿主网络路径进入异常中间态时，虚拟机只是最先感知失败的一层。 3.2 为什么重启 networking 只能救宿主 networking 服务的重启会： 但它不会销毁或重建已经存在的： 因此，虚拟机仍然绑定在失效的中间层网络对象上。 3.3 为什么必须 …