在 RTX Spark 笔记本上装 Arch Linux：116 GiB 统一内存池可同时供 CPU 与 CUDA 使用

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

当有关一款 GPU 可访问超过 100 GiB 内存的笔记本电脑的传闻开始流传时，我开始思考我能在上面构建的所有东西，以及我能花太多时间玩的所有优化。我非常支持开放权重模型。能在本地运行东西，并在笔记本电脑上折腾 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，音频需要自己的机器驱动。

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

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

显示器运行在 3840 × 2400 和 120 Hz，我使用 NetworkManager、PipeWire 和无 root 的 Podman 配合 NVIDIA CDI。安装程序用 IgnorePkg 保留内核、NVIDIA、电源管理和固件包，而普通软件包继续从 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 同时报告为系统内存和 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 内存之外。

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

事件任务读取了近 10,000 个 token，并在 6 秒内返回了正确的请求、原因和后续操作。其答案仅 39 个 token 长，整个请求折合 6.8 token/s。大部分等待时间用于处理提示词，因此对于此任务，响应时间比 token/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 s，四个请求合计产生 86.6 输出 tokens/s。该速率包括提示处理与响应开销。全部 12 个答案在三个批次中均通过。

然后我让它循环执行这三个任务，一次一个请求，持续十分钟。它完成了 150 个请求，每个任务 50 个，并且每个答案都通过了检查。中位响应时间分别为：代码审查 4.036 s、日志 5.921 s、提取 2.046 s。比较每个任务的前十次和最后十次重复，中位响应时间增长不到 1.6%。

全部 171 个被测响应都通过了检查。这是三个提示词在确定性解码下重复运行；代码审查检查会验证回归输出。我保留了每个答案和原始事件流，并将它们与摘要进行了核对。