近期，一款搭载 NVIDIA N1X 图形处理器、配备 128GB 内存的 ASUS ProArt P16 H7607BA-SE033W 笔记本电脑在 Arch Linux ARM 系统下实现了原生运行。该设备拥有 6,144 个 CUDA 核心及 2TB SSD。测试数据显示，Linux 系统与 Windows 系统在该硬件上均能向操作系统和 CUDA 报告相同的 116.0 GiB 内存池。
随着关于单款 GPU 可访问超过 100 GiB 内存笔记本的传闻流传，本地运行开放权重模型成为关注焦点。此类配置允许用户在笔记本电脑上进行强化学习（RL）、量化和微调等优化操作。此前已有开发者在 Hugging Face 发布相关 GGUF 量化版本，一个月内下载量突破 160,000 次。
尽管官方支持仅限 Windows，但通过移植工作，Arch Linux ARM 已成功适配该硬件。这一构建基于将 Arch 包移植到 ARM 的独立项目，并整合了必要的硬件支持。技术人员修复了获取控制台所需的 ACPI 覆盖分配和框架缓冲器映射，利用 astra 工具从笔记本电脑自身表中计算 ACPI 覆盖数据。音频模块需安装特定的机器驱动程序。最终系统部署于可启动 USB 中，并通过扩展上游 Archinstall 4.5 脚本实现安装，包含丢弃自定义 ACPI 表并从本地 ASUS 驱动程序包提取扬声器固件的步骤。当前运行的固件版本为 H7607BA. 300。
所有构建输入均经过哈希固定，硬件包由维护者使用 Arch Linux 包密钥签名。系统环境采用 NetworkManager、PipeWire 以及结合 NVIDIA CDI 的无根 Podman。安装程序涵盖内核、NVIDIA 驱动、电源管理及固件包，常规软件包则通过 Arch Linux ARM 源进行更新。
处理器性能基准
在 10 月 19 日的测试中，原生 Arch Linux ARM 系统配合内核 7.0.0-1022-nvidia 和 NVIDIA 驱动程序 615.78.08 运行于高性能配置文件模式下。CPU 性能对比基于原生 ARM64 版 7-Zip 26.04，使用固定的 32 MiB 字典。每个线程数进行一次热身和三次传递后取中位数：
| Threads | 压缩 (MiB/s) | 减压 (MiB/s) |
|---|---|---|
| 1 | 6.18 | 118.26 |
| 20 | 141.77 | 1,629.60 |
StorageReview 曾对另一台搭载同款 20 核 N1X 芯片、128 GB 内存的 HP OmniBook Ultra 16 进行测试，该系统运行原生 Windows ARM64 二进制程序。其报告单位为 GIPS，原始日志中的 MIPS 评分除以 1,000 后统一单位。数值越高代表性能越好。
| 7-Zip 的工作负载 | ProArt P16, 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% |
数据显示，单线程性能基本持平。在多任务场景下，Linux 设置在压缩性能上领先 5%，解压性能领先 3%。ComputerBase 也测试了一款搭载 20 核 N1X 的 ProArt P16，换算为 GIPS 后，其 Windows 7-Zip 得分为 155.774；而 Linux 环境下三次测试的中位总分为 157.084，处于 ComputerBase 结果的范围（155.759 至 157.193 GIPS）之内。需注意，ComputerBase 使用的是 64 GB 配置机型，运行 7-Zip 26.00 版本，且未公开字典大小。
内存分配机制差异
内存管理是两种系统的主要区别之一。Linux 系统将 116.0GiB 作为系统 RAM 和 CUDA 的总和进行报告。相比之下，Windows 将 RAM 划分为专用 GPU、共享和仅 CPU 使用的区域。CPU 工作负载无法访问专用 GPU 区域，GPU 分配也无法使用仅 CPU 的区域。
在 Windows NVIDIA 应用程序中，用户可调整专用保留内存并重启系统。Frandroid 对 128GB 配置的 ProArt P16 进行测试时，专用保留已达 96GB，CUDA 可通过共享 RAM 分配进一步超越此限制。当设置 91 GiB 的专用保留时，Frandroid 的 Windows 环境报告 CUDA 总内存为 109.7 GiB（含共享内存）。而 Linux 设置报告 116.0 GiB，多出约 6.3 GiB，且无需调整滑块或重启即可在不同工作负载间切换。
本地运行 Qwen 模型表现
测试通过 vLLM 在原生 ARM64 容器中运行 NVIDIA 的 Qwen3.8-Flash-Next-FP4-Local 检查点，采用 B12X CUDA 内核、混合量子化及 FP8 KV 缓存，并关闭思考模式。
加载模型前，Linux 系统报告可用 RAM 为 110.9GB。vLLM 记录显示，模型加载占用 68.2 GiB，KV 缓存分配 21.1 GiB，总计接近 90GiB。首次请求前的模型加载和编译耗时约 16 分钟。PLE 嵌入表通过磁盘支持并利用热页缓存，其他组件使用 CPU 卸载，推理过程由 CUDA 处理，部分模型数据位于 GPU 内存之外。
以下任务在热身后各执行三次，并与已知答案对照：
| Task | 输入代币 | 第一个标记，中位数 (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 个 token 的事件日志任务中，系统在不到 6 秒内返回了正确的请求、原因及下一步行动。回答长度为 39 个 token，整体速率为 6.8 tokens/s。由于大部分时间用于处理 prompt，响应时间比单纯的 tokens/s 指标更具参考价值。
对于代码审查任务，生成速度估算公式为：(输出代币 - 1) / (响应时间 - 1 到第一个代币的时间)。Frandroid 在其 Windows ProArt 上运行同类编码任务的对比数据如下：
| System | 量子和运行时间 | 生产 (代币/s) |
|---|---|---|
| ProArt P16, Linux | FP4-本地, vLLM B12X | 30.9 (中位数) |
| ProArt P16, Windows (Frandroid) | 标签特定配置 | 29.4 和 31.4 |
两种 ProArt 设置的推理速度均在 30 代币/秒左右。Frandroid 使用了 85GiB 的专用保留和 262,144 个代币的上下文限制，而 Linux 测试环境的上下文限制为 32,768 个代币。鉴于提示词、量子化方式、运行时及计时方法存在差异，此比较反映的是两种工作配置的整体表现，而非单纯隔离操作系统的影响。
在并发测试中，同时发送四个代码审查请求，中位数批处理在 5.314 秒内完成，共产生 86.6 个输出代币/秒。所有 12 个答案均通过验证。随后进行的循环测试中，系统在 10 分钟内完成了 150 个请求（每类任务 50 次），所有答案均通过检查。代码审查、日志分析和信息提取的中位响应时间分别为 4.036 秒、5.921 秒和 2.046 秒。对比每项任务的前十次和最后十次重复，平均反应时间增长不足 1.6%。全部 171 个测量反应均通过检查，表明确定性解码稳定可靠。
