在 ASUS ProArt P16 RTX Spark N1X 上运行 Arch Linux ARM：116 GiB 统一内存与本地 Qwen 基准测试

一位 Arch Linux 软件包维护者在 ASUS ProArt P16 H7607BA-SE033W（128 GB RTX Spark N1X 配置）上成功启动了 Arch Linux ARM，并报告称操作系统和 CUDA 都能识别到相同的 116.0 GiB 内存池。测试显示，其 7-Zip 性能与 Windows 大致相当，且通过 vLLM 运行本地 Qwen3.8-Flash-Next-FP4-Local 检查点时，速度约为 30.9 tokens/s。该文章记录的是一个可行的移植方案，而非受控的操作系统对比：作者明确表示，这些数据仅是对比了两种可用的配置，而非为了隔离操作系统本身的影响。

作者 Josie 是 Arch 团队的一名软件包维护者，并在 Hugging Face 上发布 GGUF 量化模型，过去一个月下载量超过 16 万次。其动机很简单：该笔记本电脑官方仅支持 Windows，而作者没有微软账户。作者对这篇文章的自述总结是“呜呜呜，微软真糟糕”。

硬件与限制

该机器是 ASUS ProArt P16 H7607BA-SE033W：拥有 128 GB 内存、6,144 个 CUDA 核心和 2 TB SSD。华硕官方仅列出了对 Windows 的支持。作者避开 Windows 的原因包括设置过程中的隐私让步、任务栏位置选项的漫长等待以及系统内的广告。

Arch 是作者首选的发行版，该构建版本使用了 Arch Linux ARM（将 Arch 软件包移植到 ARM 的独立项目），并在其上叠加了硬件支持。作者此前已在 IBM 大型机上运行过 Arch，因此这里也以 Arch 作为起点。

移植所需的工作

要获得控制台和可用的驱动程序栈，需要进行几项特定的修复。作者从 NVIDIA 的 Ubuntu 内核工作入手，修复了获取控制台所需的 ACPI 覆盖分配和帧缓冲区映射，并从笔记本电脑自身的表中整理出了 ACPI 覆盖。NVIDIA 驱动程序和华硕扬声器固件是从作者所称的“互联网上的官方渠道”获取的。键盘支持需要打补丁的 hid-asus，音频则需要其专属的机器驱动程序。

最终成果被打包为可启动的 USB 镜像，并扩展了上游的 Archinstall 4.5 以安装硬件支持。位于 github.com/pfeifferj/archlinuxarm-proart-p16 的仓库包含了构建脚本和补丁，包括转储自身 ACPI 表以及从华硕驱动程序包中本地提取扬声器固件的步骤。作者的机器运行的是 H7607BA.300 固件。

构建输入均已锁定哈希值。硬件软件包使用作者的 Arch Linux 软件包维护者密钥进行签名，ACPI 覆盖则来自笔记本电脑本身。安装程序通过 IgnorePkg 保留了内核、NVIDIA、电源管理和固件包，而普通软件包则继续从 Arch Linux ARM 更新。

显示器运行在 3840 × 2400 分辨率和 120 Hz 刷新率下。作者使用了 NetworkManager、PipeWire 以及带有 NVIDIA CDI 的无根 Podman。

7-Zip 性能与 Windows 的对比

CPU 对比使用了原生 ARM64 7-Zip 26.04，并固定了 32 MiB 字典。作者在每个线程数下进行了一次预热和三次测量，并取中位数。

线程数	压缩 (MiB/s)	解压 (MiB/s)
1	6.18	118.26
20	141.77	1,629.60

在 Windows 对比中，作者使用了 StorageReview 对 128 GB HP OmniBook Ultra 16（搭载相同的 20 核 N1X）的测试结果，该测试运行的是原生 Windows ARM64 二进制文件。StorageReview 以 GIPS 为单位报告 7-Zip 评分，因此作者将原始日志中的 MIPS 评分除以 1,000 以进行匹配。数值越高越好。

7-Zip 工作负载	ProArt, Linux (GIPS)	HP OmniBook, Windows (GIPS)	差异
单线程压缩	7.221	7.31	−1.2%
单线程解压	10.779	10.87	−0.8%
20 线程压缩	165.754	157.9	+5.0%
20 线程解压	148.471	144.5	+2.7%

单线程性能基本持平。在 20 个线程全开的情况下，Linux 设置在压缩方面领先约 5%，在解压方面领先约 3%。作者指出，HP 的评测未说明其 7-Zip 版本或字典大小，因此这些百分比对比的是两台笔记本电脑的设置，而非隔离操作系统因素。

第二个数据点来自 ComputerBase 对搭载 20 核 N1X 的 ProArt P16 的测试。转换为 GIPS 后，其 Windows 7-Zip 得分为 155.774；作者三次运行的中位数总分为 157.084，处于 155.759 到 157.193 GIPS 的三次运行范围内。ComputerBase 的机器是 64 GB 配置，运行 7-Zip 26.00，其图表未给出字典大小。

内存分配：操作系统和 CUDA 共享 116.0 GiB

内存配置是更显著的区别。Linux 运行环境报告 116.0 GiB 同时作为系统内存和 CUDA 总内存，均来自同一个物理池。Windows 将内存划分为专用 GPU 区域、共享区域和仅 CPU 区域。CPU 工作负载无法使用专用 GPU 区域，而 GPU 分配也无法使用仅 CPU 区域。

Windows NVIDIA 应用程序允许用户更改专用预留空间并重启。Frandroid 的 128 GB ProArt P16 达到了 96 GiB。CUDA 可以通过从共享内存中分配来超越该限制，但受限于 Windows 的内存预算。在 91 GiB 的专用预留空间下，Frandroid 的 Windows 设置报告 CUDA 总内存为 109.7 GiB（包含共享内存）。而 Linux 设置报告为 116.0 GiB，多出约 6.3 GiB。

作者明确表示，其首要任务是让大内存池也能用于 CPU 工作，而无需在工作负载之间移动预留滑块并重启。

在本地运行 Qwen

作者通过 vLLM 在原生 ARM64 容器中运行了 NVIDIA 的 Qwen3.8-Flash-Next-FP4-Local 检查点，使用了 B12X CUDA 内核、混合量化和 FP8 KV 缓存。运行期间关闭了思考模式。

在加载模型之前，Linux 报告有 110.9 GiB 的可用内存。vLLM 记录模型加载占用了 68.2 GiB，并为 KV 缓存分配了另外 21.1 GiB——在笔记本电脑上，模型和 KV 缓存共分配了近 90 GiB。模型加载和编译在第一个请求之前耗时约 16 分钟。PLE 嵌入表由磁盘支持并受益于热页面缓存；其他组件使用 CPU 卸载。CUDA 处理推理，部分模型位于 GPU 内存之外。

测试任务包括：审查两个有问题的 Python 辅助脚本、在一个包含 128 条记录的事件日志中查找一个失败操作，以及将一张付款单转换为 JSON。每个任务在预热后运行三次，并使用已知答案进行核对。

任务	输入 tokens	首个 token 中位数 (s)	完整响应中位数 (s)	检查通过
Python 代码审查	208	0.316	4.008	3/3
在 128 条记录的日志中查找失败	9,775	4.532	5.768	3/3
付款单提取	87	0.256	2.035	3/3

事件查找任务读取了近 10,000 个 tokens，并在 6 秒内返回了正确的请求、原因和后续操作。其答案仅 39 个 tokens 长，整个请求的平均速度为 6.8 tokens/s。大部分等待时间花在处理提示词上，因此作者认为对于该任务，响应时间比 tokens/s 指标更有参考价值。

对于代码审查，作者将生成速度估算为 (输出 tokens − 1) / (响应时间 − 首个 token 时间)，两个时间均以秒为单位，包含流式传输开销。

系统	量化与运行时	生成速度 (tokens/s)
ProArt P16, Linux	FP4-Local, vLLM B12X	30.9 (3 次中位数)
Frandroid 的 ProArt P16, Windows	UD-IQ4_XS, llama.cpp	29.4 和 31.4

两个 ProArt 设置都在 30 tokens/s 左右。Frandroid 使用了 85 GiB 的专用预留空间和 262,144 个 tokens 的上下文限制；作者的上下文限制为 32,768 个 tokens。由于提示词、量化、运行时和计时方法均不同，作者明确将其表述为两种工作配置的对比，而非操作系统影响的隔离测试。

批处理与持续负载

同时发送四个代码审查请求，四个请求的总中位批处理时间为 5.314 秒，输出速度为 86.6 tokens/s，该速率包含了提示词处理和响应开销。所有 12 个答案在三批测试中均通过。

随后，作者让机器循环执行这三个任务，每次一个请求，持续十分钟。它完成了 150 个请求（每种 50 个），所有答案均通过检查。代码审查的中位响应时间为 4.036 秒，日志任务为 5.921 秒，提取任务为 2.046 秒。对比每项任务的前十次和后十次重复，中位响应时间增长不到 1.6%。总计 171 个测量响应全部通过检查；作者保留了所有答案和原始事件流，并将其与摘要进行了核对。

讨论中的反对意见

评论者对文章的框架提出了几点反驳，大多集中在成本和用例上，而非移植本身。

在这个价格下，笔记本电脑是合适的形态吗？

最强烈的反对意见是，同样的芯片可以在更便宜或更方便的形态中获得。一位评论者写道：

“考虑到你可以用类似的钱买到一台搭载 AMD Ryzen 495 或 395、拥有 96、128 和 192 GB 内存的迷你 PC，并从更便宜/更小/更省电的笔记本电脑远程连接，我不确定这些 6000 美元的笔记本电脑是否有强烈的用例。”

同一位评论者指出，微软在非笔记本电脑形态中也提供了同样的芯片，并认为“在飞行中编码”的场景被那些在经济舱会跳闸的电源适配器以及本地 AI 负载下较短的电池续航所削弱，并建议更好的机上连接将侵蚀完全离线的用例。对于游戏，他们提到了带有独立 GPU 的笔记本电脑，如 Asus Zephyrus。

另一位评论者报告称以 3.8K 美元买到了 128 GB 的 HP 版本，称这是他们见过的该内存容量下最划算的交易。

DGX Spark 和预装 Linux 的替代方案

一位运行 Ubuntu 的 DGX Spark 用户直接质疑了前提：

“我为什么要买那个而不是 DGX Spark？对于大多数开发者来说，操作系统有很大区别，而且 DGX Spark 的栈和体验非常成熟。”

相关评论认为，几家 OEM 厂商已经销售搭载 NVIDIA Linux 发行版（NVIDIA DGX OS）的 RTX Spark 迷你 PC 并提供支持，包括华硕——反复传达的信息是“销售预装 Linux 的设备没有价值”。

微软账户真的无法避免吗？

几位评论者认为登录问题有变通方法。有人指出，在 Windows Pro 上可以使用“工作或学校账户 → 加入域”，然后设置密码和恢复问题，但家庭版需要账户且替代方案越来越少。另一位描述了一个完全脚本化的路径：

“我有一个带有文件和最新版 11 Pro 下载的 USB 密钥，设置新机器时，我运行全新安装。启动后，我运行开发者配置……没有微软登录，没有 Candy Crush，安装了 WSL 和我需要的所有工具。”

该评论者指向了一个 autounattend.xml 生成器和微软的 WindowsDeveloperConfig 仓库。其他人则更直白地指出——创建一个微软账户是免费的，而且会更快——还有人指出微软的登录流程本身就很痛苦，引用了损坏的重定向、循环按钮和验证码。

性能怀疑与未解之谜

一位评论者质疑了推理数字：“Qwen 3.8 Flash Next 上只有 30 tok/s？如今多亏了那些专门的引擎，我在 24 GB 显卡上配合内存卸载可以获得约 2 倍的速度。我猜是热限制……”他们还询问了该机器在密集模型上的表现——文章并未回答这个问题。

另一位评论者挑战了这一成就的框架，询问实际上克服了什么挑战，以及有趣的部分是 arm64 的工作还是仅仅是对新硬件的评测。第三个人指出，拥有超过 100 GiB GPU 可访问内存的笔记本电脑早在三年前 Apple Silicon 的 M3 发布时就存在了，并指出文章根本没有提到 Apple Silicon。另一位评论者询问 Wayland 在该硬件上的表现；提供的讨论中没有出现答案。

基准测试的注意事项

文章中的性能声明是两种笔记本电脑配置之间的对比，而非受控实验。Windows 7-Zip 数据来自第三方评测——StorageReview 的 HP OmniBook Ultra 16 和 ComputerBase 的 64 GB ProArt P16——且两项评测均未说明所有相关参数。HP 的评测未说明其 7-Zip 版本或字典大小；ComputerBase 运行的是 7-Zip 26.00，但其图表省略了字典大小。Qwen 的对比在 Linux 和 Windows 运行环境之间存在量化、运行时、上下文限制、提示词和计时方法上的差异。作者直接陈述了这些局限性，而不是将结果呈现为操作系统对操作系统的基准测试。