为避开 Microsoft 账户，我把 RTX Spark 笔记本装上了 Arch Linux

简而言之——微软真烂。Arch Linux 能用，在 7-Zip 上跟 Windows 不相上下，而且向操作系统和 CUDA 报告的内存池同样是 116.0 GiB。我最初的可启动配置和补丁在这里。这是针对 ASUS ProArt P16 H7607BA-SE033W：128 GB 内存配置，6,144 个 CUDA 核心和 2 TB SSD。

当关于一台拥有超过 100 GiB 内存、GPU 可访问的笔记本电脑的传闻开始流传时，我开始思考我能在上面构建的所有东西，以及我可以花太多时间玩的所有优化。我非常支持开放权重模型。能够在本地运行东西，并在笔记本电脑上折腾 RL、量化和微调，那会很棒。我已经在 Hugging Face 上发布我自己的 GGUF 量化模型，过去一个月下载量超过 160,000 次。

所以当我发现官方仅支持 Windows时，就不那么高兴了。讨厌 Windows 的理由有很多。我的包括安装过程中对隐私的让步、多年来等待微软让人们再次把任务栏放到屏幕侧边，以及广告。最后一个链接是真实 Windows 推广的拼贴，由 Pureinfotech 提供。你懂的。我可以一直说下去，所以让我回到正题。

Arch 是我偏好的发行版，我是Arch 员工中的软件包维护者。我已经把它装到 IBM 大型机上（我的 FOSDEM 幻灯片），所以这里它一直会是我的起点。这个构建使用 Arch Linux ARM，这是将 Arch 软件包移植到 ARM 的独立项目，并在其上添加了硬件支持。

NVIDIA 一直在为 Ubuntu 做内核工作，这给了我一个起点。我整合了这些，修复了获得控制台所需的 ACPI 覆盖分配和帧缓冲映射，并从笔记本电脑自身的表中弄清了 ACPI 覆盖（感谢 astra <3）。NVIDIA 驱动和 ASUS 扬声器固件来自互联网上的官方地方（请不要起诉我，电脑公司们）。键盘支持需要一个打过补丁的 hid-asus，音频需要自己的机器驱动。

我把这些整合成一个可启动 USB，并扩展了上游 Archinstall 4.5 来安装硬件支持。仓库里有构建脚本和补丁，包括在本地转储你自己的 ACPI 表并从 ASUS 驱动包中提取扬声器固件的步骤。我的运行固件 H7607BA.300。

构建输入经过哈希固定。我周末整合的硬件包用我的 Arch Linux 软件包维护者密钥签名，ACPI 覆盖来自笔记本电脑本身。

显示器运行在 3840 × 2400 和 120 Hz，我使用 NetworkManager、PipeWire 和无根 Podman 配合 NVIDIA CDI。安装程序包含内核、NVIDIA、电源管理和固件包以及 IgnorePkg，而普通软件包继续从 Arch Linux ARM 更新。

CPU 性能

我在 10 月 19 日在原生 Arch Linux ARM 上运行了测试套件，内核 7.0.0-1022-nvidia 和 NVIDIA 驱动 615.78.08。笔记本电脑插着电并选择了性能配置文件。对于 CPU 比较，我使用了已发布的 Windows 结果。

CPU 测试是原生 ARM64 7-Zip 26.04，使用固定的 32 MiB 字典。我在每个线程数下运行一次预热和三次测量，然后取中位数：

StorageReview 测试了一台 128 GB 的 HP OmniBook Ultra 16，搭载同样的 20 核 N1X，运行原生 Windows ARM64 二进制文件。他们以 GIPS 报告 7-Zip 评分，因此我将原始日志中的 MIPS 评分除以 1,000 以保持一致。数值越高越好。

单线程基本持平。在全部 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 之内。他们的机器是 64 GB 配置，运行 7-Zip 26.00，图表未给出字典大小。

内存划分

内存是更大的亮点。我的 Linux 运行报告 116.0 GiB 同时作为系统 RAM 和 CUDA 总量，来自同一物理池。Windows 将 RAM 划分为专用 GPU、共享和仅 CPU 区域。CPU 工作负载无法使用专用 GPU 区域，GPU 分配也无法使用仅 CPU 区域。

Windows NVIDIA 应用允许你更改专用预留并重启；Frandroid 的 128 GB ProArt P16 达到了 96 GiB。CUDA 可以通过从共享 RAM 分配超越该值，受 Windows 内存预算限制。

在 91 GiB 专用预留下，Frandroid 的 Windows 配置报告 CUDA 总量为 109.7 GiB，包括共享内存。我的 Linux 配置报告 116.0 GiB，多出约 6.3 GiB。我关心的是大内存池也能用于 CPU 工作，而无需在工作负载之间移动预留滑块并重启。

本地运行 Qwen

我在原生 ARM64 容器中通过 vLLM 运行 NVIDIA 的 Qwen3.8-Flash-Next-FP4-Local 检查点，使用 B12X CUDA 内核，采用混合量化和 FP8 KV 缓存。本次运行我关闭了思考功能。

加载模型前，Linux 报告可用 RAM 为 110.9 GiB。vLLM 记录模型加载占用 68.2 GiB，并为 KV 缓存分配了另外 21.1 GiB。在笔记本上，模型和 KV 缓存合计分配了近 90 GiB。

模型加载和编译在首次请求前耗时约 16 分钟。以下计时从预热后开始。PLE 嵌入表由磁盘支持，受益于热页缓存；其他组件使用 CPU 卸载。CUDA 负责推理，部分模型位于 GPU 内存之外。

我给了 Qwen 两个有 bug 的 Python 辅助函数供审查、一份包含一个失败操作的长事件日志供查找，以及一张付款备注供转换为 JSON。每个任务在预热后运行三次，并有已知答案可供核对。我想知道需要等多久，以及它是否返回了正确的字段。

事件任务读取了近 10,000 个 token，并在 6 秒内返回了正确的请求、原因和后续操作。其答案仅 39 个 token 长，整个请求折合 6.8 tokens/s。大部分等待时间用于处理提示词，因此对于此任务，响应时间比 tokens/s 数字更能说明问题。

在代码审查方面，我将生成速度估计为(output tokens − 1) / (response time − time to first token)，两次时间均以秒为单位。这包括流式开销。Frandroid 在其 Windows ProArt 上运行了 Qwen3.8-Flash-Next 编码任务：

两套 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 个测量响应均通过检查。这是用确定性解码重复的三个提示词；代码审查检查验证回归输出。我保留了每个答案和原始事件流，并将它们与摘要进行了核对。