企业官网建设流程全解析

很多人以为在 NAS 上跑 AI，就是直接在 NAS 的系统里装个镜像、拉个模型，然后就能舒舒服服地在局域网里聊天问答了。等你真正动手就会发现，各种问题接踵而至：虚拟机安装 Ubuntu 一直转圈，装到一半黑屏，好不容易装完系统，又在网络配置上卡住，最后连“本地无法访问”这个坎都迈不过去。真正痛苦的往往不是 AI 模型本身，而是最底层的虚拟机环境搭建。

这篇文章的路线图很直接：先在 NAS 上创建一台 Ubuntu 虚拟机，解决安装卡死的问题，然后在这台虚拟机里用 Docker + Ollama 跑起轻量本地 AI 推理环境。读完你可以少走很多弯路，从“NAS 只当存储”升级到“NAS 兼任轻量 AI 服务器”。

1. 为什么要用 NAS 跑 Ubuntu，而不是直接把工具装在 NAS 里？

先放下“本地 AI 部署”这顶大帽子，回到最基础的问题：你的 NAS 是什么架构，有多少内存，能不能折腾虚拟机？

现在家用 NAS 的硬件跨度非常大，低端入门级用的是 ARM 芯片，中高端则基本是 x86 平台。很多人看到别人在 NAS 上跑大模型，扭头就在自己的 NAS 上装一个 Docker 容器，结果要么架构不兼容，要么内存直接爆掉，要么权限报错到怀疑人生。

这里真正容易踩坑的地方是：NAS 的系统（比如群晖 DSM、威联通 QTS、飞牛 fnOS）虽然是基于 Linux 开发的，但它们的软件仓库、内核模块、权限模型都是厂商裁剪过的。直接在这种系统里安装复杂的 AI 工具链，往往不是装不上，就是权限不够。一旦出了问题，日志和依赖链路都很难排查，因为很多东西被系统层隐藏了。

所以更稳妥的做法是：在 NAS 里创建一台 Ubuntu 虚拟机，让 Ubuntu 成为一个独立的、可随时推倒重来的应用环境。这样做的价值主要体现在三个方面：

1. 隔离性：AI 工具链涉及的 Python 版本、CUDA 依赖、Docker 网络配置都很“任性”，放在虚拟机里不会弄脏 NAS 宿主系统。
2. 可迁移性：虚拟机就是磁盘镜像，备份、迁移、快照都比在 NAS 系统里折腾应用层方便得多。
3. 升级自由：Ubuntu 的软件仓库比 NAS 厂商维护的仓库更新更快，AI 生态里的新工具基本都能第一时间跟上。

不过，虚拟机也有明显的代价：性能损耗。虚拟机会带来 CPU 开销和内存双重占用，内存不足的 NAS 跑起虚拟机来会异常吃力。这篇文章说的“轻量化”有三个前提：x86 架构、至少 8GB 物理内存、安装时合理裁剪 Ubuntu 的桌面组件。如果拿到手的是 ARM 架构、内存只有 2GB 的入门级 NAS，这个玩法基本和你无关，建议老老实实用 Docker 容器跑一些轻量工具。

2. NAS 虚拟化的核心概念与适用场景

2.1 虚拟机与容器不是一回事

NAS 虚拟化，就是在 NAS 的底层系统上运行一台或多台完整的虚拟机。它和 Docker 容器虽然都有“隔离”的意味，但本质区别很大。

如果只是想跑一个 AI 推理服务，容器往往是更轻盈的选择；但如果想要一个可以随便折腾、不干扰 NAS 文件服务的独立系统，虚拟机更适合。而且，虚拟机内部还可以再跑 Docker，所以这两者其实是互补关系，不是二选一。

2.2 哪些 NAS 适合跑 Ubuntu 虚拟机

主流 NAS 品牌对虚拟化的支持差异比较大，买之前或者折腾之前最好先看清楚自己的型号在哪个档位：

如果你手里的 NAS 是入门级 ARM 机型，最理智的做法是不要强行折腾虚拟机。内存 4GB 以下跑 Ubuntu 加模型推理，体验会非常差，而且 ARM 架构下很多 AI 镜像没有现成版本，很容易把自己绕进依赖地狱。

3. 环境准备与前置条件

3.1 硬件与软件清单

在开始之前，先确认几个条件，任何一个不满足都可能造成安装后卡顿或失败：

• NAS CPU：x86 架构，支持硬件虚拟化（Intel VT-x 或 AMD-V）。大部分中端以上群晖、威联通、飞牛都满足。
• NAS 内存：建议不低于 8GB，虚拟机分配给 Ubuntu 的内存建议 2GB 起步。跑 7B 参数模型时，建议分配给虚拟机 4GB 以上。
• NAS 存储：系统盘和数据盘分开是理想状态。Ubuntu 虚拟机镜像建议放在 SSD 池里，机械硬盘上写镜像会明显拖慢安装速度。
• 镜像文件：Ubuntu Server 或 Ubuntu Desktop 的 ISO。Server 版更轻量，Desktop 版则适合有图形界面操作习惯的人。
• 虚拟机管理入口：不同 NAS 系统有不同的 Web 管理界面，但流程基本类似。

镜像建议选择 Ubuntu 22.04 LTS 或 Ubuntu 24.04 LTS。LTS 版本维护周期长，AI 工具链生态兼容性也更好。具体版本以 Ubuntu 官方下载页为准，本文主要演示通用思路，不绑定某一个具体版本号。

3.2 创建虚拟机前的 NAS 设置

这一步看起来简单，却是最容易被忽略的。很多人在创建虚拟机后安装卡死，原因不在 Ubuntu 镜像，而在于 NAS 虚拟机的默认配置。

建议在创建虚拟机前完成以下设置：

1. 在 NAS 上单独建一个共享文件夹，比如vm-storage，专门存放虚拟机镜像和 ISO 文件。
2. 确保 NAS 系统有足够空间，并确认 SSD 池健康状态正常。
3. 固定 NAS 的 IP 地址，避免重启后虚拟机网络环境跟着变化。
4. 如果使用群晖 VMM 或其他同类工具，确认存储池是完整健康状态。

4. 创建 Ubuntu 虚拟机

4.1 在 NAS 虚拟化管理界面中创建虚拟机

不管用哪个 NAS 系统，创建虚拟机的流程都是类似的：准备 ISO、创建虚拟机、分配硬件资源、挂载 ISO、启动安装。

下面以通用 NAS 虚拟化管理界面为例，给出完整配置步骤：

1. 登录 NAS 的虚拟机管理应用。
2. 选择“新建虚拟机”或“创建”按钮。
3. 填写虚拟机名称，例如ubuntu-ai。
4. 选择操作系统类型为 Linux，版本选择 Ubuntu（64 位）。
5. 分配 CPU 核心数：推荐 2 核起步，如果 NAS 是 4 核以上并且后续要跑推理，可以给 4 核。
6. 分配内存：推荐 4096 MB，最低不要低于 2048 MB。
7. 创建虚拟磁盘：推荐 40GB 以上，格式可以选择 qcow2 或 vmdk。
8. 挂载 Ubuntu ISO 镜像。
9. 确认配置后启动虚拟机。

这里最容易出错的地方是：很多人把 CPU 和内存全部分配给虚拟机，导致 NAS 宿主系统本身资源不足，连管理界面都打不开，虚拟机安装自然看起来像“卡死”。在设计上，要留出至少 1GB 到 2GB 内存给 NAS 宿主系统。

4.2 启动虚拟机并进入 Ubuntu 安装界面

启动虚拟机后，通过 NAS 虚拟化管理界面提供的 VNC 或 HTML5 控制台打开虚拟机屏幕。

如果能够看到 GRUB 菜单或 Ubuntu 安装启动菜单，说明虚拟机启动流程正常。如果屏幕一直是黑色，或者在 Ubuntu 启动画面停留几分钟不动，这就是典型的安装卡死现象，需要进入下一章寻找原因。

5. Ubuntu 安装卡死的常见原因与解决方案

5.1 卡死不是单一原因

虚拟机安装卡死，是一个很综合的现象。很多人习惯性怪 Ubuntu 镜像不好，但其实大部分问题出在虚拟机配置层面。根据实际经验整理，主要原因集中在下面几个方面：

很多人在网上搜索“VMware 虚拟机一直转圈”“虚拟机安装 Linux 蓝屏”时，其实遇到的问题和 NAS 场景是相通的。区别只是 NAS 上的虚拟机管理器从电脑上的 VMware Workstation 换成了 NAS 自己的虚拟化管理工具，核心原因是类似的。

5.2 最常用的三个解决手段

手段一：安装启动时添加内核参数。

在 Ubuntu 安装启动菜单出现时，按下键盘上的e键，进入编辑模式，在 Linux 行末尾加上：

nomodeset

然后按 F10 继续启动。这个参数的作用是让内核使用基本显示驱动，绕开部分虚拟显卡兼容问题。很多黑屏问题靠这一步就能解决。

手段二：使用 Ubuntu Server 镜像代替桌面版。

Ubuntu Desktop 安装器对图形化环境要求更高，在 NAS 虚拟机这类虚拟化环境里更容易出现卡死。如果只是打算在上面跑 Docker 和 Ollama，直接下载 Ubuntu Server 镜像，用最小化安装就够了。安装完成后通过命令行安装 Docker，整个过程更稳定。

手段三：检查虚拟机引导模式和分区方式。

现在 Ubuntu 默认使用 UEFI 引导。如果 NAS 虚拟机工具的默认固件是 BIOS（Legacy），两者不匹配也容易导致安装失败。建议在创建虚拟机时，根据 NAS 虚拟化工具提供的引导模式选项选择 UEFI，同时在 Ubuntu 安装手动分区时创建/boot/efi分区。如果 NAS 虚拟机工具只支持 BIOS，那么分区时不要选择 GPT+UEFI 方式，改成与传统 BIOS 匹配的 MBR 方式。

常见组合参考：

5.3 安装卡死后的操作思路

如果已经尝试多次仍然卡死，不要反复重装。更稳妥的方式是：删除当前虚拟机，重新创建一台，但把虚拟磁盘位置换到另一个存储池，或者使用之前备份的虚拟磁盘镜像。一个很重要的原则：不要在生产 NAS 上直接反复测试虚拟机配置，所有实验优先在非关键数据存储池或者测试机上进行。如果你需要在生产 NAS 上操作，务必先备份重要数据，并确保操作过程可控。

6. 安装完成后的 Ubuntu 基础配置

安装完成后，第一件事不是急着装 AI 工具，而是把基础网络和 SSH 环境准备好。这一步如果没做好，后面装完 AI 环境你会发现想远程操作都很痛苦。

6.1 确认网络配置

Ubuntu Server 安装完成并重启后，通过 NAS 虚拟机控制台登录，执行：

ip addr

如果 IP 地址是169.254.x.x，说明没有获得 DHCP 地址。这时需要检查 NAS 虚拟机的网络模式是否设置为桥接或 NAT。推荐使用桥接模式，这样 Ubuntu 可以像普通设备一样被局域网内其他机器直接访问。

在 Ubuntu 22.04 中，网络配置文件路径是/etc/netplan/。如果使用 DHCP，最简单的方式是编辑/etc/netplan/00-installer-config.yaml：

network: ethernets: ens18: dhcp4: true version: 2

然后应用配置：

sudo netplan apply

如果设置了固定 IP，可以把dhcp4: true改成类似：

network: ethernets: ens18: dhcp4: false addresses: - 192.168.1.199/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 192.168.1.1 - 223.5.5.5 version: 2

注意：固定 IP 要避开家庭局域网里的 DHCP 分配区间，否则容易出现 IP 冲突，导致“本地无法访问”的假故障。另外，网络接口名不一定就是ens18，实际名称以ip addr输出为准。

6.2 启用 SSH

NAS 上的虚拟机基本不可能一直开着控制台操作，配置好 SSH 才能远程管理。

sudo apt update sudo apt install -y openssh-server sudo systemctl enable --now ssh

确认 SSH 可以访问：

ssh ubuntu@192.168.1.199

如果虚拟机的网络是桥接模式，局域网内其他电脑就能直接访问这台 Ubuntu；如果是 NAT 模式，就只能在 NAS 宿主上做端口转发，不太推荐。

7. 在 Ubuntu 上部署轻量本地 AI 运行环境

前面的所有工作，最终都是为了这一节。这里选择 Docker + Ollama 的组合，因为它是目前在 x86 Linux 上跑本地模型最省事、最不容易出错的方案之一。

7.1 安装 Docker

先更新系统和安装依赖：

sudo apt update sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release

添加 Docker 官方仓库并安装 Docker：

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

安装完成后，让当前用户加入 docker 组，避免每条命令都加 sudo：

sudo usermod -aG docker $USER newgrp docker

检查 Docker 是否正常：

docker --version

如果因为网络问题导致 Docker 官方仓库无法访问，可以先把 Ubuntu 软件源切换为国内镜像源再重试。这一系列操作涉及系统软件源修改，建议确认当前网络环境后再执行。

7.2 使用 Docker 部署 Ollama

Ollama 是一个本地模型运行工具，它最大的价值是把“下载模型、启动推理、调用接口”这几个步骤压缩到极简。对于 NAS 超轻量场景，非常适合。

在 Ubuntu 上直接通过 Docker 运行：

docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama:latest

参数说明：

• -d：后台运行。
• --name ollama：容器名称。
• -p 11434:11434：宿主机端口 11434 映射到容器内 11434。
• -v ollama_data:/root/.ollama：创建一个 Docker Volume，用来持久化保存模型文件，防止容器删除后模型丢失。

如果使用 Docker Compose 管理，可以新建docker-compose.yml：

services: ollama: image: ollama/ollama:latest container_name: ollama ports: - "11434:11434" volumes: - ollama_data:/root/.ollama restart: unless-stopped volumes: ollama_data:

启动 Compose 服务：

docker compose up -d

查看容器状态：

docker ps

如果容器状态不是Up，查看日志：

docker logs ollama

7.3 下载并运行模型

Ollama 官方仓库提供很多模型，从 0.5B 到几十 B 的都有。NAS 上内存有限，建议从小模型开始。

执行以下命令拉取一个小模型并运行：

docker exec -it ollama ollama run qwen2.5:1.5b

第一次运行会先下载模型，下载完成后会进入交互式对话界面，可以直接输入中文问题测试。

也可以直接执行一次性推理命令：

docker exec ollama ollama run qwen2.5:1.5b "用一句话解释什么是 NAS"

如果内存比较充足（虚拟机分配了 8GB 以上），可以尝试更大的模型，比如：

docker exec -it ollama ollama run qwen2.5:7b

但要注意：模型参数越大，对内存和 CPU 的占用越高。在 NAS 虚拟机上跑 7B 模型，需要预留足够的内存，并且推理速度可能不如高性能本地方便。

7.4 通过 HTTP 接口调用本地 AI

本地部署的价值不只是能在命令行聊天，另一个关键是提供 HTTP 接口，方便其他设备调用。Ollama 启动后默认监听 11434 端口，在 Ubuntu 上执行：

curl -s http://localhost:11434/api/generate -d '{ "model": "qwen2.5:1.5b", "prompt": "你好，介绍一下你自己", "stream": false }'

如果返回结果中包含"response"字段，说明推理服务已经正常工作。后续可以结合编程语言封装成接口，比如用 Python：

import requests url = "http://192.168.1.199:11434/api/generate" data = { "model": "qwen2.5:1.5b", "prompt": "写一段 Python 代码，打印斐波那契数列", "stream": False } resp = requests.post(url, json=data) print(resp.json().get("response", "无响应"))

这里强调一下：192.168.1.199是示例 IP，实际使用时请替换为你自己的 Ubuntu 虚拟机地址。

8. 运行结果与效果验证

在完成上述部署后，需要验证整条链路是否正常工作。

8.1 验证步骤清单

1. 确认虚拟机状态：在 NAS 虚拟化管理界面中，虚拟机ubuntu-ai状态为“正在运行”。
2. 确认 SSH 能登录：ssh ubuntu@虚拟机IP能进入系统。
3. 确认 Docker 状态：docker ps能看到ollama容器处于 Up 状态。
4. 确认 HTTP 接口：curl -s http://虚拟机IP:11434/api/version返回版本 JSON。
5. 确认模型推理：执行上文的一次性推理命令后，能看到文本返回。

8.2 常见验证失败点

9. 常见问题与排查思路

9.1 虚拟机安装 Ubuntu 一直转圈

9.2 NAS 本地无法访问 Ubuntu

“本地无法访问”通常有几个原因：

1. 虚拟机的网络模式仍然是 NAT，没有暴露端口给局域网。
2. 桥接模式下 Ubuntu 没有获得正确的 IP。
3. 防火墙拦截了访问。

排查顺序建议：

先确认虚拟机内 IP -> 再确认网关 -> 再确认从其他机器 ping -> 再确认端口 -> 最后检查防火墙

查看 Ubuntu 防火墙状态：

sudo ufw status

如果防火墙开启，且没有放行 11434 端口，需要先放行：

sudo ufw allow 11434/tcp

9.3 Docker 安装 Ollama 后无法拉取模型

重启 Docker 服务：

sudo systemctl restart docker

这里有一个风险提示：如果在生产 NAS 上操作，重启 Docker 服务会影响所有依赖 Docker 的应用，务必先确认没有正在执行的重要任务。

10. 最佳实践与工程建议

10.1 资源分配策略

NAS 虚拟机的资源分配要遵循“宿主优先”原则。NAS 的核心功能是存储，不能因为跑 AI 虚拟机而让存储服务失去响应。建议：

• 物理内存 16GB 的 NAS，虚拟机最多分配 8GB。
• 物理内存 8GB 的 NAS，虚拟机分配 2GB 到 4GB 就够跑轻量模型。
• 不要给虚拟机分配所有 CPU 核心，至少保留一个核心给 NAS 宿主系统。

10.2 使用快照和备份

在 Ubuntu 系统配置完成后，建议在 NAS 虚拟机管理界面创建一个快照。快照能让你在后续安装各种依赖出现问题时，一键恢复到干净状态。备份频率可以按“系统刚装完、AI 环境刚配好、模型使用稳定”这三个节点来做。

10.3 把模型数据挂载到 NAS 存储池

如果使用 Docker Volume 保存模型数据，模型文件会存放在 Ubuntu 虚拟机的虚拟磁盘内。从长期使用角度看，更推荐把 Docker 的ollama_data数据卷挂载到 NAS 的共享文件夹上，这样即使虚拟机被删除，模型文件依然保留。

做法：创建 NFS 或 SMB 挂载，然后在 Docker Compose 中替换 volume 定义：

services: ollama: image: ollama/ollama:latest container_name: ollama ports: - "11434:11434" volumes: - /mnt/nas/ollama:/root/.ollama restart: unless-stopped

在 Ubuntu 中挂载 NFS 前需要安装客户端：

sudo apt install -y nfs-common sudo mkdir -p /mnt/nas/ollama sudo mount -t nfs 192.168.1.10:/volume1/ollama /mnt/nas/ollama

注意：NFS 挂载权限问题很多，如果出现“NAS 没有读写权限”，优先检查 NAS 共享目录的读写权限设置和 UID/GID 映射。

10.4 安全边界

本地 AI 环境也需要基本安全意识：

• Ubuntu 用户名和密码不要使用默认弱密码。
• SSH 建议禁用 root 远程登录。
• 如果对外网开放了端口，一定要在防火墙层限制来源 IP。
• Ollama 默认没有认证，不建议直接暴露到公网，尽量限制在局域网使用。

如果确实需要跨网络访问，更稳妥的做法是通过带认证的反向代理或虚拟专用网络进入家庭网络，而不是直接暴露裸端口。在整个访问链路中，始终遵循最小权限原则，只放行必要的端口和来源。

10.5 日志与监控

建议定期查看虚拟机的 CPU 和内存占用。如果 NAS 长时间处于高负载，会很影响存储响应，甚至导致硬盘寿命缩短。可以在 Ubuntu 中开启系统负载日志：

sudo apt install -y sysstat sudo systemctl enable --now sysstat

后续可以按天查看负载情况：

sar -u

11. 总结与后续学习方向

这篇文章完成了从 NAS 落到 Ubuntu、再落到轻量 AI 推理环境的一条完整链路。核心结论可以概括为三点：

1. 在普通 NAS 上部署 Ubuntu 虚拟机，最大的价值不是性能，而是隔离性与可维护性。
2. Ubuntu 安装卡死大多不是镜像问题，而是虚拟机配置与引导方式不匹配，调整引导参数或改用 Server 版基本能解决。
3. 用 Docker + Ollama 跑轻量模型是当前在 NAS 上做本地 AI 最值得走的一条路，资源和难度都比较可控。

下一步值得继续实践的方向包括：把 Ollama 接入更多脚本工具、尝试安装支持 GPU 加速的模型推理环境、给模型接口加鉴权、或者把 Ubuntu 虚拟机接入自动化监控体系。

建议收藏这份操作路径，实际动手时，先从最小配置开始，确认每一步都符合预期，再逐步增加资源。任何时候遇到问题，回到虚拟机日志和 NAS 监控面板，通常比盲目重装更有效。