本地大模型部署与量化技术现状：GGUF、AWQ、MLX 等格式与工具链 —— 横纵综合报告 未开始

题记与说明

综合说明：本报告由同日完成的两份章节研究综合而成——纵轴篇《发展脉络》与横轴篇《格式与工具链横向对比》（检索日期均为 2026-10-28，输入文件：parts/2026-10-28-本地大模型部署与量化-GGUF-AWQ-MLX-vertical.md 与 parts/2026-10-28-本地大模型部署与量化-GGUF-AWQ-MLX格式与工具链-horizontal.md）。评判准绳统一为：Windows 单机 + NVIDIA RTX 显卡可落地。综合时已消除两篇之间的表述出入（校勘记见文末附录），保留全部来源链接；文中 ※ 标注的日期来自模型既有知识、未逐一核验，2026 年近事多依赖聚合类站点（二手信息），均已就地标注。综合过程中另外执行了两次定向核验搜索（--n-cpu-moe 参数与 AutoAWQ 归档时间），结论已并入正文。本文件为 2026-10-28 按独立审读意见逐条修订后的 -final 版（共八条意见：校勘记一致性、档位表算术、来源链接补全、论断口径收窄、格式/运行时层次纠正、术语注释、2.4 表发版数据），补充核验记录见文末「核验边界」最后一条。

TL;DR

截至 2026-10，格局收敛为「一主两辅」：GGUF 在 Windows 单机一统（质量与易用双第一）；GPTQ/AWQ 退守 vLLM 服务端并双双换维护者；EXL2/3 小众；NVFP4 属 Blackwell 未来；MLX 与 Windows 无缘。工具链：llama.cpp 是一切前置，vLLM 内 GPTQ/AWQ 的 kernel 成熟度可致 10.9 倍吞吐差（Spheron 同基准未测 GGUF 吞吐，此结论不外推为跨格式吞吐排序）。纵向：格式权力从个人量化者移向基础设施，量化下沉为模型设计与硬件数据类型，MoE 专家卸载改写显存决定论。建议：默认 GGUF、Q4_K_M 起步配 imatrix；GUI 用 LM Studio、服务用 Ollama、调优用 llama.cpp。

一、纵轴：发展脉络（2015–2026.10）

阶段〇：前史（2015–2022）——模型压缩的学术积累

本地部署与量化的技术母体是 2010 年代中期的神经网络压缩研究。2015 年 Han 等人的 Deep Compression（剪枝 + 量化 + 编码）确立了训练后量化（PTQ）路线※；2022 年 8 月 Dettmers 的 LLM.int8() 用 bitsandbytes 让 8 位推理首次在大模型上可用※。真正的转折点是 2022 年 10 月 31 日：Elias Frantar、Saleh Ashkboos、Torsten Hoefler、Dan Alistarh 发表 GPTQ（arXiv:2210.17323，后中稿 ICLR 2023，Hugging Face 论文页），基于近似二阶信息实现 3–4 位单次量化，"百亿参数模型压到单卡"第一次成为工程现实。GPTQ 很快被社区移植为 GPTQ-for-LLaMA，成为后续 AWQ 等工作的对照基线。

驱动因素：Transformer 参数量爆炸与消费级显存（8–24 GB）之间的鸿沟；学术圈 OBS/OBQ 类二阶量化方法的成熟。

阶段一：诞生（2023.2–2023.8）——"一台 MacBook 跑 LLaMA"

2023 年 2 月 Meta 发布 LLaMA（权重申请制发放），3 月 3 日权重经 4chan 种子泄漏。 保加利亚开发者 Georgi Gerganov 随即在 2023 年 3 月写出 llama.cpp——纯 C/C++、零依赖的 LLaMA 推理实现，用 4 位量化权重在 MacBook CPU 上跑通。这是"本地大模型"作为一门大众技术的诞生日（Wikipedia、HN 与 r/LocalLLaMA 均确认此叙事）。

同一窗口内，生态的第一批构件迅速出现：

• 2023 年 4 月，Nomic AI 发布 GPT4All，第一批纯 CPU、跨平台（含 Windows）的本地模型桌面应用，用户无需 GPU 即可跑量化模型（GPT4All Windows 讨论、gpt4all-chat issue（2023-04-14））。
• 2023 年 6 月 1 日，MIT 韩松组（Ji Lin 等）发表 AWQ（arXiv:2306.00978）：观察到约 1% 的"显著权重通道"由激活分布决定，用数学等价的逐通道缩放保护它们即可低成本 4 位量化；后在 MLSys 2024 拿下最佳论文。AWQ 走"weight-only + 专用 GPU kernel"路线，与 GPTQ 共同构成 GGUF 之外的另一大格式家族。
• 2023 年 6 月，UC Berkeley Sky Lab 发布 vLLM 与 PagedAttention（虚拟内存式 KV cache 分页管理，论文导读），此后成为服务端推理的事实标准后端。
• 2023 年 7 月，前 Docker 员工 Jeffrey Morgan（CEO）与 Michael Chiang 创办 Ollama——"LLM 界的 Docker"，封装 llama.cpp、提供 Modelfile 与模型仓库，把本地部署门槛降到一条命令（Picovoice 博客、Jeffrey Morgan LinkedIn）。
• TheBloke（Tom Jobbins） 在 Hugging Face 上以一人之力为几乎每个开源模型产出 GGUF/GPTQ/AWQ 全套量化（HF 主页），成为 2023 年事实上的"量化分发中枢"。

驱动因素：LLaMA 权重泄漏打破发布管制；ChatGPT 引爆需求；苹果 M 系列/游戏本证明消费硬件具备推理算力；Llama 2（2023 年 7 月，商用许可）※ 让"本地跑大模型"从极客玩具变成正当需求。

阶段二：格式定型（2023.8–2024 年中）——GGUF 一统桌面，多格式分家

这是本课题三种"格式"集体定型的窗口期：

1. GGUF 取代 GGML。 2023 年 8 月，llama.cpp 引入新容器格式 GGUF（GGML Universal File），以自描述单文件（内嵌架构、超参、分词器、聊天模板等元数据）取代旧 GGML 依赖外部 config 的做法（Vasu Grover 笔记、ggml#797 格式讨论）。同期引入 K-quants（Q2_K…Q6_K 超级块量化，2023 年年中），把"位宽-质量"曲线整体推高（K-quants/I-quants 演进）。
2. GPU 服务向格式。 2023 年 9 月 turboderp 发布 ExLlamaV2（r/LocalLLaMA 原帖、仓库），2024 年初在其上引入 EXL2 可变位宽格式（2–8 bit 混合），主打 RTX 单卡高速度短上下文；AutoGPTQ/AutoAWQ 让 GPTQ/AWQ 模型直接喂给 vLLM。服务端（vLLM）与桌面端（llama.cpp）从此形成两套并行格式生态。
3. Apple 阵营的 MLX。 2023 年 12 月，Apple 开源 MLX 数组框架（ml-explore/mlx、Apple 开源项目页），专为 Apple 芯片统一内存设计，随后 mlx-lm 使其成为 Mac 本地 LLM 的第三种格式。注意：MLX 至今没有面向 Windows 的官方支持路线（详见横轴），对 Windows 单机它只是参照系。
4. Windows 桌面化两个关键节点。 2024 年 2 月 15 日 Ollama 登陆 Windows（预览版）（官方博客），补齐三大平台；2024 年 6 月初 llama.cpp 合入 Vulkan 后端（作者 0cc4m）（r/LocalLLaMA 公告帖），让 AMD/Intel/NVIDIA 显卡在 Windows 上用标准驱动即可 GPU 加速——ROCm 在 Windows 上长期缺席，Vulkan 因此成为 AMD 卡用户的默认选择。
5. 社区换血。 2024 年 1 月底前后 TheBloke 停更（社区确认帖，2024-03），bartowski、mradermacher、Unsloth 等接棒。同期 llama.cpp 引入 imatrix（重要性矩阵校准，PR #4861 起）（imatrix 说明、社区讨论）：用少量校准文本统计激活，量化时对高频激活权重加权，低比特（IQ2/IQ3）质量显著改善——此后"是否带 imatrix"成为 GGUF 社区量化的事实标准。

驱动因素：单文件分发需求（旧 GGML 双文件极易出错）；Mistral 7B（2023-09）、Mixtral 8x7B（2023-12）※ 等宽松许可小模型连发，社区需要"当天出全套量化"的流水线；Meta Llama 2/3（2023-07/2024-04）※ 确立开源权重节奏。

阶段三：生态爆发与机构化（2024 年中–2025 年中）

1. vLLM 机构化与量化工具链收编。 vLLM 2024 年 7 月贡献给 Linux 基金会、2024 年 10 月 28 日进入 LF AI & Data 孵化、2025 年 5 月成为 PyTorch Foundation 托管项目，2025 年底被 Berkeley Sky 评为 2025 年 GitHub 第一开源项目（周安装量超百万；V1 路线图 issue #9006）。伴随而来的是量化器的换代：AutoAWQ 仓库于 2025 年 5 月 11 日归档为只读并宣布"officially deprecated"（仓库、归档说明 issue #629），AWQ 后续开发移入 vLLM 项目的 llm-compressor（仓库、issue #2181）；GPTQ 侧 AutoGPTQ 亦停更，社区转向 GPTQModel。个人维护者时代的量化器开始被基金会托管的基础设施取代。
2. DeepSeek-R1 时刻与"动态量化"。 2024-12 DeepSeek-V3、2025-01-20 DeepSeek-R1（671B MoE）※ 发布后，Unsloth 当天跟进 GGUF 与"动态 4-bit"量化（敏感层保精度、其余激进低比特），其中 UD-IQ1_S/M（UD = Unsloth Dynamic，Unsloth 动态混合位宽量化版本的命名前缀，下文 UD-Q3_K_XL 同理）约 1.78-bit、约 131 GB，让 R1 首次"有希望"进 192 GB 内存的工作站（HN 讨论 2025-01-11、unsloth/DeepSeek-R1-GGUF discussion #6）。这确立了新范式：大 MoE 模型发布 → 社区数小时内出全套动态 GGUF → 桌面端当天可跑。
3. RTX 50 系与 MoE 本地化。 2025 年初 RTX 5090（32 GB GDDR7，约 1.79 TB/s）上市（RunPod 指南），被多家评测视为本地推理最佳消费卡；2025 年 7 月智谱 GLM-4.5（355B-A32B）/GLM-4.5-Air（106B-A12B） ※ 发布（MoE 尺寸记法："-A32B/-A12B"＝总参数 355B/106B、每 token 激活约 32B/12B，下文 30B-A3B 同理），llama.cpp 支持后社区确认：单张 24 GB 卡 + 量化 + 专家张量卸载 CPU 即可跑 Air 版（约 10–20 tok/s，社区实测口径）。工具上 llama.cpp 原生化 --n-cpu-moe（别名 -ncmoe）/ --cpu-moe（别名 -cmoe）/ --override-tensor "exps=CPU"：注意力与 KV 留显存、专家 FFN 留内存；性能向 fork ik_llama.cpp（IQ_K 系列量化、更快 CPU 推理）在此期壮大（Discussion #599、KTransformers 专家布局文档）。2025-08 llama.cpp 还出现"自动计算每层最优量化混合"的讨论（discussion #15576），量化从"全家桶位宽"走向"逐张量混合精度"。

驱动因素：大厂开源权重竞赛（Llama 3.1 405B、Qwen2/2.5、DeepSeek-V3/R1）；MoE 架构把"能跑"的条件从"显存 ≥ 参数量"改写为"显存 + 内存混合"；基金会/公司接管个人维护者留下的基建。

阶段四：当下（2025 年中–2026.10）——硬件原生量化与 GGUF 的全面胜利

1. MXFP4/NVFP4：量化内嵌进模型与硬件。 2025 年 8 月 5 日 OpenAI 开源 gpt-oss-120b/20b（GPT-2 之后首个开放权重模型），专家权重原生 MXFP4：120b 可装进单张 80 GB 卡，20b 权重约 12 GB、官方口径 16 GB 内存可跑（架构解析）；llama.cpp 兼容 PR 当天合并（r/LocalLLaMA），Ollama/LM Studio 随即跟进。另一侧，NVIDIA 在 Blackwell 上力推 NVFP4（4-bit 浮点，E2M1+块缩放），2025 年发表 NVFP4 预训练论文（12B 模型接近 FP8 精度，报道、部署教程），vLLM/TensorRT-LLM 已支持推理，llm-compressor 2026 Q1 路线图亦含 NVFP4 改进——量化格式正从"社区文件格式"走向"张量核心原生数据类型"。
2. GGUF 侧技术收敛。 2026 年 2 月 20 日前后，ik_llama.cpp 中打磨的 IQK 系列（IQ*_K/IQ*_KS）合入 llama.cpp 主线（Jangwook Kim 博客），低比特质量再上台阶；2026 年 9 月 22 日 Hugging Face Transformers 宣布可直接 from_pretrained 加载运行 GGUF 量化模型（报道）——GGUF 从"llama.cpp 专属格式"升级为跨框架通用格式。路线之争的余波：vLLM v0.20 集成了 TurboQuant，而 llama.cpp 主线 2026 年 6 月拒绝将其上游化（聚合源报道，可信度中等），说明两条生态仍按各自节奏演化。同期 llama.cpp 讨论区还在推进自适应混合精度（discussion #18531）与逐层量化模拟选型。
3. Ollama 与 2026 模型潮。 Ollama 2025-07 的 0.10 加入 ollama ps 等改进，2026 年中 0.30.0 引入新引擎：现代 Qwen/Gemma 模型默认开 FlashAttention、统一模型管理、可指向外部 llama.cpp 目录、支持 MXFP4（聚合源，可信度中等：Insider LLM 指南、DataHunter 版本汇总）；至 2026 年 10 月已迭代到 v0.40.12（Ollama Releases）。模型侧，2026 年 3 月 Qwen3.5 发布、4 月 GLM-5.1、年初 DeepSeek V4（及 V4-Flash）落地、8 月 Qwen3.8-27B 开放权重主打端侧多模态（均为聚合源报道：whatllm.org、fazm.ai、AINews）；本地可跑主力家族被概括为 Qwen、DeepSeek、gpt-oss、Gemma、GLM、Mistral（DevelopersIO 2026 本地 LLM 指南）。显卡侧，基础版 RTX 5080 为 16 GB 显存（已上市，即 3.2 档位表中的「5080」，社区俗称 5080-16G），其 Super 版 24 GB（约 1 TB/s）2026 年 7 月被曝光（TechPowerUp 论坛），原计划 2026 Q1–Q2 窗口（Overclock3D），截至今日未确认正式发售，只能作为观望项。

纵轴小结：四条演化逻辑

1. 格式权力从"个人量化者"转移到"基础设施项目"。 TheBloke（2023–2024.1）→ bartowski/mradermacher/Unsloth → vLLM 基金会托管 llm-compressor、AutoAWQ 弃用——分发与制作都在机构化，但 GGUF 桌面生态仍由 llama.cpp + 社区量化者主导。
2. 量化从"离线压缩"变为"模型设计的一部分"。 gpt-oss 原生 MXFP4、NVIDIA NVFP4 预训练说明：与其训完再压，不如天生低比特。本地部署因此受益——同等显存能跑的模型能力上限持续上移。
3. MoE 是 Windows 单机的最大红利。 激活参数小、总参数大，配合 --n-cpu-moe 让"24 GB 单卡 + 128 GB 内存跑百亿-千亿级模型"成为 2025 年后的标准玩法；这改变了 2023 年"显存决定一切"的配置逻辑。
4. Windows 视角的格局：GGUF（llama.cpp 系）是 Windows 上的绝对主流；AWQ/GPTQ 依附 vLLM/ExLlamaV2 生态，Windows 上多走 WSL2 或 text-generation-webui；MLX 是 Mac 专属，只作为跨平台参照。

二、横轴：横向对比（2026-10-28 截面）

2.1 课题界定：三个咬合的层次

"本地大模型部署与量化"在当下时间截面上是三个相互咬合的层次，横轴对比必须同时展开，否则会犯"拿格式比工具"的错位：

1. 量化格式/模型文件层：GGUF、GPTQ、AWQ、EXL2/EXL3、bitsandbytes、FP8/NVFP4、MLX 原生量化——决定"模型以什么形态存盘、以什么精度参与计算"；
2. 推理引擎/运行时层：llama.cpp、Ollama、vLLM、ExLlamaV3/tabbyAPI、KTransformers/ik_llama.cpp、mlx-lm——决定"谁来调度权重、KV cache 和 kernel"；
3. 分发与前端层：Ollama、LM Studio、Jan、GPT4All 等 GUI/服务化封装——决定"普通用户怎么用上"。

2.2 本报告最重要的横向发现：kernel 成熟度 > 量化算法

2026 年的基准数据表明，在 vLLM 内部，推理 kernel 的成熟度对吞吐的影响远大于量化算法之间的差异——先交代口径：Spheron 2026 年 9 月的对比测试只提供了 GPTQ/AWQ 的 vLLM 吞吐与三种格式的质量分，没有给任何 GGUF 的 tok/s（原文明确说明 GGUF 只测了质量，并警告不要拿 llama.cpp 的数字与 Marlin 数字混比——那是引擎之别而非格式之别），因此本报告不对 GGUF 与 GPTQ/AWQ 做跨运行时的吞吐排序，本条结论只在 vLLM 系内部成立。该测试中：AWQ 在 H200 上默认 kernel 路径仅 68 tok/s，切到 Marlin kernel（vLLM 内针对 4bit 权重的融合反量化 GPU kernel，AWQ/GPTQ 均有对应实现）后达 741 tok/s（10.9 倍）；而 RTX 5090 上 GPTQ 反而比 AWQ 快 6–19%（74.7 vs 65.9 tok/s，见 2.3 GPTQ 要点），原因是 gptq_marlin kernel 在该版本 vLLM 中更成熟——GPTQ/AWQ 在 vLLM 内的排序随 kernel 成熟度翻转。同一基准的质量数据（4bit 档）：GGUF Q4_K_M 的 WikiText-2 困惑度（ppl，语言建模困惑度，越低越好）6.74、HumanEval（Python 代码生成 pass@1 通过率，越高越好）51.8%，为所有 4bit 方案最优；AWQ 6.84 / 51.8% 与之接近；GPTQ 6.90–6.97 / 45.7–46.3%，代码能力损失最明显。因此本报告把"工具链"作为与"格式"并列的一等公民来比。

2.3 量化格式层对比

逐项要点：

• GGUF —— 消费级 Windows 单机的默认解。 GGUF 是 GGML 的继任者，文件内嵌完整元数据与分片支持；「GGUF + llama.cpp」组合是唯一做到"CPU、GPU、混合、Vulkan、SYCL、OpenVINO、ROCm 全后端通吃"的格式/运行时组合——需要说明，Vulkan/SYCL/OpenVINO/ROCm 这些后端属于 llama.cpp 运行时而非 GGUF 格式自身的属性，通吃是二者叠加的结果。关键证据：llama.cpp 当前版本 b11936（2026-10-27 发布）为 Windows x64 提供 CUDA 12、CUDA 13、Vulkan、SYCL、OpenVINO、ROCm 10.0、CPU 七类官方预编译包（llama.cpp Releases）——没有任何其他格式/运行时组合在 Windows 上有这种开箱即用程度。生态端，Unsloth Dynamic 2.0 用 KL 散度校准的 imatrix 动态混合位宽，把"低 bit 不掉点"进一步推进（daily.dev），bartowski、Unsloth 的 HF 仓库覆盖几乎所有热门模型。
• GPTQ —— GPU 量化老将，维护者已换代。 原理是近似二阶误差补偿逐层量化（Grootendorst 综述）。原维护库 AutoGPTQ 已停止向前开发：官方维护者于 2024-12-19 发布 Discussion #758「AutoGPTQ has stopped developement. Switch to GPTQModel」，声明 "effectively stopped forward development" 并指引切换到 GPTQModel（ModelCloud/GPTQModel，本报告核验时仍活跃），仓库随后于 2025-04-11 归档为只读；vLLM 侧经 gptq_marlin kernel 获得目前消费卡上最快的 4bit 路径之一（RTX 5090 上 74.7 tok/s，快于 AWQ 的 65.9，Spheron 基准）。适用场景：WSL2 + vLLM 的高吞吐服务；纯 GUI 用户无感。
• AWQ —— 激活感知量化，老库已死、新链上位。 原理是统计激活分布、只保护对输出影响大的显著权重。casper-hansen/AutoAWQ 于 2025 年 5 月 11 日归档为只读（issue #629 归档说明），社区指定 vLLM 项目的 llm-compressor 为继任者（issue #2096），但其主要输出 compressed-tensors 格式而非传统 awq checkpoint——"AWQ"正在从一种文件格式退化为一种可被 llm-compressor 表达的量化方法，这是 2026 年生态最值得记录的变化之一。
• EXL2/EXL3 —— 显存极限玩家的小众利器。 EXL3 采用 Trellis 张量编码，支持逐层任意混合位宽乃至亚 2bit。但生态封闭：截至 2026 年中，vLLM 与 SGLang 均不原生支持 EXL3，主要服务栈是 ExLlamaV3/tabbyAPI，另有社区 fork vllm-exl3（EXL3 分析文章，2026-07）。适用场景：24GB 内跑 70B 级 dense 模型的极限需求；Windows 有社区编译包，但踩坑概率高于 GGUF 系。
• FP8/NVFP4 —— Blackwell 专属新赛道，消费卡上尚早。 NVFP4 是 NVIDIA Blackwell 原生 4bit 浮点格式，旧架构卡不可用（Hivenet 解读）。Unsloth 已发布 Dynamic NVFP4 跑法指南（unsloth.ai/docs），NVIDIA 也在 HF 发布官方 NVFP4 权重。但消费级 SM120 上 vLLM 支持仍有明确 bug 报告（vLLM Issue #47749），社区实测中 AWQ 系方案质量有时反超（r/LocalLLaMA 讨论）。结论：5090 用户现阶段仍应以 GGUF/AWQ 为主，NVFP4 作为尝鲜。
• MLX —— Apple 生态冠军，Windows 场景的"对照品"。 MLX 已有官方 CUDA 后端（pip install mlx[cuda]，需 NVIDIA 驱动 ≥ 580），但仅限 Linux；Windows 支持尚在推进中，多数改动已就位、社区可从 PR 构建 Python 扩展，但非官方支持平台（MLX 安装文档、Issue #1513、Discussion #2422）。LM Studio 虽长期内置 MLX 引擎（v0.3.4 起），但只在 Apple Silicon 上启用（LM Studio Changelog）。对 Windows 单机用户，MLX 当下不构成可落地选项；其价值在于跨平台团队（Mac 开发 + NVIDIA 部署）的统一框架，以及 Apple 侧"GGUF + MLX 双引擎"格局（Ollama v0.40.12 release notes 提及 MLX 引擎上的 speculative decoding，Ollama Releases）——而 Windows 侧两者都只走 GGUF。
• bitsandbytes —— transformers 内 load_in_4bit 即时量化，零预处理但质量与速度均弱于专门方案，研究场景为主。

2.4 推理引擎与前端层对比

引擎层三个要点：① Ollama 与 LM Studio 在 Windows 上"都是 llama.cpp 套壳"，引擎之争已收敛，选型差异在交互形态（CLI 服务 vs GUI）而非内核性能；② vLLM 的 Windows 路径始终是 WSL2——多卡 --tensor-parallel-size 2 在 WSL2/容器下有已知失败案例（vLLM Issue #5161），单卡可用、生产多卡建议裸 Linux；③ llama.cpp 主线已吸收 --cpu-moe/--n-cpu-moe（MoE 专家卸载），但历史上出现过与 GPU offload 组合时的 KV cache 损坏（Issue #20140）与 CUDA 专家卸载数据损坏（Issue #16945，2025-11，已修）等 bug 报告，大 MoE 用户应保持新版，或倾向 ik_llama.cpp/KTransformers。

三、交叉洞察：两轴结合说明了什么

3.1 六条双轴结论

1）横轴的格局是纵轴"诞生语境"的沉淀——GGUF 赢在出生点，不是赢在算法。 GGUF 之所以在横轴总表上"质量、开箱即用、生态"三栏全绿，回纵轴看原因清晰：它从 2023 年诞生起就面向"本地 + 混合 + 消费硬件"，单文件自描述解决了分发可靠性，K-quants/IQ/imatrix 三次迭代叠加社区"当天出全套量化"的流水线（TheBloke → bartowski/Unsloth 的接力），三年积累的预编译分发矩阵（七类 Windows 官方包）没有任何后来者能在短期内复制。反过来，AWQ/GPTQ 出生于"GPU 集群服务端"语境，天生依赖专用 kernel 与 Linux 服务栈——它们在横轴上"退守 vLLM 阵地"不是失败，而是归位：横轴的排名，其实早已被纵轴的出生点写定。

2）量化重心的三次迁移，且层层叠加而非替代。 纵轴显示量化技术的主战场经历了三次迁移：文件格式层（GGUF 容器与 K-quants，2023）→ 校准方法层（imatrix、动态混合位宽、Unsloth Dynamic 2.0 的 KL 散度校准，2024–2025）→ 硬件数据类型层（gpt-oss 原生 MXFP4、NVIDIA NVFP4 预训练，2025–2026）。横轴总表正是这个叠加过程的截面呈现：表中"GGUF IQ 系列"与"NVFP4"并排而立，前者是第一、二次迁移的成熟果实，后者是第三次迁移的早期形态。对用户的含义：新格式不会让你现有的 GGUF 资产作废——NVFP4 只惠及 Blackwell 及以后，而 GGUF 的位宽-质量曲线还在被 imatrix/自适应混合持续推高。

3）"kernel 成熟度 > 量化算法"有纵轴解释：算法冻结了，工程还在跑。 横轴最重要的发现（AWQ 在 H200 上 68 → 741 tok/s 的 10.9 倍差距、RTX 5090 上 GPTQ/AWQ 排序翻转）放到纵轴上立刻可解释：AutoAWQ 于 2025 年 5 月归档、AutoGPTQ 同期停更之后，这两种格式的算法已经冻结，而围绕它们的 kernel 工程仍由 vLLM 等基础设施项目按自己的优先级推进——谁被投入维护，谁就在基准里靠前。这印证了横轴篇的方法论警告：比较量化格式必须绑定运行时与 kernel，否则"轴选错层级会得出完全相反的结论"。

4）机构化是双轴交汇处的风险信号：把"最近一次 release 日期"当硬指标。 纵轴记录了完整的机构化链条（vLLM → Linux 基金会 → PyTorch Foundation；AutoAWQ/AutoGPTQ → llm-compressor/GPTQModel），横轴则给出了它的消费者版本：AutoAWQ 归档、AutoGPTQ 停更、GPT4All 停滞——在这三个个案中，维护停摆都明显领先于产品影响力的消退。但必须说明：这是由三个个案归纳的经验观察，本报告并未逐一考证各产品的"实际衰亡时点"（GPT4All 仓库至今未被归档，只是自 2025-02-25 的 v3.10.0 后再无正式版本、社区持续追问其死活，Issue #3690），因此不将其上升为"开源本地 LLM 工具半衰期约两年"的普适定律。GPT4All 的弧线仍最有说服力——2023 年 4 月它是"第一批 Windows 纯 CPU 桌面应用"（纵轴阶段一），2026 年 10 月社区仍在公开追问它是否已死（横轴前端表，含 2026-10 的 "GPT4All is no longer maintained" Issue #3708）。据此经验，选型时应把"仓库最近一次 release / 归档状态"作为一票否决项。

5）MoE + 专家卸载是双轴交汇的最大红利，配置逻辑已从"显存决定一切"变为"显存 + 内存带宽联合定价"。 纵轴：DeepSeek-R1 的动态 GGUF（1.78-bit / 131 GB）、GLM-4.5-Air 单 24 GB 卡实测、llama.cpp 原生化 --n-cpu-moe；横轴：24 GB 显存 + 64–128 GB 内存的档位表、ik_llama.cpp/KTransformers 的专家布局调优。两轴合起来的判断：2023 年"多大显存跑多大模型"的算术已失效，内存容量与带宽成了第二变量——这也是"内存 ≥ 64 GB DDR5"从可选项变成建议标配的原因。

6）MLX 的双轴定位揭示："GGUF 的全面胜利"准确说是"Windows 的胜利"。 纵轴上 MLX 是 Apple 2023 年 12 月对统一内存生态的押注；横轴上它在 Windows 不可落地（官方 CUDA 后端仅 Linux，Windows 支持推进中但非官方），但 Ollama 与 LM Studio 在 Apple Silicon 上同时维持"GGUF + MLX"双引擎。也就是说，格式竞争并未终结，只是战场在 Mac——跨平台团队可以 Mac 用 MLX、Windows 部署用 GGUF/vLLM，但不存在一条"MLX 模型直接上 RTX"的官方路径。同时 MLX 提供了方法论上最有价值的一课：判断"可落地"要看官方预编译分发矩阵，而不是技术能力——MLX 有 CUDA 后端，却因不分发 Windows 包而对 Windows 用户等于不存在。

3.2 对用户的判断与建议（Windows + RTX 单机，2026-10）

三条通用原则（横轴）：① 默认 GGUF，例外才换——只有"vLLM 批处理吞吐"和"EXL3 极限塞大模型"两个场景值得离开 GGUF 生态；② GUI 用 LM Studio、服务用 Ollama、调优用裸 llama.cpp，三者共用同一批 GGUF 文件，迁移成本为零；③ 量化的"位宽选择"比"格式选择"更影响单机体验——8GB 卡纠结 Q4/Q3 的收益远大于纠结 GGUF vs AWQ。

软件栈选择（按上手难度递增）：LM Studio（GUI，Windows 用 llama.cpp/CUDA 引擎；Simon Willison 笔记、2026 横向指南）；Ollama（0.30 新引擎，命令行/服务化，默认 FlashAttention）；llama.cpp 官方 Windows CUDA 构建 + llama-server（最新功能最快到位，n-cpu-moe 等参数最全）；KoboldCpp（单文件 exe）。AWQ/GPTQ 模型在 Windows 上建议 text-generation-webui（EXL2/EXL3 模型走 ExLlamaV2/V3 运行时）或 WSL2 内跑 vLLM/llm-compressor——服务端引擎原生支持仍以 Linux 为主。

分层配置建议（综合两章节档位表；KV cache 预留 1–2 GB，故可用权重比显存标称略小；CUDA 13 构建需驱动 ≥ 580——CUDA 13.0 对应 R580 驱动分支、官方最低要求即 ≥ 580，见 CUDA Toolkit Release Notes——部分 Win11 环境有 GPU 未启用报告，遇问题先回退 CUDA 12 包，见 r/LocalLLaMA）：

显存外的通用建议：内存 ≥ 64 GB DDR5（MoE 专家卸载的速度取决于内存带宽）；长上下文开 KV cache 量化（Q8_0）+ FlashAttention；AMD/Intel 卡或混合 GPU 用 Vulkan 后端，但注意 Vulkan iGPU 上 -ncmoe 可能比纯 CPU 慢（llama.cpp issue #26876，搜索摘要）。

观望清单：NVFP4（SM120 bug、质量争议，Blackwell 用户可尝鲜但不宜作为主力）；RTX 5080 Super 24 GB（已曝光、未确认发售）；TurboQuant 路线之争（vLLM 已收、llama.cpp 已拒，聚合源信息，等下一代基准再判断）。

一句话结论：2026 年 10 月，Windows + RTX 单机的最优解是"GGUF + llama.cpp 系运行时"：位宽按显存选、Q4_K_M 起步、配 imatrix 的 K/IQ 系为主，MoE 模型用 --n-cpu-moe 撑大参数量；AWQ/GPTQ 留给 WSL2 + vLLM 服务场景（选型先看 kernel 与维护状态）；MLX 与 Windows 无缘，NVFP4 等硬件原生量化是 Blackwell 之后的下一章。

3.3 这次学到什么

1. 比较量化格式必须绑定运行时与 kernel：AWQ/GPTQ 的性能排序在 H200 与 RTX 5090 上相反，决定因素是 Marlin kernel 的成熟度而非算法本身；而 kernel 的兴衰又由纵轴上的维护者更替决定——横轴看到的"排名"，要回纵轴找"谁在养它"。
2. 判断"可落地"看官方预编译分发矩阵，不看技术能力：llama.cpp 七类 Windows 官方包 vs MLX CUDA 后端仅 Linux，技术上有后端 ≠ 用户能用上。
3. 开源维护者更替是生态风险的先行指标：AutoAWQ 归档、AutoGPTQ 停更、GPT4All 停滞三个个案中，维护停摆都领先于产品影响力的消退（个案归纳的经验观察，非"半衰期两年"式普适定律），选型把"最近一次 release 日期"当硬指标。
4. 横纵交叉的方法论：横轴排名问"为什么是它"，去纵轴找出生语境与维护归属；纵轴转折点问"现在格局如何"，回横轴做截面验证——单轴结论（"GGUF 最好"）经交叉后才成为有因果链的判断（"GGUF 因出生点与机构归属而最好，且这一优势随分发矩阵自我强化"）。

四、参考来源

论文与技术原理

• GPTQ：arXiv:2210.17323、Hugging Face 论文页
• AWQ：arXiv:2306.00978
• PagedAttention：论文导读（Micah Lerner）
• 量化方法综述：Maarten Grootendorst
• NVFP4：BDTechTalks 预训练论文报道、Macnica 部署教程、Hivenet 解读

官方仓库、发布与文档

• llama.cpp：Releases（b11936）、discussion #15576（自动量化混合）、discussion #18531（自适应混合精度）、Issue #20140（KV cache）、Issue #16945（专家卸载数据损坏，本会话核验补充）
• ggml：#797（GGUF 元数据讨论）
• ik_llama.cpp：Show-and-tell（K-quants/I-quants）、imatrix README、Discussion #599
• ExLlamaV2：turboderp-org/exllamav2
• GPTQModel：ModelCloud/GPTQModel、ExLlamaV3：Releases（v1.6.5）、KTransformers：Releases（v0.7.2）、KoboldCpp：Releases（v1.123.1）、text-generation-webui：Releases（v4.9）、Jan：Releases（v0.8.7）（以上版本号均为 2026-10-28 GitHub Releases API 核验）
• NVIDIA：CUDA Toolkit Release Notes（CUDA 13.0 → R580 驱动分支，13.x 最低驱动 ≥ 580；本修订版核验补充）
• MLX：ml-explore/mlx、Apple 项目页、安装文档、Issue #1513（Windows 支持）、Discussion #2422（CUDA）
• Ollama：Windows 预览（2024-02-15）、Releases（v0.40.12）
• LM Studio：Changelog（0.4.26）
• vLLM：LF AI & Data 孵化（2024-10-28）、PyTorch Foundation（2025-05）、Berkeley Sky 年度项目、Issue #9006（V1 路线图）、Issue #5161（WSL2 多卡）、Issue #47749（SM120 NVFP4）、docs.vllm.ai
• 量化工具链：AutoAWQ（归档）、AutoAWQ Issue #629、AutoGPTQ（已归档）、AutoGPTQ Discussion #758（2024-12-19 停止开发公告，本修订版核验补充）、GPTQModel、llm-compressor、llm-compressor Issue #2181、Issue #2096
• KTransformers：专家布局文档
• Unsloth：DeepSeek-R1-GGUF discussion #6、NVFP4 指南、Dynamic 2.0（daily.dev）、TheBloke HF 主页

基准与硬件

• Spheron：GPTQ vs AWQ vs GGUF（2026-09）
• RunPod：RTX 5090 指南、Bizon：最佳 GPU 指南
• TechPowerUp：RTX 5080 Super 24 GB 曝光、Overclock3D：50 Super 发售窗口

社区事件与生态（Reddit/HN/博客）

• Georgi Gerganov / llama.cpp 叙事佐证（LinkedIn）、GPT4All on Windows（r/ChatGPT）、gpt4all-chat issue #30（2023-04-14）
• GPT4All 现状核验（本修订版补充）：Issue #3690「Is this development dead? No updates in two years」（2026-07-09）、Issue #3605「Is GPT4all dead?」（2025-08-05）、Issue #3708「Use Unsloth - GPT4All is no longer maintained」（2026-10-22）、Releases（最新 v3.10.0，2025-02-25）
• ExLlamaV2 发布帖（2023-09）、Vulkan 后端合入公告
• TheBloke 停更讨论（2024-03）、imatrix 源起讨论
• Unsloth R1 GGUF（HN，2025-01-11）
• gpt-oss 架构与 MXFP4（Centron）、gpt-oss 兼容 PR 当天合入（r/LocalLLaMA）
• IQK 合入主线（Jangwook Kim，2026-02-20）、Transformers 直读 GGUF（2026-09-22）
• NVFP4 质量讨论（r/LocalLLaMA）、CUDA 13 Win11 问题、RTX 5080 16GB 不够用讨论
• Ollama 起源（Picovoice）、Jeffrey Morgan LinkedIn、GGUF 量化笔记（Vasu Grover）
• EXL3 生态分析（X/Mayhem4Markets，2026-07）
• 选型参考：Simon Willison local-llms、Ajayk 2026 工具链横向指南、DevelopersIO 2026 本地 LLM 指南

2026 年近事（聚合类站点，二手信息，可信度中等）

• TurboQuant 之争（Sotaaz，2026-08）、Ollama 0.30.0 新引擎（Insider LLM）、Ollama 版本汇总（DataHunter）
• Qwen3.5 等 3 月发布潮（whatllm.org）、GLM-5.1（fazm.ai，2026-04）、Qwen3.8-27B（AINews，2026-08-14）

附：核验边界与综合校勘记

核验边界（承接两章节的声明）：

• 带 URL 的事实来自 2026-10-28 当天的搜索/网页读取（标题/摘要层核验，未逐篇打开全文）；2026 年近事（Qwen3.5/GLM-5.1/DeepSeek V4、Ollama 0.30 新引擎、TurboQuant 之争、RTX 5080 Super）主要依赖聚合类站点，属二手信息。
• ※ 标注的日期（LLaMA 官方发布、Llama 2/3、Mistral、Mixtral、DeepCompression、LLM.int8()、DeepSeek-V3/R1、GLM-4.5 等）来自模型既有知识，未在本次会话中逐一核验，仅供时间轴定位。
• 本次综合会话未运行任何本地部署/基准测试命令，性能数字均转引自上述来源；综合过程中执行了两次定向搜索核验（llama.cpp --n-cpu-moe/--cpu-moe 参数家族；AutoAWQ 归档日期 2025-05-11），结果已并入正文并新增来源（llama.cpp Issue #16945）。
• 2026-10-28 -final 修订版补充核验（当日执行）：① GPT4All"停滞/公开质疑死亡"论断补 issue 直链（#3690/#3605/#3708，GitHub Search API），最新正式 release v3.10.0（2025-02-25）、仓库未归档（Releases/Repo API）；② AutoGPTQ Discussion #758 直链核验（2024-12-19 维护者公告停止开发，仓库 2025-04-11 归档），并补 GPTQModel 仓库链接（ModelCloud/GPTQModel）；③ CUDA 13 驱动要求改引官方 Release Notes（R580 分支、13.x 最低 ≥ 580）；④ 复核 Spheron 原文，确认其未提供任何 GGUF 的 tok/s 数据且明确警告勿与 llama.cpp 数字混比，据此收窄 2.2 与 TL;DR 的 kernel 论断口径；⑤ 2.4 表各工具版本号均经 GitHub Releases API 当日核验（vLLM v0.32.0、ExLlamaV3 v1.6.5、KTransformers v0.7.2、Jan v0.8.7、KoboldCpp v1.123.1、text-generation-webui v4.9）；tabbyAPI 与 ik_llama.cpp 无正式 release，已在表内如实标注（分别注明最近提交日期）。修订未运行任何本地部署/基准测试命令。

综合校勘记（两章节间的表述出入及处理）：

1. AutoAWQ 弃用：纵轴称"仓库声明 officially deprecated"，横轴称"2025-05-11 归档为只读"。经搜索核验两者同时成立，合并为"2025 年 5 月 11 日归档为只读并宣布弃用（最后测试配置 Torch 2.6.0）"。
2. MoE 卸载参数名：纵轴写 --n-cpu-moe / --override-tensor "exps=CPU"，横轴写 --cpu-moe。经搜索核验，两者是同一参数家族：--cpu-moe（-cmoe，全部专家层卸载）与 --n-cpu-moe N（-ncmoe，前 N 层专家卸载），报告统一按此表述。
3. MLX Windows 可用性：纵轴称"至今没有可用的 Windows/RTX 路线"，横轴称"CUDA 后端仅 Linux、Windows 推进中、可从 PR 构建"。统一为："官方不支持 Windows（Linux 有 CUDA 后端；Windows 社区途径非官方支持），对普通 Windows 用户等于不可用"。
4. 显存档位表：纵轴按 8/12/16/24/32/48 GB 分档、横轴按 8/12-16/24/32/MoE 分档，档位推荐略有出入（如 12 GB 卡上 14B 的量化档）。合并为统一七档表（即 3.2 的分层配置建议表：8/12/16/24/32/48 GB 六档显存 + "24 GB 显存 + 64–128 GB 内存" MoE 组合行），以"KV cache 预留 1–2 GB"为前提，Q4_K_M 为 12–24 GB 档默认、16 GB 档上探 Q5–Q6。
5. GLM-4.5-Air 内存需求：纵轴 64–96 GB、横轴 64–128 GB，统一为"64 GB 起、128 GB 从容"。
6. GPT4All：纵轴（诞生叙事）与横轴（现状：停滞约两年）时间线统一为"2023 年入门王者 → 2026 年停滞、社区公开质疑死亡（issue 直链见 2.4 表与参考来源）"，不做删并。
7. Ollama 版本：纵轴"2026 年中 0.30.0 新引擎"与横轴"当前 v0.40.12"为先后关系，按时间线合并呈现。