01
Docker 权限
问题
Open WebUI deployment failed because the account could not access the Docker socket.
回应
Isolated the problem as a permissions issue rather than an application failure and worked through Docker group and service access.
← 返回项目
私有 AI 基础设施
本地 LLM 架构与部署
使用 Ollama、GPU 加速推理、Docker 容器和安全远程管理，设计并运行本地大语言模型（LLM）基础设施。
Ubuntu Server LTSNVIDIA RTX 5070 TiDockerOllamaOpen WebUILocal LLMsSSH10 GbE
项目概览
运行中的实验室- 我的角色
- 独立进行实验室研究、设计和文档编写。
- 实施状态
- 记录的构建建立了无头 Linux AI 服务器、GPU 加速、本地模型托管、容器和远程管理。
- 下一里程碑
- 在声明性能结果之前发布经过清理的部署演练、模型基准条件和可重现的服务配置。
实现代码仓库：尚未发布。
证据与结果
作品展示了什么
远程管理
Ubuntu Server LTS
Docker · Ollama · Open WebUI
本地模型工作负载
已记录的工作
- 针对本地 AI 工作负载验证了 NVIDIA 驱动程序和 RTX 5070 Ti 可用性。
- 通过 Ollama 与容器化服务托管的本地模型。
- 为无头服务器建立基于 SSH 的操作。
概述
为什么我建造它
我想要一个私有环境，可以在其中运行本地语言模型、试验 GPU 加速的工作负载，并了解人工智能基础设施在托管云服务之外的行为方式。
该项目还为我提供了 Linux、Docker、网络、远程管理、安全测试、故障排除和自动化的实用环境。
我的目标不仅仅是在本地运行模型。我想了解它们周围的完整系统——硬件、操作系统、网络、安全、部署、监控和恢复。
建筑
系统设计
01
计算
采用 AMD Ryzen 7 5800XT 的服务器平台，使用 NVIDIA RTX 5070 Ti 加速本地 AI 工作负载。
02
操作系统
通过 SSH 远程管理的无头 Ubuntu Server 环境。
03
人工智能运行时
Ollama 和用于运行、测试和管理本地语言模型的容器化服务。
04
网络
通过 TP-Link TX401 进行 10 GbE 网络，考虑到远程管理和未来分段。
硬件
当前服务器配置
CPU
AMD Ryzen 7 5800XT
主板
ASUS TUF GAMING X570-PLUS (WI-FI)
记忆
128 GB DDR4
GPU
PNY GeForce RTX 5070 Ti
网络
TP-Link TX401 10 GbE
操作系统
Ubuntu Server LTS
存储
多个 NVMe SSD
人工智能堆栈
Ollama · Docker · Open WebUI
实施
构建堆栈
环境是分层构建的，因此每个组件都可以独立测试和维护，而无需将系统视为一个大型应用程序。
现状
专用 AI 服务器采用 AMD Ryzen 7 5800XT、128 GB DDR4 内存和 NVIDIA RTX 5070 Ti。Linux、GPU 加速、模型运行环境、容器和远程管理的基础工作流程已建立，监控和安全自动化仍在持续完善。
已实施
Linux基金会
配置了具有远程管理和稳定网络基线的无头 Ubuntu Server 环境。
已实施
GPU 加速
配置 NVIDIA 驱动程序并验证 RTX 5070 Ti GPU 对本地 AI 工作负载的可用性。
已实施
模型运行时
安装Ollama并直接从服务器测试本地语言模型。
已实施
集装箱服务
使用 Docker 来支持服务，使用 Open WebUI 来进行基于浏览器的模型访问和管理。
已实施
远程管理
构建了通过SSH和远程管理工具进行无头操作的系统。
已实施
专用人工智能硬件
部署了 AMD Ryzen 7 5800XT 平台，配备 128 GB DDR4 和 RTX 5070 Ti。
计划中
安全自动化
添加以安全为中心的工作流程，用于监控、事件分析、响应协助和可重复管理。
计划中
可观察性
扩展日志记录、性能监控、GPU 利用率跟踪和服务运行状况可见性。
故障排除
问题成为项目的一部分
构建不仅仅是为了获得在线服务。每次失败都成为隔离各层、验证假设和改善环境的机会。
故障排除方法
我将硬件、网络、操作系统、驱动程序、容器和模型运行时问题分开，而不是将每个故障都视为应用程序问题。
02
DNS 解析
问题
The server experienced name-resolution problems even while basic network connectivity remained available.
回应
Separated DNS from general connectivity and validated network, resolver, and operating-system configuration independently.
03
GPU 验证
问题
AI services depend on more than the GPU simply appearing in the system.
回应
Verified NVIDIA driver availability and confirmed that the RTX 5070 Ti could actually be used by local AI workloads.
04
模型验证
问题
A successfully loaded model does not automatically mean the environment is useful.
回应
Tested models with logic questions, technical prompts, and infrastructure scenarios to evaluate behavior and practical usefulness.
05
无头政府
问题
The server needs to remain manageable without relying on a local desktop environment.
回应
Built the system around SSH and remote administration so services can be maintained, restarted, and diagnosed remotely.
06
分层诊断
问题
AI infrastructure failures can originate from hardware, drivers, networking, containers, or the model runtime.
回应
Used a layer-by-layer troubleshooting process to reduce guesswork and identify the actual point of failure.
“我们的目标不仅仅是让系统正常工作。而是要了解系统失败的原因、如何恢复以及如何使下一次故障更容易诊断。”
安全
内置安全性
环境
我设计环境时期望远程管理、本地人工智能服务、容器和未来自动化都会产生需要从一开始就解决的安全考虑因素。
设计原理
安全性被视为基础设施设计的一部分，而不是作为系统运行后添加的单独层。
安全优先事项
限制特权访问
控制管理路径
可行的分段服务
通过日志记录保持可见性
文档恢复和重建过程
远程管理
通过受控远程访问而不是依赖于本地桌面会话，设计用于无头管理的服务器。
访问控制
将管理访问与应用程序访问分开，并将特权操作限制为需要它们的帐户和服务。
服务隔离
使用容器和独立的服务来减少不必要的依赖，并使各个组件更易于管理和安全。
网络分段
围绕专用网络边界规划人工智能环境，以便管理接口和人工智能服务可以与一般客户端流量分开。
系统强化
减少不必要的服务，维护操作系统和驱动程序，让服务器专注于其预期的角色。
记录和监控
构建系统健康状况、身份验证活动、容器事件、GPU 利用率和服务故障的集中可见性。
本地数据控制
将选定的人工智能工作负载和数据处理保留在我控制的基础设施内，而不是自动将它们发送到托管模型提供商。
恢复和记录
记录配置更改和部署步骤，以便可以在不依赖内存的情况下重建服务、排除故障和恢复服务。
保护
通过受控访问、强化服务和网络边界减少不必要的暴露。
检测
提高对身份验证、服务运行状况、故障和异常系统行为的可见性。
恢复
保持环境记录并可重复，以便可以以更少的停机时间和猜测来重建失败的组件。
“目标不是让实验室变得复杂。而是让每一层都可理解、可控和可恢复。”
吸取的教训
建造教会了我什么
最有用的经验教训来自于将服务器视为一个完整的基础设施系统，而不仅仅是一台运行模型的机器。
01
在添加人工智能服务之前，从稳定的硬件和网络基线开始。
02
在故障排除时将 GPU 驱动程序、容器、模型运行时和远程访问视为单独的层。
03
记录配置更改，使故障更容易逆转，系统更容易重建。
04
从一开始就在环境中构建安全的远程管理。
关键要点
该项目强调，成功的人工智能基础设施不仅取决于模型性能，还取决于系统管理、网络、安全、文档和恢复。
下一步
实验室的下一步发展
该平台有意可扩展。未来的工作将不再关注添加硬件，而是更多地关注提高可见性、自动化、可重复性和实际安全用例。
01
扩大模型测试和基准测试
02
改进监控和日志记录
03
添加更多以安全为中心的自动化
04
记录可重复的部署工作流程
05
发布视频演练
项目媒体
视频演练稍后推出
未来的演练将记录硬件、部署过程、模型环境、远程管理和安全架构。
更多项目