因为没有 Microsoft 账户，我给 RTX Spark 笔记本装上了 Linux

# 因为我没有微软账号，所以给我的 RTX Spark 笔记本装上了 Linux 来源：https://josie.lol/blog/linux-rtx-spark t;dr —— 哭唧唧，微软真烂。Arch Linux 能用，7-Zip 性能跟 Windows 不相上下，并且向操作系统和 CUDA 报告的都是同一个 116.0 GiB 内存池。我的初始可引导配置和补丁在这里（https://github.com/pfeifferj/archlinuxarm-proart-p16）。这是针对 ASUS ProArt P16 H7607BA-SE033W 的：128 GB 内存配置，6,144 个 CUDA 核心，2 TB SSD。 Fastfetch 显示运行在 ASUS ProArt P16 上的 Arch Linux ARM，配 NVIDIA N1X GPU。 当传闻开始流传一台笔记本拥有超过 100 GiB 显卡可访问内存的时候，我就开始琢磨能用它构建些什么，以及可以花上大把时间折腾哪些优化。我非常支持开源权重模型。能在笔记本上本地运行这些东西，玩转 RL、量化和微调，简直太爽了。我已经在 Hugging Face 上发布我自己的 GGUF 量化模型（https://huggingface.co/pfeifferj），过去一个月下载量超过 16 万次。 所以当我发现官方只支持 Windows（https://www.asus.com/laptops/for-creators/proart/proart-p16-h7607/techspec/）的时候，心情就没那么好了。讨厌 Windows 的理由多得很。我的理由包括（https://www.microsoft.com/en-us/windows/get-windows-11）安装过程（https://blogs.windows.com/windows-insider/2022/02/16/announcing-windows-11-insider-preview-build-22557/）中（https://blogs.windows.com/windows-insider/2025/03/28/announcing-windows-11-insider-preview-build-26200-5516-dev-channel/）的隐私（https://blogs.windows.com/windows-insider/2025/10/06/announcing-windows-11-insider-preview-build-26220-6772-dev-channel/）妥协（https://www.windowslatest.com/2026/10/13/one-click-let-you-escape-microsofts-forced-sign-in-on-windows-11-of-course-microsoft-killed-it/），等了这么多年才等到微软允许人们重新把任务栏放到屏幕侧边（https://blogs.windows.com/windows-insider/2026/05/15/improving-windows-quality-making-taskbar-and-start-more-personal/），以及广告（https://i0.wp.com/pureinfotech.com/wp-content/uploads/2024/04/windows-11-advertisement-experience-hero-mauro-huculak.webp?fit=827%2C551&quality=78&ssl=1&strip=all）。最后一个链接是真实的 Windows 推送广告拼贴图，感谢 Pureinfotech（https://pureinfotech.com/remove-ads-windows-11/）。你懂的。我可以一直说下去，所以还是言归正传吧。 Arch 是我首选的发行版，而且我是 Arch 团队的软件包维护者（https://archlinux.org/people/package-maintainers/#josie）。我已经在 IBM 大型机上装过 Arch（我的 FOSDEM 幻灯片（https://josie.lol/talks/slides/fosdem-bru-mainframe.pdf）），所以它自然就是这里的起点。这个构建使用的是 Arch Linux ARM（https://archlinuxarm.org/about），也就是把 Arch 软件包移植到 ARM 的独立项目，在此基础上再加上硬件支持。 NVIDIA 一直在为 Ubuntu 做内核工作，这给了我一个起点。我在此基础上整合、修复了让控制台正常工作所需的 ACPI 覆盖分配和帧缓冲映射，并从笔记本自身的表中推导出了 ACPI 覆盖（感谢 astra <3）。NVIDIA 驱动和 ASUS 扬声器固件来自*互联网上的官方渠道*（求电脑公司别告我）。键盘支持需要一个打过补丁的 `hid-asus`，音频则需要自己的机器驱动。 我把它打包成了一个可引导的 USB，并扩展了上游的 Archinstall 4.5 来安装硬件支持。仓库里有构建脚本和补丁（https://github.com/pfeifferj/archlinuxarm-proart-p16），包括在本地转储你自己的 ACPI 表以及从 ASUS 驱动包中提取扬声器固件的步骤。我的固件版本是 H7607BA.300。 构建输入的哈希值都是固定锁定的。我周末打包的硬件软件包用我的 Arch Linux Package Maintainer 密钥签过名，ACPI 覆盖则来自笔记本本身。 屏幕运行在 3840 × 2400、120 Hz，我使用 NetworkManager、PipeWire 以及带 NVIDIA CDI 的无根 Podman。安装器通过 `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（https://www.storagereview.com/review/hp-omnibook-ultra-16-review-rtx-spark-n1x），同样搭载 20 核 N1X，运行原生 Windows ARM64 程序。他们以 GIPS 报告 7-Zip 评分，所以我把自己原始日志中的 MIPS 评分除以 1,000 以对齐。数值越高越好。 单线程基本打平。全部 20 线程下，我的 Linux 配置压缩快约 5%，解压快约 3%。HP 的评测没有说明 7-Zip 版本和字典大小，所以这些百分比比较的是两台笔记本的配置差异。 ComputerBase 也测试了一台搭载 20 核 N1X 的 ProArt P16（https://www.computerbase.de/artikel/notebooks/nvidia-rtx-spark-n1x-test.99679/seite-3）。换算成 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 则把 RAM 划分为专用 GPU 区、共享区和仅 CPU 区（https://docs.nvidia.com/rtx-spark/rtx-spark-porting-guide/latest/uma/index.html）。CPU 负载无法使用专用 GPU 区，GPU 分配也无法使用仅 CPU 区。 Windows 的 NVIDIA 应用可以让你调整专用保留量然后重启；Frandroid 的 128 GB ProArt P16 达到了 96 GiB（https://www.frandroid.com/test/3283093_test-nvidia-rtx-spark）。CUDA 可以通过从共享 RAM 中分配（https://docs.nvidia.com/rtx-spark/rtx-spark-porting-guide/latest/uma/umacuda.html）超出这个上限，但受 Windows 内存预算限制。 在 91 GiB 专用保留量下，Frandroid 的 Windows 配置报告的 CUDA 总量（含共享内存）为 109.7 GiB。我的 Linux 配置报告的是 116.0 GiB，多出约 6.3 GiB。我真正在乎的是这个大内存池对 CPU 负载同样可用，而不用在不同负载之间拖动保留量滑块并重启。 ## 本地运行 Qwen 我在原生 ARM64 容器中通过 vLLM 使用 B12X CUDA 内核运行了 NVIDIA 的 Qwen3.8-Flash-Next-FP4-Local 检查点（https://huggingface.co/nvidia/Qwen3.8-Flash-Next-FP4-Local），采用混合量化和 FP8 KV 缓存。这次运行我关闭了 thinking 模式。 加载模型之前，Linux 报告 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 编码任务（https://www.frandroid.com/test/3283093_test-nvidia-rtx-spark）： 两套 ProArt 配置都在 30 tokens/s 左右。推理方面，Frandroid 使用 85 GiB 专用保留量，上下文限制为 262,144 tokens；我的上下文限制是 32,768 tokens。提示词、量化、运行时和计时方法都不同。这比较的是两套都能跑的配置，并没有隔离操作系统本身的影响。 我还一次性发了四个代码审查请求。中位批次在 5.314 秒完成，四个请求合计产出 86.6 output tokens/s。这个速率包含了提示词处理和响应开销。三个批次共 12 个答案全部通过检查。 然后我让它在十分钟内一次一个请求地循环跑这三项任务。它完成了 150 个请求，每项各 50 个，每个答案都通过了检查。中位响应时间：代码审查 4.036 秒，日志任务 5.921 秒，提取任务 2.046 秒。比较每项任务最初的十次和最后的十次重复，中位响应时间增长不到 1.6%。 全部 171 个测量响应都通过了检查。这是用确定性解码重复的三个提示词；代码审查的检查项验证的是回归输出。我保留了每一个答案和原始事件流，并与摘要进行了比对。