一台华硕 ProArt P16，128GB RAM、6144 个 CUDA 核心、2TB SSD。

官方支持只给 Windows。

博客作者偏不。理由很直接，他不想被微软账号、隐私选项和广告包围。

他把 Arch Linux ARM 装了进去。

boo hoo microsoft bad. Arch Linux works, keeps up with Windows in 7-Zip, and reports the same 116.0 GiB memory pool to the OS and CUDA.

一台让本地模型玩家心痒的机器

传闻里有笔记本能让 GPU 访问超过 100GiB 内存。作者听到后，脑子里已经全是本地模型、RL、量化、微调。

他是开放权重模型派。自己在 Hugging Face 发 GGUF 量化，过去一个月下载超过 160,000 次。

看到 Windows-only，他当场不爽。

他选的路很硬：Arch on ARM

这不是普通装系统。

作者是 Arch Linux 包维护者，还把 Arch 装上过 IBM 大型机。这次他用 Arch Linux ARM，叠加硬件支持。

NVIDIA 给 Ubuntu 做过 kernel 工作。他拿来当起点，修 ACPI override allocation、framebuffer mapping，再从笔记本自己的表里提取 ACPI overrides。

NVIDIA 驱动和 ASUS 扬声器固件来自官方渠道。键盘要打补丁，音频要单独 machine driver。

个人觉得，这段最像硬核玩家的改装车间。没有现成路，就自己铺。

他把这些做成启动 USB，扩展 Archinstall 4.5。仓库里有脚本、补丁，还有本机 ACPI 表和扬声器固件提取步骤。

构建输入 hash pinned。硬件包用他的 Arch 维护者密钥签名。

Windows 的痛点，不只是账号

作者讨厌 Windows 的理由，素材里列了几条。

隐私设置。任务栏位置多年不改。系统广告。

评论区还有一条很扎心：微软登录流程经常重定向、坏链、按钮循环，开发者接 SSO 更痛苦。

但真正影响这台机器的，是内存分配。

Windows 会把内存切成几块：专用 GPU、共享、CPU-only。CPU 工作负载吃不到专用 GPU 区域，GPU 也吃不到 CPU-only 区域。

想改专用预留，还得重启。

Frandroid 的 128GB ProArt P16 在 Windows 上，专用预留拉到 91GiB 后，CUDA 总量报 109.7GiB。

Linux 这边，系统和 CUDA 都看到同一个 116.0GiB 物理内存池。

多出约 6.3GiB。

更关键的是，不用在 CPU 和 GPU 工作负载之间来回切预留、重启。

这点我很认同。对本地大模型来说，内存池够大、够统一，比纸面跑分更实在。

性能没翻车，7-Zip 还略占上风

很多人听到 Linux 硬装新硬件，第一反应是驱动残废、性能翻车。

这次没有。

10 月 19 日，作者在原生 Arch Linux ARM 上跑测试。内核 7.0.0-1022-nvidia，NVIDIA 驱动 615.78.08，插电，性能模式。

CPU 项目是原生 ARM64 7-Zip 26.04，32MiB 字典。一次预热，三次测量，取中位数。

对比 StorageReview 的 HP OmniBook Ultra 16。同样是 20 核 N1X，运行原生 Windows ARM64。

结果：单线程基本打平。20 线程下，Linux 压缩约领先 5%，解压约领先 3%。

ComputerBase 也测过一台 ProArt P16。Windows 下 7-Zip 换算为 155.774 GIPS。作者 Linux 三次中位 157.084 GIPS。

对方是 64GB 配置，版本和字典也不完全一致。不能当严格对照。

但至少说明，这台 ARM 笔记本上的 Linux，不只是能亮屏。

真正刺激的是本地大模型

重头戏在 Qwen。

作者跑 NVIDIA 的 Qwen3.8-Flash-Next-FP4-Local checkpoint。vLLM，B12X CUDA kernels，原生 ARM64 容器，混合量化，FP8 KV cache。

加载模型前，Linux 可用内存 110.9GiB。

vLLM 记录模型加载 68.2GiB，又给 KV cache 分配 21.1GiB。

一台笔记本，给模型和 KV cache 吃掉了近 90GiB。

加载和编译约 16 分钟。之后才开始计时。

他给了三类任务：两个有 bug 的 Python 辅助函数、近 10,000 token 的事故日志、一个支付说明转 JSON。每个任务跑三次，有已知答案。

事故日志任务，6 秒内返回正确请求、原因、下一步。输出只有 39 token，整体 6.8 token/s。

看起来不快。长 prompt 处理才是大头。响应时间更有参考价值。

代码审查任务，估算生成速度约 30 token/s。Frandroid 在 Windows ProArt 上跑类似 Qwen 编码任务，也在 30 token/s 附近。

老实讲，这个数字不算惊艳。惊艳的是规模。

他还一次发四个代码审查请求。中位批处理 5.314 秒，四个请求合计输出 86.6 token/s。三批共 12 个答案，全部通过。

随后连续循环 10 分钟，三类任务共 150 个请求。全部通过。

代码审查中位响应 4.036 秒，日志 5.921 秒，抽取 2.046 秒。前十和后十次对比，中位响应时间增长小于 1.6%。

最终，171 个测量响应全部通过检查。

这就有点工作台味道了。

评论区泼冷水：贵，才是最大门槛

文章看着很燃，热门评论却很冷静。

有人质疑：6000 美元买这种笔记本，不如用同样预算组一台大内存 mini PC，再远程连一台便宜小笔记本。

也有人提到，微软同样芯片还有非笔记本形态。飞行途中写代码常被拿出来当理由，但电源砖也不轻松。

还有人说，自己已有 DGX Spark，Ubuntu 栈成熟。既然 RTX Spark 跑 Windows，为什么要放弃更成熟的开发体验。

更有趣的是，评论区也有人觉得作者折腾过度。

注册一个微软账号，可能更快。

也有反驳：Windows Pro 可以走本地账户，Home 才越来越强制云账号。

说实话，我站作者一半。

技术上，这次折腾很值。它证明 ARM 新硬件、NVIDIA 驱动、CUDA、大内存、本地模型，可以在 Linux 上跑起来。

但商业上，这类设备离大众还很远。6000 美元、驱动补丁、ACPI 表、固件提取，每一项都在劝退普通人。

当 Windows 把账号、广告和内存切块塞进这台笔记本，Linux 的吸引力当然会上升。

问题是，你愿意为了本地大模型，花 6000 美元，再花一个周末修驱动吗？

【锐评】：微软账号成了开机门槛，Linux 把 128GB 硬件还给了开发者。

参考链接：
https://josie.lol/blog/linux-rtx-spark