显存 on KnightLi的博客

本地部署 Qwen3.6：27B 与 35B-A3B 各量化版本需要多少显存

Fri, 01 May 2026 12:02:00 +0800

Qwen3.6 目前最适合本地部署讨论的开放权重版本，主要是两类：

Qwen3.6-27B：27B 稠密模型。
Qwen3.6-35B-A3B：35B total / 3B active 的 MoE 模型。

还有一些线上产品名或 API 模型名，例如 Qwen3.6-Plus、Qwen3.6-Max。这类模型如果没有公开完整权重和稳定量化文件，就不适合列入本地显存表。本文只整理可以围绕 Hugging Face 权重与 GGUF 量化文件部署的版本。

和 /05/10 的 Gemma 4 表一样，这里也要先区分两个概念：

GGUF 文件体积：模型权重文件本身有多大。
实际显存占用：模型权重、KV cache、上下文长度、运行后端、多模态模块、批大小共同决定。

Qwen3.6 的默认上下文很长，官方模型卡里写到原生支持 262,144 tokens，并可扩展到 1,010,000 tokens。所以表格里的“最低显存”只适合短上下文或中等上下文。如果你真的要跑 128K、256K 或更长上下文，必须额外给 KV cache 留大量空间。

先看结论

显存	比较合适的选择	不建议硬上
8GB	27B / 35B-A3B 的 2-bit 极限尝试，质量风险较高	Q4 以上
12GB	27B Q2/Q3，35B-A3B Q2/Q3 短上下文	27B Q4 长上下文
16GB	27B Q3/Q4，35B-A3B Q3/IQ4_XS	35B-A3B Q4 长上下文
24GB	27B Q4/Q5/Q6，35B-A3B Q4	35B-A3B Q8、BF16
32GB	27B Q8，35B-A3B Q5/Q6	BF16
48GB	35B-A3B Q8，27B 长上下文更从容	35B-A3B BF16
80GB+	27B / 35B-A3B BF16	没有必要为普通本地聊天追 BF16

如果你是 24GB 显卡，重点看：

Qwen3.6-27B Q4_K_M
Qwen3.6-27B Q5_K_M
Qwen3.6-35B-A3B UD-Q4_K_M

如果你只有 16GB 显存，优先从低位宽版本开始，不要一上来就开超长上下文。

官方权重体积

以下是官方 Hugging Face 仓库中 model.safetensors.index.json 统计到的 BF16 权重体积。它可以作为原始权重规模参考。

模型	架构	官方 BF16 权重体积	官方上下文
`Qwen3.6-27B`	27B dense	55.56GB	262K 原生，可扩展到 1,010K
`Qwen3.6-35B-A3B`	35B total / 3B active MoE	71.90GB	262K 原生，可扩展到 1,010K

35B-A3B 虽然每次只激活约 3B 参数，但它仍然需要加载完整 MoE 权重。所以它不能按 3B 小模型来估算显存。

Qwen3.6-27B 显存表

Qwen3.6-27B 是稠密模型，优点是能力稳定，缺点是推理成本更接近传统 27B 模型。从本地部署角度看，它比 35B-A3B 更吃计算，但显存需求更容易预估。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_XXS`	9.39GB	12GB	16GB	极限低显存尝试
`UD-IQ2_M`	10.85GB	12GB	16GB	低显存可用性优先
`UD-Q2_K_XL`	11.85GB	14GB	18GB	低位宽折中
`UD-IQ3_XXS`	11.99GB	14GB	18GB	省显存的 3-bit
`Q3_K_S`	12.36GB	16GB	20GB	3-bit 入门
`Q3_K_M`	13.59GB	16GB	20GB	3-bit 常用折中
`IQ4_XS`	15.44GB	20GB	24GB	接近 Q4 的省显存选择
`IQ4_NL`	16.07GB	20GB	24GB	质量和体积折中
`Q4_K_M`	16.82GB	20GB	24GB	27B 常用推荐
`Q5_K_M`	19.51GB	24GB	32GB	更稳的高质量量化
`Q6_K`	22.52GB	28GB	32GB	质量优先
`Q8_0`	28.60GB	32GB	40GB	接近原始精度
`BF16`	53.80GB	64GB	80GB	研究、评测、精度对比

如果只是普通本地编码和聊天，Q4_K_M 是最容易推荐的起点。 24GB 显卡可以比较舒服地跑 Q4_K_M，但如果要长上下文，最好降低量化位宽或减少上下文长度。

Qwen3.6-35B-A3B 显存表

Qwen3.6-35B-A3B 是 MoE 模型，35B total，但每次激活约 3B 参数。它的优势是速度和能力之间的平衡很好，尤其适合本地 Agent、工具调用、代码协作。

但要注意：MoE 的 3B active 主要影响计算量，不代表显存只需要 3B 模型级别。完整运行仍要加载专家权重。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_XXS`	10.76GB	12GB	16GB	极限低显存尝试
`UD-IQ2_M`	11.52GB	14GB	16GB	低显存可用性优先
`UD-Q2_K_XL`	12.29GB	14GB	18GB	低位宽折中
`UD-IQ3_XXS`	13.21GB	16GB	20GB	省显存的 3-bit
`UD-Q3_K_S`	15.36GB	18GB	24GB	3-bit 入门
`UD-Q3_K_M`	16.60GB	20GB	24GB	3-bit 常用折中
`UD-IQ4_XS`	17.73GB	20GB	24GB	质量和体积折中
`UD-IQ4_NL`	18.04GB	20GB	24GB	接近 Q4 的推荐选择
`UD-Q4_K_M`	22.13GB	24GB	32GB	35B-A3B 常用推荐
`UD-Q5_K_M`	26.46GB	32GB	40GB	更稳的高质量量化
`UD-Q6_K`	29.31GB	32GB	48GB	质量优先
`Q8_0`	36.90GB	48GB	64GB	接近原始精度
`BF16`	69.37GB	80GB	96GB	研究、评测、精度对比

24GB 显存可以把 UD-Q4_K_M 作为重点选择，但上下文不要开得太夸张。如果想给 128K 以上上下文留空间，UD-IQ4_XS、UD-IQ4_NL 或 3-bit 版本会更现实。

27B 和 35B-A3B 怎么选

需求	更推荐
稳定稠密模型表现	`Qwen3.6-27B`
更快响应、Agent 和工具调用	`Qwen3.6-35B-A3B`
24GB 显存日常本地用	`35B-A3B UD-Q4_K_M` 或 `27B Q4_K_M`
16GB 显存尝试	两者都选 2-bit/3-bit，不建议长上下文
长上下文优先	降低量化位宽，留更多 KV cache 空间
质量优先且有 32GB+ 显存	`27B Q5/Q6` 或 `35B-A3B Q5/Q6`

如果你主要写代码、跑 Agent、做工具调用，35B-A3B 更值得先试。如果你更在意稠密模型的稳定性和一致性，27B 更直观。

为什么长上下文会吃掉大量显存

Qwen3.6 的模型卡建议在复杂任务中保持较长上下文，甚至提到 128K 以上上下文对思考能力有帮助。但对本地部署来说，长上下文意味着更大的 KV cache。

影响实际显存的因素包括：

KV cache：上下文越长，占用越高。
是否启用视觉输入：Qwen3.6 是带视觉编码器的模型，多模态场景会增加额外开销。
是否使用 --language-model-only：在 vLLM 等运行时里，跳过视觉部分可以释放一部分内存给 KV cache。
批大小和并发：并发越高，显存需求越高。
KV cache 量化：q8_0、q4_0 等设置可以省显存，但可能影响细节。
运行时差异：llama.cpp、vLLM、SGLang、KTransformers、LM Studio 的占用不完全一样。

所以不要只看 GGUF 文件大小。如果文件已经接近显存上限，模型即使能加载，也可能在生成长文本或长上下文时 OOM。

怎么选

如果你只是想本地体验 Qwen3.6：

12GB 显存：尝试 27B UD-IQ2_M 或 35B-A3B UD-IQ2_M，上下文要短。
16GB 显存：尝试 27B Q3_K_M 或 35B-A3B UD-IQ3_XXS。
24GB 显存：优先看 27B Q4_K_M、35B-A3B UD-IQ4_NL、35B-A3B UD-Q4_K_M。
32GB 显存：可以考虑 27B Q5/Q6 或 35B-A3B Q5/Q6。
48GB 以上：可以尝试 Q8_0，或者给长上下文留更多空间。

一般用户不需要追 BF16。 Qwen3.6 的本地部署重点不是“文件越大越好”，而是在显存、上下文长度、速度和输出质量之间找到平衡。

参考来源

本地部署 DeepSeek V4：Pro、Flash 与 Base 版本显存占用估算表

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 和 Gemma 4 的本地部署不是一个量级。 Gemma 4 的 26B、31B 还能讨论 24GB、32GB 显卡怎么选量化版；DeepSeek V4 则是超大 MoE 模型，真正完整本地部署时，显存需求会直接进入多卡工作站或服务器级别。

官方发布的 DeepSeek V4 Preview 主要包含两个推理版本：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

Hugging Face 官方 collection 里还包含两个 Base 版本：

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

这篇只讨论完整加载模型权重时的大致显存门槛。 MoE 的 active params 主要影响每个 token 的计算量，不等于只需要加载这部分参数。如果没有专家按需加载、CPU/NVMe offload、分布式推理或专门运行时优化，显存仍然要按完整权重来估。

先看结论

显存规模	能比较现实地尝试什么	不建议期待什么
24GB	不能完整跑 DeepSeek V4；只能跑小型蒸馏模型或 API	V4-Flash / V4-Pro 完整本地加载
48GB	仍不适合完整加载；可做小模型或远程 API 客户端	V4-Flash Q4 稳定运行
80GB	理论上可尝试 V4-Flash Q2/Q3 或强 offload	V4-Pro
128GB	V4-Flash Q4 比较现实；Q5/Q6 仍紧	V4-Pro Q4
192GB	V4-Flash FP8/Q6 更从容；Pro Q2 勉强进入讨论	V4-Pro Q4
256GB	V4-Flash FP8 比较稳；Pro Q2/Q3 可实验	V4-Pro Q5 以上
512GB	V4-Pro Q4 开始进入可讨论范围	V4-Pro FP8
1TB+	V4-Pro FP8、Pro-Base 低位宽更现实	单机低成本部署
2TB+	Pro-Base FP8 级别	普通工作站部署

如果你的目标是个人电脑本地运行，DeepSeek V4 并不是合适对象。更现实的路线是：

用 DeepSeek 官方 API 或兼容服务；
等社区稳定的 GGUF/EXL2/MLX 量化和推理支持；
使用更小的 DeepSeek 蒸馏模型；
或者把本地模型换成 Qwen、Gemma、Llama 等 7B 到 70B 级别模型。

官方权重体积

以下是 Hugging Face 官方仓库的 model.safetensors.index.json 中统计到的权重总量。它反映的是当前公开权重文件大小，不等于长上下文运行时的完整显存占用。

模型	参数规模	官方权重体积	说明
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	推理版，体积相对最小
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	推理版，能力更强，体积巨大
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base 版，更接近全量 FP8 权重体积
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base 版，约 1.6TB 级别

可以看到，即使是最小的 V4-Flash，官方权重也已经接近 160GB。这就是为什么它不能按“13B active params”理解成 13B 小模型。

DeepSeek V4 Flash 显存估算

V4-Flash 是 DeepSeek V4 里最适合本地尝试的一档。但“最适合”只是相对 Pro 而言，它仍然不是消费级单卡模型。

下面按官方 159.61GB 权重体积做折算。其中 Q4/Q3/Q2 是按位宽估算，不代表当前已经有稳定可用的官方 GGUF 版本。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	159.61GB	192GB	256GB	多卡服务器、推理服务
`Q6`	120GB	160GB	192GB	质量优先的量化尝试
`Q5`	100GB	128GB	160GB	质量和体积折中
`Q4`	80GB	96GB	128GB	Flash 本地化较现实的起点
`Q3`	60GB	80GB	96GB	大显存单卡或多卡实验
`Q2`	40GB	48GB	64GB	极限低位宽实验，质量风险明显

如果未来社区出现成熟的 V4-Flash Q4，它大概率也不是 24GB 显卡的模型。更现实的硬件起点是 96GB 到 128GB 级别的总显存，或者依赖 CPU 内存/offload 换速度。

DeepSeek V4 Pro 显存估算

V4-Pro 是旗舰推理版，官方权重体积约 864.70GB。即使做 4-bit 量化，完整权重也仍然是数百 GB 级别。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	864.70GB	1TB	1.2TB+	多机多卡推理服务
`Q6`	648GB	768GB	1TB	高质量量化服务
`Q5`	540GB	640GB	768GB	高质量与成本折中
`Q4`	432GB	512GB	640GB	Pro 本地化较现实的最低质量线
`Q3`	324GB	384GB	512GB	低位宽实验
`Q2`	216GB	256GB	320GB	极限实验，质量和稳定性风险高

对个人用户来说，V4-Pro 更适合通过 API 使用。如果目标是完整本地部署，至少要把它当成多卡服务器模型，而不是 4090、5090、RTX PRO 单卡模型。

DeepSeek V4 Flash-Base 显存估算

Base 版通常用于研究、微调或继续训练，不是普通聊天部署的首选。 V4-Flash-Base 官方权重体积约 294.67GB。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	294.67GB	384GB	512GB	研究、训练前处理、评测
`Q6`	221GB	256GB	320GB	高质量量化研究
`Q5`	184GB	224GB	256GB	质量和体积折中
`Q4`	147GB	192GB	224GB	Base 版低成本实验
`Q3`	111GB	128GB	160GB	低位宽实验
`Q2`	74GB	96GB	128GB	极限实验

如果只是要使用 DeepSeek V4 能力，不建议从 Base 版开始。 Base 版的部署和调优成本更高，普通应用更适合推理版或 API。

DeepSeek V4 Pro-Base 显存估算

V4-Pro-Base 是最重的一档，官方权重体积约 1606.03GB。这已经是 1.6TB 级别的模型文件。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	1606.03GB	2TB	2.4TB+	大规模研究集群
`Q6`	1205GB	1.5TB	2TB	高质量量化研究
`Q5`	1004GB	1.2TB	1.5TB	研究与评测
`Q4`	803GB	1TB	1.2TB	低位宽研究
`Q3`	602GB	768GB	1TB	极限低位宽研究
`Q2`	402GB	512GB	640GB	极限实验

这类模型不适合被放进“家用显卡能不能跑”的框架里讨论。哪怕是 Q4，也已经超过绝大多数单机工作站的舒适范围。

为什么不能只看 active params

DeepSeek V4 是 MoE 模型。 MoE 的特点是每个 token 只激活一部分专家，因此计算量会明显低于总参数量。但这不等于显存只需要放 active params。

完整本地推理通常还要考虑：

所有专家权重是否需要常驻 GPU；
是否支持按需专家加载；
CPU 内存与 GPU 显存之间的数据搬运成本；
NVMe offload 的延迟；
KV cache 在长上下文下的增长；
1M context 场景下的额外运行时开销；
多机多卡通信成本。

所以，49B active 的 V4-Pro 不能当成 49B 模型来部署。 13B active 的 V4-Flash 也不能当成 13B 小模型来部署。

怎么选

如果你只是普通个人用户：

不建议完整本地部署 DeepSeek V4。
需要 DeepSeek V4 能力时，优先用官方 API。
需要本地私有化时，优先看是否有成熟推理服务商或内部多卡服务器。
只有 24GB 到 48GB 显存时，转向 7B、14B、32B、70B 级别量化模型更实际。

如果你有 128GB 到 256GB 总显存：

可以关注 V4-Flash Q4/Q5 是否有稳定社区实现。
不建议把 V4-Pro 当成主力本地模型。

如果你有 512GB 以上总显存：

V4-Pro Q4 才开始进入工程验证范围。
仍然要关注推理框架、专家调度、KV cache、吞吐和并发。

DeepSeek V4 的本地部署重点不是“下载哪个量化文件”，而是“有没有足够的系统级推理能力”。它更接近一个服务器模型，而不是普通桌面模型。

参考来源

本地部署 Gemma 4：E2B、E4B、26B、31B 各量化版本需要多少显存

Fri, 01 May 2026 11:42:34 +0800

Gemma 4 现在主要有四个本地部署尺寸：E2B、E4B、26B A4B 和 31B。其中 E2B、E4B 面向轻量和边缘设备，26B A4B 是 MoE 架构，31B 是更大的稠密模型。

本地运行时，最容易混淆的是两个数字：

GGUF 文件体积：模型权重文件本身有多大。
实际显存占用：模型权重、KV cache、运行时开销、上下文长度、是否加载多模态投影文件共同决定。

下面的表格按 GGUF 文件体积估算显存需求。默认假设是 llama.cpp、LM Studio、Ollama 这类本地推理场景，主要跑文本，使用中短上下文。如果要开长上下文、视觉/音频输入、并发请求，显存要继续往上留余量。

先看结论

显存	比较合适的选择	不建议硬上
4GB	E2B 的低比特量化	E4B 以上
6GB	E2B Q4/Q5，E4B 低比特量化	26B、31B
8GB	E2B Q8，E4B Q4/Q5	26B Q4、31B Q4
12GB	E4B Q8，26B/31B 的 2-bit/3-bit 低质量尝试	26B Q4 长上下文、31B Q4
16GB	26B 低比特量化，31B 低比特量化	31B Q4 长上下文、26B Q5 以上
24GB	26B Q4/Q5，31B Q4	31B Q8、BF16
32GB	26B Q6/Q8，31B Q5/Q6	BF16
48GB	31B Q8 更从容，26B Q8 长上下文	31B BF16
80GB+	26B/31B BF16	普通消费卡单卡部署

如果只是想本地可用，优先从 E4B Q4_K_M 或 E2B Q4_K_M 开始。如果有 24GB 显存，26B A4B Q4_K_M 和 31B Q4_K_M 才开始进入比较舒服的范围。

Gemma 4 E2B 显存表

E2B 是最轻量的版本，适合笔记本、迷你主机、移动端和低显存测试。它的优势是容易跑，缺点是复杂推理、代码和长任务稳定性有限。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_M`	2.29GB	4GB	6GB	极限低显存测试
`UD-Q2_K_XL`	2.40GB	4GB	6GB	低显存可用性优先
`Q3_K_M`	2.54GB	4GB	6GB	轻量聊天、摘要
`IQ4_XS`	2.98GB	6GB	8GB	质量和体积折中
`Q4_K_M`	3.11GB	6GB	8GB	E2B 常用推荐
`Q5_K_M`	3.36GB	6GB	8GB	比 Q4 更稳一点
`Q6_K`	4.50GB	8GB	10GB	小模型高质量量化
`Q8_0`	5.05GB	8GB	10GB	接近原始精度的轻量部署
`BF16`	9.31GB	12GB	16GB	调试、对比、研究

E2B 的 Q4_K_M 已经够日常体验。如果只有 4GB 显存，可以尝试 2-bit 或 3-bit，但输出质量会更容易波动。

Gemma 4 E4B 显存表

E4B 是更实用的轻量版本。它比 E2B 更适合日常写作、资料总结、轻量代码辅助和本地助手。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_M`	3.53GB	6GB	8GB	低显存尝试
`UD-Q2_K_XL`	3.74GB	6GB	8GB	低显存可用性优先
`Q3_K_M`	4.06GB	6GB	10GB	轻量本地助手
`IQ4_XS`	4.72GB	8GB	12GB	质量和速度折中
`Q4_K_M`	4.98GB	8GB	12GB	E4B 常用推荐
`Q5_K_M`	5.48GB	8GB	12GB	更稳的日常使用
`Q6_K`	7.07GB	10GB	16GB	质量优先
`Q8_0`	8.19GB	12GB	16GB	接近原始精度
`BF16`	15.05GB	20GB	24GB	研究、评测、精度对比

如果你的显卡是 8GB，E4B Q4_K_M 是很现实的起点。如果是 12GB 或 16GB，E4B Q8_0 也可以考虑。

Gemma 4 26B A4B 显存表

26B A4B 是 MoE 版本，参数规模更大，但每次推理只激活其中一部分专家。它适合更复杂的问答、代码、工具调用和 Agent 工作流。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_M`	9.97GB	14GB	16GB	16GB 显卡极限尝试
`UD-Q2_K_XL`	10.55GB	14GB	16GB	低显存跑 26B
`UD-Q3_K_M`	12.53GB	16GB	20GB	质量略好，仍偏省显存
`UD-IQ4_XS`	13.42GB	16GB	24GB	质量和体积折中
`UD-Q4_K_M`	16.87GB	20GB	24GB	26B 常用推荐
`UD-Q5_K_M`	21.15GB	24GB	32GB	更稳的高质量量化
`UD-Q6_K`	23.17GB	28GB	32GB	质量优先
`Q8_0`	26.86GB	32GB	40GB	接近原始精度
`BF16`	50.51GB	64GB	80GB	单卡消费级不现实

24GB 显存是 26B A4B 比较舒服的分界线。 16GB 显卡可以尝试低比特版本，但上下文长度、并发和多模态都要收敛。

Gemma 4 31B 显存表

31B 是更大的稠密模型。它的优点是综合能力更强，缺点是显存压力比 26B A4B 更直接。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_XXS`	8.53GB	12GB	16GB	极限低显存尝试，质量牺牲明显
`UD-IQ2_M`	10.75GB	14GB	18GB	低显存尝试
`UD-Q2_K_XL`	11.77GB	16GB	20GB	16GB 显卡可尝试
`Q3_K_S`	13.21GB	16GB	24GB	更省显存的 3-bit
`Q3_K_M`	14.74GB	20GB	24GB	3-bit 常用折中
`IQ4_XS`	16.37GB	20GB	24GB	接近 Q4 的折中
`Q4_K_M`	18.32GB	24GB	32GB	31B 常用推荐
`Q5_K_M`	21.66GB	28GB	32GB	更稳的高质量量化
`Q6_K`	25.20GB	32GB	40GB	质量优先
`Q8_0`	32.64GB	40GB	48GB	接近原始精度
`BF16`	61.41GB	80GB	96GB	服务器或大显存工作站

31B 的低比特版本可以在 16GB 显卡上做实验，但如果想日常使用，最好从 24GB 显存起步。 Q4_K_M 是比较平衡的选择，Q5_K_M 往上更适合 32GB 以上显存。

为什么实际占用会比文件体积更高

GGUF 文件体积只是权重大小。真正运行时还会增加这些开销：

KV cache：上下文越长，占用越高。
批大小和并发：一次处理更多 token 或多用户并发，会增加显存。
多模态组件：图片、音频、视频输入通常还要加载 mmproj 或额外处理模块。
运行时后端：CUDA、Metal、ROCm、CPU/GPU 分层加载的占用不同。
KV cache 量化：开启 q8_0、q4_0 等 KV cache 量化可以省显存，但可能影响细节。

所以表格里的“最低显存”只能理解为“能启动并短上下文运行”的门槛。如果你要 32K、64K、128K 甚至 256K 上下文，显存需求会明显增加。

怎么选

如果只是想在本地体验 Gemma 4：

4GB 到 6GB 显存：选 E2B Q3_K_M 或 E2B Q4_K_M。
8GB 显存：优先选 E4B Q4_K_M，也可以跑 E2B Q8_0。
12GB 显存：选 E4B Q8_0，或者尝试 26B/31B 的低比特版本。
16GB 显存：可以尝试 26B A4B UD-Q3_K_M 或 31B Q3_K_S，但不要期待长上下文很舒服。
24GB 显存：26B A4B UD-Q4_K_M 和 31B Q4_K_M 是重点选择。
32GB 以上：可以考虑 Q5_K_M、Q6_K，或者更长上下文。

一般用户不需要追 BF16。本地部署的核心不是文件越大越好，而是在显存、速度、上下文和输出质量之间找到平衡。