NAS虚拟机部署Ubuntu:打造轻量AI运行环境的完整指南 有一台 NAS稳定跑了几年主力功能一直是存照片、备份文件、挂下载任务。直到某天你想在本地跑一个 AI 相关的轻量任务比如对一批文档做批量处理、跑一个小模型试试效果才发现 NAS 自带的套件环境并不顺手版本太老、依赖装不上、权限又受限。于是不少人会想到一条路——在 NAS 的虚拟机里装一个 Ubuntu再在这个 Ubuntu 里搭建一套本地的 AI 运行环境。这个思路本身没有错。但我在实际操作中发现真正难住大多数人的不是 Ubuntu 安装命令而是两个并不起眼的问题第一NAS 的虚拟化能力到底有多少余量第二安装过程中各种“卡死”到底是什么原因导致的。如果把这两点搞清楚了后面的事情就顺了。这篇文章会从一个比较务实的角度把 NAS 部署 Ubuntu 的完整过程拆开先判断你的设备适不适合再走一遍安装流程然后把最常见的卡死问题按排查顺序理清最后落地一个轻量的本地 AI 环境。核心想说明一句话NAS 跑 Ubuntu 的真正价值不是把一台存储设备变成全能服务器而是用最小的代价获得一个统一、可控、能备份、能回滚的 Linux 实验环境。1. 先搞清楚在 NAS 上跑 Ubuntu真正解决的是什么1.1 为什么不是直接用 Docker 套件如果你的 NAS 已经能装 Docker第一反应往往是“那我直接在 NAS 的 Docker 里跑镜像不就行了”。确实很多轻量应用用 Docker 套件就能解决但 Docker 套件不等同一个完整的 Linux 环境。在实际项目里你会遇到这些限制有些工具链需要内核模块比如特定的网络桥接、文件系统驱动有些脚本依赖系统级服务比如 cron、systemd、特定用户权限有些编译任务需要 gcc、make、python 依赖树在套件容器里装很别扭NAS 的 Docker 界面通常只提供容器管理不提供完整的系统控制权。Ubuntu 虚拟机相当于把“系统级控制权”从 NAS 套件手中拿了回来。之后你在这个 Ubuntu 里再跑 Docker就是一套标准的 Linux 工作流网上绝大多数教程都能直接参考不用再适配 NAS 的私有环境。1.2 一个容易被忽视的收益环境收敛我见过不少人在自己的 Mac 或 Windows 电脑上尝试跑 AI 项目结果系统被各种 Python 包、CUDA 依赖、模型文件搞得一塌糊涂。后来换了一台机器同样的东西又得重新装一遍。NAS 虚拟机的价值其实是一台随时可重建的“实验机”。你不需要占用自己主力电脑的环境也不需要在多个机器之间同步依赖。所有 AI 相关的实验、脚本、镜像、数据都收拢在 NAS 里的一个 Ubuntu 虚拟机上。环境坏了直接回滚快照或重装虚拟机代价非常低。所以主判断是这个方案真正解决的不是“算力不够”而是“环境不收敛”。1.3 但这不是说任何 NAS 都适合这里必须先泼一盆冷水。我见到很多人在旧 NAS 上折腾装了虚拟机之后发现卡到没法用。原因不是 Ubuntu 装错了而是 NAS 本身的硬件条件不够。这个判断会在下一章展开。2. 动手之前先判断你的 NAS 和场景适不适合2.1 硬件门槛第一条命门NAS 虚拟机能不能稳定跑主要看三样东西架构绝大多数 NAS 虚拟机功能需要 x86 架构。ARM 架构的 NAS 也有跑 Docker 的但虚拟机支持普遍较弱性能也更难保证。内存这是最容易 hit 到天花板的地方。NAS 本身需要内存虚拟机至少需要 2GBUbuntu 装好后要跑 Docker 和一个 AI 模型进程内存占用很容易到 4GB 以上。如果你的 NAS 只有 4GB 内存基本只能跑一个很小的模型。存储Ubuntu 系统镜像在 2GB 左右安装后的虚拟磁盘一般建议至少 20GB。如果你准备跑模型文件还要额外预留几 GB 到几十 GB 的空间。如果你用的是四核以上的 x86 NAS、8GB 及以上内存、有独立的系统盘和存储盘通常体验会好很多。如果设备只有 2GB 内存建议直接放弃虚拟机方案改用云服务器或本地 Linux 旧电脑。2.2 适合与不适合的场景先对号入座这里给一张我常用的判断表你可以直接对照场景是否适合说明个人学习 Linux适合随便折腾快照回滚即可跑小模型、CPU 推理适合小模型可以接受慢但不能太慢批量文档处理、定时脚本适合后台跑不用一直盯着跑 Docker 容器适合比 NAS 自带 Docker 更灵活大模型训练不适合没有独显CPU 训练太慢高并发服务不适合NAS 的网卡和资源都很有限需要独立 GPU 的推理不适合大部分 NAS 没有 GPU也不支持直通全天候高负载任务谨慎要考虑散热和功耗长期满载可能影响寿命这张表的意思很简单NAS 虚拟机适合做“轻量、低并发、可容错”的任务不适合做“重计算、高并发、实时性要求高”的事。2.3 前置条件清单在开始之前把这几件事处理好会省掉大部分麻烦确认硬盘上有足够空间建议至少预留 30GB。在 NAS 的电源设置里关闭硬盘休眠或至少让虚拟机所在的存储不会频繁休眠。提前下载好 Ubuntu 的 LTS 版本镜像避免安装过程中联网下载卡住。确认 NAS 的虚拟机管理模块已经安装。群晖平台上一般是 Virtual Machine Manager飞牛、威联通等平台也有类似功能。给 NAS 分配一个固定 IP别用 DHCP 随机分配否则后续 SSH 不方便。注意如果只是第一次测试不要急着把资源全部给虚拟机。先用最保守的配置跑通再逐渐增加资源这样排查速度会快很多。3. 安装 Ubuntu 完整流程从镜像准备到虚拟机创建3.1 镜像获取与版本选择现在常见的 LTS 版本是 Ubuntu 22.04 LTS 和 24.04 LTS。如果原始需求没有特别指定版本我的建议是选择当前社区支持较好的 LTS 版本。Server 版和 Desktop 版的选择取决于你更喜欢命令行还是图形界面。如果是跑轻量 AI 环境我更推荐 Server 版。原因很简单Desktop 版会多占用几百 MB 内存还要跑图形界面而你在实际使用时大多是通过 SSH 进入命令行操作图形界面帮不上什么忙。下载镜像后不要急着上传。先做一步校验sha256sum ubuntu-22.04.x-live-server-amd64.iso将输出结果和官方发布的 SHA256 值对比。这一步非常关键因为镜像下载不完整是安装卡死最常见的隐性原因。3.2 在 NAS 虚拟化管理器里创建虚拟机这里以群晖的 Virtual Machine Manager 为例其他平台逻辑基本一致打开套件中心安装 Virtual Machine Manager。打开 VMM进入“虚拟机”页面点击“新建”。设置虚拟机名称选择操作系统为 Ubuntu。选择已经上传到 NAS 存储的 Ubuntu ISO 镜像。配置 CPU 和内存。先从小配置开始比如 2 核 4GB。创建虚拟磁盘。建议至少 20GB我一般给 40GB。网络模式选择桥接模式这样 Ubuntu 会直接获得局域网 IP方便后续 SSH 访问。确认配置开机。需要注意的一点是不同 NAS 系统对“ISO 文件存放路径”有要求比如某些平台要求 ISO 放在指定共享文件夹中。实际界面以你的 NAS 型号为准。3.3 Ubuntu 安装过程的关键节点虚拟机开机后会从 ISO 引导进入 Ubuntu 安装界面。有几个节点需要特别留意语言选择选 English 或者中文都可以。如果后续要用命令行处理路径建议保持英文减少编码问题。网络配置默认使用 DHCP 即可安装完成后再改成固定 IP。安装时不要花太多时间在这里。磁盘分区选择“整块磁盘”安装使用默认分区方案。如果你还不清楚 LVM 和 ext4 的区别就走默认。用户配置创建一个普通用户并且勾选“安装 OpenSSH server”。这是非常关键的一步之后你就可以完全用 SSH 操作不用一直盯着虚拟机的控制台屏幕。安装过程中如果提示是否下载更新建议选择“不下载”或“继续安装”等系统装好后再执行更新。很多安装进度条卡住的问题就是因为在安装时联网更新导致的。安装完成后重启重启时如果提示移除安装介质通常在虚拟机设置里把 ISO 从光驱中卸载即可。如果一切顺利重启后你会看到 Ubuntu 的登录界面或者在局域网里找到一个新设备。这时还不要急着高兴先验证系统基本功能。4. 安装卡死问题排查这是大多数人跨不过去的坎4.1 先判断“卡死”到底卡在哪一层很多人一看到虚拟机黑屏或进度条不动就说“安装卡死了”。但“卡死”这个词太模糊真正要判断的是卡在哪一层。我一般把卡死分成四类还没进入安装界面就黑屏安装加载过程中进度条长时间不动安装过程中报错退出安装完成后重启无法进入系统。不同类型对应完全不同的排查方向。不要一上来就改资源参数先记录现象。4.2 镜像层下载不完整是最坑的隐形问题如果卡在启动阶段先重新检查镜像完整性。很多人下载镜像时网络不稳定文件损坏了也不知道引导到一半就会莫名失败。用 SHA256 校验一遍如果对不上就重新下载。另外如果你下载的是 Ubuntu 的每日构建版或非 LTS 版本遇到问题的概率会更高。建议先换回 LTS 的 Server 版。4.3 虚拟硬件配置层不是配置越高越好接下来看虚拟硬件配置。这里有一个很多人反直觉的点给虚拟机的配置太高有时反而会出问题。内存过小虚拟机容易 OOM安装进程被杀掉。内存过大NAS 自身没有足够内存导致系统整体变慢虚拟机看起来像卡死。CPU 核心数过高NAS 本体也需要 CPU全部分出去会让宿主系统无响应。磁盘空间不足虚拟磁盘文件所在存储没有足够的剩余空间安装写到一半就可能失败。虚拟显存不够如果安装的是 Desktop 版图形界面黑屏很可能是显存分配太少。我的建议是第一次安装时分配 2 核 CPU、4GB 内存等系统装好后再根据需要修改配置给到 4 核或 6GB。先保证安装过程稳定再追求性能。4.4 环境层引导模式、虚拟化支持和平台版本如果镜像和配置都没有问题下一步看环境层UEFI 和 BIOS 引导模式部分 NAS 虚拟机和某些 Ubuntu 版本的组合不兼容切换引导模式可能解决问题。虚拟化支持如果 NAS 的 CPU 虚拟化扩展没有正确开启Ubuntu 会在安装过程中卡住。这种情况在老旧 DIY NAS 上比较多见。VMM 或虚拟化模块版本过旧Ubuntu 新版本对虚拟设备要求更高升级平台的虚拟化管理模块后再试。磁盘控制器类型有些平台可以选择 SATA、IDE 或 virtio如果默认 SATA 有问题可以尝试换 IDE 或 virtio。4.5 卡死排查顺序表现象优先检查常见原因处理方式启动黑屏镜像完整性ISO 文件损坏重新下载并校验 SHA256进度条卡住网络/更新选项安装时联网更新重装时选择“不下载更新”安装中途报错磁盘/内存空间不足或内存不足检查存储剩余空间调大内存重启后无法进系统引导顺序/ISO光驱引导仍在优先移除 ISO设置磁盘启动系统可用但很慢CPU/内存资源分配过低逐渐增加核数和内存网络方式无法访问网络模式NAT/桥接配置错改成桥接模式获取局域网 IP这张表基本覆盖了绝大多数 NAS 虚拟机安装 Ubuntu 的卡死问题。4.6 安装后的验证步骤安装完成后先不要急着去装 AI 工具。花十分钟确认基础环境在局域网里用另一台机器 ping 一下 Ubuntu 的 IP。用 SSH 登录系统确认能正常进入命令行。执行free -h查看内存确认可用内存足够。执行df -h查看磁盘空间。执行sudo apt update sudo apt upgrade确认系统更新能正常完成。如果 SSH 连不上优先检查 Ubuntu 是否安装了 OpenSSH server以及防火墙是否放行 22 端口。5. 把 Ubuntu 变成轻量 AI 运行环境5.1 装完系统后先搭基础而不是急着跑模型很多新手拿到一个干净的 Ubuntu第一件事就是下载模型跑起来。这个顺序容易踩坑。我建议按下面这个顺序来更新系统工具链。安装 Docker。创建长期复用目录例如/opt/ai和/data/models。配置 SSH 固定 IP方便后续连接。观察系统资源基线。基础环境安装可以走官方脚本curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo systemctl enable --now docker装完 Docker 后执行sudo docker version验证一下。如果网络环境无法访问 Docker 仓库后面拉镜像会失败这一步也可以提早暴露问题。5.2 一个最小可落地的本地 AI 实验环境示例在 NAS 上跑 AI最合适的形态是跑一个小模型做文本问答、文档摘要、分类这类轻量任务。这里用一个很常见的开源运行工具来演示项目名称和具体镜像版本以官方仓库为准。用 Docker 启动一个支持小模型推理的服务sudo docker run -d \ --name ollama \ -v ollama:/root/.ollama \ -p 11434:11434 \ --restart unless-stopped \ ollama/ollama等容器启动后拉取一个适合 CPU 推理的小模型。从运行体验看0.5B 到 1.5B 级别的模型在 NAS 上比较合适既不会占用过多内存也能跑出可用结果sudo docker exec -it ollama ollama run qwen2.5:0.5b这个命令会进入交互式对话你可以直接输入问题。如果只是想测试也可以执行一个单次请求sudo docker exec ollama ollama run qwen2.5:0.5b 用一句话解释什么是 NAS这里有两个提醒这个示例只是演示最小流程实际使用时的模型选择、接口调用方式都应该以官方仓库和你自己的场景为准。模型只能用于合规的学习和实验场景不要用于任何违法、违规或打擦边球的内容。5.3 资源限制与稳定运行策略NAS 不是专门的计算服务器跑 AI 任务时要学会“限流”。否则一个模型进程就可能把整台 NAS 拖垮。推荐几个做法用 Docker 限制容器内存。在 docker run 命令里加--memory2g防止模型占用无限增长。不要让 CPU 满载运行。如果 NAS 的 CPU 没有主动散热设计长时间满载会导致降频甚至死机。定期清理日志。容器日志会不断增长建议用docker system prune或配置 log rotation。观察温度。如果 NAS 本身有温度监控功能跑推理任务时要留意温度曲线。经验值4GB 内存的 NAS 跑 0.5B 模型问题不大想跑 7B 级别的模型基本不现实。先跑最小的模型验证整条链路再决定要不要升级硬件。6. 长期维护与方案边界6.1 备份不是可选而是默认虚拟机比物理机好的地方就在于快照和备份。在 NAS 的虚拟机管理界面里定期给虚拟机打快照是成本最低的容错手段。我习惯按照“三个默认”来维护默认每次重大变更前打快照默认每周导出一次虚拟机配置默认在/data/models目录存放模型文件虚拟磁盘只保留系统环境。这样即使虚拟机系统彻底损坏最容易出问题的模型文件也不会跟着丢失。6.2 更新节奏要保守Ubuntu 和 Docker 镜像的更新节奏不一样不要所有东西都一股脑升级。Ubuntu 系统定期执行安全更新但不要一有新版本就做系统级升级。Docker 镜像先在测试容器里验证新版本确认没问题后再更新生产用的容器。模型文件模型版本更新后旧版本可以先保留一段时间确认稳定后再删除。在 NAS 这种资源有限的环境里“能不升就不升”和“该升必须升”之间需要一个平衡。我的建议是小版本升级可以跟着走大版本升级至少等半个月社区反馈正常后再操作。6.3 这套方案的适用边界说清楚最后再回到边界。NAS 部署 Ubuntu 虚拟机做轻量 AI 运行环境适合的是个人学习和技术验证文档批量处理、文本分类、摘要生成定时脚本、数据整理、自动化流程把散落各处的 AI 实验环境收敛到一个可备份的虚拟机里。不适合的是大模型训练和微调高并发的在线推理服务需要独立 GPU 的任务要求 7×24 小时稳定运行的生产级系统。如果后续你的任务量真的增长到一定程度我会建议考虑一台专用 Linux 迷你主机或者带 GPU 的本地服务器。NAS 虚拟机更适合作为“入口”和“实验田”而不是重型计算主力。回到文章开头那句话NAS 上部署 Ubuntu难点从来不是安装命令而是你真的知道手里这台设备能承受什么、瓶颈在哪里、出了问题怎么定位。先把最小流程跑通再逐步扩大范围这是我认为最稳妥的路线。真正长期能用的方案都是先解决工程问题再谈人工智能。