CHUWI AuBox Ai365:装进一个盒子里的AI家庭实验室

CHUWI AuBox Ai365是一台几乎没什么人听过的迷你主机,来自一个以廉价平板闻名的品牌,核心却是一颗通常只会出现在笔记本电脑里的芯片。它就摆在我显示器后面,芯片本身的功耗比一个手机充电器还低,却跑着八个具名AI智能体、一个家庭聊天应用、一个邮件分拣服务,以及我维护的每一个网站。这是我这些年拥有过的硬件里最“无聊”的一台,而在接替了上一台机器之后,“无聊”正是全部意义所在。

完整规格

组件	规格
型号	CHUWI AuBox Ai365(BIOS AuBox_06)
CPU	AMD Ryzen AI 9 365“Strix Point”—10核/20线程(4×Zen 5 + 6×Zen 5c),最高5.0GHz,24MB三级缓存,4nm制程
GPU	AMD Radeon 880M — RDNA 3.5架构,12个计算单元,最高2.9GHz
NPU	AMD XDNA 2 — 50 TOPS(平台总算力73 TOPS)
内存	2×16GB DDR5-5600 SODIMM,双通道—30GB可用,可扩展至96GB
内存带宽	128位总线,约90GB/s
存储	1TB PCIe 4.0 NVMe,2×M.2 2280插槽(目前均已占用)
以太网	2×Realtek RTL8125 2.5GbE
无线	Realtek RTL8851BE — Wi-Fi 6(802.11ax),蓝牙5.3
USB	2×USB4 40Gbps(支持DP alt-mode,100W PD输入),3×USB 3.2 Gen 2 Type-A
视频输出	HDMI 2.1、DisplayPort 1.4,加上两个USB4接口—最多支持4块显示器,8K60/4K144
操作系统	Bluefin 44(20260721)— Fedora Silverblue原子化系统,GNOME 50.3(Wayland),Linux 7.0.12
电源	19V/6.32A 120W圆头电源适配器
物理尺寸	140×139×55mm,846g,全金属机身,单风扇—可VESA壁挂
价格	建议零售价899美元;我实际支付大约900美元

为什么选这台机器

我之前的家庭实验室是一台ROG Flow Z13——一台配备128GB统一内存的游戏平板。2026年7月,它出现了电源故障:开机、卡在logo上,大约三十秒后自动进入休眠,每次都一样。完整的事后复盘在这里。简单说就是它从没到达过引导程序,所以不管我在软件层面做什么,都碰不到问题所在。

这让我的采购清单变得相当具体。我需要一台至少32GB内存的Linux主机、足够跑本地视觉任务的GPU、有线网络,而且——在亲眼见证一台靠电池供电的机器在电源管理上翻车之后——关键路径上不能有电池,也不能有USB-PD协商。一根圆头电源线,加一个风扇。

这台机器不寻常的地方在于,它是一台Strix Point桌面机。Ryzen AI 9 365本来是一颗笔记本芯片;它通常活在ThinkPad和OmniBook里,直到不久前,还活在我刚刚报废的那台平板里。把它塞进一个140mm的金属方盒里,配上两个2.5GbE网口和两个USB4接口,这种决定只有小众OEM厂商做一些略显古怪的东西时才会出现。而这份古怪,恰恰是家庭实验室想要的:笔记本级的能效、桌面级的供电,加上服务器级的网络。

这套硬件上的Linux

这部分我本来以为会很痛苦,结果完全没有。这台机器里的每一个设备,都由标准Fedora内核自带的驱动支持。我的配置里没有第三方仓库,没有DKMS模块,也没有任何GPU环境变量覆盖。

设备	驱动	在Linux 7.0.12上的状态
Radeon 880M(gfx1150)	amdgpu	正常工作。识别为strix1,不需要任何覆盖设置。
2×RTL8125 2.5GbE	r8169	两个网口都能被识别并正常工作,不需要任何模块参数。
RTL8851BE Wi-Fi	rtw89_8851be	自6.5内核起已进入主线。能用——但请看下面的说明。
XDNA 2 NPU	amdxdna	自6.14起已随内核自带。以/dev/accel/accel0的形式被识别。
USB4	thunderbolt	正常工作。

Wi-Fi这部分的说明值得讲清楚,因为CHUWI自己的宣传资料语焉不详,我找到的一份规格表甚至把它标成了Wi-Fi 7。其实不是。RTL8851BE是一颗Wi-Fi 6、单流、非2×2、不支持6GHz频段的芯片——它以802.11ax控制器的身份被识别,实际速率大约在300–400Mbps。它稳居这台机器里最弱的那个部件。它也是一张M.2 2230 A/E-key规格的卡,所以如果你想要Wi-Fi 7,可以换成一张MediaTek MT7925。我没费这个事:这台机器靠有线2.5GbE生活,Wi-Fi接口干脆就是关着的。

Bluefin,具体说说

这台机器上,我特意选了Bluefin而不是Bazzite。两者底子相同——都是ublue系,基于镜像的rpm-ostree、Flatpak优先、一次重启就能回滚一次失败的更新——但Bluefin跟的是标准Fedora内核,而不是打过补丁的游戏内核。在一台最新硬件是一颗驱动还很年轻的NPU的机器上,跟着上游走是更稳妥的选择。

这是整个搭建过程里最轻松的部分。真正让原子化桌面适合这样一台机器的,不是哪一个具体功能,而是操作系统本身不再是一样需要你去维护的东西。它以一份签名镜像的形式到来。要么启动成功,要么你重启回上一份镜像。不存在半途而废的更新,不存在三个月前就已经没人管的依赖,也不存在一堆没人记得自己动过手的手改积累——而这恰恰就是那种,会让人不敢重启家庭服务器的“腐化”。

写这篇文章的时候我检查了一下这台机器,实际情况是这样的:零个失败的用户服务,部署状态和发布的摘要值完全一致,整套技术栈里该跑的每一部分都在跑。唯一一个失败的系统单元是systemd-remount-fs,它想把/重新挂载成可读写但失败了,因为在这个镜像上,/是一个只读的composefs挂载点。这是设计上刻意如此,只是一条外观上的错误信息,而不是真的出了故障。

真正的代价写在下面的“踩过的坑”里:更新会以新部署的形式到达,并且需要重启,而这在某个任务可能正在跑的时候,是个要认真考虑的问题。而且因为基础系统是不可变的,任何指望用包管理器把自己装进系统里的东西,都得换个地方住——容器、Flatpak,或者用户级安装。对于从传统发行版过来的人来说,这是一个真实存在的适应过程,但这也正是这台机器能保持干净的全部原因。

它在跑什么

这里的一切都是systemd --user服务。没有Docker,没有supervisor脚本,断电之后也不需要手动重启。整个动物园会自己爬起来。

服务	作用	监听地址
openclaw-gateway	智能体网关——路由、工具、会话	端口18789,仅回环地址
local-chat	DisPatch,全家在用的聊天应用	端口8765,局域网+Tailscale
lm-studio	本地模型服务器,兼容OpenAI接口	端口1234,回环地址
comfyui	本地图像生成——现在是备用路径	端口8188,回环地址
openclaw-email	分拣两个邮箱的邮件。只写回复草稿,从不发送。	—
hermes-gateway	另一个独立的消息网关	—
rgb-idled	电源状态守护进程——根据屏幕和会话状态设置系统电源模式	—
openclaw-backup.timer	每晚备份配置和智能体状态	每天02:17
arkvault-backup.timer	每晚Borg快照备份	每天02:00
arkvault-mirror.timer	每晚镜像到第二块硬盘,按日期存档	每天02:30

智能体名单

八个具名智能体,外加两个邮箱智能体。真正重要的划分是每一个的模型跑在哪里:交互式任务上云端,隐私或长时间运行的任务留在这台机器上,视觉模型则交给网络上的第二台机器。

智能体	职责	模型跑在
Bits	前台。接收请求、分派任务、审查结果。	云端
Brains	深度思考——架构设计、调试、审查	云端
Flash	快速廉价的活儿——摘要、查询、追踪卡住的任务	云端
Hermes	部署通道。默认试运行,只有我明确下达指令才真正上线。	云端
Doxy	批量苦力活和一切隐私任务——整夜运行,只花电费	这台机器—35B MoE
Charley	视觉——截图、图表、错误弹窗	第二台机器
Alpha	家庭设备的安全前台——只有只读工具	云端
Beta	家庭设备的第二个安全机器人	第二台机器

Alpha和Beta是我家人平时对话的对象。它们能查东西、能回答问题;但碰不了文件,也跑不了命令,而且聊天应用会在智能体配置之外单独强制执行这一点,所以一层出错,不会连累另一层。廉价云端与本地划分背后的道理,写在成本拆解里。

一条消息如何在这台机器里流转

整套系统的可靠性,主要靠两个细节撑着。如果某个模型繁忙或者宕掉了,会有一个备用模型顶上来回答,而不是直接请求失败。而且每当一个任务被派发出去,就会有一个看门狗被激活——如果工作者在它的时间窗口内一直沉默,Flash就会被派去查明原因。这两个做法都算不上多聪明;但正是它们之间的差别,决定了一套系统是能无人值守运行,还是需要人时刻盯着。

这颗芯片上的性能表现

功耗。 这是最让我意外的数字。在整套系统跑起来、负载均值大约为2的情况下,以5秒窗口测量SoC封装功耗,芯片本身只吃了4.6W。加上主板、两块NVMe硬盘、内存、网卡和风扇,墙插功耗大约在10W左右——但处理器本身在托管八个智能体的同时,功耗还不到5W,这是Zen 5c能效核到底能带来什么好处的最清楚证明。空闲时Tctl温度大约在40°C。

CPU。 十个5GHz的Zen 5核心,对这份工作负载来说绰绰有余。智能体路由在负载均值里几乎看不出来;这台机器大部分时间都近乎空闲,一米开外根本听不到风扇的声音。

本地推理。 这是这台机器真正的极限所在,而且限制来自带宽,不是算力。Radeon 880M有12个计算单元,大约90GB/s的内存带宽可用。作为对比,Z13有40个计算单元和256GB/s带宽,而我桌面上那几块独立显卡各自大约有1.8TB/s。这台机器上的本地生成速度,是每秒十几到二十几个token这个量级,不是几百个。对它承担的工作——通宵批量任务,以及任何不能离开这栋房子的东西——这完全够用,但对交互式聊天毫无用处,这也是为什么交互式聊天都走云端。

NPU。 XDNA 2 NPU能干干净净地以/dev/accel/accel0的身份被识别,然后什么都不干。这算是诚实,而不是让人失望:那50 TOPS是真的,但从“我有一个NPU”到“我的智能体技术栈真的在用它”之间的软件路径,对我关心的这些需要长上下文窗口和强大工具调用能力的模型来说,目前还不存在。它未来真正能派上用场的地方,是一些小型的固定任务——比如给邮件智能体的搜索索引提供一个嵌入向量端点,或者做一个初筛分类器,判断哪些邮件值得唤醒一个真正的模型来处理。那是以后的项目,而这台机器完全没靠它就已经搭起来了。

网络。 两个2.5GbE网口都不需要任何配置就能工作。一个接了网络,另一个空着备用。

我放弃了什么

这次搬家真正的代价是内存,而且不是一笔小代价。Z13有128GB统一LPDDR5X内存,我从中划出64GB当VRAM,本地跑了一个120B参数的模型。这台机器总共只有30GB可用内存,操作系统和其他一切都得从里面分。

所以那个120B档位,直接没了。本地智能体现在跑的是一个35B混合专家(mixture-of-experts)模型——一个真正能干活的模型,但完全不是同一个量级的东西。这个网站上有几篇旧文章,把本地120B描述成我技术栈的一部分;那在Z13上是真的,现在已经不是了。

我换来的东西,正是这次更换的全部理由:没有电池会老化,没有负载下的USB-PD协商,也没有Modern Standby这种能崩溃进去的状态机。主板可以通过两个SODIMM插槽升级到96GB,这样能挽回一部分上限。我暂时还没这么做——今年DDR5的价格大概翻了一倍,而且加内存也不会加带宽,而带宽才是真正限制这里本地推理的那个维度。

Z13的SSD现在住在这里

有一个细节,我喜欢的程度可能有点不太合理。Z13上唯一一个用户能自己动手的部件,就是那块藏在支架小门后面的SSD。它取出来的时候状态健康,经过一个2230转2280的转接支架,现在装在这台机器的第二个M.2插槽里。

它现在专门存放备份。每天凌晨02:30,这台机器当前状态的一份带日期镜像,都会被写进这块曾经就是“那台机器本体”的硬盘里。这台报废电脑的最后一份工作,就是确保它的接替者能够被还原回来。它上面还留着故障发生前一天的一份完整旧系统镜像——正是这份镜像,让这次迁移变成了一次复制,而不是一次重建。

花费多少

花费项目	金额	说明
主机本身	约900美元(一次性)	建议零售价899美元,32GB+1TB配置
云端API额度	约24美元/月	覆盖所有交互式智能体——完整拆解
电费	约4.5美元/月	按东京电价24/7运行
本地模型	0美元	隐私层。硬件的钱你已经付过了。

整套东西跑下来,一个月不到30美元。跟任何同档次的托管服务比,这台硬件一年之内就能把自己的成本赚回来,而且那个隐私层,不管花多少钱,托管服务都给不了你。

踩过的坑

真正咬过我一口的事情,大致按耗费时间从多到少排序:

• 30GB的上限是真的。 标称32GB,减去固件和核显占用的部分,free -h里剩下的就是30GB。本地图像生成和本地语言模型没法同时常驻内存,所以图像生成改成按需启动、空闲时停止——而且默认的图像生成路径,已经整个搬到了网络上的第二台机器。
• 本地模型服务器在内存压力下崩溃过。 跟老机器上同一个bug:内存吃紧的时候,AppImage的临时挂载点会被回收,进程收到的是一个总线错误,而不是一次干净的内存不足杀进程。改成用systemd跑一份解压好的副本,而不是直接跑AppImage,就彻底解决了这个问题。
• 超时设置默认按云端速度算的。 核显上跑一个大模型是慢,不是坏,但网关默认的provider、turn和abort这三层超时,会在它回答到一半时直接把它杀掉,还报告说是卡住了。这三层必须按顺序调高——先request,再turn,最后abort——不然你只是把故障发生的位置挪了个地方。推理模型还得额外标记成推理类型,不然它们在思考的时候会被当成卡住,然后被中止。
• 智能体ID在一条代码路径里被转成小写,另一条路径里却没有。 跨智能体消息一直悄无声息地失败,直到allowlist里也加上了小写条目。没有报错,没有日志行,就是单纯地送不到——这是最糟糕的一种故障模式。
• 原子化更新会重启机器。 Silverblue会把更新暂存成一份新的部署,然后重启进入它。如果正好赶上某个任务在跑,任务就会死掉。现在更新都按我自己的时间表,挑一个安静的窗口来做。
• 旧配置会跟着你。 迁移过程中,老机器备份里一份过时的身份文件被重新注入进来,把网关拖进了崩溃循环。“还原一个能跑的系统”和“还原一个正确的系统”不是一回事;智能体能改写的配置,就有可能从半年前的某个版本里冷不丁咬你一口。

我会改进什么

• 如果我用Wi-Fi,会换一块更好的网卡。 这块单流Wi-Fi 6网卡是唯一真正弱的部件。它是一张可更换的M.2 2230 A/E-key卡,十五分钟就能换掉。但因为走的是有线网络,我一直没这个必要。
• 迟早会加内存。 两个SODIMM插槽装满能到96GB,能挽回一部分Z13曾经有过的余量。但按现在的内存价格,这笔账不划算,而且也不会提升带宽。
• 固件更新是个谜。 这个型号没有公开的BIOS下载。想要更新就得把型号和序列号发邮件给厂商,然后祈祷。这就是买一台小众机器要付出的代价。
• NPU需要一个存在的理由。 五十TOPS的算力就这么空闲着,是个明摆着的邀请。一个嵌入向量端点,是最明显的第一个任务。

结论

我还会再买一次。不是因为它快——其实并不算快——而是因为它恰好做到了一台常开家庭实验室需要的一切,又没有多余的东西。它小、安静、省电,除了一个风扇之外没有任何会动的故障源,跑主线Linux不需要一个外置驱动,而且在一台三明治大小的机器上,配了两个网口和两个USB4接口。

上一台机器教会我的道理是:对基础设施来说,一台会死掉的炫酷硬件,价值比不上一台一直开着的无聊硬件。这就是那台无聊的硬件。用了两周,它没做过任何有意思的事——这是我能给它的最高评价。

每周日志

2026年7月26日–8月1日这一周

日期	发生了什么
7月29日	网关的自我修复机制改成了事件驱动:救援单元现在只有在服务真正进入失败状态时才会触发,而且尝试三次后就会放弃,不会跟一次刻意的关停死磕。之前有个智能体把网关停掉了,结果一整晚都没起来。
7月30日	正式搭好了远程访问,刻意分成两扇门:一扇从冷启动开始就提供登录界面,另一扇镜像当前的桌面会话。两者用不同的凭据存储,所以一边出故障,不会把我锁在另一边之外。
7月30日	加了一个电源状态守护进程。屏幕关闭就把机器降到低功耗模式,并关掉键盘灯;一个活跃的远程会话优先级高于这两者,因为不这样的话,远程输入看起来就像是闲置。
7月31日	对智能体网关做了一次全面审计。发现智能体ID在一条路径里被归一化成小写,但在一个目录覆盖设置里却没有,导致某个智能体的记忆被悄悄分叉进了第二个目录。移除了这些覆盖设置,让路径能正确推导。
7月31日	老机器的SSD装进了第二个M.2插槽,当作备份目标。每晚02:30会跑一次带日期的镜像备份,紧接在02:00既有的Borg快照之后。
7月31日	图像生成默认改到网络上的第二台机器上跑;本地实例现在是备用。这解决了上面“踩过的坑”里提到的内存争用问题。
8月1日	聊天应用加了一个临时表情图片功能——一张图片会在每台连接的设备上弹出十秒,任何输入都能关掉它。设计上刻意只限定给一个机器人使用。
8月1日	第一次测量了SoC封装功耗:整套系统运行时是4.6W。空闲Tctl 40°C,磁盘已用286GB,共952GB。

当前快照

指标	数值
操作系统	Bluefin 44(20260721),Linux 7.0.12
运行时间	1天
负载均值	0.67
内存	已用7.8GB,共30GB
磁盘	已用286GB,共952GB(31%)
SoC封装功耗	4.6W
智能体响应情况	8/8全部正常,外加2个邮箱智能体