CHUWI AuBox Ai365：我的“AI家庭实验室”一体机

CHUWI AuBox Ai365是一款几乎无人知晓的迷你电脑。它的制造商以生产廉价平板电脑而闻名，而这款机器则搭载了通常只用于笔记本电脑的AMD Ryzen AI 9 365处理器。它放置在我的显示器后面，该处理器的功耗仅为4.6瓦；这台机器上还运行着我的六个AI智能体、一个家庭聊天应用、邮件分类服务以及我维护的所有网站。多年来，它算是我拥有过的最“乏味”的硬件设备了——不过对于它所承担的任务而言，这种“乏味”恰恰正是它应有的特性。需要说明的是，它无法运行大型模型；本页的后半部分将讲述我是如何意识到这一点的，以及之后我又把哪些任务转移到了其他设备上。

完整规格参数

组件	规格说明
型号	CHUWI AuBox Ai365（BIOS版本：AuBox_06）
中央处理器	AMD Ryzen AI 9 365 “Strix Point”——10核心/20线程（4个Zen 5核心 + 6个Zen 5c核心），最高频率达5.0 GHz，24 MB三级缓存，采用4纳米制程
显卡	AMD Radeon 880M——基于RDNA 3.5架构，拥有12个计算单元，最高频率可达2.9 GHz
神经网络处理器	AMD XDNA 2——运算能力达50 TOPS（整个平台的总运算能力为73 TOPS）
内存	两根16 GB DDR5-5600 SODIMM内存条，支持双通道模式；实际可用内存为30 GB，最大可扩展至96 GB
内存带宽	通过128位总线传输，带宽约为90 GB/s
存储	1 TB PCIe 4.0 NVMe固态硬盘；配备两个M.2 2280插槽（目前均已使用）
以太网	两个Realtek RTL8125网卡，支持2.5 GbE速率
无线网络	Realtek RTL8851BE芯片——支持Wi-Fi 6 (802.11ax)及蓝牙5.3技术
USB接口	两个40 Gbps速率的USB4接口（支持DP替代模式及100瓦电源传输功能）；三个USB 3.2 Gen 2 Type-A接口
视频输出	HDMI 2.1、DisplayPort 1.4以及两个USB4接口——最多可同时连接4台显示器，支持8K@60Hz或4K@144Hz分辨率
操作系统	Bluefin 44——基于Fedora Silverblue的原子化发行版；系统界面为运行在Wayland协议上的GNOME 50.3。初始安装时系统版本为Linux 7.0.12，截至2026年9月15日已更新至7.1.8版本
电源	19伏特/6.32安培的120瓦圆柱形电源适配器
物理规格	尺寸为140 × 139 × 55毫米，重量846克；全金属机身设计，配备单个风扇；支持VESA标准安装方式
价格	官方建议零售价为899美元；我个人购买时的价格约为900美元

为什么选择这个主机？

我之前的家用实验室设备是一台 ROG Flow Z13，这是一款配备 128 GB 统一内存的游戏平板。2026年7月时它出现了电源故障：每次开机后都会卡在开机Logo界面，大约30秒后又自动进入休眠状态。完整的故障分析请见此处。简而言之，系统根本无法进入引导程序，因此任何软件层面的操作都无济于事。

这便决定了我的采购需求：我需要一台至少配备 32 GB 内存的 Linux 主机，要有足以处理本地视觉处理任务的显卡、有线网络功能；另外，鉴于之前那台依赖电池供电的设备在电源管理方面出了问题，这次我明确要求主机不带电池且关键路径中也不涉及 USB-PD 供电协议。当然还要有桶形电源接口和风扇。

这款主机的特别之处在于它属于 Strix Point 系列台式机。Ryzen AI 9 365 本是一款面向笔记本电脑的处理器，常见于 ThinkPad 与 OmniBook 系列产品中。将其安装在一个尺寸仅为 140 毫米的金属机箱中，并配备两个 2.5GbE 网络接口和两个 USB4 接口——这种配置通常只有规模较小的 OEM 厂商才会做出。而这种“与众不同”的特性恰恰正是家用实验室所需要的：笔记本电脑般的能效表现、台式机的供电能力以及服务器级别的网络功能。

此硬件上的 Linux 系统

原本我以为这一步会很棘手，但实际上并没有。包装盒内的所有设备都能被 Fedora 默认内核中的驱动程序所支持。我的配置中既没有使用任何第三方软件源，也没有 DKMS 模块，更没有对 GPU 相关环境变量进行任何覆盖设置。

设备	驱动程序	在 Linux 7.0.12 下的状态（于 7.1.8 版本再次验证）
Radeon 880M (gfx1150)	amdgpu	运行正常。系统将其识别为 strix1，无需任何额外设置。
两块 RTL8125 2.5GbE 网卡	r8169	均能被系统识别并正常工作，无需配置模块参数。
RTL8851BE 无线网卡	rtw89_8851be	自内核 6.5 起即被纳入主线版本。可正常使用，但需注意下文中的注意事项。
XDNA 2 NPU	amdxdna	自内核 6.14 起即被纳入主线版本。系统将其识别为 /dev/accel/accel0。
USB4 接口	thunderbolt	运行正常。

关于无线网卡的注意事项值得明确说明：CHUWI 自身的宣传描述较为模糊，我找到的一份规格表甚至将其称为“Wi-Fi 7”设备。其实并非如此。RTL8851BE 实际上是一款 仅支持单数据流、不支持 6 GHz 频段的 Wi-Fi 6 网卡。它在系统中被识别为 802.11ax 控制器，实际传输速率大约在 300–400 Mbps 左右。它无疑是整台机器中最薄弱的组件。该网卡采用 M.2 2230 A/E-key 接口，因此如果你需要 Wi-Fi 7 功能的话，也可以将其更换为 MediaTek MT7925 网卡。不过我没这么做：这台机器一直使用有线 2.5GbE 网络，无线网卡根本用不上。

尤其是 Bluefin 系统

我特意选择了 Bluefin 而非 Bazzite。两者都基于 ublue 框架（采用基于镜像的 rpm-ostree 技术、优先使用 Flatpak 应用，且只需一次重启即可回滚失败的更新），但 Bluefin 跟踪的是 Fedora 的原版内核，而非经过游戏优化补丁处理过的版本。对于这台搭载了驱动尚不成熟的 NPU 的新硬件而言，紧跟上游版本显然更为稳妥。整个操作系统以一个经过签名的镜像形式提供，要么成功启动，要么自动回滚至之前的状态；因此不会出现更新未完全应用的情况，也不会出现那些没人记得曾修改过的杂乱配置——正是这些混乱的配置常常让家庭服务器变得让人不敢随意重启。不过这样做自然也会带来一些需要注意的问题。

运行的内容

所有服务都是以 systemd --user 形式运行的，具备失败自动重启功能。核心服务栈并未使用 Docker，也没有任何监督脚本；即使发生断电情况也无需手动重启。

服务名称	功能说明
代理网关	将每条消息转发给相应的代理，运行相关工具并维护会话状态。它仅监听本地回环接口；聊天应用是其唯一入口。
家庭聊天应用	DisPatch，全家人通过手机和平板使用的聊天工具。
小型本地模型服务器	已于 2026 年 9 月 16 日停用。如今嵌入向量及备用小模型均来自配备 GPU 的机器。
邮件处理服务	MailForge 负责读取三个邮箱并起草回复，但它绝不会自行发送邮件。
夜间备份	凌晨 02:00 执行一次 Borg 快照，备份网关配置与代理状态；02:30 再将数据镜像备份至第二块 SSD。
硬件监控程序	每 15 分钟检查一次 GPU 机器上的图像处理服务是否正常，如有异常便向聊天应用发送警报。

哪些服务被移出本机？原因是什么？

今年 7 月设置这台机器时，它本地运行着一个拥有 350 亿参数的混合专家模型以供私人代理使用，还配备了一个本地图像生成器作为备用。两者都需占用那仅有的 30 GB 存储空间。8 月 15 日起，所有代理所需的本地模型均被迁移至另一台配有真正 GPU 的机器上；到了 8 月 26 日，本机上的本地图像生成功能也彻底停用。一旦 GPU 机器宕机，便无法生成任何图像——系统也不会假装还能正常工作。

对于想要照搬此配置的人，我的建议是：主机本身只需稳定可靠即可，不必追求高性能。需要快速响应的交互式任务可交由云端模型处理；而那些涉及大量数据处理或私密性要求较高的任务则应使用具备足够内存带宽的本地硬件来运行模型。像这样的迷你 PC 正适合运行网关、聊天应用及调度程序，却不适合承载大型模型。

各代理的职责

截至 2026 年 9 月 6 日，整个服务栈共有六名代理；此前随着各种新想法的出现，代理数量曾不断增加：

• 主代理负责接收所有请求、决定由谁执行任务并审核结果。它运行在云端模型之上。
• 工作代理自身不保留任何记忆，每次任务都会重新启动，并根据需求选用不同模型：快速型、思考速度较慢但能力更强的模型、支持长上下文处理的模型，或是 GPU 机器上的本地模型。一个灵活的通用代理取代了原先多个功能单一的代理。
• 审核代理运行在另一款云端模型上，负责对已完成的任务以及即将发送出去的信息进行最终检查。
• 两个人格化代理则运行在 GPU 机器上的本地模型中，因此它们的对话内容通常只留在本地。云端模型仅作为它们最后的备用选择。
• 家庭安全机器人是家庭成员的设备所对接的对象。它可以查询信息并回答问题，但无权访问文件或执行命令。

聊天应用会独立于代理配置来强制执行“家庭安全限制”，这样即便某一层设置出错也不会影响另一层的安全性。关于为何采用云端与本地模型相结合的方式，详情可参见 成本分析说明。

消息在系统中的传递流程

有两个机制确保了系统的可靠性。其一：若某个模型正忙或出现故障，系统会由该智能体列表中的下一个模型来响应请求，从而避免整个请求失败；其二：每个任务执行完毕后都会生成一份报告并写入磁盘，随后一个定时器每隔45秒读取该报告并将其发送至聊天应用，这样即便发起请求的智能体已停止运行，最终结果也不会丢失。这两个机制虽简单，却是实现系统自动运行与需要人工干预之间的关键区别。

在这款芯片上的性能表现

功耗。这个数字着实让我惊讶。在五秒的时间窗口内对SoC封装进行测量，此时整个系统处于满载状态且平均负载约为2，该芯片的功耗仅为4.6瓦。再加上主板、两块NVMe固态硬盘、内存、网卡以及风扇，我估计整个系统的实际功耗大约在10瓦左右；不过我尚未使用功率计进行实测。一个在承载整个代理堆栈的情况下功耗仍低于5瓦的处理器，正是Zen 5c能效核心所带来的优势的最佳例证。在空闲状态下，Tctl温度维持在40°C左右。

CPU表现。四颗频率可达5 GHz的Zen 5核心加上六颗Zen 5c能效核心，这样的配置对于当前的工作负载来说显然绰绰有余。从平均负载来看，代理路由几乎不会占用任何资源；整台机器大部分时间都处于近乎空闲的状态，即便距离一米远也几乎听不到风扇转动的声音。

本地推理能力。在这方面该设备确实存在局限，主要是带宽限制而非计算能力上的不足。Radeon 880M拥有12个计算单元，内存带宽约为90 GB/s。作为对比，Z13拥有40个计算单元且内存带宽高达256 GB/s；而我使用的GPU服务器中的显卡分别具备约1.8 TB/s（RTX 5090）与0.9 TB/s（RTX 3090）的带宽。由于令牌生成速度受带宽限制，因此自8月15日起所有需要运行模型的代理都转移到了那台GPU服务器上。如今这台设备已不再运行任何模型；9月16日之后，那些小型模型也全部被迁移至GPU服务器中。

NPU表现。XDNA 2 NPU能够顺利在/dev/accel/accel0处被识别，但实际上并未发挥任何作用。虽然其理论性能可达50 TOPS，但对于那些需要长上下文窗口以及强大工具调用能力的重要模型而言，目前仍缺乏从“拥有NPU”到“代理堆栈能真正利用它”的完整软件支持。未来它或许能在一些简单且固定的任务中派上用场：比如为邮件搜索索引提供嵌入向量服务，或是作为初级分类器来判断哪些邮件值得调用真正的模型处理。即便没有NPU，这台设备也能正常运行。

网络性能。两个2.5GbE端口均无需任何配置即可正常使用。其中一个连接至网络，另一个则处于备用状态。

我放弃的东西

这次升级的真正代价就是内存，而且这个代价可不小。Z13配备了128 GB的LPDDR5X统一内存，我从中划出了64 GB作为显存，从而能够在本地运行一个拥有1200亿参数的模型。而现在的这台机器总共只有30 GB可用内存，这些内存还要在操作系统及其他程序之间共享使用。

因此，在这台机器上已无法运行1200亿参数级别的模型了。最初的几周里，本地AI代理运行的是一个350亿参数的混合专家模型——这确实是个能实际工作的模型，但级别远不及之前的那个。自8月15日起，所有本地模型都改在另一台配备独立GPU的机器上运行，这才是解决内存瓶颈的真正办法。本博客早前有几篇文章提到过在我的家庭实验室中运行1200亿参数模型的情况；在Z13上这确实可行，但现在已不可行了。

作为交换，我得到了促成这次升级的全部理由：不再有会老化的电池、负载下无需进行USB-PD协议协商、也不用担心Modern Standby状态机出现崩溃问题。这块主板还支持通过两个SODIMM插槽将内存扩容至96 GB，那样或许能恢复部分性能上限。不过我不会这么做：如今DDR5 SODIMM的价格比我购买机器时贵了很多，而且增加容量也提升不了带宽——而带宽才是真正限制本地推理能力的关键因素。

现在，Z13的固态硬盘就在这里

有个细节让我特别喜欢——虽然其实不该这么在意。Z13上唯一用户可以自行更换的部件就是它的固态硬盘，它位于支架上的一个小门后面。这个硬盘状态良好，经过2230转2280尺寸的适配器后，如今被安装到了这个机箱的第二个M.2插槽中。

这个硬盘用来存储备份数据。每天凌晨02:30，系统会将当前状态生成一个带日期标记的镜像文件并写入该硬盘——这个硬盘原本就是原机的存储设备。这台“已死”电脑最后的使命就是确保它的替代机能够顺利恢复数据。此外，硬盘上还保留着故障发生前一天拍摄的完整系统镜像，正因如此这次迁移过程只是复制而非重新构建系统。

费用明细

项目	费用	备注
硬件设备	一次性花费约900美元	标价899美元，配置为32GB内存+1TB存储
电费	每月几美元	按设备全天候以10瓦功率运行估算；未安装电表计量
云端服务	自2026年8月30日起，每月固定费用约60美元（含税）	此为主代理与工作节点使用的统一收费套餐，另包含少量按使用量计费的部分。各月份实际扣款金额（6月242美元、7月225美元、8月385美元，含其他服务费用）详见完整费用明细表。
本地模型运行	这些模型运行在我已有的硬件上；所用GPU设备的能耗未计入此处。

实际上，硬件设备才是最便宜的部分。真正产生持续开支的是云端服务费用；随着工作负载增加，按使用量计费的模式变得不可控，于是采用统一收费套餐才解决了这一问题。

注意事项/易错点

实际上让我吃亏的事情，按造成的损失时间长短大致排列如下：

• 30 GB的上限确实存在。标称的32 GB容量减去固件和集成显卡所占用的空间后，实际可用的内存仅为30 GB（通过 free -h 命令可验证）。本地图像生成任务与中等规模的本地语言模型无法同时保持加载状态。解决办法：将两者都迁移到配备独立GPU的机器上运行。

远程后端可能会静默失败。 9月2日，GPU服务器上的图像处理后端出现了故障，持续了约14个小时却无人察觉，因为没有任何服务向它发起请求。解决方案：设置一个15分钟一次的监控程序，它会尝试重启服务并发出一次警报。

本地模型服务器在内存压力过大时崩溃了。 当内存紧张时，AppImage的临时挂载点会被重新利用，此时进程会触发总线错误，而非正常因内存不足而终止。解决方法：在 systemd 下运行解压后的程序副本，而非直接使用 AppImage。

超时设置是以云端响应速度为基准的。 大型本地模型虽然运行缓慢，但并未出现故障；不过网关的默认设置中，请求、处理及中止超时机制会在模型回答过程中强制中断其运行，并报告出现卡顿现象。解决方法：按顺序提高各项超时阈值（先提高请求超时值，再提高处理超时值，最后提高中止超时值），否则故障点只会随之转移而已。此外，对于推理型模型也必须进行相应标记，否则它们在思考时会被误判为处于停滞状态，进而被强制中止。

在某个代码路径中，代理ID被转换为小写形式，而在另一个路径中则没有。 在允许列表中包含小写形式的条目之前，跨代理消息发送均悄无声息地失败了。既没有错误提示，也没有日志记录，就是没有任何消息被成功发送。修复方法：在所有地方都将代理ID统一设为小写形式。

原子级更新会导致机器重启。 更新内容会以新部署的形式呈现，但只有在重启后才会生效。如果此时恰好有任务正在运行，该任务就会中断。解决办法：我会在指定的空闲时段按计划进行更新。

该系统没有包管理器。 任何需要安装到基础操作系统中的程序，都应使用容器、Flatpak 或用户级安装方式。

旧配置仍在起作用。 迁移过程中，系统从旧机器的备份中重新导入了一个过时的身份文件，导致网关陷入死循环。恢复一个能正常运行的系统并不等同于恢复一个配置正确的系统。解决方法：修正源文件内容，而不只是修改生成的配置文件。

我会做出的改动

• 如果能用 Wi-Fi 的话，希望信号能更好。 这款电脑上唯一真正薄弱的组件就是那个单流 Wi-Fi 6 网卡。它是一个可更换的 M.2 2230 A/E 接口模块，更换起来只需十五分钟左右。不过由于我一直使用有线网络，所以倒也没什么必要换。
• 或许可以增加内存容量。 如果在两个 SODIMM 插槽上都装上内存的话，总容量能达到 96 GB，这样就能恢复 Z13 原本的内存水平了。不过鉴于我现在用的是另一台机器，加上目前的内存价格也不算便宜，我觉得没必要这么做了。
• 固件更新机制实在不明朗。 这款机型并没有公开的 BIOS 下载服务。想要获取更新只能给厂商发邮件说明型号和序列号，然后只能寄望于对方能回复。这就是购买小众产品所要付出的代价吧。
• NPU 需要发挥点作用才行。 拥有 50 TOPS 运算能力却闲置着实在可惜。最合适的用途就是用来搭建嵌入向量生成服务了。

总结/评价

我会再次购买它。倒不是因为它速度快——其实它也算不上快——而是因为它完美满足了作为全天候运行的家庭实验室主机所需的一切功能，没有多余的冗余功能。它体积小巧、运行安静、功耗极低；除了一个风扇外没有任何易损坏的活动部件；能直接运行主流版 Linux，且无需任何非官方驱动程序。在这么小的机身里，它还配备了两个以太网端口和两个 USB4 端口。

从它所取代的那台机器身上我学到了：那些性能出色但容易出故障的硬件，对基础设施而言远不如那些平平无奇却能长期稳定运行的硬件有价值。从7月到9月，围绕这台机器的技术栈发生了许多变化；而它本身则始终安安静静地运行着，什么“惊天动地”的事都没发生——这恰恰是对它的最高赞誉了。

更新日志

按日期排列，最新的在最下方。此记录仅用于说明发生了哪些变化，并非保证会定期更新。

日期（2026年）	变更内容
7月29日	网关的自修复机制已重构为事件驱动型：只有当服务确实进入故障状态时才会触发救援程序；且该程序在尝试三次后仍无法恢复时便会停止运行，而非强行阻止系统关机。此前曾出现一个代理程序意外关闭了网关，导致其整晚处于离线状态。
7月30日	远程访问功能通过两个完全独立的入口实现：一个用于冷启动时的登录界面，另一个则用于实时桌面会话。两者使用不同的凭证存储机制，因此其中一个出现故障也不会导致无法访问另一个入口。
7月31日	对网关进行了审计。发现某个路径下的代理程序ID被统一转为小写形式，但目录覆盖设置中却未做相应调整；这一差异导致某个代理程序的内存数据被写入了另一个目录。现已移除相关覆盖设置。
7月31日	旧机器的固态硬盘被安装到第二个M.2插槽中，作为备份存储设备。每晚02:30会执行带时间戳的镜像备份操作，该操作在02:00的Borg快照之后进行。
7月31日	图像生成任务现改由网络中的GPU机器处理，此举有效缓解了此前提到的内存资源竞争问题。
8月1日	首次测量了SoC封装的功耗：整个系统满载运行时功耗为4.6瓦；空闲状态下 Tctl 温度为40摄氏度。
8月15日	所有代理程序所需的本地模型现均存储于GPU机器中。本机则仅保留嵌入模型以及一个小型备用模型。
8月26日	现已确认本机不再执行任何本地图像生成任务；所有图像数据均来自GPU机器，且不再有本地备用机制。
8月30日	由于按量计费模式下的资源消耗持续上升，主代理程序现改用固定费率的云服务套餐（含税后每月约60美元）。
9月2日	GPU机器的图像生成后端意外宕机了约14小时，期间无人察觉。现已在此机器上添加了15分钟周期的监控机制。
9月6日	代理程序数量调整为六个，另设一个灵活配置的辅助工作节点。任务完成报告现由定时器每隔45秒自动发布一次。
9月9日	聊天应用中使用的旧版终端编码助手程序已被弃用。
9月15日	操作系统镜像已升级至Bluefin 44版本（更新日期为20260915），内核为Linux 7.1.8。原先加载的五个驱动程序仍可正常使用，NPU路径依旧为 /dev/accel/accel0。
9月16日	本机上的本地模型服务器已被移除；如今本机不再运行任何模型，所有嵌入模型数据均来自GPU机器。
9月16日	此页面内容已更新以匹配当前的系统配置。

相关链接：关于被本机取代的ROG Flow Z13设备的详细记录、我的OpenClaw代理程序架构、DisPatch（承载该应用的聊天平台）、StudioForge（本地模型迁移至的GPU服务器），以及这些代理程序的实际运行成本分析。