这确实挺让人费解的——明明GPU满载了，但速度反而只有CPU的1/5。咱们来拆解一下这个情况，看看是不是预期结果，以及你的代码有没有可以优化的地方：

一、这个结果大概率是预期的，原因主要有这几点： #

• 任务太小，GPU的优势没发挥出来：MNIST是个极小的数据集（单样本仅28x28像素），你的模型也非常简单（仅两个128神经元的全连接层）。GPU的强项是大规模并行计算，但启动GPU计算、在CPU和GPU之间传输数据都有固定开销。对于这种小任务，开销占比极高，反而抵消了GPU的并行优势。而如果你的CPU是多核高频型号，拉满负载后处理这种轻量任务的效率会更高。
• PlaidML的额外开销：你用的PlaidML是跨平台深度学习中间层，相比AMD官方的ROCm框架，它会有额外的兼容性适配开销。这种开销在小任务下会被放大，进一步拖慢GPU的整体速度。
• 模型类型适配问题：全连接层（Dense）虽然能并行，但相比卷积层（CNN），它对GPU核心的利用率本来就低一些。如果换成CNN模型，GPU的并行优势会明显凸显。

二、你的代码有没有问题？ #

从逻辑上看，两段代码的核心流程完全一致：加载数据→归一化→构建全连接模型→训练，没有明显的错误。不过可以做几个优化尝试，看看能不能提升GPU性能：

• 调大batch size：默认batch size通常是32，你可以在model.fit里加上batch_size=128或256的参数。更大的batch能让GPU的众多核心更充分地被利用，减少调度开销。
• 换成AMD官方ROCm框架：放弃PlaidML，直接安装支持AMD GPU的TensorFlow（通过ROCm环境），这样能减少中间层的额外开销，更充分发挥GPU的原生性能。
• 测试更大的模型/数据集：比如把全连接层改成512/1024神经元，或者搭建简单的CNN模型（加几层Conv2D），再用CIFAR-10这类更大的数据集测试——这时GPU的并行优势会立刻显现，速度会远超CPU。

总结 #

对于MNIST这种极小的任务，CPU比GPU快完全是正常现象。GPU的价值体现在大规模、高并行度的深度学习任务上。如果想验证GPU的真实性能，换个更复杂的模型或数据集试试就清楚了。

内容的提问来源于stack exchange，提问作者Web Nexus