NAS 里的 AI 牛马 · 完整部署方案

> AI 牛马，随叫随到。

把一台闲置的群晖 NAS 变成一台 7×24 小时在线的 AI 工作台：
手机在任何网络下派活、查进度、收结果，不需要任何电脑开机，断电重启后自动恢复。

> 授权范围与使用声明见文末「八、授权与使用声明」。
> 免费精简版见同名 synology-vmm-linux-host（仅含方法论，不含脚本与清单）。

零、怎么用我（先看这一节）

> 如果你只读一节，就读这一节。
> 下面直接用大白话说明：什么情况下该找我、你可以怎么说、以及什么情况下别找我。

0.1 你可以直接这样说

把下面任意一句发给你的 AI 助手（或直接在这个 Skill 的对话里说），我就会启动：

> 不用记这些句子 —— 意思到了就行。
> 上面这些是示例，不是必须逐字匹配的口令。

0.2 这些说法也会触发我

0.3 ❌ 什么情况下别找我

> 一句话边界：
> 要跑「必须有图形界面的桌面程序」→ 找我。
> 要跑「纯命令行 / 有网页界面的服务」→ 用 Docker，别上虚拟机。

0.4 最快的上手路径（三步）

① 想先看看是什么感觉          → 读 references/09-walkthrough.md（一篇真实部署实录）
② 确认自己的机器能不能做      → 读「二、硬性前置条件」+ 跑 scripts/nas-preflight.sh
③ 决定做了                    → 按 references/00 → 06 顺序执行

> 想知道自己的群晖型号支不支持？ → 直接看 §2.1 的型号对照表。
> 在犹豫用虚拟机还是 Docker？ → 看 assets/case-no-docker.md（能省一整晚）。

一、这个方案解决什么问题

1.1 三个真实的痛点

1.2 本方案的思路

NAS 天生就是为 7×24 运行设计的：低功耗、被动散热、系统稳定、断电容错。
它本来就该一直开着，只是我们让它闲着太久了。

于是：用群晖自带的 Virtual Machine Manager 建一台 Ubuntu 虚拟机，
在里面跑官方 Linux 版 AI 桌面客户端 —— 于是 NAS 变成一台永远在线的 AI 牛马。

1.3 为什么用虚拟机，而不是 Docker

这是本方案第一个关键决策，走错路会浪费一整晚：

结论：目标是"必须有图形界面的桌面程序"→ 用虚拟机；目标是"纯命令行服务"→ 用容器。

> ★ 这不是理论推演，是在同一台 DS918+ 上实测失败后得出的结论。
> Docker 路线具体死在哪一步、报错信息为什么把人引向错误方向，
> 完整记录见 assets/case-no-docker.md —— 动手前建议先读，能省一整晚。

二、硬性前置条件（不满足则无法完成）

2.1 ★ 你的群晖型号支持吗（先看这张表）

判断标准只有两条：① 是 x86_64 架构；② CPU 支持硬件虚拟化（Intel VT-x / AMD-V）。

> ⚠️ 这张表是经验归纳，不是官方兼容列表 —— 群晖机型繁多，
> 最终请以群晖官方「Virtual Machine Manager 支持机型」页面为准。
> 不确定时，最快的验证方法是：跑一次 scripts/nas-preflight.sh，
> 看有没有输出 vmx（Intel）或 svm（AMD）标志 —— 有标志 = 有戏。

> ★ 本方案已在 DS918+ 上完整实测通过（DSM 7.3.2 / 12GB，含断电重启验收）。

2.2 硬性条件（不满足则无法完成）

> ⚠️ 必须提前说明的边界：本方案交付的是部署方法与配套工具，
> 不含任何账号、API Key、License、云服务费用。

2.3 ★ 客户端版本要求（重要）

> 一句话：版本会过时，方法不会。
> 本文档把"跟具体版本强绑定的部分"压缩到了 4 个变量，其余全是通用的工程方法。

三、目标架构

                     ┌──────────────────────────────────┐
   手机 APP   ──────▶│                                  │
   （遥控器）         │          群晖 NAS                 │
                     │   ├─ DSM                         │
   微信小程序 ──────▶│   └─ Virtual Machine Manager      │
   （遥控器）         │         └─ 虚拟机 host            │
                     │              └─ Ubuntu 22.04      │
                     │                   └─ AI 桌面客户端  │  ← AI 牛马
                     │                      （自动登录）   │
                     └──────────────────────────────────┘
                                  ↑ 断电重启后自动恢复

核心认知（决定了能不能做到"随叫随到"）：

> 官方架构是「一个宿主 + 多个遥控器」（宿主 = 那台真正干活的机器，
> 遥控器 = 手机这类只发指令的端），各台干活的机器之间没有同步通道。
> 所以"多端共享同一批任务"的唯一解法就是只保留一台常开的机器。

3.1 部署完成后的实际效果（实测）

手机端「选择设备」列表的实际形态（实测截图，设备名已做遮盖处理）：

┌──────────────────────────────┐
│  选择设备              ai-host│  ← 顶部标题 = 当前任务跑在 NAS 上
├──────────────────────────────┤
│  云端                         │
│  DESKTOP-xxx        （在线）  │
│  ai-host            （在线）✓ │  ← NAS 已被手机发现、连通并选中
└──────────────────────────────┘

这个画面是本方案的核心价值证明：

• 这台 NAS（设备名已遮盖）出现在设备列表里 → 官方 Linux 版确实能被手机识别并配对（具备完整的「宿主」能力）
  （官方公开文档里写明能被配对的系统只有 macOS / Windows，Linux 从未被承诺 —— 属实测突破）
• 与 云端、DESKTOP-xxx 并列 → 一个账号可同时管理多个落点，切换即用
• ★ 「命令行 + 网页版」路线给不出这个画面 —— 那种形态不是「宿主」（不是那台真正干活的机器），
  手机设备列表里根本不会有它，只能开浏览器访问

> ⚠️ 实拍截图已对设备名做纯色遮盖（存于项目的小红书配图资料，不在本包内 ——
> 上传平台仅接受文本类文件）。如需在别处引用，请沿用遮盖版；
> 替换素材时同样要求：设备名、IP 地址、账号名一律用纯色方块覆盖
> （勿用马赛克，马赛克可被部分还原）。

四、执行流程（按顺序读 references/）

> 三种读法：
> - 首次部署 → 先读 09-walkthrough.md 建立全局感，再按 00→06 执行
> - 卡住了 → 直接跳 07-troubleshooting.md（先看 7.1 速查表，没报错就看 7.4 软故障，再看 7.5 排障实录）
> - 在犹豫路线 → 先读 assets/case-no-docker.md

配套文件：

五、关键设计决策（为什么这么做）

5.1 虚拟机参数：照抄这张表

> 黑屏 + 闪烁光标：先等 10~20 秒（引导需要时间）；仍黑屏则关机 → 编辑 →
> 确认「启动 ISO 文件」不是「已卸载」。看虚拟机画面必须点「连接」开控制台窗口。

5.2 系统安装：五处必须拿主意

5.3 三层自启链，缺一不可

NAS 重启
   ↓  ① VMM「自动启动 = 是」      → 虚拟机自己开机
虚拟机开机
   ↓  ② 系统「自动登录」           → 不停在登录界面
进入桌面
   ↓  ③ 桌面「开机自启应用」        → 自动拉起客户端
就绪 → 手机设备列表自动出现

任何一层断了，断电后都要人工进控制台救。 验收方式：直接断 NAS 电源，
全程不干预，等 8~10 分钟，从手机端确认设备出现且能正常使用。

5.4 控制台里点不出来的两个开关

• 「允许移动端连接」往往默认就是开的，不用手动开；
• ★ 但 「为远程访问保持唤醒 / Stay awake」这类开关通常默认是关的，
  必须手动打开，否则远端根本发现不了这台机器。
• 这类开关有的不随重启持久化，重启后回控制台确认一次。

5.5 客户端下载的坑（官方 CDN）

症状：同一 URL 每次下载字节数都不一样、与 Content-Length 对不上、
sha256sum 也和官方接口给的 hash 不符。

根因：CDN 的 HTTP/2 连接会被提前关闭，而 curl -f
只检查状态码、不校验长度，于是它以为成功了。

对策：
1. 下载时加 --http1.1；
2. 官方接口里的 hash 字段未必对应该安装包的 URL（可能对应增量包），
别拿它当唯一判据 —— 最终以包管理器能否装成功为准。

5.6 群晖专属坑（最高价值的部分）

> 写脚本三条铁律（都是血泪）：
> ① 必须 LF 换行（CRLF 会让 shell 报 \r: not found）；
> ② 禁用 ! 字符（触发 shell 历史扩展，报 event not found，整条命令被拒）；
> ③ 常用工具显式列入依赖，不能假定存在（curl 在 Ubuntu 桌面版默认没有！）。

5.7 性能：先诊断，别瞎优化

远端访问慢时，在虚拟机里跑 vmstat 2 30（60 秒采样），
期间发起一次真实请求，看三列：

三条反直觉但极常见的经验：

1. 慢 ≠ 磁盘慢。必须用 wa 证实，别凭直觉去折腾存储。
2. lscpu 里 Hypervisor vendor 显示 Microsoft 是正常的 ——
   虚拟机开了 Hyper-V 兼容增强就会这样显示。判断有没有硬件加速，
   看 BogoMIPS 是否接近原生水平（1.5GHz 的 CPU 约 3000）。
3. 软件优化最多找回 20~30%，弥合不了数量级差距。
   差距超过 5 倍时，应该直接考虑换硬件，而不是继续调软件。

正确的期望管理：让远端发一句零计算的话（如 1+1等于几）测出的时间，
几乎全是固定启动开销。真实任务动辄数分钟，这段开销占比很小。

六、必须一并交代的"已知限制"

做完部署一定要主动告诉用户，否则他们遇到时会误判成故障：

1. 远端（尤其手机 APP）可能不显示"思考过程" —— 客户端自身的呈现行为，
   NAS 侧无任何开关可改。感知上的"迟钝"往往来自"没有过程反馈"，而不是绝对速度。
   缓解：换另一种客户端形态试（小程序 vs APP）、升级客户端到最新版。
2. 远端响应时间取决于 NAS 的 CPU，与台式机差一个数量级属于正常。
3. 各台干活的机器之间没有同步通道 —— "多端共享同一批任务"的唯一解是只保留一台。
4. 「云端」和 NAS 上是两套数据 —— 用手机时请务必先切到那台机器再发消息。
5. 固定启动开销在极简问答上最明显，在长任务上占比很小 —— 别用小问题下大结论。

七、常用操作速查

# 进它的桌面
DSM → Virtual Machine Manager → 选中虚拟机 → 「连接」

# 从电脑传文件进去（最快）
cd ~/Downloads; scp 文件名 用户名@虚拟机IP:~/

# 在里面启动客户端（不要加 sudo）
客户端启动命令

# 重启它（温和 / 强制）
VMM → 「关机」；或 「关机」下拉 → 「关闭电源」

八、授权与使用声明

• 本方案提供完整的部署方法、配套脚本与文档，免费分享。
• 不含任何 AI 客户端账号、API 额度、License —— 需自行注册并承担相应费用。
• 不含域名、云服务器、内网穿透等第三方服务的费用。
• 部署在自有设备上，数据存放位置由使用者自行决定，本方案不接触任何用户数据。
• 请遵守群晖、以及各第三方服务的用户协议。
• 许可协议：CC BY-NC 4.0。
  欢迎自用、转载、改编写成你自己的教程（注明来源即可）；请勿用于商业售卖。

九、资源索引