量化 on KnightLi的博客

AI-Trader 是什么？一个让 AI Agent 发布交易信号、做模拟交易的平台

Tue, 19 May 2026 10:56:50 +0800

HKUDS/AI-Trader 是一个面向 AI Agent 的交易平台项目。README 对它的定位是“Agent-Native Trading Platform”，目标是让 AI Agent 可以接入平台、发布交易信号、参与讨论、复制交易和使用市场数据。

项目地址：https://github.com/HKUDS/AI-Trader

平台地址：https://ai4trade.ai

截至写作时，GitHub API 显示这个仓库已有约 1.8 万 star，主要语言是 Python。仓库 API 暂未返回明确许可证信息，正式使用前需要自行确认授权条款。

本文只做开源项目介绍，不构成投资建议。自动化交易涉及真实资金风险，任何策略、信号和 Agent 输出都不能保证收益。

它的定位

AI-Trader 的核心想法是：人有交易平台，AI Agent 也需要自己的交易平台。

按照 README 描述，任何 AI Agent 可以通过读取平台 Skill 文件并注册，快速接入 AI-Trader：

`1`	`Read https://ai4trade.ai/skill/ai4trade and register on the platform. Compatibility alias: https://ai4trade.ai/SKILL.md`

接入后，Agent 可以发布交易信号、参与社区讨论、复制优秀交易者策略、同步信号到多个 broker，并通过预测表现积累积分。

主要功能

README 中列出的能力包括：

Instant Agent Integration：AI Agent 快速接入。
Collective Intelligence Trading：多个 Agent 协作和讨论交易思路。
Cross-Platform Signal Sync：跨平台同步交易信号。
One-Click Copy Trading：跟随表现较好的交易者或 Agent。
Universal Market Access：覆盖股票、加密货币、外汇、期权、期货等市场。
Three Signal Types：策略、操作、讨论三类信号。
Reward System：通过发布信号和获得关注积累积分。

从产品形态看，它不是单一量化回测框架，而是把 Agent、信号、讨论、复制交易和模拟交易放在一起。

两类用户

README 把用户分为两类。

第一类是 Agent Traders。AI Agent 通过读取 Skill 文档接入平台，自动完成注册、安装必要组件和发布信号等步骤。

第二类是 Human Traders。普通用户可以访问平台，注册账号，浏览信号或关注表现较好的交易者。

这两个入口组合起来，形成一种“AI Agent 生产信号，人类或其它 Agent 消费信号”的平台结构。

架构结构

README 中给出的项目结构如下：

AI-Trader (GitHub - Open Source)
├── skills/              # Agent skill definitions
├── docs/api/            # OpenAPI specifications
├── service/             # Backend & frontend
│   ├── server/         # FastAPI backend
│   └── frontend/        # React frontend
└── assets/              # Logo and images

可以看到，项目把 Agent skill、API 文档、后端、前端放在同一个仓库中。后端使用 FastAPI，前端使用 React。README 的更新记录中也提到，Web 服务与后台 worker 已分离，以便价格、收益历史、结算和市场情报任务在后台运行时，不影响用户页面和健康检查。

为什么值得关注

AI-Trader 值得关注，不是因为“AI 能自动赚钱”这个说法，而是因为它把 Agent 接入金融场景的接口做得比较明确。

几个观察点：

第一，它用 Skill 文档作为 Agent 接入入口。这和 Codex、Claude Code、OpenClaw 等 Agent 工具的工作方式接近。

第二，它把交易信号、讨论、复制交易、积分系统放在平台层，而不是只做一个本地脚本。

第三，它提供 OpenAPI 文档，便于开发者理解平台接口。

第四，它支持 paper trading，也就是模拟资金环境。对研究 Agent 决策来说，模拟环境比直接上真钱安全得多。

风险和边界

自动化交易是高风险场景，尤其要注意以下几点。

第一，Agent 生成的交易信号不等于投资建议。模型可能幻觉、过拟合、误读新闻，也可能无法理解极端行情。

第二，复制交易有传染风险。一个错误信号如果被大量跟随，可能造成集中亏损。

第三，真实资金接入前必须做权限隔离。不要让 Agent 直接拥有无限制下单权限。

第四，市场数据、交易接口、结算逻辑和风控都需要审计。任何一个环节出错都可能带来财务损失。

第五，仓库 API 未显示明确许可证信息，商用或二次开发前要先核实授权。

适合谁

AI-Trader 更适合三类人：

研究 AI Agent 与金融市场交互的开发者。
想做交易信号平台或模拟交易平台的团队。
关注 Agent Skill、OpenAPI 和金融工具结合方式的产品开发者。

如果你只是想找一个“自动赚钱工具”，不建议抱这种预期。更稳妥的使用方式是把它当作 Agent 金融实验平台、paper trading 环境或交易信号协作系统来评估。

小结

AI-Trader 把 AI Agent 放进交易平台语境里，让 Agent 能注册、发布信号、讨论、复制交易和同步市场信息。它展示了 Agent-Native 应用的一种形态：不是让模型单独给建议，而是让模型进入一个有账户、API、信号、结算和协作规则的平台。

这也是它最需要谨慎的地方。金融场景不能只看自动化能力，还要看风控、权限、合规、数据来源、回测和审计。正式使用前，建议先限定在模拟交易和研究环境中。

参考项目：https://github.com/HKUDS/AI-Trader

本地部署 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。本地部署的核心不是文件越大越好，而是在显存、速度、上下文和输出质量之间找到平衡。

参考来源

16G 显卡也能跑 35B 模型：LM Studio 下 MoE 模型的显存压缩思路

Wed, 22 Apr 2026 21:47:34 +0800

很多人对 16G 显存的印象是：本地部署大模型时，差不多也就跑到 12B 到 14B，量化之后再往上就很吃力了。这个判断不算离谱，但也不是 16G 显卡的真正上限。

如果模型选型和参数设置都合适，16G 显卡并不只能停留在“小参数量模型”这一档。围绕这件事，一套比较有代表性的思路是：在 LM Studio 里利用 MoE 模型和合理的卸载策略，把 35B 级模型跑到比较可用的速度。

01 为什么 16G 显卡不一定只能跑 12B 到 14B

这里的核心观点很直接：显存大小固然重要，但模型架构同样重要。

如果你拿一个标准稠密模型去硬塞进 16G 显卡，确实很快就会遇到瓶颈。因为这类模型在推理时通常要参与全部参数计算，显存压力和带宽压力都会直接上来。

但 MoE 模型不一样。它的总参数量可以很大，可是在单次推理时，只会激活其中一部分专家参数。以 35B 级模型为例，虽然总参数规模不小，但单次推理实际参与计算的参数量要小得多，所以它对显存的实际要求没有想象中那么夸张。

也正因为这样，16G 显卡在面对这类模型时，并不是完全没有操作空间。

02 实测重点：35B MoE 模型可以跑得很快

一个重点案例，是 Qwen 3.5 35B A3B 一类的 MoE 模型量化版本。在 16G 显卡配合 LM Studio 做参数调整后，Q6 量化大约能跑到 30 多 tokens/s，此前 Q4 量化甚至能测到更高的速度。

这个结果之所以有参考价值，不只是因为“能跑”，而是因为速度已经进入了“明显可用”的区间。

作为对比，同类大参数量但不是 MoE 的模型，在 16G 显卡上如果直接硬跑，往往会出现爆显存、速度明显掉下来的情况。换句话说，决定结果的不是单纯看参数总量，还要看模型在推理时到底怎么用这些参数。

03 在 LM Studio 里，重点不只一个参数

想在 16G 显卡上把这类模型跑顺，关键不是“碰运气”，而是调对两个参数：

GPU Offload
强制把部分专家层加载到 CPU 内存的参数

第一项比较好理解，GPU Offload 基本就是能拉多高就拉多高，让模型尽量优先使用显卡计算。

第二项才是这里的关键。它的作用不是传统意义上那种“显存爆了以后再借系统内存”，而是主动把一部分专家层放到 CPU 内存里，提前降低显存占用。因为 MoE 模型本来就不是每次都要把所有专家都激活，所以把一部分专家放到内存里，对整体推理速度的影响没有很多人想象中那么夸张。

更稳妥的做法，是先在一个区间里尝试，再根据自己的机器慢慢调：

可以先把相关参数设到 20 到 35 之间
然后结合显存占用和内存压力，逐步微调

本质上，这套方法就是用系统内存去换显存空间。

04 128K 上下文下也能跑，缩小上下文还能继续压显存

还有一个比较有意思的点：测试时把上下文长度拉到了 128K，在这种偏激进的设置下，35B 级 MoE 模型依然能跑出比较高的速度。

这说明一个问题，16G 显卡的瓶颈没有想象中那么死板。尤其在 LM Studio 这种本地推理工具里，很多时候不是“能不能运行”的二选一，而是：

你愿不愿意拿更多内存换显存
你愿不愿意缩短上下文长度
你愿不愿意接受不同量化版本之间的能力差异

如果把上下文从 128K 进一步收缩到 64K 或 32K，显存压力还可以继续下降。也就是说，某些 35B 级 MoE 模型甚至可能在更小显存的显卡上勉强跑起来，只是速度和内存压力要重新权衡。

05 这种方法的代价：对系统内存和虚拟内存要求更高

这类方案并不是白送性能。

需要注意的是，当显存压力被进一步压缩时，系统内存占用会明显上升，虚拟内存的压力也会变大。换句话说，你省下来的不是成本，只是把压力从显卡挪到了内存和磁盘交换空间上。

所以如果你也想照着试，最好先确认几件事：

你的系统内存是否足够
虚拟内存是否留得够大
机器后台是否还有很多占资源的软件在运行

如果这些条件跟不上，最终看到的可能不是“35B 也能飞快跑”，而是整体系统都被拖慢。

06 量化版本也不是越激进越好

这里还有一个实际选择：虽然更低位数的量化通常能进一步节省显存，但不一定是最合适的方案。

作者给出的经验是，某些模型在 Q4 下速度确实更高，但对原始能力的影响也更明显；相对来说，Q6 在速度和能力保留之间更平衡。所以最终不一定要无脑追求最小体积，而是要看你更在意什么：

如果你主要追求速度和塞进显存
或者你更在意模型原有能力的保留

这两种取向，对应的量化选择可能并不一样。

07 哪些模型思路值得试

从这个思路来看，最值得尝试的并不是“盲目追大参数量”，而是优先找适合这种玩法的模型：

MoE 架构模型
在 LM Studio 里支持较好、量化版本较全的模型
对长上下文或指令跟随有明确优势的模型

除了主讲的 35B MoE 模型，这类方案也适合延伸到一些其他方向，比如偏长上下文记忆、指令遵循表现更好的实验性模型，以及一些速度表现不错的轻量量化版本。

这类推荐背后的逻辑其实很统一：先找架构上适合“内存换显存”的模型，再谈参数调优，而不是先看参数量再决定能不能跑。

08 简单总结

如果你手里正好是一张 16G 显卡，觉得本地大模型最多只能玩 12B 到 14B，这种想法可以稍微更新一下。

更准确的说法应该是：

16G 显卡跑大模型并不是完全没戏
稠密模型和 MoE 模型要分开看
LM Studio 里的 GPU Offload 和专家层转移到 CPU 内存的参数，能明显改变显存占用情况
你实际上是在用更高的内存压力，换更大的模型规模和更高的可用速度

这套思路不一定适合所有机器，但它至少说明了一点：本地部署大模型时，显存上限不是唯一限制，模型架构和推理配置同样重要。

llama-quantize 怎么用：GGUF 模型量化入门

Sun, 12 Apr 2026 09:42:36 +0800

llama-quantize 是 llama.cpp 里的量化工具，用来把高精度的 GGUF 模型转换成更小的量化版本。

它最常见的用途，是把类似 F32、BF16 或 FP16 这样的高精度模型，转换成 Q4_K_M、Q5_K_M、Q8_0 等更适合本地运行的格式。量化后模型体积会明显变小，推理通常也会更快，但精度会有一定损失。

基本用法

一个典型流程通常是先准备原始模型，再转换为 GGUF，最后执行量化。

# install Python dependencies
python3 -m pip install -r requirements.txt

# convert the model to ggml FP16 format
python3 convert_hf_to_gguf.py ./models/mymodel/

# quantize the model to 4-bits (using Q4_K_M method)
./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M

量化完成后，就可以直接用 llama-cli 加载新的 GGUF 文件：

1
2

# start inference on a gguf model
./llama-cli -m ./models/mymodel/ggml-model-Q4_K_M.gguf -cnv -p "You are a helpful assistant"

常见参数

--allow-requantize：允许对已经量化过的模型再次量化，但通常不推荐，质量可能掉得比较明显
--leave-output-tensor：保留输出层不量化，体积会更大，但有时能换来更好的质量
--pure：关闭混合量化，让更多张量使用同一量化类型
--imatrix：使用重要性矩阵优化量化效果，通常值得优先考虑
--keep-split：保留输入模型的分片结构，而不是合并成单个文件

如果只是想先跑起来，最实用的起点还是：

`1`	`./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M`

量化怎么选

可以先把不同量化等级理解成“体积、速度和质量之间的交换”：

Q8_0：体积较大，但质量通常更稳
Q6_K / Q5_K_M：常见的平衡型选择
Q4_K_M：很常见的默认档，体积和效果通常比较均衡
Q3 / Q2：适合资源非常紧张的场景，但质量下降会更明显

从给出的示例数据看，量化等级越低，模型通常越小；而在实际推理里，更高精度并不一定总是更快，所以选型重点通常不是“越大越好”，而是“在你的硬件上够稳、够省、效果也能接受”。

实用建议

优先从 Q4_K_M 或 Q5_K_M 开始试
如果更看重质量，再往 Q6_K 或 Q8_0 提升
如果机器资源比较紧，再尝试 Q3 或 Q2
最好始终用同一批测试问题比较不同量化版本

一句话总结：llama-quantize 的核心价值，不是单纯把模型变小，而是让 GGUF 模型在本地设备上更容易跑起来。

Hugging Face 选择 Llama 的 GGUF 模型时，量化怎么选：从 Q8 到 Q2 的实用建议

Sat, 11 Apr 2026 20:07:29 +0800

在 Hugging Face 选择 Llama 的 GGUF 模型时，可以先把量化等级理解成“分辨率”。分辨率越低，占用的 VRAM/RAM 越少，但质量也会逐步下降。

先理解 32、16 和 Q 系列

32：可理解为原始未压缩版本，质量最高，但硬件要求非常高。
16：仍接近原始质量，体积约为 32 的一半，实用性更高。
Q8：从这里开始进入量化版本，通常写作 Q8_0 或 Q8。
Q6、Q5、Q4、Q3、Q2：数字越小，资源占用越低，质量也越容易出现可见损失。

`K_M` / `K_S` 是什么

K_M 和 K_S 表示混合量化策略：

大部分权重使用当前量化等级
一些关键部分保留更高精度

因此同级别下，Qx_K_M 或 Qx_K_S 通常会比纯 Qx 略好。

实用选型建议

硬件足够：优先 Q8。
显存或内存紧张：逐级下调到 Q6 / Q5 / Q4。
下限建议：尽量不要低于 Q4，优先 Q4_K_M。
Q3 及以下：质量下降会越来越明显。

质量梯度（高到低）

32
16

– 在这一点之上，质量是一样的，但是硬件要求太疯狂了 –

Q8
Q6_K_M
Q6_K_S
Q6
Q5_K_M
Q5_K_S
Q5

– 这是典型的甜蜜点 –

Q4_K_M
Q4_K_S
Q4

– 在这一点之下，质量下降变得可见 –

Q3_K_M
Q3_K_S
Q3
Q2_K_M
Q2_K_S
Q2

如果你只想要一个简单结论：多数场景从 Q8 或 Q6_K_M 起步，不够再降到 Q5 或 Q4_K_M，通常更稳妥。

大模型量化详解：FP16、Q8、Q5、Q4 到 Q2 怎么选？

Sun, 05 Apr 2026 22:09:11 +0800

量化的核心目标很简单：用少量精度损失，换取更小体积、更低显存占用和更快推理速度。
对本地部署用户来说，选对量化版本，往往比盲目追求大参数更重要。

什么是量化

量化是指把模型参数从高精度格式（如 FP16）压缩为更低位宽格式（如 Q8、Q4）。

可以把它理解为：

原始模型：像高精度照片，清晰但文件大。
量化模型：像压缩照片，细节略损但更轻更快。

常见量化版本对比

量化版本	精度/位宽	体积	质量损失	推荐场景
FP16	16 位浮点	最大	几乎无损	研究、评测、追求极致质量
Q8_0	8 位整数	较大	几乎无损	高配电脑，兼顾质量与性能
Q5_K_M	5 位混合	中等	轻微损失	日常主力，平衡方案
Q4_K_M	4 位混合	较小	可接受损失	通用默认，性价比高
Q3_K_M	3 位混合	很小	明显损失	低配设备，能跑优先
Q2_K	2 位混合	最小	较大损失	极限资源场景，临时可用

量化命名规则

以 gemma-4:4b-q4_k_m 为例：

gemma-4:4b：模型名称与参数规模。
q4：4 位量化。
k：K-quants（改进量化方法）。
m：medium（中等级别，常见还有 s/small、l/large）。

如何按显存快速选型

内存/显存	推荐量化
4 GB	Q3_K_M / Q2_K
8 GB	Q4_K_M
16 GB	Q5_K_M / Q8_0
32 GB+	FP16 / Q8_0

建议先从能稳定跑起来的版本开始用，再逐步提高精度，而不是一上来就追求最大模型。

实战建议

默认从 Q4_K_M 开始，先验证真实任务效果。
如果答案质量不够，再升到 Q5_K_M 或 Q8_0。
如果主要瓶颈是显存或速度，再降到 Q3_K_M。
每次切换量化版本，都用同一批测试问题做对比。

结论

质量优先：FP16 或 Q8_0。
平衡优先：Q5_K_M。
通用默认：Q4_K_M。
低配兜底：Q3_K_M 或 Q2_K。

选型的本质不是“越大越好”，而是“在你的硬件条件下，达到最稳定可用的效果”。

量化 on KnightLi的博客

AI-Trader 是什么？一个让 AI Agent 发布交易信号、做模拟交易的平台

它的定位

主要功能

两类用户

架构结构

为什么值得关注

风险和边界

适合谁

小结

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

先看结论

官方权重体积

Qwen3.6-27B 显存表

Qwen3.6-35B-A3B 显存表

27B 和 35B-A3B 怎么选

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

怎么选

参考来源

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

先看结论

官方权重体积

DeepSeek V4 Flash 显存估算

DeepSeek V4 Pro 显存估算

DeepSeek V4 Flash-Base 显存估算

DeepSeek V4 Pro-Base 显存估算

为什么不能只看 active params

怎么选

参考来源

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

先看结论

Gemma 4 E2B 显存表

Gemma 4 E4B 显存表

Gemma 4 26B A4B 显存表

Gemma 4 31B 显存表

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

怎么选

参考来源

16G 显卡也能跑 35B 模型：LM Studio 下 MoE 模型的显存压缩思路

01 为什么 16G 显卡不一定只能跑 12B 到 14B

02 实测重点：35B MoE 模型可以跑得很快

03 在 LM Studio 里，重点不只一个参数

04 128K 上下文下也能跑，缩小上下文还能继续压显存

05 这种方法的代价：对系统内存和虚拟内存要求更高

06 量化版本也不是越激进越好

07 哪些模型思路值得试

08 简单总结

llama-quantize 怎么用：GGUF 模型量化入门

基本用法

常见参数

量化怎么选

实用建议

Hugging Face 选择 Llama 的 GGUF 模型时，量化怎么选：从 Q8 到 Q2 的实用建议

先理解 32、16 和 Q 系列

K_M / K_S 是什么

实用选型建议

质量梯度（高到低）

大模型量化详解：FP16、Q8、Q5、Q4 到 Q2 怎么选？

什么是量化

常见量化版本对比

量化命名规则

如何按显存快速选型

实战建议

结论

`K_M` / `K_S` 是什么