Skip to main content
PromptQuorumPromptQuorum
主页/本地LLM/LLM量化详解:Q4_K_M vs Q4_0 vs Q8_0(2026)
Best Models

LLM量化详解:Q4_K_M vs Q4_0 vs Q8_0(2026)

·阅读约14分钟·Hans Kuepper 作者 · PromptQuorum创始人,多模型AI调度工具 · PromptQuorum

根据显存选择量化:6–8 GB 显存 → 使用 Q4_K_M(7B 模型约 4.5 GB,质量损失 1–3%),16 GB → Q5_K_M,24+ GB → Q8_0(损失可忽略)。量化将模型权重精度从 16 位浮点数降至 4 位或 8 位整数,将内存减少 50–75%。对于大于显存的模型,可添加 CPU 卸载或多 GPU 层分割。

LLM量化(Q4_K_M、Q5_K_M、Q8_0、GGUF)及高级VRAM减少技术的完整指南:CPU卸载和多GPU层分割。了解如何通过卸载在RTX 4090上运行Llama 3.3 70B,通过层分割使用2× RTX 4090,或在Mac Studio M2 Ultra上原生运行。本指南现已新增逐一对决比较(Q4_0 vs Q4_K_M、Q4_K_M vs Q4_K_S、Q8_0 vs Q4_K_M、Q8_0 vs Q8_K_XL)。2026年6月更新。

演示文稿: LLM量化详解:Q4_K_M vs Q4_0 vs Q8_0(2026)

下方幻灯片涵盖:Q4_K_M vs Q8_0 vs GGUF格式对比、按模型大小(3B~70B)节省的RAM、各量化级别的质量损失,以及如何为您的硬件选择量化级别。将PDF下载为LLM量化参考卡片。

浏览以下幻灯片或下载PDF以供离线参考。 下载参考卡(PDF)

关键要点

  • 量化将模型权重从32位压缩到4~8位,RAM使用量减少50~75%。
  • Q4_K_M是标准推荐级别----质量与RAM的最佳平衡,适用于消费级硬件。
  • 7B模型示例:FP16 = 约14GB RAM、Q4_K_M = 约4.5GB、Q8_0 = 约7GB。
  • Q4_K_M的MMLU基准质量损失为1~3%,与FP16相比----在大多数实际任务中难以察觉。
  • GGUF是llama.cpp、Ollama和LM Studio用于存储量化模型的文件格式。

什么是大语言模型量化及其为何重要

大型语言模型将学习到的知识存储为数十亿个数值权重。 默认情况下,这些以16位浮点数(FP16)的形式存储----每个权重两个字节。一个7B模型有70亿个权重,因此FP16文件大小约为14GB。

量化用低精度整数替换这些16位浮点数。在4位量化中,每个权重使用0.5字节而不是2字节----将内存仅对权重本身减少到约3.5GB。加上元数据开销,Q4_K_M量化的7B模型大约为4.5GB。

这对本地推理很重要,因为消费级硬件的RAM有限。不使用量化,7B模型需要16GB RAM来运行。使用Q4_K_M量化,同一模型在6GB RAM上运行,使其可在大多数现代笔记本电脑上使用。

Q4_K_M量化是什么?

Q4_K_M 是在 llama.cpp 和 Ollama 中使用的 4 位 GGUF 量化格式。"K"表示它使用 K-quants(混合精度),"M"= 中等 — 在模型大小、速度和质量损失之间取得平衡。 Q4_K_M 将大多数权重存储为 4 位,但对最敏感的层使用 6 位,与纯 4 位 Q4_0 相比,质量/大小比更优。

  • Q4_K_M 为 7B 模型使用约 4.5 GB RAM — 比 FP16 少 70% — 仅有 1–3% 的质量损失
  • K-quants 根据敏感度对不同权重组应用不同精度(重要权重获得更多位)
  • "M"变体是标准推荐版本(较轻的"S"和较重的"L"变体也存在)
  • Q4_K_M 是 6–16 GB VRAM 消费级硬件的默认选择
  • 与 Ollama(`ollama run model:q4_k_m`)、LM Studio 和 llama.cpp 兼容

Q4_K_M、Q5_K_M、Q8_0等级有何区别

量化名称遵循模式:Q{bits}_{variant}。比特数是权重精度;变体影响量化的应用方式:

级别位数RAM (7B)质量损失使用场景
Q2_K2约2.7GBRAM < 4GB,接受质量下降
Q3_K_S3约3.3GB中等RAM 4~5GB
Q4_K_M4约4.5GB低 (1~3%)大多数用户的默认选择
Q5_K_M5约5.7GB最小 (<1%)16GB RAM,需要更高质量
Q6_K6约6.6GB近乎无损16GB RAM,编码/数学任务
Q8_08约7.7GB可忽略不计16GB+RAM,最高质量
量化级别对比:从Q2_K(最高压缩)到Q8_0(最高质量)。Q4_K_M是大多数用户推荐的标准。
量化级别对比:从Q2_K(最高压缩)到Q8_0(最高质量)。Q4_K_M是大多数用户推荐的标准。

Q8_0量化是什么?

Q8_0是一种8位GGUF量化格式,几乎无损----相比FP16质量下降不足0.5%----而文件大小约为其一半。 每个权重以8位加一个小的逐块缩放因子存储,因此7B模型约为7.7 GB,而FP16下约为14 GB。与K-quants(Q4_K_M、Q5_K_M)不同,Q8_0对每个权重都使用统一的8位精度----它没有混合精度的"K"变体,因为8位已经几乎保留了全部信息。

  • Q8_0为7B模型使用约7.7 GB RAM----比FP16少约45%----质量损失可忽略不计
  • 当您拥有16 GB以上VRAM并需要最高保真度时(编码、数学、智能体),这是最佳选择
  • 相比Q6_K,在通用聊天上几乎没有可测量的提升,但在质量最重要时是最稳妥的选择
  • 使用 `ollama run model:q8_0` 运行,或在LM Studio中选择Q8_0 GGUF

Q4_0 vs Q4_K_M:哪种4位格式更好?

请选择Q4_K_M而非Q4_0。两者平均都是每权重4位,但Q4_K_M是一种K-quant,它将最敏感的层以6位存储,在7B模型相同的约4.5 GB占用下恢复了5~8%的质量。 Q4_0是早期llama.cpp的原始统一4位格式,如今仅为兼容旧版而存在。当Q4_K_M可用时,没有任何大小或速度上的理由去选择Q4_0。

FormatMethodRAM (7B)QualityPick When
Q4_0统一4位(旧版)~4.0 GB比Q4_K_M差约5~8%仅当Q4_K_M不可用时
Q4_K_MK-quant,混合4/6位~4.5 GB相比FP16损失1~3%几乎所有人的默认选择

Q4_K_M vs Q4_K_S:中等与小型K-quant

Q4_K_M和Q4_K_S都是4位K-quants;区别在于有多少层保持更高精度。Q4_K_M(中等)将更多敏感层保持在6位,而Q4_K_S(小型)将更多权重压到4位,从而在7B模型上节省约0.3~0.4 GB。 在llama.cpp上的实测中,Q4_K_S在7B上使困惑度增加约+0.11,而Q4_K_M为+0.05----大约多3~5%的质量损失。仅当那几百MB决定模型能否装入VRAM时,才选择Q4_K_S。

FormatVariantRAM (7B)Quality LossPick When
Q4_K_S小型~4.1 GB~4~6%(小但确实存在)需要约0.4 GB以装入VRAM
Q4_K_M中等~4.5 GB1~3%(均衡)默认----多约0.4 GB换更好质量

Q8_0 vs Q4_K_M:8位值得双倍VRAM吗?

对于大多数聊天和写作任务,Q4_K_M是更好的取舍----7B模型约4.5 GB,而Q8_0约7.7 GB,质量损失仅多1~3%。当您需要在编码、数学或智能体工具调用中获得最高保真度(小错误会累积)时,请选择Q8_0(需要16 GB以上VRAM)。 Q8_0相比FP16损失不足0.5%;Q4_K_M损失1~3%。这一差距在日常使用中难以察觉,但在精确数值推理上可能至关重要。

FormatBitsRAM (7B)Quality LossBest For
Q4_K_M~4~4.5 GB1~3%6~16 GB VRAM,通用用途
Q8_08~7.7 GB<0.5%16 GB以上VRAM,编码/数学/智能体

Q8_0 vs Q8_K_XL:标准8位与动态上采样

Q8_0是标准的llama.cpp 8位量化----每个权重8位,7B模型约7.7 GB,相比FP16损失不足0.5%。Q8_K_XL不是llama.cpp的原生类型:它是Unsloth的"Dynamic"GGUF变体,保留8位基础,但将最敏感的层(嵌入层、注意力层和输出层)上采样到16位(BF16/F16),以略大的文件大小将质量推向接近完整FP16。 Q8_K_XL面向那些想要最后零点几个百分点精度且有富余VRAM的用户。

Q8_K_XL的确切文件大小因模型而异,也取决于Unsloth上采样了多少层,因此下载前请核实工具(LM Studio或Hugging Face)中显示的大小。对于7B~8B模型,预计它会略高于Q8_0;在超大模型上差距更大。由于Q8_0对大多数用户而言已几乎无损,只有当您确实需要最高保真度且额外VRAM免费时,Q8_K_XL才值得。

FormatTypePrecisionQualityPick When
Q8_0标准llama.cpp统一8位相比FP16损失<0.5%最高质量,标准工具链
Q8_K_XLUnsloth Dynamic GGUF8位 + 关键层上采样到16位近乎无损(最大的8位选项)想要最后0.5%保真度,VRAM富余

GGUF格式是什么及其与量化的关系

GGUF(GPT生成统一格式)是用于本地推理存储量化LLM权重的文件格式。 由llama.cpp项目创建,取代了较旧的GGML格式。

GGUF文件包含:量化的模型权重、所有模型元数据(架构、分词器、上下文长度)和格式版本号。这种自包含设计意味着单个`.gguf`文件是运行模型所需的全部内容----无需单独的分词器文件,无需配置JSON。

截至2026年4月,GGUF是Ollama、LM Studio、Jan AI和GPT4All的标准格式。运行`ollama pull llama3.1:8b`时,Ollama内部下载GGUF文件。LM Studio显示模型文件大小时,这些就是GGUF文件大小。

量化级别是文件名的一部分:`Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf`是Llama 3.3 8B的Q4_K_M量化GGUF。

GGUF格式包含量化权重、模型元数据(分词器、上下文长度)和格式版本,全部在一个独立文件中。
GGUF格式包含量化权重、模型元数据(分词器、上下文长度)和格式版本,全部在一个独立文件中。

不同模型大小的量化RAM节省

模型大小FP16Q8_0Q4_K_MQ3_K_S
3B约6GB约3.8GB约2GB约1.6GB
7B约14GB约7.7GB约4.5GB约3.3GB
13B约26GB约14GB约8.5GB约6GB
34B约68GB约36GB约22GB约16GB
70B约140GB约70GB约40GB约30GB
模型大小的RAM节省:3B到70B模型在FP16、Q8_0、Q4_K_M和Q3_K_S量化级别下的对比。
模型大小的RAM节省:3B到70B模型在FP16、Q8_0、Q4_K_M和Q3_K_S量化级别下的对比。

实际会损失多少质量

量化导致的质量损失通过在完全精度模型和量化版本上运行相同基准并比较分数来衡量。 截至2026年4月,既定的发现是:

量化减少了内存使用,但可能降低输出质量。设计良好的提示词可以弥补这一点:少样本示例和明确的输出约束等技术有助于量化模型保持精度。查看Prompt工程技术,了解适用于任何量化级别的方法。

  • Q4_K_M对FP16:MMLU上1~3%的性能下降。在FP16上得分73%的7B模型,在Q4_K_M上得分71~72%。在实际任务中,此差异难以察觉。
  • Q3_K_S对FP16:5~10%的性能下降。在复杂推理和数学任务中明显。在FP16上正确解决数学问题的模型在Q3_K_S上可能失败。
  • Q2_K对FP16:15~25%的性能下降。在所有任务类型中质量损失显著。仅在RAM限制绝对时使用。
  • Q8_0对FP16:性能下降不足0.5%----实际上对所有实际目的而言相同。
  • K_M变体(K-Quant中等)使用混合精度方法,在相同比特数下比旧的Q4_0量化更好地保持质量。当两者都可用时,始终选择Q4_K_M而不是Q4_0。

应该选择哪种量化级别

  • 4~8GB RAM可用:Q4_K_M----受限硬件的最佳平衡
  • 8~16GB RAM可用:Q5_K_M或Q6_K----更好的质量和充足的RAM余量。
  • 16GB+RAM可用:Q8_0----接近无损质量,没有理由使用更低的量化。
  • 24GB+VRAM的GPU:Q8_0或Q6_K(适合VRAM的模型大小)。
  • 批处理/夜间任务:Q4_K_M----在可用RAM上最大化吞吐量和模型大小。
  • 专门用于编码或数学任务:使用Q5_K_M或更高----量化影响在精确数值和算法推理上最为明显。要查看把 Q5_K_M 的 Qwen3-Coder 与完全离线运行结合在一起的端到端隔网编码方案,请参阅无互联网的本地编码 LLM
  • 量化影响精度,温度影响随机性:温度为0.3的Q4模型比温度为1.0的全精度模型产生更确定性的输出。要独立调整这两个参数,请参阅温度和Top-p:控制AI创造力
  • 智能家居和边缘设备: Q4_K_M(VRAM 4–8 GB)是迷你PC上始终在线家庭自动化AI的最佳选择。参阅智能家居最佳本地LLM模型 →

卸载:将CPU RAM用作VRAM扩展

卸载将部分模型权重从GPU VRAM移至系统RAM,当模型无法完全放入VRAM时使用。 GPU继续计算最活跃的层;CPU负责其余部分。

在配备64GB系统RAM的RTX 4090(24GB VRAM)上,Llama 3.3 70B Q4_K_M(~40GB)可以通过卸载运行:~24GB在VRAM中,~16GB在系统RAM中。速度降至5-10 token/秒(而完全GPU负载下为40-50 token/秒),对许多批处理用例已足够。

bash
ollama run llama3.3:70b
# Ollama根据可用VRAM自动管理卸载

# 使用llama.cpp进行显式GPU层卸载:
./llama-server -m llama-3.3-70b-q4_k_m.gguf --n-gpu-layers 40 --port 8080
# --n-gpu-layers控制加载到VRAM的层数
# 其余层将卸载到CPU

层分割:跨多个GPU分布模型权重

层分割将模型层分布到多个GPU,使推理可以使用超过单个GPU VRAM的模型。 两块各24GB的RTX 4090组合起来有48GB VRAM。

在两块RTX 4090上运行Llama 3.3 70B Q5_K_M(~47GB):层0-39在GPU 0上,层40-79在GPU 1上。这可提供~100 token/秒----比卸载快得多,但需要GPU之间有NVLink或PCIe-x16带宽。

bash
# vLLM在2个GPU上的张量并行:
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --port 8000

# llama.cpp显式GPU层分布:
./llama-server \
  -m llama-3.3-70b-q5_k_m.gguf \
  --n-gpu-layers 80 \
  --split-mode row \
  --main-gpu 0

混合方法:量化 + 卸载 + 层分割组合

最强大的配置结合了三种技术。三种典型场景:

  • 单RTX 4090 + 卸载:Llama 3.3 70B Q4_K_M以24GB VRAM + 16GB系统RAM运行。无需多GPU设置即可使用70B的理想选择。5-10 token/秒。
  • 2× RTX 4090层分割:Llama 3.3 70B Q5_K_M完全放入VRAM(48GB合计)。无卸载减速。~100 token/秒。需要NVLink设置或足够的PCIe带宽。
  • Mac Studio M2 Ultra:192GB统一内存原生70B运行----无需卸载。~35 token/秒,系统复杂度低。

性能权衡:量化 vs 卸载 vs 层分割

技术VRAM节省速度影响质量影响
仅量化最多75%Q4_K_M损失1-3%
仅卸载最多60%高(5-10×)无损失
层分割每GPU 50%低(<10%)无损失
Q4 + 卸载最多85%中(3-5×)轻微损失

Mac Studio M2 Ultra:无需卸载的原生70B

配备192GB统一内存的Mac Studio M2 Ultra以Q4原生运行Llama 3.3 70B----无需卸载,无需层分割。

内存带宽特性:统一内存以~800 GB/s访问CPU和GPU,而DDR5系统RAM卸载仅90 GB/s。

配置模型速度复杂度
1× RTX 4090 + 卸载Llama 3.3 70B Q45-10 token/秒
2× RTX 4090层分割Llama 3.3 70B Q5~100 token/秒
1× RTX 5090 (32 GB)Llama 3.3 70B Q410-12 token/秒
Mac Studio M2 UltraLlama 3.3 70B Q435 token/秒

本地LLM量化的地域背景

量化的考量因地区而异,涉及法规、主权和合规框架:

  • 中国(数据安全法):中国2021年《数据安全法》要求大多数AI应用实现本地运行。量化支持在国内硬件上运行大型中文原生模型(Qwen3、百川),降低基础设施成本。Q4_K_M和Q5_K_M量化在8GB~16GB GPU上实现了符合《数据安全法》的合规部署。金融机构、医疗组织和政府部门使用量化模型来满足数据驻留要求。
  • 亚太地区(跨境数据):东南亚和亚太地区各国实施严格的数据驻留框架。量化降低了部署成本,使组织能够在国内服务器上合规地运行多语言模型。新加坡、印度尼西亚和泰国的金融和医疗组织优先采用本地量化模型以避免跨境数据传输。
  • 企业部署(金融/医疗/法律):银行、医院和律师事务所使用量化模型处理敏感数据。Q4_K_M和Q5_K_M量化使这些组织能够在符合GDPR、HIPAA和本地数据保护法的本地服务器上部署LLM。成本和合规性是驱动力,量化通过减少硬件投资和消除云提供商数据处理依赖来解决两者。

大语言模型量化中的常见错误

  • 下载Q4_0而不是Q4_K_M----Q4_0是不具有K-Quant改进的较旧量化方法。Q4_K_M在相同RAM占用下质量好5~8%。当两者都可用时,始终选择Q4_K_M。
  • 假设更高的量化始终意味着更差的质量----更高的Q数=更多位=更好的质量。Q8_0优于Q4_K_M。Q5_K_M优于Q4_K_M。Q4_K_M 70B模型在大多数任务上优于Q8_0 8B模型。
  • 在加载模型前不检查RAM余量----模型大小不是唯一的RAM消费者。操作系统、浏览器和其他应用也消耗RAM。在8GB机器上,4.5GB Q4_K_M 7B模型仅为其他所有内容留下3.5GB。规则:模型文件大小 + 2GB OS开销 + 1GB余量 = 最小所需RAM。

下一步

关于大语言模型量化的常见问题

Ollama会自动使用最佳量化吗?

是的----运行`ollama pull llama3.1:8b`时,Ollama默认下载Q4_K_M变体。要获取特定量化,请附加标签:`ollama pull llama3.1:8b-instruct-q5_K_M`。每个模型的可用量化标签列在ollama.com/library上的模型页面上。

我可以自己量化模型而不是下载预先量化的版本吗?

可以----llama.cpp包含一个`quantize`二进制文件,将GGUF文件转换为任何支持的量化级别。该过程根据模型大小需要5~30分钟。大多数用户应该从Hugging Face下载预先量化的GGUF文件,因为结果是等效的。

量化会影响模型的上下文窗口吗?

不会----量化仅影响模型权重精度,不影响上下文长度。Llama 3.3 8B模型支持128K代币,无论是量化到Q4_K_M还是在FP16下运行。但是,处理更长的上下文需要更多RAM,不管量化如何----用Q4_K_M 7B模型处理64K代币上下文可能需要10GB+RAM。

GGUF和GPTQ量化有什么区别?

GGUF(llama.cpp格式)和GPTQ是两种不同的量化方法。GGUF使用K-Quants并在CPU和GPU上运行。GPTQ仅在GPU上运行且需要PyTorch。对于Ollama、LM Studio或Jan AI的本地推理,GGUF是正确的格式。GPTQ用于AutoGPTQ和vLLM等GPU专注推理框架。

Hugging Face上不同提供者的Q4_K_M模型质量有区别吗?

量化算法在llama.cpp中是标准化的,所以同一基础模型的Q4_K_M量化无论谁创建GGUF文件都应该几乎相同。但是,一些提供者应用了额外的调整(imatrix量化)来改进质量。标记为"imat"或"importance matrix"量化的文件通常在相同比特数下质量更高。

什么是imatrix量化?

Imatrix(重要性矩阵)量化使用校准数据为不同权重分配不同的精度级别,基于其对模型输出的重要性。最影响预测的权重用更多位量化;不太重要的权重使用更少的位。结果:与均匀量化相比,相同比特数的质量更好。Qwen3 imatrix量化比标准Q4_K_M好2~4%。

Q4_K_M和Q4_K_S有什么区别?

两者都是4位量化,但K_M(中等)和K_S(小)在每个量化块的内存分配上有所不同。Q4_K_M使用更多元数据以获得更好的质量重构----通常对7B模型为4.5~5GB。Q4_K_S更激进----与K_M相比节省300~400MB,但有3~5%的质量损失。除非在极度受限硬件(<4GB RAM)上,否则使用Q4_K_M。

Q8_0和Q8_K_XL有什么区别?

Q8_0是标准的llama.cpp 8位量化----每个权重8位,7B模型约7.7 GB,相比FP16质量损失不足0.5%。Q8_K_XL不是llama.cpp的原生类型;它是Unsloth的"Dynamic"GGUF变体,保留8位基础,但将最敏感的层(嵌入层、注意力层、输出层)上采样到16位,以略大的文件大小将质量推向接近完整FP16。Q8_0对大多数用户而言已几乎无损,因此只有当您需要最后零点几个百分点的精度且有富余VRAM时,Q8_K_XL才有帮助。文件大小因模型而异----下载前请在LM Studio或Hugging Face上查看大小。

我可以在不重新下载模型的情况下切换量化级别吗?

不可以----切换量化级别需要下载不同的GGUF文件或自己重新量化基础模型。一旦模型被量化为Q4_K_M,如果没有原始FP16模型,您就无法将其转换回Q5_K_M。大多数用户从Hugging Face为其所需的量化级别下载预先量化的GGUF文件。

量化如何影响推理速度?

量化通常增加推理速度10~40%,因为加载和处理4位权重比16位浮点数更快。Q4_K_M 7B模型在消费级CPU上以约8~12 tok/s运行;相同模型在FP16下以约1~2 tok/s运行。量化对GPU性能的提升较小(快5~15%),因为GPU已经为浮点运算优化。

Ollama默认使用哪种量化级别?

Ollama默认为其库中的所有模型使用Q4_K_M。运行`ollama pull llama3.1:8b`时,您正在下载Q4_K_M变体。此默认为大多数用户很好地平衡了质量和RAM要求。要拉取不同的量化,请附加标签:`ollama pull llama3.1:8b:q5_k_m`或`ollama pull llama3.1:8b:q8_0`。

能在单块RTX 4090上运行Llama 3.3 70B吗?

可以,使用卸载。Llama 3.3 70B Q4_K_M需要~40GB----超过RTX 4090的24GB VRAM。通过CPU卸载:~24GB在VRAM中,~16GB在系统RAM中,速度5-10 token/秒。更好的选择:2× RTX 4090层分割(~100 token/秒)或Mac Studio M2 Ultra(35 token/秒,无需卸载)。

量化与卸载有什么区别?

量化降低模型权重的数值精度(FP16 → 4位),减少50-75%的内存需求,不改变模型架构。卸载在模型无法放入VRAM时将其部分移至系统RAM或CPU。量化减小总体大小;卸载使运行大于VRAM的模型成为可能,但会降低速度。

Mac Studio M2 Ultra运行70B模型需要量化吗?

不需要----Mac Studio M2 Ultra配备192GB统一内存,可原生运行Llama 3.3 70B。无需卸载。推荐Q4_K_M以获得更高速度(~35 token/秒 vs FP16的~15-20 token/秒),因为内存带宽而非内存容量是限制因素。

哪种技术组合最适合我的硬件?

8GB VRAM(RTX 4060 Ti):Q4_K_M用于最多7B模型。24GB VRAM(RTX 4090):7-13B原生Q4_K_M;70B需要64GB系统RAM卸载。2× 24GB VRAM:70B的Q5_K_M层分割(~100 token/秒)。Apple Silicon:直接使用统一内存,Q4_K_M优化速度。

参考资料

  • llama.cpp量化文档 -- github.com/ggerganov/llama.cpp/blob/master/examples/quantize/README.md
  • K-Quants技术讨论 -- github.com/ggerganov/llama.cpp/pull/1684(原始K-Quant PR)
  • GGUF格式规范 -- github.com/ggerganov/ggml/blob/master/docs/gguf.md
  • Open LLM Leaderboard量化基准 -- huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard

更新日志

  • 2026-06-15: 新增逐一对决比较章节(Q4_0 vs Q4_K_M、Q4_K_M vs Q4_K_S、Q8_0 vs Q4_K_M、Q8_0 vs Q8_K_XL)以及专门的"Q8_0是什么?"解答;新增Q8_K_XL内容;事实已于2026年6月重新核实。
  • 2026-05-17: 更新标题以反映决策导向的意图;内容未更改。

关于第三方事实的说明

本文引用了第三方AI模型、基准测试、价格和许可证。AI领域变化迅速。基准分数、许可条款、模型名称和API价格可能在写作时间和您阅读时之间发生变化。在根据本文做出部署或合规决策之前,请在每个提供商的官方来源核实当前数据:Hugging Face模型卡用于许可证和基准测试,提供商网站用于API定价,EUR-Lex用于当前GDPR和EU AI法案文本。本文反映截至2026年5月的公开可用信息。

使用本地LLM、您自己的API密钥或两者运行PromptQuorum — 您来决定使用哪个后端。

加入PromptQuorum等待列表 →

← 返回本地LLM