NAS虚拟化实战：Ubuntu虚拟机+Docker+Ollama搭建本地AI环境

很多人以为在 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 成为一个独立的、可随时推倒重来的应用环境。这样做的价值主要体现在三个方面隔离性AI 工具链涉及的 Python 版本、CUDA 依赖、Docker 网络配置都很“任性”放在虚拟机里不会弄脏 NAS 宿主系统。可迁移性虚拟机就是磁盘镜像备份、迁移、快照都比在 NAS 系统里折腾应用层方便得多。升级自由Ubuntu 的软件仓库比 NAS 厂商维护的仓库更新更快AI 生态里的新工具基本都能第一时间跟上。不过虚拟机也有明显的代价性能损耗。虚拟机会带来 CPU 开销和内存双重占用内存不足的 NAS 跑起虚拟机来会异常吃力。这篇文章说的“轻量化”有三个前提x86 架构、至少 8GB 物理内存、安装时合理裁剪 Ubuntu 的桌面组件。如果拿到手的是 ARM 架构、内存只有 2GB 的入门级 NAS这个玩法基本和你无关建议老老实实用 Docker 容器跑一些轻量工具。2. NAS 虚拟化的核心概念与适用场景2.1 虚拟机与容器不是一回事NAS 虚拟化就是在 NAS 的底层系统上运行一台或多台完整的虚拟机。它和 Docker 容器虽然都有“隔离”的意味但本质区别很大。对比项虚拟机VMDocker 容器隔离级别独立内核完全隔离共享宿主内核进程级隔离镜像大小数 GB 起几十到几百 MB启动速度慢快资源占用高低适用场景运行完整系统、异构应用单应用、微服务、工具链对 NAS 的要求需要硬件虚拟化Intel VT-x / AMD-V需要 Docker 内核支持如果只是想跑一个 AI 推理服务容器往往是更轻盈的选择但如果想要一个可以随便折腾、不干扰 NAS 文件服务的独立系统虚拟机更适合。而且虚拟机内部还可以再跑 Docker所以这两者其实是互补关系不是二选一。2.2 哪些 NAS 适合跑 Ubuntu 虚拟机主流 NAS 品牌对虚拟化的支持差异比较大买之前或者折腾之前最好先看清楚自己的型号在哪个档位NAS 系统是否支持虚拟机说明群晖 DSM部分型号支持Virtual Machine Manager需要 x86 型号且内存充足威联通 QTS支持Virtualization Station飞牛 fnOS支持系统自带虚拟机应用界面简单入门级 ARM NAS基本不支持建议放弃虚拟机改用 Docker 容器跑轻量工具如果你手里的 NAS 是入门级 ARM 机型最理智的做法是不要强行折腾虚拟机。内存 4GB 以下跑 Ubuntu 加模型推理体验会非常差而且 ARM 架构下很多 AI 镜像没有现成版本很容易把自己绕进依赖地狱。3. 环境准备与前置条件3.1 硬件与软件清单在开始之前先确认几个条件任何一个不满足都可能造成安装后卡顿或失败NAS CPUx86 架构支持硬件虚拟化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 虚拟机的默认配置。建议在创建虚拟机前完成以下设置在 NAS 上单独建一个共享文件夹比如vm-storage专门存放虚拟机镜像和 ISO 文件。确保 NAS 系统有足够空间并确认 SSD 池健康状态正常。固定 NAS 的 IP 地址避免重启后虚拟机网络环境跟着变化。如果使用群晖 VMM 或其他同类工具确认存储池是完整健康状态。4. 创建 Ubuntu 虚拟机4.1 在 NAS 虚拟化管理界面中创建虚拟机不管用哪个 NAS 系统创建虚拟机的流程都是类似的准备 ISO、创建虚拟机、分配硬件资源、挂载 ISO、启动安装。下面以通用 NAS 虚拟化管理界面为例给出完整配置步骤登录 NAS 的虚拟机管理应用。选择“新建虚拟机”或“创建”按钮。填写虚拟机名称例如ubuntu-ai。选择操作系统类型为 Linux版本选择 Ubuntu64 位。分配 CPU 核心数推荐 2 核起步如果 NAS 是 4 核以上并且后续要跑推理可以给 4 核。分配内存推荐 4096 MB最低不要低于 2048 MB。创建虚拟磁盘推荐 40GB 以上格式可以选择 qcow2 或 vmdk。挂载 Ubuntu ISO 镜像。确认配置后启动虚拟机。这里最容易出错的地方是很多人把 CPU 和内存全部分配给虚拟机导致 NAS 宿主系统本身资源不足连管理界面都打不开虚拟机安装自然看起来像“卡死”。在设计上要留出至少 1GB 到 2GB 内存给 NAS 宿主系统。4.2 启动虚拟机并进入 Ubuntu 安装界面启动虚拟机后通过 NAS 虚拟化管理界面提供的 VNC 或 HTML5 控制台打开虚拟机屏幕。如果能够看到 GRUB 菜单或 Ubuntu 安装启动菜单说明虚拟机启动流程正常。如果屏幕一直是黑色或者在 Ubuntu 启动画面停留几分钟不动这就是典型的安装卡死现象需要进入下一章寻找原因。5. Ubuntu 安装卡死的常见原因与解决方案5.1 卡死不是单一原因虚拟机安装卡死是一个很综合的现象。很多人习惯性怪 Ubuntu 镜像不好但其实大部分问题出在虚拟机配置层面。根据实际经验整理主要原因集中在下面几个方面问题现象可能原因排查方式解决方案黑屏无任何输出CPU 虚拟化未开启查看 NAS CPU 是否支持 VT-x/AMD-V在 BIOS 或 NAS 设置中开启硬件虚拟化卡在 Ubuntu 启动 Logo显卡/控制台兼容问题查看虚拟机日志在 GRUB 中加 nomodeset 参数安装到一半无响应磁盘 I/O 过慢检查存储池负载把虚拟磁盘迁移到 SSD 池频繁蓝屏或系统崩溃虚拟机内存不足查看 NAS 监控面板增加内存分配或改用 Server 版安装后重启无法开机引导加载器配置错误重新进入安装界面检查分区手动分区时正确设置 /boot/efi很多人在网上搜索“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 虚拟机工具的默认固件是 BIOSLegacy两者不匹配也容易导致安装失败。建议在创建虚拟机时根据 NAS 虚拟化工具提供的引导模式选项选择 UEFI同时在 Ubuntu 安装手动分区时创建/boot/efi分区。如果 NAS 虚拟机工具只支持 BIOS那么分区时不要选择 GPTUEFI 方式改成与传统 BIOS 匹配的 MBR 方式。常见组合参考Ubuntu 版本NAS 虚拟机固件分区模式建议Ubuntu Server 22.04 LTSUEFIGPT推荐Ubuntu Server 24.04 LTSUEFIGPT推荐Ubuntu Server 22.04 LTSBIOSMBR兼容旧工具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.yamlnetwork: 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 启用 SSHNAS 上的虚拟机基本不可能一直开着控制台操作配置好 SSH 才能远程管理。sudo apt update sudo apt install -y openssh-server sudo systemctl enable --now ssh确认 SSH 可以访问ssh ubuntu192.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 官方仓库并安装 Dockercurl -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 组避免每条命令都加 sudosudo usermod -aG docker $USER newgrp docker检查 Docker 是否正常docker --version如果因为网络问题导致 Docker 官方仓库无法访问可以先把 Ubuntu 软件源切换为国内镜像源再重试。这一系列操作涉及系统软件源修改建议确认当前网络环境后再执行。7.2 使用 Docker 部署 OllamaOllama 是一个本地模型运行工具它最大的价值是把“下载模型、启动推理、调用接口”这几个步骤压缩到极简。对于 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.ymlservices: 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 ollama7.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字段说明推理服务已经正常工作。后续可以结合编程语言封装成接口比如用 Pythonimport requests url http://192.168.1.199:11434/api/generate data { model: qwen2.5:1.5b, prompt: 写一段 Python 代码打印斐波那契数列, stream: False } resp requests.post(url, jsondata) print(resp.json().get(response, 无响应))这里强调一下192.168.1.199是示例 IP实际使用时请替换为你自己的 Ubuntu 虚拟机地址。8. 运行结果与效果验证在完成上述部署后需要验证整条链路是否正常工作。8.1 验证步骤清单确认虚拟机状态在 NAS 虚拟化管理界面中虚拟机ubuntu-ai状态为“正在运行”。确认 SSH 能登录ssh ubuntu虚拟机IP能进入系统。确认 Docker 状态docker ps能看到ollama容器处于 Up 状态。确认 HTTP 接口curl -s http://虚拟机IP:11434/api/version返回版本 JSON。确认模型推理执行上文的一次性推理命令后能看到文本返回。8.2 常见验证失败点验证项失败现象排查建议虚拟机状态NAS 控制台显示已停止查看虚拟机日志确认是否内存或存储不足SSH 登录连接超时检查桥接网络是否配置正确Ubuntu 是否获得有效 IPDocker 启动容器反复重启查看docker logs ollama输出模型下载下载超时或报错确认 Ubuntu 是否有稳定网络连接或换用更小模型HTTP 接口curl 无响应检查防火墙确认 11434 端口未被屏蔽9. 常见问题与排查思路9.1 虚拟机安装 Ubuntu 一直转圈问题现象可能原因排查方式解决方案启动后一直转圈虚拟机显示驱动不兼容在 GRUB 中添加 nomodeset重新启动并编辑启动参数安装到一半卡住磁盘 I/O 慢或资源不足查看 NAS 存储池和内存监控迁移虚拟磁盘到 SSD降低桌面版为 Server 版9.2 NAS 本地无法访问 Ubuntu“本地无法访问”通常有几个原因虚拟机的网络模式仍然是 NAT没有暴露端口给局域网。桥接模式下 Ubuntu 没有获得正确的 IP。防火墙拦截了访问。排查顺序建议先确认虚拟机内 IP - 再确认网关 - 再确认从其他机器 ping - 再确认端口 - 最后检查防火墙查看 Ubuntu 防火墙状态sudo ufw status如果防火墙开启且没有放行 11434 端口需要先放行sudo ufw allow 11434/tcp9.3 Docker 安装 Ollama 后无法拉取模型问题现象可能原因排查方式解决方案拉取模型超时网络到模型仓库不稳定查看 Docker 日志检查网络连通性后重试容器无法连接网络Docker 网桥配置异常检查/etc/docker/daemon.json重启 docker 服务重启 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 -u11. 总结与后续学习方向这篇文章完成了从 NAS 落到 Ubuntu、再落到轻量 AI 推理环境的一条完整链路。核心结论可以概括为三点在普通 NAS 上部署 Ubuntu 虚拟机最大的价值不是性能而是隔离性与可维护性。Ubuntu 安装卡死大多不是镜像问题而是虚拟机配置与引导方式不匹配调整引导参数或改用 Server 版基本能解决。用 Docker Ollama 跑轻量模型是当前在 NAS 上做本地 AI 最值得走的一条路资源和难度都比较可控。下一步值得继续实践的方向包括把 Ollama 接入更多脚本工具、尝试安装支持 GPU 加速的模型推理环境、给模型接口加鉴权、或者把 Ubuntu 虚拟机接入自动化监控体系。建议收藏这份操作路径实际动手时先从最小配置开始确认每一步都符合预期再逐步增加资源。任何时候遇到问题回到虚拟机日志和 NAS 监控面板通常比盲目重装更有效。