在6GB RTX 4050上对20个小LLM的基准测试

我正在寻找可以在我的GPU上运行并能实际做一些有用事情的模型。我认为任何微小的差异都可能带来“巨大”的改进，因为它们都这么小。所以我去了LM Studio数据库，搜索了同一家族的许多变体，试图选择较新的模型。然后让Claude选择已知的基准测试并运行一些定性测试。现在我将尝试用真实用例进行测试，然后选择一个“团队”。大多数人在本地使用更强大的机器，但大部分人只有6GB GPU。因此这篇评测可能会对他们有所帮助。以下是报告内容： **问题所在** 我希望本地模型能在6GB笔记本GPU上完成重复性的夜间工作（文件整理、标签分类、日志筛选）——零成本、私密、无速率限制。真正的问题不是“哪个模型最好”，而是“这些特定的量化版本中哪一个实际适合6GB并能在*我的*任务上正确表现”。排行榜分数无法回答这个问题：它们是在全精度权重和通用基准上运行的，而不是你实际会加载的Q4/Q6 GGUF。 **为什么使用定性探针而不是完整的基准套件** 在单个6GB GPU上跨20个模型运行BFCL-v3/v4 + IFEval + MMLU需要数天到一周的计算时间，而且大部分信号已经在每个模型家族中*发布*了。没有发布的是特定量化版本在你所需的确切行为上的表现。因此我建立了一个固定的6探针集来针对这些行为——(1) 可解析的工具调用，(2) 多轮工具调用（是否能链式使用真实工具结果还是幻觉占位符），(3) 严格JSON，(4) 指令遵循（IFEval风格），(5) 计划分解，(6) 无路径幻觉，外加一个GSM8K风格的算术检查——直接判断输出，并与已发布的BFCL/IFEval交叉对比以捕获量化级别的回归。这样就把一周缩短到约1小时，并测试了真正重要的东西。然后单独进行性能测试，测量了1k/8k/32k上下文下的预填充（提示处理）速度和生成tok/s，每个设置N=5，使用LM Studio的OpenAI兼容API。 **20个模型** Granite 4.1 3B（lmstudio-community, unsloth, nikolaykozloff Q6/Q8）· Granite-3B-function-calling-xLAM (Salesforce/unsloth) · Granite-3B-sft-claude-opus-reasoning · Granite 4.1 8B · Granite 4.1 8B base · LFM2.5-8B-A1B（liquidai官方, unsloth, RemySkye-i1）· Gemma-4-e2b（google base, agentic, ×opus-4.7-turbo, ×deepseek-v4）· LFM2.5-1.2B-Instruct · LFM2.5-VL-1.6B（liquidai, unsloth）· Qwen3.5-4B（base, claude-4.6-opus-reasoning-distilled）· Nemotron-3-Nano-4B。 **结果**（生成tok/s，N=5，σ<2.5贯穿始终；VRAM = 完整GPU负载）： | 模型 | VRAM | @1k | @8k | @32k | 最大上下文(GPU) | 备注 | |---|---|---|---|---|---|---| | lfm2.5-1.2b-instruct | 1.9G | 129 | 118 | 102 | 256k | 干净，快速 | | unsloth/lfm2.5-vl-1.6b | 3.0G | 207 | 182 | 142 | 128k | 总体最快（视觉） | | liquidai/lfm2.5-vl-1.6b | 2.7G | 128 | 115 | 100 | 256k | 视觉 | | liquidai/lfm2.5-8b-a1b | 5.4G | 99 | 97 | 90 | 64k | MoE，32k下表现良好 | | unsloth/lfm2.5-8b-a1b | 4.6G | 121 | 112 | 102 | 128k | 快速但会丢失文件 | | lfm2.5-8b-a1b-i1 | 5.4G | 108 | 99 | 95 | 32k | 推理变体 | | gemma-4-agentic-e2b | 2.4G | 82 | 78 | 70 | 256k | 最轻量，保持32k | | google/gemma-4-e2b (base) | 3.6G | 78 | 79 | 69 | 256k | 基础，有噪声 | | gemma-4-e2b×opus-turbo | 2.4G | 82 | 78 | 71 | 256k | 聊天模板损坏 | | gemma4-e2b-deepseek | 2.4G | 83 | 78 | 71 | 256k | 幻觉路径 | | unsloth/granite-4.1-3b | 4.8G | 70 | 60 | 40 | 32k | 质量≈8B | | granite-3b-xLAM (fc) | 4.8G | 71 | 61 | 41 | 32k | 相比基础3B无优势 | | lmstudio/granite-4.1-3b | 4.9G | 66 | 59 | 42 | 32k | 稳定的基线 | | granite-3b-sft-reasoning | 4.8G | 68 | 58 | 39 | 32k | 推理开销 | | nikolaykozloff/granite-3b | 4.6G | 45 | 40 | — | 24k | 幻觉函数名 | | nvidia/nemotron-3-nano-4b | 3.7G | 58 | 56 | 48 | 128k | 上下文退化最小 | | qwen3.5-4b-distilled | 5.1G | 52 | 50 | 43 | 32k | 推理，冗长 | | qwen3.5-4b (base) | 5.6G | 52 | 49 | 43 | 32k | 不错，无特别 | | granite-4.1-8b base | 5.1G | 38 | 32 | — | ~10k | 基础，幻觉 | | granite-4.1-8b | 5.6G | 28 | 25 | — | ~10k | 慢 + 上下文受限 | 三个跨领域发现： (a) **推理调优的模型有代价，但不会失败** —— 在紧凑的token上限下它们看起来有问题（中途被截断），但给足空间后它们能正确回答，消耗2–3倍的token；这是批处理工作的延迟/成本信号，不是质量理由去排除它们（尽管有两个在开放式分解中即使预算充足也丢失了一个文件）。 (b) **第三方微调是地雷** —— 幻觉函数名、损坏的jinja聊天模板（多轮工具调用直接无效）、幻觉路径；基础/官方指令版本始终更安全。 (c) **上下文开销真实且均匀** —— 每个模型从1k到32k的生成速度下降约20–35%，且N=5测试中没有热节流。 **推荐选择** **LFM2.5-1.2B-Instruct** —— 廉价、始终在线的模型。1.9GB VRAM，1.5s加载，129 tok/s，在JSON/指令遵循/无幻觉探针上表现干净。其孱弱的规划能力对于低风险常驻角色无关紧要。整体中预填充最快（8k下约8.5k tok/s），因此能几乎瞬间处理短输入。 **Granite-4.1-3B (instruct)** —— 质量与VRAM的基准线。在我的探针上输出质量与Granite-8B相当，但速度是2–3倍（8k下60 tok/s vs 25），并且是唯一能干净保持32k上下文的密集3B模型。值得注意的是，"function-calling-xLAM"微调在测试多轮时**没有**优势——单轮中它链式调用工具更好的印象在多轮探针下完全崩溃。使用普通指令版本。 **Gemma-4-agentic-e2b** —— 惊喜。仅2.4GB VRAM（这里最轻的非平凡模型），保持256k上下文，在32k下维持70 tok/s并具有高预填充速度（~3.8k tok/s）。它给出了干净、完整的分解计划。这是唯一一个足够灵活可以充当轻量级编排器或快速工作者的模型，这在6GB中角色切换时很重要。 **Nemotron-3-Nano-4B** —— 长上下文工作者。短上下文下较慢（1k下58 tok/s），但**退化最少**——32k下仍有48 tok/s，而Granite-3B跌至约41——仅占用3.7GB和128k上限。当工作者需要一次性读取大输入时是最佳选择。 **LFM2.5-8B-A1B (liquidai)** —— 编排器，也是头条结果。这个8B/1B活跃MoE在32k上下文下达到**90 tok/s**，占用约5.4GB。明显的密集替代品Granite-8B在相同VRAM下只能达到25–28 tok/s并限制在约10k上下文——所以MoE速度快3–4倍，可用上下文多3倍。我也测试了unsloth版本（更快，102 tok/s和128k上下文），但即使在慷慨的token预算下它也在开放式分解中丢失了一个文件，因此官方liquidai版本在完整性上胜出；unsloth保留作为速度备用。 **总结** 在你自己的量化版本和你自己的任务上做基准测试——已发布的分数不会捕获损坏的聊天模板或幻觉函数名的量化版本。在VRAM受限硬件上，MoE远超其参数数量所暗示的性能。而一个紧凑、有针对性的探针集通过人工判断，能让你在一小时内获得可靠的决策，而不是一周的GPU时间。