30B参数模型在树莓派上实时运行

对于本次发布，我们针对人们在实际运行模型时的体验进行了优化：在特定目标设备上实现快速、高质量的响应。

我们使用 ShapeLearn（我们的数据类型学习方法）为 Qwen3-30B-A3B-Instruct-2507 选择权重数据类型，以最大化每秒生成的 token 数（TPS）和输出质量，同时有一个实际约束：模型必须能舒适地装入可用内存。一旦装下了，把文件做得更小本身不是目标。我们只在能改善人们真正关心的权衡关系时才进一步压缩：速度 vs. 质量。

以这种方式处理数据类型学习之所以重要，是因为在 llama.cpp 中，"更少的比特"并不自动等于"更快的速度"。不同的量化格式可能触发不同的 kernel 和开销，在某些 GPU 上，使用更低的比特甚至会变得更慢，尽管使用的内存更少。

底线：把内存视为需要满足的预算，然后优化最重要的东西：TPS 和质量。

是的，这个 30B 的 Qwen3 确实能在树莓派上运行。在树莓派 5（16GB）上，Q3_K_S-2.70bpw [KQ-2] 在 2.70 BPW 时达到 8.03 TPS，并保持了 BF16 质量的 94.18%。它真正感觉是实时的。更广泛地来看，同样的规律处处出现：ByteShape 模型相比其他方案（这里我们考察了 Unsloth 和 MagicQuant）提供了更好的 TPS/质量权衡。

在 CPU 上，通过更短的比特长度来减少占用空间会按照预期影响 TPS 和准确度的权衡：一旦模型装下了，减少占用空间往往以相当单调的方式增加 TPS。如果数据类型选择正确，你可以可预测地用一些质量换取速度，这使得选择一个匹配你的约束条件的曲线上的点变得容易得多。

我们从最受内存限制的 CPU 情况开始（树莓派 5 16GB），其中"装入 RAM"是限制因素，然后转向配备 64GB 内存的 Intel i7，其中一切都能装下。

下面的图表显示了树莓派 5 16GB 上能装入 RAM 的模型的 TPS vs. 标准化准确度。

值得注意的是，在树莓派上使用 30B 模型保持 92%+ 基准准确度时达到 8.5 TPS，重新定义了对树莓派级系统的预期。总体趋势表明 ShapeLearn 始终生成更好的模型，ByteShape 的表现向右上方发展，超过 Unsloth，在相同质量下实现更高的 TPS，或在相同吞吐量下实现更高质量。

我们为两个主要目标强调了选择：准确度或响应时间。

针对响应时间优化同时保持准确度：对于交互式的设备上使用，感知的响应速度由文本出现的速度驱动，而不是峰值吞吐量。实际上，生成达到大约 8 TPS 时感觉就是实时的，舒适地超过了典型阅读速度。在这个树莓派实时领域，Q3_K_S-2.70bpw [KQ-2]（2.70 BPW，8.03 TPS，94.18% 准确度）是我们推荐的首选：它跨越了实时阈值，同时保持了高准确度。与相似质量的 Unsloth 模型相比，ByteShape 以较低的 BPW 和更高的 TPS 实现实时性能，使其成为交互式边缘部署中更高效的选择。

准确度优先：下表列出了能在树莓派上运行的同时实现最高准确度的模型。在这个集合中，ByteShape 模型最好地利用了可用资源来最大化准确度，占据最低错误率的行（约 1.1–1.3% 相对错误，约 98.8% 准确度），而最强的 Unsloth 条目仍然在约 2.1–2.2% 错误（约 97.9% 准确度）。与 Unsloth 的 UD-Q3_K_XL [8] 相比，ByteShape 实现了高达 1.87 倍的更低错误率，同时仍以约 5–6 TPS 运行，舒适地在树莓派 TPS 范围内，使其成为准确度是优先事项时的更好选择。即使在优先考虑最大速度并有所降低准确度时，Q3_K_S-3.25bpw [KQ-5] 也提供了更好的权衡：比最快的 Unsloth 模型更准确、更小和更快。

许多其他 Unsloth 和 MagicQuant 模型（我们的一些也是！）不在这个图表中。我们在其他部分对它们进行了比较，但它们在树莓派情况下不适用。它们根本装不下！

接下来，我们转向配备 64GB RAM 的 Intel i7。下面的图表显示了所有模型的 TPS vs. 标准化准确度。

总体上，ByteShape 模型优于 Unsloth 和 MagicQuant，在可比的吞吐量下使用更少的每参数比特位提供更高的质量。只有 ByteShape 提供了在 26+ TPS 范围内运行的模型，将性能扩展到远超其他方法的水平。

质量优先：在表格的高准确度端，IQ4_XS-4.67bpw [KQ-9] 实现了最低的相对错误率（0.25%），优于最好运行的 Unsloth 模型（Q6_K [20] 和 Q5_K_M [18]，其相对错误分别为 0.36% 和 0.44%）。直接对比，ByteShape 相比 Q6_K [20] 提供了高达 1.44 倍的更低错误率和更高的吞吐量，相比 Q5_K_M [18] 则是 1.76 倍的更低错误率，基本相同的速度。MagicQuant mxfp4 [3] 在这个领域表现落后，既有更高的错误也有更低的 TPS。

平衡点：在中等准确度、高吞吐量区域，Q3_K_S-3.25bpw [KQ-5] 在仅仅 3.25 BPW 下结合了约 98% 的准确度和 23.1 TPS，提供了表中最好的总体平衡。使用 Unsloth（IQ4_XS [10]）匹配或超过这个准确度需要更高的 BPW 和更低的 TPS，而选择速度更接近的 Unsloth 模型（Q3_K_S [7]）会招致 1.73 倍更高的错误率。MagicQuant 在这个范围内没有提供有竞争力的模型；其最快的条目（IQ4_NL [2]）在准确度和吞吐量上都落后于 ByteShape 和 Unsloth。

要点：在质量优先和平衡设置中，ByteShape 始终将可用的比特预算转化为更高的准确度或更高的 TPS，是唯一同时覆盖本比较中高质量和 26+ TPS 平衡性能区域的方法。

GPU：RTX5090/32GB 和 RTX4080/16GB

在 GPU 上，性能与内存占用一样取决于 kernel 选择。对于 matmul/matvec，llama.cpp 的特定量化 GPU 解码路径会产生非常不同的开销，因此每个权重使用更少比特并不能可靠地转化为更高的 TPS。相反，TPS 通常在量化特定的最优点达到峰值。将 BPW 推得更低甚至可能增加 VRAM 流量和指令计数，从而伤害性能而非改善它。我们在 GPU 结果部分之后更深入地分析这种行为，kernel 级别的权衡变得更明显。

我们在两个 GPU 上进行评估：RTX 5090（32 GB），能运行 4 BPW 以上的模型并通常达到最快的最优点，以及 RTX 4080（16 GB），其中超过 4 BPW 的模型装不下，强制进行不同的权衡并使设备优化曲线更容易看到。

RTX 5090（32GB VRAM）

让我们从 5090 开始，它有足够的 VRAM 来支持所有量化模型。下面的图表显示了 TPS vs. 标准化准确度。

两件事立即突出：首先，这个 GPU 显示了明确的约 4 比特最优点：几个约 4b 的模型在非常高的 TPS 处聚集，质量几乎相同。例如包括 Unsloth Q4_0 [12]、Unsloth IQ4_XS [10]、IQ4_XS-3.87bpw [IQ-6] 和 MagicQuant iq4_nl-EHQKOUD-IQ4NL [1]，都在约 98.4–98.9% 的准确度下运行在约 302–303 TPS 左右。在这个紧密的集群中，Unsloth 在吞吐量和质量上略占优势。

其次，在那个最优点之外，权衡变得更加不均匀：

许多其他 Unsloth 和 MagicQuant 模型显示明显更低的 TPS，无论它们被量化得更激进还是保守。

过了约 4b 区域，只有 ByteShape 继续增加 TPS 且质量以更可预测的方式降低。

准确度关键的工作负载：当输出质量至关重要时，ByteShape 在 5090 上提供了最准确的模型：IQ4_XS-4.67bpw [IQ-8]（4.67 BPW，272.98 TPS，99.75% 准确度）。它超过了 Unsloth Q6_K [20]（6.57 BPW，264.88 TPS，99.64% 准确度），同时使用更少的比特并实现了略高的吞吐量，并清晰地优于 MagicQuant mxfp4_moe-H-B16-EUR-IQ4NL-KO-Q5K-QD-Q6K [3]（5.46 BPW，240.42 TPS，99.32% 准确度）在准确度和速度上，使其成为准确度是任务关键部署要求时的最强选择。

实用建议。如果你的 GPU 有足够的 VRAM 来运行一个已经满足你的速度和准确度要求的强约 4b 模型，那个集群是一个极好的默认选择。当任务关键的部署约束要求更高的准确度或更小的模型时曲线变得更有趣，比如在更紧张的内存预算或受限环境下（如我们将在 4080 上看到的）。

RTX 4080（16GB VRAM）

接下来，让我们转向一个更容易获得的 GPU，特别是在这些内存吃紧的时代。4080 的最大绊脚石是其 16GB VRAM，不足以支持 30B 模型的"魔法"约 4b 量化。多方便！这"避免"了 5090 的约 4b 最优点并在硬 VRAM 预算下强制进行了更"真实世界"的比较。下面的图表显示了 TPS vs. 标准化准确度，适用于所有在 4080 上装得下的模型。

在 RTX 4080 上，ByteShape 在相同的 16 GB VRAM 约束下始终优于 Unsloth，提供了更好的 TPS–质量权衡。

特别是，ByteShape 能装的最高质量模型 IQ4_XS-3.87bpw [IQ-6]（3.87 BPW，214.81 TPS，98.66% 准确度）提供了：

对比 Unsloth Q3_K_XL [8]（3.62 BPW，196.42 TPS，97.87% 准确度），1.59 倍更低的错误率和 9.4% 更高的 TPS。

对比 Unsloth IQ2_M [2]（2.84 BPW，214.79 TPS，96.59% 准确度），在相同 TPS 下 2.54 倍更低的错误率。

当我们转向更高的吞吐量时，ByteShape 保持了准确度，而 Unsloth 的错误率出现了悬崖式跌落。

房间里的大象：当 3 比特不仅仅是 3 比特时

这些结果中隐藏着一个不便的真相。在多个设置中，大约 4 bpw 已经很快了，把量化推得更硬并不会使事情变得更快。它只是设法在相同的时间里变得更小和更慢。

减小数据的大小不会自动加快速度。虽然使用更少的比特来存储每个数字看起来应该会减少内存流量并加快计算，但 GPU 不是这样工作的。NVIDIA GPU 以称为"warp"的 32 线程固定组为单位处理工作，这些线程以接近锁步的方式一起进行指令。GPU 硬件针对芯片电路被物理设计为高效处理的特定数据格式、内存访问模式和操作进行了优化。当你的工作负载与这些"黄金路径"匹配时，你会获得峰值性能。超出它们，你会遇到减速。这不是设计缺陷，而是有意的权衡。支持更多灵活性需要额外的电路：更多的线路、更多的晶体管、更多的复杂性。那额外的硬件消耗更多的功率并为每个操作增加延迟，不管程序是否需要那种灵活性。

这里有几个相关硬件"怪癖"的例子：VRAM 以对齐的 32 字节块读取，所以读取 1 字节或 32 字节消耗相同的内存带宽。片上和片外内存也可能遭受争用，具体取决于数据的布局方式，意味着一个 warp 的访问可能在一步内完成或在最坏的情况下被序列化为 32 步。当然，在计算前解码量化值可能需要额外的指令，成本取决于量化方案。

这解释了我们观察到的行为：4 比特 kernel 比 3 比特或 2 比特 kernel 更有效地使用 VRAM 带宽，并在计算前需要更少的解码步骤。同时，4 比特 kernel 和低比特 kernel 一样有效地利用子字并行，都主要依赖动态缓存而非共享内存来在可能的情况下利用数据重用。

那么为什么 llama.cpp 还没被优化为为每个比特长度提供峰值速度呢？我们的理解是 llama.cpp 优先考虑便携、节省空间的量化，可以在广泛的硬件上运行。那个设计目标限制了后端如何激进地重塑数据布局或重新排列计算的方式，这可能对一个 GPU 或一个比特宽度有帮助。

一个关键例子是它选择在固定的 256 值块中存储量化权重。每个块是自包含的（它包含解码它所需的一切）并位于张量中简单、可预测的偏移处，这使得该格式易于实现且快速查找。

权衡是 GPU 经常需要并行解码许多块来保持其宽计算单元繁忙。有许多独立的 256 值块，那些并行解码可以转化为更分散或零碎的 VRAM 读取和额外的解码开销，降低带宽效率，特别是对于某些低比特格式。

例如 RTX 5090 上的一个例子：一个矩阵乘法 [256, 768] × [768, 2048] 用 iq4_xs 数据类型耗时约 54µs，但用 iq3_xxs 耗时约 62µs（mul_mat_q()+mul_mat_q_stream_k_fixup()）。换句话说，切掉接近 1.2 比特每个权重（权重占用空间的 25% 多的减少）导致了约 13% 的减速，直接伤害用户体验。

对数据类型学习很重要的绝佳提醒：启发式方法可以让我们走一部分路，但不是全部。ShapeLearn 做出了经过深思熟虑的、按张量的数据类型选择，改善了速度而不牺牲准确度。

方法论（简要回顾）

如果你想知道我们是如何给这些点评分的，完整的方法论在我们之前的博文中讨论过。这篇文章有意专注于曲线和设备权衡，所以这是快速版本。

对于每个量化变体，我们在目标设备上测量吞吐量（TPS）并计算单个标准化质量分数，相对于 BF16 基准，使用与方法论文相同的评估工具和提示。质量分数将标准基准（MMLU、GSM8K、IFEval、LiveCodeBench V4）聚合为一个数字，所以你可以直接比较点。换句话说，图中的每个点回答两个问题：它在这个设备上运行的速度如何，它相比 BF16 保留了多少质量，同时内存装下是第一约束。

我们也想感谢所有人在我们最近的 Reddit 帖子上提供的许多极好的建议，用于改进和扩展这个评估策略，我们正在积极处理它们。现在，评估是主要瓶颈，而不是数据类型学习/量化。仔细的评估对于清晰地传达每个模型的优势至关重要。

首先，感谢你的坚持。你度过了所有这一切而没有放弃。我们真诚地感到荣幸！

要点很简单：把内存视为约束，而不是目标。一旦模型在你的设备上装下了，重要的是权衡曲线，TPS vs. 质量。跨 CPU 和 GPU，ByteShape 始终落在那条曲线的更好一侧，提供相同质量下更多的速度或相同速度下更高的质量。

如果你在树莓派 5（16 GB）上部署并想要一个真正的交互体验，从 Q3_K_S-2.70bpw [KQ-2] 开始。在更大的 CPU 或 GPU 上，你可以沿曲线向上移动到更高质量的点，吞吐量损失很小，同样的规则适用：先装下，然后优化权衡。

我们会继续发布更多设备目标的变体（和更多图）。如果你的系统不能平顺地运行 30B 模型，别怪模型或硅。怪数据类型吧。