LLM Local Inference

让我试着梳理一下我的思路，把 LLM 在消费级硬件上的 local inference 讲一讲。

Hook

Kimi K3 发布了，Hype 是超越了 Anthropic 的 Fable 5，但是它是开源的。

开源的模型不同于开源的软件，基本上只有模型的「权重」和相关的纯文本配置，比如 Chat Template 会被公开。业界托管开源模型权重的网站是 Hugging Face。有些公司还会提供公开发表的相关论文，来介绍他们的模型架构、训练方法等等。

如果去 Hugging Face 上看看就会发现，所谓开源模型的权重，是一堆 .safetensors 的巨大文件，带编号，从 00001 开始，全部权重文件加起来有几十、几百 GB，甚至上 TB。这么大规模的东西，很难想象在普通人的普通电脑上跑起来。没错，所谓的 Local LLM 很多时候指的并不是 Kimi K3 这种规模的前沿模型，而是体积要小很多的中小型模型。

让我们来看一个 2026 年在社区里面很流行的模型，比如说这个 gemma-4-31B-it-Q4_K_M.gguf。你可能会问，怎么它只有一个单一文件，不像刚刚看的 Kimi K3 那样，有一堆？这是因为它用了不同的二进制格式来储存模型相关的东西。比如说你把你的资料压缩成 .zip 和 .rar 就是两种不同的格式，但是里面的东西是一样的。

如果你去看 Google 的官方 Hugging Face 页面，你会发现他们提供的也是 .safetensors ，那么 .gguf 到底是啥？

GGUF 和 llama.cpp

这就不得不提一个人了：Georgi Gerganov。GG，一个保加利亚人，一个高尚的人，一个才能出众的人，一个值得被记住的人。2023年2月，Meta 也就是 Facebook 发布并开源了 llama-65B 模型。此时，GG 刚刚拿到他崭新的 M1 MacBook。他很快算了一下，“Okay, 65 billion parameters. You probably need about 40 gigs of RAM, with 4-bit quantization. So this can run on a MacBook. Why not do it?”

对这段故事感兴趣的话可以听听这个采访 GG 的播客节目，也有文字转录稿：Bringing Whisper and LLaMA to the masses with Georgi Gerganov

于是 GG 就拓展了他已有的 Project GGML (它的意思很可能是 Georgi Gerganov Machine Learning)，来尝试在 Apple Silicon 的 CPU 上跑 LLM Inference。

这里得提一句，LLM，也就是 Large Language Model，本质上还是神经网络，只不过规模特别庞大。这样的模型也是有训练和推理两个阶段的。训练就不说了，需要庞大的算力和更加庞大的数据，我们和 LLM 聊天，使用 AI 生成、修改图片，都是「使用」，也就是「推理」，Inference。在机器学习作为一个时髦的名词还活跃的时候，大家一般用「训练（Training）」、「验证（Evaluation）」和「预测（Prediction）」，但随着深度学习打败了机器学习，成为新的时髦名词，「预测（Prediction）」就被「推理（Inference）」取代了。但含义差不多，都指的是消费已经训练好的模型。

言归正传，Georgi Gerganov 拓展了他的 ggml，后来这个词变成了他的公司名称，为了适应 LLM 的迅速发展，他又设计并普及了新的二进制数据格式，GGUF，含义很可能是 GGML- Unified Fileformat，而不是 Google Search 或者 AI 说的那个 GPT-Generated Unified Format。主打一个 All-In-One。就像一开始说的那样，原始发布的 .safetensors 只是模型权重文件，为了跑起来，还有配套的一堆 .json, .yml 等等。.gguf 就把所有需要的文件都打包放在了一起。这个项目后来成为了广为人知的 llama.cpp。

也就是说 .gguf 是给 llama.cpp 专用的 LLM 数据文件格式。llama.cpp 是 Georgi Gerganov 为了在他自己崭新的 M1 MacBook 上跑 llama-65B 而搞出来的项目。

模型名称详解

让我们再看看模型名字：gemma-4-31B-it-Q4_K_M.gguf，现在我们理解了什么是 .gguf，那是文件格式。文件名的其它部分是什么意思呢？

gemma-4 是模型系列，意思是第4代 Gemma。代际差异一般是架构优化和训练数据、训练方法更新。比如 DeepSeek R1， DeepSeek V3.2， DeepSeek V4，Kimi K2.6， K2.7，K3 等等。

31B 是参数量，意思是这个模型一共有 310亿参数。只写了参数量的话，一般暗示这个模型是 Dense（稠密）架构，而不是 MoE （混合专家）架构。后者名称一般看起来是这样的：gemma-4-26B-A4B-IT，代表总参数量是 26B，但推理时的单次激活参数量只有 4B，A4B 是 Active 4B 的意思。

IT 是 Instruction Tuned，代表这不是一个学术研究用的 base model，而是可以直接用来聊天的，遵循人类指令的微调版本。

Q4_K_M 意思是 4bit 量化，使用的是 K-quant 动态量化算法，体积是 Medium。K-quant 动态量化算法是 .gguf格式也就是 llama.cpp 生态独占的一种量化算法。

参数量和量化

那什么是量化？为什么要量化？量化算法又是什么？

这要从参数量谈起。

31B 参数量，就是 31,000,000,000 （310亿） 个参数，每个参数都是一个浮点数。有计算机背景的人都知道，常见的单精度浮点数格式 float32 是用 32个 bit 来存储一个数字。这太臃肿了。在 LLM 领域，往往用的是半精度格式，也就是 fp16，存一个数字只需要 16个 bit，也就是 2个字节（Bytes）。但是 fp16 有一个致命的缺陷： 它用了很多 bit 来存储精度，导致它能表示的数字大小很有限。而模型训练过程中，很可能出现超出它上限的大小，导致数据溢出，影响训练，更影响模型的性能。2017年为了解决这个问题，Google 的 AI 研究机构，Google Brain，公开了新的半精度格式 bf16，意思是 Brain Floating Point 16 bits。同样用 16 个 bits 来存储一个浮点数，但它牺牲了精度，匀出了更多 bit 给数字的大小。用 bf16 训练模型就不会出现溢出的问题了，所以很快这就成了新的行业标准，直到现在。所有官方发布的模型权重，在没有特殊说明的情况下，.safetensors 里面存储的都是 bf16 格式的浮点数。

说回参数量，31,000,000,000 （310亿） ，用10进制和我们所熟悉的 K，M，G 来表示，就是 31G 个参数。每个参数占用 16bit 也就是 2个字节(Bytes)，那么一共占用 31×2 GB 的空间。

众所周知，CPU 是通用计算单元，而 GPU 是专用密集计算单元，像 31G 个浮点数做复杂运算，CPU 的效率远远低于 GPU。而无论是给 CPU 用的内存 RAM 还是给 GPU 用的显存 VRAM，都昂贵且有限。把 31×2 GB 的数据放在 RAM 里还有可能，想全部放进 VRAM 里面，对消费级显卡来说，几乎不切实际。目前最强的消费级单卡是 NVIDIA GeForce RTX 5090，也只有 32GB VRAM。

那怎么办呢？只好想办法压缩这些浮点数了。最好的方法当然是用更少的 bit 来表示这些浮点数，当然会牺牲精度。比如fp8, fp4, mxfp8, mxfp4, nvfp8, nvfp4。这都是现代格式，可以说就是为了 LLM 而生的。据我所知，只有 Blackwell 架构的 NVIDIA 显卡（最新一代，也就是 5090 这一代）原生支持部分这类格式。

那其它的硬件怎么办呢？常用做法是用放缩法把浮点数映射成整数。比如我们可以在 310亿参数里面，按 128 分组，每 128个浮点数放进一组。我们约定好用 8bit 整数来表示它们，那就要把这 128个浮点数按统一的比例缩放进 [0, 2^8-1] 这 256 个数的区间里面，按就近原则把它们变成整数。这就是 INT8 量化。当然，这样实际上存下来的是128个整数和1个浮点数，那个浮点数就用来把整数再重新变回浮点数。这一来一回，精度就损失了。

这里有必要提一下，如果我们除了放缩，再加上偏置，也就是用 kx+b 再就近取整，代价是多存一个浮点数，好处就是精度可以更好。这种也是 INT8 量化，不过是 Affine INT8 量化。

这样以来，一个参数占用的空间就从 16bit 变成了 8bit，也就是从 2个字节变成了1个字节，31×2 GB 就变成了 31GB，啊，刚好能放进 5090 的显存了。

同理，4bit 量化就再减少一半，只需要大约 16GB 就可以了。

代价呢？当然是精度进一步损失了。那有没有办法挽回一些精度呢？办法是有的，那就是各种动态量化算法大显身手的地方了。比如说，K Quant 就不是用统一的分组大小，而是一个大组下面还会分成小组。再比如说，这些权重的在推理的时候发挥的作用是不一样的，有一些要比剩下的更重要，那我们可以分配 5bit 或者 6bit 给这些权重，4bit 给另一些权重。而如何知道哪些权重更重要呢？这就有各种算法和理论大显神通了：AWQ (Activation-aware Weight Quantization), GPTQ (Generalized Post-Training Quantization), Importance Matrix 等等.

为了在 4bit 和更激进的量化中保留更多模型的智力，MLX 社区也有对应的量化算法。比如 OptiQ，它选择了使用 KL 散度作为度量指标，来精准识别应该保护的权重。还有 JANG-Q，为了兼顾速度和质量，这个算法抛弃了通用的 MLX 格式，选择在此基础上使用 custom kernel，致力于成为 MLX 社区的 GGUF。它的 2-bit 和 3-bit 量化版本确实感觉质量高不少。当然也有 oMLX 的 oQ-e，它用自己收集的校准数据来跑出 Importance Matrix，并根据实际激活时的 RMS 来找出敏感权重并加以保护。还有 Unsloth 的 Dynamic 2.0，它的校准数据是公认的高质量，而且它的 4bit MLX 版本数据对齐更好，也就是能榨出更多的 Apple Silicon 算力，Prefill 显著更快。但 Unsloth 主攻 GGUF，他们自己也说，MLX Quant 还在持续改进中。

硬件选择

CPU 还是 GPU

尽管 llama.cpp 一开始是为了用 CPU 让尽可能多的设备都可以跑 LLM 推理，但 Georgi Gerganov 很快意识到了，CPU 还是太慢，想舒服地跑 LLM 还是得用 GPU。因此 llama.cpp 其实包含对 Nvidia 的 CUDA 支持，也包括对 Apple Silicon 的 Metal 支持。

首先是算力优势。算力有一个计量单位，Operations Per Second，OPS。不同硬件对不同格式的数据的算力都不太一样。但几乎所有硬件都支持 fp32，此时的算力用 FLOPS 表示，比如 Intel Core i9-14900K 的集成 Intel UHD Graphics 770 有大约 0.8 TFLOPS 的算力。5年前的 M1 Max 32核 GPU 的 fp32 算力则有 10.4 TFLOPS，也就是每秒1040亿次单精度浮点数运算。由于没有专门的半精度格式电路，这个芯片的 fp16 格式算力和 fp32 是一样的。NVIDIA 显卡对很多格式都有专用电路，比如 RTX 5090，fp32算力达到了 104.8 TFLOPS，在不启用专用的 Tensor Core 的情况下，fp16/bf16算力有大约 209.5 TFLOPS，启用的话则可以来到 838.4 TFLOPS。Blackwell 架构和第五代 Tensor Core 还支持 fp4 格式，能有 3,352 FP4 TFLOPS 的算力。可以看出，CPU 到 GPU 是 10倍算力差距，GPU 到先进的独立显卡是 20倍到40倍的差距。

其次是速度，也就是带宽优势。普通 PC 的双通道 DDR5 RAM 能提供大约 80 – 90 GB/s 的带宽，比如 Intel Core i9-14900K / AMD Ryzen 9 7950X。Apple 不带后缀的芯片，比如 M1，有 68.25 GB/s，M1 Pro 则有 200 GB/s， M1 Max 是 400 GB/s，M1 Ultra 是 800 GB/s。NVIDIA RTX 4090 是 1008 GB/s，5090 则是 1792 GB/s。

独立显卡还是统一内存

NVIDIA 有完整的 CUDA 生态，虽然是消费级显卡，但依然有顶级的算力和带宽。美中不足的是显存实在有限。

而 Apple Silicon 却有一个得天独厚的优势：统一内存。它的算力再怎么说也是 CPU 的 10倍以上，带宽更是普通 RAM 带宽的 2-5倍。虽然远不如 NVIDIA，但它的统一内存却可以轻松来到 48GB，64GB，甚至 96GB，128GB，乃至 256GB，512GB。对跑 LLM 来说，放得下才是先决条件。你的速度再快，模型都加载不了，也是白搭。

Apple Silicon 的另一个优势是功耗。RTX 5090 光单张显卡功耗就来到了 600W，而 128GB 统一内存的 16英寸 M5 Max MacBook Pro 整机功耗瞬时峰值也才 200W。

更不必说，这还是一台完整的 Laptop，可以随身携带，甚至可以带去飞机上。

如果你明确知道自己要跑什么模型，并且有能力组装一台整机，那么 NVIDIA 的独立显卡能提供最强的 local LLM 体验。但如果你不能，也不想让房间变成火炉，不想听到直升机一般的风扇声，还想多体验一些模型，甚至想随身带走，那么 Apple Silicon 才是唯一的选择。

这里需要强调的是，由于芯片设计的年代较早，M1 和 M2 系列并没有支持 bf16 的硬件（电路），这个格式 2017年才初次发布，直到 M3 系列，才有了对它的原生硬件支持。但是 M3 Pro 的带宽只有 150 GB/s，相较于 M1 Pro 和 M2 Pro 的 200 GB/s 来说，是一个显著倒退。M5 系列则是单独一档，因为它拥有 Apple 的 Neural Accelerators，相当于 Apple 阵营的 Tensor Cores，这极大地提升了 M5 系列芯片的算力。当然，带宽也是独一档，M5 Max 有 614 GB/s。

选的时候，优先选 64GB 以上的统一内存，芯片则要优先带 Max 后缀的，最不济也得是 Pro，当然，要避开 M3 Pro。M3 Max 有两个版本，30核 GPU 的只有 300 GB/s，40核的才有 400 GB/s。

推理框架（软件）选择

最大的社区就是 llama.cpp， 你总是能找到各种有意思的 .gguf。

但如果你想榨干你的 NVIDIA 显卡，也许 vLLM 才是最佳选择。毕竟 llama.cpp 主打通用，vLLM 则走向了极致的性能优化。

在 Apple Silicon 上也是一样，不过 Metal 提供的工具叫 MLX，想榨干 Apple Silicon 的性能，就要在相对年轻和不成熟的 MLX 社区里面找了。最推荐的是 oMLX，当然，如果你想尝试，也可以看看 Rapid-MLX，以及 MTPLX。还有一个比较新的项目，支持的模型还不算多，但确实比通用 MLX 框架榨出了更多 Apple Silicon 的算力：baseRT。

你可能会看到另一些推荐，比如 Ollama 和 LM Studio。这两个都是 llama.cpp 的 wrapper，LM Studio 提供了成熟的图形界面，Ollama 则主打一个简洁，一行简单的命令就能让你跑起来本地模型。

可我不得不说，Friends Don’t Let Friends Use Ollama。从写这篇文章的角度来讲，我无疑是尊重和感恩 Georgi Gerganov 的，可 Ollama 并不愿意承认自己只是给 llama.cpp 包装了一层，在开源社区里面这是极其不受欢迎的行为。而且它不尊重 .gguf All-In-One 的设计理念: 明明是通用的 .gguf 格式，Ollama 却强制推行其自家的 Modelfile 和私有打包格式，不仅违背了 GGUF 「All-in-One」 的初衷，还让不熟悉底层的人产生了一种「模型必须由 Ollama 官方适配才能跑」的错觉。

Prefill 和 Decode

上面介绍了「算力」和「带宽」的概念，但是没有深入介绍，这两个概念和 LLM 推理有什么关系。

LLM 推理大体分为两个阶段，Prompt Prefill （PP）和 Token Generation。这里要稍微啰嗦一点，仔细讲一下这些概念。当我们把一段自然语言，比如「Hello，who are you？」发给 LLM 的时候，LLM 是不认识的。自然语言首先要变成数字才行，也就是 embedding。这一步需要用到 embedding 字典，也就是所谓的 Vocabulary。它将自然语言打断分割成更小的单元，比如「你」是一个单位，「你好」也是一个单位；再比如英文里面的常见单词后缀「ness」是一个单位，「Apple」也是。这些单位被称作 Token。每个模型的分词都不太一样。

根据算法，每个 Token 都要通过模型训练的过程，变成一串固定的浮点数，称作词向量。推理的时候，则是把输入的自然语言先分词，然后映射到权重里面 embedding 层，用类似查表的方式把自然语言变成组成它的 token 的词向量。

那有了这些词向量，是不是 LLM 就可以开始生成回复了呢？不是的。这些词向量还要完整地按模型的架构从头到尾跑一遍，和每一个权重按照模型的设计进行浮点运算，最终被转换为另一批浮点数。在 LLM 的世界里，这些东西被称作 K-V Cache。这里的 K-V 来自 Google 的 Transformer 架构，Google 创造性地提出了这种架构和注意力机制，解决了传统的自然语言处理中的难题。这个注意力机制，就是 Q-K-V 矩阵。

不去聊算法底层和现代 LLM 的各种注意力机制的创新变体，这里的关键是，所有的输入，都要先变成一个个 token，这些 token 再变成 K-V Cache，这里面要进行大量的浮点数运算。按照公式，一个 token 在这个过程中，要和每一个参数进行乘法和加法运算各一次，也就是2次浮点数运算。为了完成这个运算，还要把参数（权重）从统一内存（或者显存）搬运到算数计算单元的高速片上缓存中去，这个搬运速度取决于带宽。

以 4bit 均匀量化的 gemma-4-31B-IT 为例，bf16 精度下，模型权重占 62 GB，4bit 量化约占 15.5 GB。

假设使用的设备是 32核 GPU 的 M1 Max，它的统一内存带宽是 400 GB/s，fp16 算力是 10.5 TFLOPS，也就是 10500\times 10^9 FLOPS

Prefill 理论上限计算

所以1个 token 在 Prefill 阶段需要的算力是：31\times 10^9 (个参数) \times 2 （乘加运算） = 62 \times 10^9 （次）

那么极限 Prefill 的速度就是

\displaystyle \frac{10500\times 10^9 (FLO/s) }{62\times 10^9 (FLO/token)} \approx 169.4 （tokens/s）

在实际运行中，GPU 不可能 100% 时间都在做矩阵乘法。由于非线性算子（如激活函数、Norm 层）、线程同步、以及反量化占用的微小指令周期，在移动端 GPU 上能够达到 78% 左右的硬件利用率已经是非常了不起的工程优化了。也就是说，实际上能看到的 Prefill 速度大约是

\displaystyle 169.4 \times 78\% \approx 132.1 (tokens/s)

这个阶段，显然 GPU 的算力越强，速度就越快。LLM生成第一个 token 就越快。从输入到看到 LLM 吐出的第一个回复 token 的时间叫做首字延迟 TTFT （Time To First Token），这方面 Nvidia 显卡有无与伦比的优势。

Decode 理论上限计算

到了生成 token 的阶段，事情就变得不一样了。

在本地单批次（Batch Size = 1）的部署场景下，也是单人单机自己玩耍的场景，为了生成1个token，都要把它之前的所有 token 按顺序过一遍所有的权重，这里是有顺序的，所以只能一个 token 一个 token 的生成，无法并行。算第一个 token 需要把 15.5GB 的权重从显存搬运到寄存器，然后算第二个token的时候还要再搬一遍，所以生成 token 的速度几乎就是完整搬运所有权重的速度：

\displaystyle \frac{400 (GB/s)}{15.5 (GB/token)} \approx 25.8 (tokens/s)

可是实际上，由于 K-V Cache 也有体积，而且会随着已生成 token 的长度增长而增加，实际上分母并不是 15.5(GB/token)，而是更大的数字，而且会动态增长。M1 Max 宣称的 400 GB/s 是理论峰值带宽。在现实的半导体物理中，没有任何内存控制器能做到 100% 的总线效率。考虑 DRAM 延迟和物理折损（内存地址转换、Bank 冲突、总线周转等物理延迟），M1 Max 的内存控制器实际吞吐效率也只能达到 85% – 90%。而由于 Gemma-4 系列的特殊架构，GPU 运算的程序，也就是 Kernel 和算子，也会有损失，实际上的吞吐效率可能也就 60% – 80%。也就是：

\displaystyle 25.8(tokens/s)\times 80\% = 20.64(tokens/s)

显然，想让 LLM 回复的时候吐字快一点，带宽很重要。

根据我的经验，吐字的时候有 10-20 tokens/s 就很舒适了，比人眼的阅读速度略快一些，完全可以接受。20-30 tokens/s 几乎是网页上那些 API 提供的吐字速度。更快当然更好。

Prefill 的体感就很有趣了，200 tokens/s 是一个分界线，这个级别给人的感觉是可用，但明显慢。400 tokens/s 左右开始有流畅的感觉。最好有 600-800 tokens/s，但是对 Apple Silicon 来说，这几乎意味着只能用 MoE 了。

好在除了 Agentic Coding，很少有需要 64K 以上的 context 的使用场景。而 Agentic Coding 场景下，得益于 K-V Cache 的 Cache Hit，通过持久化 K-V Cache，可以节省大量时间。单轮新增的 Prompt 也几乎不会超过 64K。

2026年7月流行模型的规模和前沿模型的对比

名称	参数量	注释
Kimi K3	2.8T-A50B
DeepSeek V4 Pro	1.6T-A49B
Xiaomi MiMo-V2.5-Pro	1.02T-A42B
GLM 5.2	744B-A40B	需要2台 128GB 统一内存机器部署2bit 版本
MiniMax M3	428B-A23B
Qwen3.5-Plus	397B-A17B
Tencent Hy3	295B-A21B
DeepSeek V4 Flash	284B-A13B	128 GB 统一内存可部署 2-bit 版本 64 GB 统一内存可用 SSD Streaming
Qwen3.5-122B-A10B	122B-A10B
GPT-OSS-120B	117B-A5B	2025年8月发布
Qwen3.6-35B-A3B	35B-A3B	Qwen3.6-Flash
Gemma-4-31B-IT	31B
Qwen3.6-27B	27B	消费级硬件 Agentic Coding SOTA
Gemma-4-26B-A4B	26B-A4B
GPT-OSS-20B	21B-A3.6B	2025年8月发布
Gemma-4-12B-IT	12B
Qwen3.5-9B	9B	模型智力分界线
Gemma-4-E4B-IT	4.5B (8B with embedding)
Qwen3.5-4B	4B

这个表格列出了一些模型，是你在 2026年7月会想要考虑部署的那些。其中有两条分界线。

一个是 Qwen3.5-9B，这是社区最受欢迎的模型之一。它体积小巧，性能优越，还是原生多模态。最大的优点是它的 CoT （思维链），它能通过冗长的 CoT 来获得远超它体积的智力。这也是它的缺点。因为如果到了不得不考虑它的时候，那你的硬件绝对显存有限，没那么大的 context window 给它放 reasoning tokens。而且作为一个稠密模型，它的速度比较慢。

把它作为底座进行微调的社区版本数不胜数，目前来看，表现最好的是 Ornith-1.0-9B，和 Qwythos-9B-V2。前者是 agentic 能力强化版，代价是智力受损，靠 CoT 也无法挽回。后者是世界知识和 Coding 能力强化版，且通过 YarN 支持 1M 上下文，并且特别处理了原版 reasoning 过长容易陷入循环的问题，代价是逻辑能力受损，推理有瑕疵。

另一条分界线则是 DeepSeek V4 Flash。相比于它的参数量，它的能力相当之强，并且 K-V Cache 特别特别紧凑。Redis 的作者 antirez 专门为它用 Cpp 写了推理框架（现在已经扩展到了 DSv4 Pro 和 GLM 5.2）。antirez 专门为它制作的动态 2bit 量化版是单机可以部署的智力上限。在 2026年7月，Apple 下架了 256GB 和 512GB 统一内存版本的所有机型，所以包括 NVIDIA DGX Spark 在内，单机 128GB 统一内存就是天花板了。比这个模型更庞大的那些，没有单机部署的可能性，比动态 2bit 更激进的量化无疑会严重损伤模型的一致性、智力和逻辑能力。世界知识倒是可能保留较全，比如 1bit 量化版的 Hy3。

两条分界线中间，就是消费级硬件可以部署的全部模型了（当然包括它们的各种社区微调版）。

有意思的是 Gemma-4 和 Qwen3.5/3.6 几乎在打擂台：

	Gemma-4	Qwen3.5/3.6
Flagship （旗舰）	Gemma-4-31b-it	Qwen3.6-27B
Fast MoE （速度）	Gemma-4-26B-A4B	Qwen3.6-35B-A3B
Budget Choice （小钢炮）	Gemma-4-12B-IT	Qwen3.5-9B

几乎可以说，你舒服使用的，一定在这6个模型之中（包括社区微调版，比如 Ornith-1.0 系列）。

还有因为年龄大往往被无视，但实际上依然很强的 GPT-OSS 系列，特别是 GPT-OSS-20B。OpenAI 去年发布它的时候，所有的权重都已经是 MXFP4 量化过的了，少量 bf16 如果量化到 8 bit，那么即便是 16GB 统一内存的入门版MacBook Pro，也能在 32K 上下文舒服跑起来。别忘了，它也是一个 MoE，天生拥有跑得快的便利。而它的逻辑能力更是非比寻常，合适的 prompt 能让它有相当犀利的表现，比如可以在 System Prompt 里面提示它注意物理世界的限制和因果关系。