128GB的AMD输给64GB的英伟达，差距藏在日志里

一台是64GB内存的英伟达RTX Spark笔记本，一台是128GB的AMD Strix Halo平板。同样的模型、同样的文件、同样的设置，跑同一批本地AI任务，结果几乎每一项都是内存更小的那台赢。

但速度不是AMD该紧张的原因。真正的原因，写在日志里。

先交代两台机器。英伟达这边是联想Yoga 9n，搭载RTX Spark N1X和64GB内存，配置价3750美元；AMD这边是华硕ROG Flow Z13，锐龙AI Max+ 395加128GB，3300美元。两台都跑Windows 11，Smart App Control保持开启并强制执行——不会为了跑AI工具去关掉一个Windows安全功能。

测试条件统一：所有大模型任务走Ollama 0.40.8，模型文件完全相同，16K上下文，每项跑三次。Ollama自己选了CUDA和ROCm，也就是说两块芯片各跑各的原生GPU栈。图像生成用ComfyUI，FLUX.2 Klein 4B，文件、参数、种子一致。两台都开厂商最高性能模式。

能装下的任务，Spark全赢

本地AI的速度分两半：提示处理是模型读你给的材料有多快，token生成是它写回来有多快。测试方法是把《时间机器》前4万个字符（约9600个token）喂给三个模型，让它写摘要。

Spark读文档快2.1倍到3.5倍。这个差距是能感觉到的：Qwen3.8 27B在Spark上12秒开始回答，Z13上要31秒。领先最大的是gpt-oss 20B，每秒5616个token对1589个。

生成环节差距小一些，但仍是明确胜出：三个模型全部快1.4倍到1.6倍。Qwen3-Coder 30B在Spark上每秒写69.7个token，Z13上是50.7个。

图像生成的时间差最夸张。同样一张1024x1024、同样20步、同样种子，Spark用25.8秒，Z13用66.3秒，差2.6倍。每张图Z13多花40秒。

拔掉电源，差距更大

用电池时，Spark一点没降速，八次运行稳定在每秒71.4个token。Z13从插电成绩掉了17%，降到每秒42个token，部分原因是华硕在电池模式下锁掉了Turbo，只剩性能模式。联想保留了性能模式，于是Spark的领先从约1.4倍扩大到1.7倍。

功耗上Spark略高，墙插137W对126W，但它用一半时间写完每份摘要。折算下来每份摘要0.28Wh对0.52Wh，同样的活大约只用一半电。电池模式下两者分别约99W和71W，都能撑约一小时连续推理，但Spark靠更大的电池，一小时内能写完约两倍的摘要。

带宽解释不了差距，指向的是CUDA

这类芯片上，生成速度主要看内存带宽。英伟达的移植指南给RTX Spark标300GB/s，AMD给锐龙AI Max+ 395标256GB/s，英伟达纸面领先1.17倍。

但Spark的文本生成快了1.37倍到1.61倍，远超带宽差能预测的水平。纸面硬件解释不了这个差距，那就指向软件：一边是CUDA，一边是ROCm。300GB/s这个数可能还偏乐观——英伟达给自家DGX Spark里的GB10芯片标的是273GB/s，那样的话留给软件解释的空间更大。

连AMD自己的AI栈都得说CUDA

这才是AMD该紧张的地方。ROCm在Z13上是能用的：Ollama日志显示它跑在Radeon 8060S上，用的是自带的ROCm 7.1库。但在Z13上打开ComfyUI的系统信息，PyTorch的ROCm版本是这样描述这块GPU的：

• PyTorch版本：2.12.0+rocm7.14.0
• cuda:0 AMD Radeon(TM) 8060S Graphics : native (cuda)

这是设计使然。PyTorch文档写明，它的ROCm构建"有意复用现有的torch.cuda接口"，所以为英伟达写的代码在AMD上几乎不用改就能跑。这是个聪明的变通，但AMD的AI栈是靠把自己伪装成英伟达来工作的。

AMD支持的Lemonade表现更差。安装包有签名，但它首次使用时下载的llama.cpp ROCm后端试图加载一个Windows无法验证的CPU库，被Smart App Control拦下，模型根本没加载。这跟测试用的是候选版本构建有关，但用winget或从Lemonade下载msi拿到的就是这个版本，所以值得指出。

另一边，Spark上的ComfyUI没被要求就自己开了DynamicVRAM内存管理和NVML监控——英伟达自家的管理库，同时把AMD后端报告为"PyTorch ROCm/HIP运行时不可用"。

Windows on Arm也让Spark付出代价

英伟达这边也不是全无摩擦。Windows on Arm版的ComfyUI还是beta，只支持英伟达GPU，跑的是每夜构建的PyTorch，而Z13拿到的是正式版。不过两边把模板跑起来都只花了约五分钟，没用什么变通手段。Arm更大的问题在别处，英伟达承诺所有应用都能跑，但没给时间表。

Strix Halo仍赢下一局，而且正是需要128GB的那局

Z13跑起了一个64GB的Spark连加载都做不到的120B模型。OpenAI的gpt-oss 120B在Ollama里需要约60GB内存，Z13把它整个放进GPU，每秒写31.7个token——对一台平板上的120B模型来说，这是真能用的速度。

Spark这边CUDA可用内存约46GB，没有机会。llama-server在启动时报内存不足：cudaMalloc失败，kv缓存缓冲区分配失败。这是64GB配置的限制，不是芯片的限制。两种GPU内存切分方式下CUDA都只看到约46GB，换个切分大概也救不回来。128GB的RTX Spark是存在的，但贵得多。

Z13用比Yoga低450美元的价格给了两倍内存。要在RTX Spark上追平128GB，得看6500美元的ProArt P14，接近翻倍，当然那也是更高一档的ProArt机器。

AMD的问题不在Strix Halo，在它周围的一切

两台都能跑的任务里，RTX Spark用掉的时间是Z13的40%到60%；唯一测了墙插功耗的那项，它用了约一半的电；图像生成快2.6倍。而生成速度的差距超出带宽规格能解释的范围，这总把人拉回软件。这是生态问题，不是芯片问题。

Strix Halo确实还有实打实的优势：Z13能跑64GB Spark跑不了的模型，价格更低，拿的是正式版构建，而Spark依赖beta和每夜版。但当PyTorch的ROCm构建自我介绍成cuda:0时，很难忽略大家到底在为谁的平台写代码。