迈向本地即插即用的人工智能

2026年5月17日

上周我写了关于本地运行AI的硬件方面：为什么内存带宽比原始算力更重要，哪些机器值得构建，以及市场趋势。如果错过了，请从那里开始，因为本文直接建立在此之上。

在追求AI独立的过程中，硬件设定了天花板，但决定你能接近多少的是软件。两台拥有相同GPU、相同VRAM、相同带宽的机器，一台运行朴素推理，另一台运行优化栈，每秒钟的token数可能相差3-5倍。这可能意味着从5 tok/s到20-30 tok/s的差距，后者才达到可用程度。更进一步，一些技术以及软件-模型-硬件优化实现，可能允许你在至少96GB RAM的MacBook上运行像DeepSeek-V4-Flash这样的大模型。相同的模型、相同的硬件，不同的软件层选择（我觉得我们在这方面可以向视频编码和压缩行业学习很多。我们必须从每一美元的硬件资源中榨取最大价值）。

上周我提出了一个新目标：创建一个在一定价格点内足够快速地生成token的推理盒。到目前为止，我还没有找到一个完全满足我需求的产品。我希望这项工作的成果能让我找到一个针对本地推理优化的硬件配置，它即插即用且价格合理，或者是一个能检测当前硬件并建议最佳模型和配置的工具。

本文继续这一搜索，重点介绍改进推理栈的最新技巧。

MoE vs 密集模型

在讨论软件技巧之前，有一个架构决策位于所有技巧之下，因为它改变了软件层需要处理的内容。你可能会在本地以不错吞吐量运行的大多数有趣模型都是混合专家（MoE）架构。Qwen3.6-35B-A3B、Qwen3-235B-A22B-250、DeepSeek-V4。命名约定告诉你结构：35B总参数，但每个token仅3B活跃。模型被划分为专家子网络和一个路由器，决定每个token激活哪些专家。

这类模型的主要优势（以及为何它是对硬件影响最大的变化）在于，如果每个token只有3B/30B参数工作，你就能获得接近3B规模推理速度，同时模型拥有30B规模知识。配合正确的服务技巧，如llama.cpp的-ngl 99 -ncmoe 99标志（将注意力和共享权重保留在GPU上，并将冷门专家FFN层卸载到系统RAM），Qwen3.6-35B-A3B在仅8GB VRAM的RTX 3070 Ti上可达33.5 tok/s，前提是你有64GB+快速系统RAM用于卸载的专家。运行35B知识模型的底线比大多数人意识到的还要低。

主要缺点是一致性。如果你使用了足够长时间的MoE模型，你可能经历过我将要描述的情况。把MoE模型想象成医院。每个患者被分诊给合适的专家。但哪个专家激活取决于token。模型在一个领域可能感觉敏锐，而在另一个领域明显较弱，取决于激活的专家。密集模型没有这个问题，因为每个参数每次都处理每个token。更慢、更昂贵，但完全一致。这种不一致性可能体现在工具调用循环、性能下降和灾难性遗忘上。

对于推理任务、长上下文连贯性，以及任何需要模型在50,000 token上下文中保持敏锐的任务，密集模型通常更好。这就是为什么我始终建议在需要多次助理轮次和准确上下文保持的任何智能体任务中使用密集模型。

此外还有服务问题：当一个批次中太多token同时路由到同一个专家时，该专家的缓冲区会溢出，token被静默丢弃。模型不会警告你这一点，情况只会恶化。密集推理没有这种复杂性。

那么如何在密集和MoE模型之间选择？以下是我目前使用的实践决策树：

• 8GB VRAM GPU + 64GB系统RAM？MoE与专家卸载是你能运行一个有能力模型的唯一真正选择。Qwen3.6-35B-A3B Q4或Gemma4-26B-A4B配合llama.cpp卸载适合此配置。吞吐量受CPU带宽限制，而非GPU，因此快速DDR5系统比GPU世代更重要。
• 16–24GB VRAM（RTX 3090、RTX 4090、RTX 4080）？你有真正的选择。密集Qwen3.6-27B Q4_K_M约16GB可容纳，无需卸载，无服务复杂性，质量一致。MoE Qwen3-35B-A3B在此级别也可部分卸载。如果你的工作负载是智能体型（长上下文、工具调用、多步连贯性等），密集模型的一致性优势值得略低的原始吞吐量（这可能像我在上一篇文章中描述的那样痛苦）。
• 128GB+统一内存（Mac M3 Ultra、Strix Halo / Ryzen AI Max+）？这是MoE明确更好的地方。你可以在统一内存中容纳整个Qwen3-235B-A22B（235B总参数，每个token 22B活跃），并在完整上下文下运行而无需任何卸载。在此级别，你可以在本地获得前沿级能力。每个token 22B活跃参数仍能在统一内存的高带宽池上提供强劲吞吐量。敏锐的读者可能会想，那为什么你还要在自己的Strix Halo上运行Qwen3.6-27B这样的密集模型？我们又回到了一致性问题。我正在尝试运行长时间运行的智能体任务。随着上下文增长，性能迅速崩溃。
• 多GPU / 192GB+ VRAM？你基本上可以运行适合你需要的任何模型。MoE全精度，无需量化。在此并行级别，路由开销变得微不足道。

简而言之：如果VRAM有限且系统RAM充足，选择MoE与专家卸载。如果有足够VRAM干净地容纳密集模型，对于需要长上下文连贯性的任务，优先选择密集模型。如果有大型统一内存机器，顶级MoE（如Qwen3-235B-A22B）成为你在本地能运行的最有能力选项。

幸运的是，阿里巴巴用Qwen3.6构建了这一范围的两端，到目前为止我一直在使用它们，并且相当满意。MoE选项是Qwen3.6-35B-A3B。密集选项是Qwen3.6-27B。两者运行相同的混合注意力核心，它们之间的选择几乎完全是硬件和工作负载问题，而非模型质量问题。

我是如何得到这些数字的？在为这一部分做研究时，我遇到了LocalMaxxing.com。这个网站是纯金。它提供了不同硬件架构上的不同模型基准测试，并带有清晰的推理引擎及其配置信息。这给了我接下来几个月的功课，也是我这一新追求的绝佳资源。

注意力动物园

MoE/密集问题只是模型架构的一个维度。另一个是模型内部使用的注意力机制。每个变体都是对同一约束的不同回答：标准注意力产生一个N×N矩阵，其中N是序列长度。在10,000 token时，那是1亿个条目，内存成本呈二次方增长。过去两年中每一个有趣的注意力发展本质上都是试图在不牺牲太多质量的情况下摆脱这一曲线。每个都有其自身的权衡，可能更适合不同的底层架构。

Sebastian Raschka的可视化指南是我能推荐的最佳资源来导航注意力格局。这个进展值得关注，因为每一步都揭示了不同的权衡。

• 标准多头注意力是每个人（或者也许只是我）想到transformer中的注意力机制时想到的，每个token关注每个其他token，就这么简单。二次方内存，二次方计算。今天没有人选择它用于本地硬件；它只是衡量其他一切的标准基线。
• GQA（分组查询注意力）是第一个实际大规模部署的修复。不是每个查询头维护独立的键值投影，而是多个查询头共享一个KV对。大约节省50% KV缓存，几乎没有质量损失。Llama 3、Qwen3、Gemma 3都使用它。权衡很小，这就是它迅速成为默认的原因。
• MLA（多头潜在注意力），来自DeepSeek，更深入。不是减少你保留的KV对数量，而是压缩每个存储的内容，保存一个潜在表示并按需重建完整KV状态。服务起来比GQA更复杂，但在大规模下，每字节的质量优势是真实的。DeepSeek V3和Kimi K2使用它；当你拥有吸收重建开销的内存并想要前沿级输出质量时，这是正确的选择。
• SWA（滑动窗口注意力）则采取不同角度。不是压缩缓存，而是简单限制每个token回顾的距离。Gemma 3使用5:1的局部与全局层比例，窗口为1,024 token，并结合GQA。内存线性增长而非二次方，对于大多数实际工作负载（如代码补全、文档问答、聊天），质量影响极小。权衡是你确实在这些局部层上放弃了全局上下文。对于大多数任务没问题；对于极长距离推理则重要。
• Gated DeltaNet，用于Qwen3.6-27B，更进一步：不是关注存储的序列，而是维护一个快速权重内存，每个新token不断更新。无论序列长度如何，内存占用保持平坦。从4k到65k上下文只增加约800MB VRAM，而非几GB，这意味着16GB卡从撞墙到与三倍大小的机器保持竞争力。权衡是架构复杂性，以及对于完整注意力而言微不足道的极长距离依赖，需要模型学会将其压缩到运行中的内存状态中。
• Mamba-2混合体（Nvidia的Nemotron Nano）是逻辑上的极致，其中大部分注意力被循环状态机取代，内存恒定不变，与序列长度无关。对于边缘和嵌入式硬件是正确的选择，即使GQA也太多。当你有合适的GPU可用时，不是首选；质量上限较低，但内存下限是格局中的最低点。

这些差异在机器上体现出来。在长上下文下，使用SWA时KV缓存几乎不动，服务引擎拥有在MHA下不会有的余量。切换到相同上下文长度的GQA，VRAM明显攀升。运行DeltaNet混合体，内存分布几乎平坦。当你将多个智能体适应固定内存预算时，模型使用的注意力变体与其参数数量一样重要。

甚至还有一个维度我决定不在此文中讨论，它值得单独一篇文章，那就是使用哪种量化机制及其不同变体（这本身就是一个巨兽）。关于这个，请参阅我关于TurboQuant的文章。

推测解码

几周前，谷歌宣布Gemma 4配备了专用的MTP起草器：小型伴侣模型，可将推理速度提升高达3倍，而不影响质量。

推测解码解决的问题是transformer的一个根本问题。正如我们在本通讯中多次描述的，LLM自回归地生成文本，即一次一个token，每个token依赖于它之前的所有内容。大型模型必须为每个token执行一次完整的前向传递。你无法并行化生成本身。所以无论多快...（由于AI成本控制截断）