---

本文通过解析Qwen官方多个LLM模型对比评测的数据，
加上v观察并描述本地语言模型通过调用工具完成任务的情况。
试图展现出本地LLM模型的能力和差别。

（零）前言

出于兴趣，我当上了C级英雄……
啊不，好像应该是我做了两个开源小项目：

有个是基于RAG的企业知识库，这玩意儿其它部分比较难，本来想写的文章也一直写不下去。
但对于LLM这边只存在回答得好不好，不容易失败，上下文够就行。
另一个是基于OpenCLI的个人小助理，没设置任何类似Langgraph的流程，直接把工具和问题丢给LLM。

记得仅仅是2年前，好像当时是GPT3.5到4o的时代。
类似的项目LLM会比较难以控制工具，只能人为的定制比较复杂的流程。
否则至少GPT3.5特别容易无限工具循环。
只有4o比较稳健的能够调用工具 —— 当时那可是最厉害的云端大模型。

两年过去了，别说云端，就算本地消费级显卡上的小模型，也能hold住复杂的工具调用了。

因为最开始就是冲着要全部本地跑，为了选出最适合的模型，我逐渐变成了报脸下载狂……

（一）模型理论评测

本地能用起来的LLM，如果不是土豪级别的配置，目前几乎只有Qwen3.6/3.5和Gemma4。

（1.1）Qwen与Gemma对比

先看看理论评测，数据是Qwen模型页面的，所以不用看也知道Qwen赢。
不过还是让我们看看，到底怎么个赢法。

评测项 \ 模型	Qwen3.5-27B	Gemma4-31B	Qwen3.5-35BA3B	Gemma4-26BA4B	Qwen3.6-35BA3B
SWE-bench Verified	75.0	52.0	70.0	17.4	73.4
SWE-bench Multilingual	69.3	51.7	60.3	17.3	67.2
SWE-bench Pro	51.2	35.7	44.6	13.8	49.5
Terminal-Bench 2.0	41.6	42.9	40.5	34.2	51.5
Claw-Eval Avg	64.3	48.5	65.4	58.8	68.7
Claw-Eval Pass^3	46.2	25.0	51.0	28.0	50.0
SkillsBench Avg5	27.2	23.6	4.4	12.3	28.7
QwenClawBench	52.2	41.7	47.7	38.7	52.6
NL2Repo	27.3	15.5	20.5	11.6	29.4
QwenWebBench	1068	1197	978	1178	1397
TAU3-Bench	68.4	67.5	68.9	59.0	67.2
VITA-Bench	41.8	43.0	29.1	36.9	35.6
DeepPlanning	22.6	24.0	22.8	16.2	25.9
Tool Decathlon	31.5	21.2	28.7	12.0	26.9
MCPMark	36.3	18.1	27.0	14.2	37.0
MCP-Atlas	68.4	57.2	62.4	50.0	62.8
WideSearch	66.4	35.2	59.1	38.3	60.1
MMLU-Pro	86.1	85.2	85.3	82.6	85.2
MMLU-Redux	93.2	93.7	93.3	92.7	93.3
SuperGPQA	65.6	65.7	63.4	61.4	64.7
C-Eval	90.5	82.6	90.2	82.5	90.0
GPQA	85.5	84.3	84.2	82.3	86.0
HLE	24.3	19.5	22.4	8.7	21.4
LiveCodeBench v6	80.7	80.0	74.6	77.1	80.4
HMMT Feb 25	92.0	88.7	89.0	91.7	90.7
HMMT Nov 25	89.8	87.5	89.2	87.5	89.1
HMMT Feb 26	84.3	77.2	78.7	79.0	83.6
IMOAnswerBench	79.9	74.5	76.8	74.3	78.9
AIME26	92.6	89.2	91.0	88.3	92.7

先看看Dense稠密模型在评测中的表现：

• Qwen3.5-27B：Agent，编程，中文大幅领先。
• Gemma4-31B：知识问答接近，数学略弱，多模态略强。

再来看看MoE混合专家模型的情况

• Qwen3.5-35B-A3B：编程，软件工程，Agent，搜索，MCP，中文大幅度领先。
• Gemma4-26B-A4B：网页理解，多模态，部分视觉Agent领先。

✋Gemma视觉部分领先是之前例子《本地跑LLM模型哪家强：Qwen3.5+3.6 vs Gemma4 的个人实测》中遇到过的，可能正好碰上了，那张稍微模糊的图片，Qwen怎么都要看错。

噢忘了，最后看看MOE的Qwen3.6，它对比3.5的优化方向也非常明显，
强化 Coding Agent 和 Web Agent。并没有继续强化纯知识推理部分。

💡结论，Qwen在大多数方面都领先Gemma，有些方面领先幅度巨大。

（1.2）小模型与大模型对比

数据是也Qwen模型页面的。
这次没法全赢，因为加入了不是同一级别的对比对象。

评测项 \ 模型	Qwen3.5-27B	Qwen3.5-397B-A17B	Gemma4-31B	Claude 4.5 Opus	Qwen3.6-35B-A3B	Qwen3.6-27B
SWE-bench Verified	75.0	76.2	52.0	80.9	73.4	77.2
SWE-bench Pro	51.2	50.9	35.7	57.1	49.5	53.5
SWE-bench Multilingual	69.3	69.3	51.7	77.5	67.2	71.3
Terminal-Bench 2.0	41.6	52.5	42.9	59.3	51.5	59.3
SkillsBench Avg5	27.2	30.0	23.6	45.3	28.7	48.2
QwenWebBench	1068	1186	1197	1536	1397	1487
NL2Repo	27.3	32.2	15.5	43.2	29.4	36.2
Claw-Eval Avg	64.3	70.7	48.5	76.6	68.7	72.4
Claw-Eval Pass^3	46.2	48.1	25.0	59.6	50.0	60.6
QwenClawBench	52.2	51.8	41.7	52.3	52.6	53.4
MMLU-Pro	86.1	87.8	85.2	89.5	85.2	86.2
MMLU-Redux	93.2	94.9	93.7	95.6	93.3	93.5
SuperGPQA	65.6	70.4	65.7	70.6	64.7	66.0
C-Eval	90.5	93.0	82.6	92.2	90.0	91.4
GPQA Diamond	85.5	88.4	84.3	87.0	86.0	87.8
HLE	24.3	28.7	19.5	30.8	21.4	24.0
LiveCodeBench v6	80.7	83.6	80.0	84.8	80.4	83.9
HMMT Feb 25	92.0	94.8	88.7	92.9	90.7	93.8
HMMT Nov 25	89.8	92.7	87.5	93.3	89.1	90.7
HMMT Feb 26	84.3	87.9	77.2	85.3	83.6	84.3
IMOAnswerBench	79.9	80.9	74.5	84.0	78.9	80.8
AIME26	92.6	93.3	89.2	95.1	92.7	94.1

虽然模型和内容很多，但整个数据其实都在说一件事儿，Qwen3.6-27B Dense 究竟到了什么水平？
它和规模相差十倍的 Qwen3.5-397B-A17B、和Claude 4.5 Opus 这种顶级模型还有多大差距？

实际数据体现了它平均吧，居然有Claude 4.5 Opus大概90%以上的功力。在Agent、代码、数学几个核心领域，开始直追着 Claude 4.5 Opus 跑，在很多项目上居然超过了 Qwen3.5-397B-A17B 这种超大MoE模型。

这和社区用户的感觉是一样的，大家都把Qwen3.6-27B当作目前开源小模型最强。
只要硬件跑得动，对蹦出字的速度没太大要求（Qwen有集成MTP的版本啊）。
如果应用场景不是太刁难模型呢，Qwen3.6-35B-A3B 则是速度飞快。

💡结论，Qwen3.6-27B参数虽小，但能力接近大模型。

（1.3）量化损失

等等，刚才那些数据，都是BF16的完整模型啊。
我们跑的可是很小的GGUF。

借用一张图来看看量化带来的质量损失。
这里的原版100%已经是砍一刀后的Qwen3.6-28B-A3B模型了。
如果对比原版BF16模型，还不知道到底损失了多少呢……

有种说法是，不要用量化到Q3以下的模型，能力损失太大。
所以我的硬件配置大概只够i1-IQ3_S，71%能力。

（二）模型实测表现

和社区用户的刁钻测试，复杂程序的完整实现，逻辑陷阱不同。
我这里的场景其实是很简单的：给了LLM几个工具，可以调用OpenCLI的指令。

这个程序🔗个人小助理不耗显存，如果用企业知识库RAG，则向量数据库那边还要显存，资源更加不够。
类似这种工具调用应该是不需要推理的，基本理解能力就够了，无推理理论上效果会更好（至少更快）。

对于Qwen和Gemma来说，更小级别的模型都可以完成工作。
但是其它一些模型，不知道为什么却很难完成。

硬件环境: Intel i9-12900F + 64GB(DDR4-3000) + 4060Ti-16GB。
软件环境: Windows 11 专业版 25H2 LLM后端: llama.cpp。

测试内容：

• 用户要求：

帮我查查后天从成都到北京的火车。找到G字头、有二等座、最快的车次。查询那趟车的票价和停站详情。

• 可用网站：
  1. 为了节约不必要的开销，已经通过提示词给了。
• 可用工具：
  1. 获取当天日期：today_date() ：后期取消了工具，通过提示词给了。
  2. 站点指令帮助：site_help(site)
  3. 执行完整指令：cmd_exec(full_cmd)

模型都是选的我的硬件大概Hold住的模型，都是用的显存够的版本。
对于大模型来说很可能有量化过度的风险。
模型的温度都是0.1，其它默认，通常不开推理，除非必须开才能过。

💡测多了发现所有的模型，都无法在各种情况下，连续多次全部通过（包括表现最好的Ornith）。
也就是说逐渐的变成了各种Benchmark里的"通过率"。但大量重复测试不现实，也没必要，不如去看专业的评测分数。我不准备改结论的通过与否。重点看简评吧。

（2.1）Qwen 3.6/3.5 系列

（2.1.1） Qwen3.5-88B-A10B-IQ3xxs (31.8GB) ✅

• 结论：通过✅
• 工具：5轮。

更新：超纲模型的砍一刀版本(原本是122B)，运行起来仅模型就用了19GB共享显存(内存)。
如果再量化狠点，则模型可能识字都会弄错，所以这是最小能接受版本。
加入的原因是后面测了几个大些的模型都不靠谱，就试试Qwen咯，结果没让人失望！！！
可以关闭推理，但有时会混合token和tool输出。

• 关闭推理：最少步骤完成，取日期，查车次列表，查票价，查详情。回答完整且简介。
• 打开推理：完成情况同上。推理正确不啰嗦不重复。

运行日志(模范样本)：

[2026-06-21 15:51:55.578] [Question] 帮我查查后天从成都到北京的火车。找到G字头、有二等座的、最快的车次。查询那趟车的票价和停站详情。
[2026-06-21 15:51:55.582] [Service] LLM provider: http://127.0.0.1:8999/v1
[2026-06-21 15:51:55.931] [开始] 收到用户指令并开始处理……  <349ms>
[2026-06-21 15:52:10.292] [工具] (1.1) today_date →  <14.36s>
[2026-06-21 15:52:10.295] [工具] (1.1) today_date ← (12) "2026-06-21"
[2026-06-21 15:52:22.780] [工具] (2.1) site_help → {'site': '12306'}  <12.48s>
[2026-06-21 15:52:23.127] [工具] (2.1) site_help ← (3859) {"command_count": 9, "commands": [{"name": "login", "usage": "opencli 12306 login ", "siteSession": "pers...  <346ms>
[2026-06-21 15:52:42.924] [工具] (3.1) cmd_exec → {'full_cmd': '12306 trains 成都 北京 --date 2026-06-23', 'result_limit': 100}  <19.80s>
[2026-06-21 15:52:43.770] [工具] (3.1) cmd_exec ← (4541) [{"train_no": "760000G32200", "code": "G322", "from_station": "成都东", "to_station": "北京西", "from_code": "ICW"...  <845ms>
[2026-06-21 15:53:09.704] [工具] (4.1) cmd_exec → {'full_cmd': '12306 train 760000G32200 --from 成都东 --to 北京西 --date 2026-06-23'}  <25.93s>
[2026-06-21 15:53:10.387] [工具] (4.1) cmd_exec ← (686) [{"station_no": "01", "station_name": "成都东", "arrive_time": "", "start_time": "06:55", "stopover_time": ""}, {"s...  <683ms>
[2026-06-21 15:53:38.759] [工具] (5.1) cmd_exec → {'full_cmd': '12306 price 760000G32200 --from 成都东 --to 北京西 --date 2026-06-23'}  <28.37s>
[2026-06-21 15:53:39.544] [工具] (5.1) cmd_exec ← (389) [{"seat_code": "A9", "seat_name": "商务座", "price": "2606.5", "currency": "CNY"}, {"seat_code": "P", "seat_name": ...  <785ms>
[2026-06-21 15:54:03.536] Streaming...  <23.99s>
根据查询结果，后天（2026年6月23日）从成都到北京的火车中，**G322** 是符合您要求（G字头、有二等座、最快）的车次。

### 车次信息
- **车次号**: G322
- **出发站**: 成都东
- **到达站**: 北京西
- **出发时间**: 06:55
- **到达时间**: 14:26
- **全程耗时**: 7小时31分钟
- **二等座票价**: 832.5 元

### 停站详情
1. **成都东** (06:55 发车)
2. **西安北** (10:05 到达, 10:09 发车, 停留4分钟)
3. **洛阳龙门** (11:24 到达, 11:26 发车, 停留2分钟)
4. **郑州东** (12:04 到达, 12:07 发车, 停留3分钟)
5. **石家庄** (13:23 到达, 13:25 发车, 停留2分钟)
6. **北京西** (14:26 到达)

这是目前查询到的从成都到北京最快的G字头列车，且提供二等座服务。如果您需要其他信息或帮助，请告诉我！

Retrieval: 127605.11 ms, Answers: 25926.89 ms, Total: 153531.99 ms
Prompt Tokens: 28471, Completion Tokens: 627 <Qwen3.5-88B-A10B-IQ3xxs> <24.18 tokens/s>

（2.1.2） Qwen3.6-27B-IQ3xxs-MTP (11.3GB) ✅

• 结论：通过✅
• 工具：5轮。

按照前面的推断，那么这是16GB级别 “最靠谱模型的最低能接受量化” 版本。

• 无法完全关闭推理，关闭则把推理文字输出在普通token中。
• 关闭推理：最少步骤完成，取日期，查车次列表，查票价，查详情。
• 打开推理：正常时同上，但偶现不回答。

日志性能部分：

Retrieval: 48735.25 ms, Answers: 16976.58 ms, Total: 65711.83 ms
Prompt Tokens: 30121, Completion Tokens: 866 <Qwen3.6-27B-IQ3XXS-MTP> <51.0 tokens/s>

（2.1.3） Qwen3.6-35b-A3B-MQ2-MTP (11.7GB) ✅

• 结论：通过✅
• 工具：4 or 6轮。

最快专家模型：

• 可以关闭推理。
• 关闭推理：弄错了参数，后一步马上修正，所以多用了一步，无逻辑问题。
• 打开推理：没有错误，并且规划同一轮查询了票价和详情，只用4轮完成。

日志性能部分：

Retrieval: 23763.72 ms, Answers: 3089.21 ms, Total: 26852.93 ms
Prompt Tokens: 36020, Completion Tokens: 615 <Qwen3.6-35b-A3B-MQ2> <199.03 tokens/s>

（2.1.4） Qwen3.5-9B-UD-Q4_K_XL-MTP (5.7GB) ✅

• 结论：通过✅
• 工具：5轮。

小模型，之前别的场景容易无限循环，但此场景完美完成。

• 无法完全关闭推理，关闭则把推理文字输出在普通token中。
• 关闭推理：最少步骤完成，取日期，查车次列表，查票价，查详情。
• 打开推理：同上。

日志性能部分：

Retrieval: 16995.47 ms, Answers: 8070.37 ms, Total: 25065.84 ms
Prompt Tokens: 29457, Completion Tokens: 791 <Qwen3.5-9B-UD-Q4_K_XL-MTP> <98.02 tokens/s>

（2.1.5） Qwen3.5-4B-IQ4_NL-MTP (2.5GB) ⚠️

• 结论：部分通过⚠️
• 工具：5轮。

既然Qwen前面都通过，就继续换更小的模型。
有时能通过，但是无法稳定。

• 有时完美完成，没有任何多余重复指令，没有指令错误。
• 有时会弄有幻觉，没有查询，自己编造了个18元的票价。
• 无法关闭输出推理过程，且输出到普通token中。

日志性能部分：

Retrieval: 11360.87 ms, Answers: 4247.08 ms, Total: 15607.94 ms
Prompt Tokens: 23474, Completion Tokens: 787 <Qwen3.5-4B-IQ4_NL-MTP> <185.18 tokens/s>

衍生模型情况：

• Qwopus3.5-4B-Coder-MTP-Q8_0：关闭推理无法进行，开启推理步骤全正确，但结论错误。
• Qwopus3.5-4B-v3-MTP-Q8_0：无法关闭推理，步骤全正确，偶尔结论错误。

错误非常奇怪，在过程全对以及数据完整的情况下，有时分不清楚最快的车次。

（2.1.6） Qwen-AgentWorld-35B-A3B-IQ3s (13.9GB) ✅

• 结论：通过✅
• 工具：6轮。

是阿里通义千问团队在2026年6月24日发布的首个"原生语言世界模型"（Language World Model）。它不是一个直接执行任务的AI智能体，而是一个能模拟环境会如何反应的"世界模拟器"。简单说，它接收智能体的动作，比如点击、输入命令。然后预测环境将返回什么，比如网页变化、终端输出。

但是当普通模型也能用啊……

• 无法完全关闭推理，关闭则把推理文字输出在普通token中。
• 关闭推理：多查了车站信息，无其它多余步骤，取日期，查车次列表，查票价，查详情。
• 多次查询不同的情况，似乎都没出错耶。

日志性能部分（已更新，接近服务端统计数据，准确了很多）：

Retrieval: 4060.41 ms, Answers: 14750.89 ms, Total: 43683.26 ms
Prompt Tokens: 41976, Completion Tokens: 1075, <Qwen-AgentWorld-35B-A3B-IQ3s> <72.88 tokens/s>

---

（2.2）Gemma-4 系列

全部换回非QAT模型重新测试，表现正常了许多。

（2.2.1） gemma-4-31B-it-UD-IQ3XXS (11.0GB) ✅

• 结论：通过✅
• 工具：5轮。

Gemma最强的稠密模型，偏慢，用了MTP。

• 正确，无多余指令，无任何理解错误。
• 偶然遇到12306的临时错误时，会分析并另外想办法。

日志性能部分：

Retrieval: 42538.22 ms, Answers: 10648.35 ms, Total: 53186.58 ms
Prompt Tokens: 20598, Completion Tokens: 571 <gemma-4-31B-it-UD-IQ3XXS> <53.62 tokens/s>

（2.2.2） gemma-4-26B-A4B-it-UD-IQ3_S (10.5GB) ✅

• 结论：通过✅
• 工具：5轮。

Gemma最强的专家模型，速度快，用了MTP。

• 正确，无多余指令，无任何理解错误。
• 偶然遇到12306的临时错误时，未取得部分信息，如实告知了用户。

日志性能部分：

Retrieval: 17406.03 ms, Answers: 3788.38 ms, Total: 21194.41 ms
Prompt Tokens: 20485, Completion Tokens: 511 <gemma-4-26B-A4B-it-UD-IQ3_S> <134.83 tokens/s>

（2.2.3） gemma-4-12b-it-IQ4_NL (6.3GB) ✅

• 结论：通过✅
• 工具：5轮。

Gemma最新模型，可以输入音频，用了MTP。

• 正确，无多余指令，无任何理解错误。
• 遇到了12306的临时错误时，可以自动调整查询，并给出结果。

日志性能部分：

Retrieval: 31728.83 ms, Answers: 6202.41 ms, Total: 37931.24 ms
Prompt Tokens: 31393, Completion Tokens: 704 <gemma-4-12b-it-IQ4_NL> <113.55 tokens/s>

（2.2.4） gemma-4-E4B-it-IQ4_NL (4.5GB) ⚠️

• 结论：部分通过⚠️
• 工具：3轮。

小模型反而更加遵守提示词，按部就班。为了它能理解，问题写得更加详细了:

帮我查查12306，明天，从成都到北京的火车。尽可能多查些条数，找到G字头有二等座的最快的车次。查询那趟车的票价和停站详情。直接查无需我确认。

• 比E2B好些，基本能理解对，指令参数错误可以纠正。
• 最终结果稍有问题，答案给的不是最快的那班列车，原因不明（但不离谱）。

日志性能部分：

Retrieval: 18249.96 ms, Answers: 14659.96 ms, Total: 32909.92 ms
Prompt Tokens: 29071, Completion Tokens: 1328 <gemma-4-E4B-it-IQ4_NL> <90.59 tokens/s>

（2.2.5） gemma-4-E2B-it-IQ4_NL (2.8GB) ❌

• 结论：未通过❌
• 工具：3轮。

Gemma最小模型，可用于移动端，比如手机，iPad等。
必须开推理，否则没机会。在极度的详细提示后可以部分完成。
小模型反而更加遵守提示词，按部就班。为了它能理解，问题写得更加详细了:

帮我查查12306，明天，从成都到北京的火车。尽可能多查些条数，找到G字头有二等座的最快的车次。查询那趟车的票价和停站详情。直接查无需我确认。

• 不太理解用户问题的含义，指定12306后，又不懂什么是G字头等等。
• 总是喜欢停下来等用户确认，偶尔可以查询，但很难返回一次正确答案。

日志性能部分：

Retrieval: 11214.75 ms, Answers: 3257.59 ms, Total: 14472.34 ms
Prompt Tokens: 21768, Completion Tokens: 1057 <gemma-4-E2B-it-IQ4_NL> <324.23 tokens/s>

（2.3）其它模型

（2.3.1）granite-4.1-30b-UD-IQ3_XXS (10.5GB) ⚠️

• 结论：部分通过⚠️
• 工具：5轮。
• 原因：幻觉编造信息。

是IBM在2026年4月29日正式发布的一系列面向企业级应用的开源大模型。它的核心特点是性能强大但参数规模小巧，旨在以更低的成本、更高的效率，在企业任务上对标甚至超越规模更大的模型。

• 工具正常时，无重复调用，汉字似乎会有神奇的错误（很像人写错字）。
• 工具返回有误时，编造了一些可能是自己知道的内容，没有如实反馈工具调用出错。
• 速度非常慢，和文件体积，显存占用不成比例。
• 更小的granite-4.1-8b-IQ4_NL无法通过，工具都对，但回答的车次错误。

日志性能部分：

Retrieval: 63924.3 ms, Answers: 117967.0 ms, Total: 181891.3 ms
Prompt Tokens: 20266, Completion Tokens: 1151 <granite-4.1-30b-UD-IQ3_XXS> <9.76 tokens/s>

（2.3.2）JoyAI-LLM-Flash-IQ3_XS (18.7GB) ✅

• 结论：通过✅
• 工具：11轮。（旧版程序）

是的，你没看错，京东！京东！京东！
它京东于2026年2月开源的一款中等规模MoE大模型，主打“Token效率”（用更少的计算资源完成任务），也是京东近期力推的AI智能体产品矩阵 “龙虾天团” 的核心技术底座。似乎它是一个基于Deepseek V3 的模型？

PS: 京东最近还开源了基于LTX的长视频生成方案。
强哥给力！

无法关闭推理，不太记得以前的表现，但这次OK。
只是模型太大了，在16GB显存上长期跑比较困难。

• 推理，调用，推理，调用 …… 输出。看上去很不错。
• 弄错了一些参数，然后自己能改过来。

日志性能部分：

Retrieval: 34637.92 ms, Answers: 12776.36 ms, Total: 47414.28 ms
Prompt Tokens: 53176, Completion Tokens: 1199 <JoyAI-LLM-Flash-IQ3_XS> <93.82 tokens/s>

（2.3.3）North-Mini-Code-1.0-UD-IQ3_XXS (10.9GB) ⚠️

• 结论：部分通过⚠️
• 工具：5轮。
• 原因：幻觉编造信息。

它是 Cohere 于2026年6月发布的首个面向开发者的开源代码模型。它采用 MoE（混合专家）架构，总参数量为 300 亿（30B）推理时激活 30 亿（3B）参数，主打高性价比和本地部署。以 Apache 2.0 许可开源，专为代码生成、Agentic 软件工程和终端任务优化。

从评测分数上看，接近Qwen3.6-35B-A3B，其中SciCode超越Qwen但不敌Gemma4-26B-AB。
这个模型的架构是llama.cpp刚刚 2026-06-14, b9626 正式支持的，不需要拉PR自己编译。

无法关闭推理，好在推理正常输出到了 reasoning 里而不是普通 token 里。
推理部分非常有逻辑，一次搞定，没有反复否定自己，没有无意义的循环。
可能会编造信息，都不知道该说通过还是不通过了。

• 推理，调用，推理，调用 …… 输出。看上去很不错。
• 遇到返回错误会分析，并设法解决。
• 有时会因为中英翻译问题，搞错一些参数，导致失败（成功概率很高，算通过吧）。
• 思考和回答速度比较快（计算方式不同所以没有显示的那么快）。
• 后来发现查询接口出错的时候，它可能会编造一些信息给你，而不是告诉你出错了查不到。

日志性能部分：

Retrieval: 35639.87 ms, Answers: 5185.21 ms, Total: 40825.08 ms
Prompt Tokens: 30520, Completion Tokens: 1894 <North-Mini-Code-1.0-UD-IQ3_XXS> <364.93 tokens/s>

（2.3.4）GLM-4.7-Flash-IQ3_XS (11.4GB) ⚠️

• 结论：部分通过⚠️
• 工具：6轮。

它由智谱AI推出，于2026年1月正式发布，是开源的混合思考模型，主打轻量化和高性能。模型总参数量为300亿，激活参数量仅30亿（采用MoE架构）。整个GLM后面还有好几款新版模型，但是暂时没有Flash的小版本。

更新：之前测试的是砍一刀版本GLM-4.7-Flash-23B-A3B-IQ4XS (11.7GB)。
无法关闭推理，不太稳定，有时会陷入重复工具调用直到出错，有时自己又能救回来。

换成正常版本更小量化版后，没有了重复调用工具的问题。
但非常可惜的是无法每次都通过测试。

• 无法完全关闭推理，过程比较正常，偶尔用错参数会马上改正。
• 有时推理很完美，给出正确答案干净利索。
• 有时似乎看不到数据里最快的车次，返回了错误答案（不算太离谱）真是可惜。

日志性能部分：

Retrieval: 22788.17 ms, Answers: 8636.02 ms, Total: 31424.19 ms
Prompt Tokens: 34757, Completion Tokens: 716 <GLM-4.7-Flash.i1-IQ3_XS> <82.87 tokens/s>

（2.3.5）Kimi-Linear-48B-A3B-Instruct-IQ3_M (21.0GB) ⚠️

• 结论：部分通过⚠️
• 工具：7-12轮。

它由月之暗面 (Moonshot AI) 在2025年10月发布。最大特点是其混合线性注意力架构，核心创新是 Kimi Delta Attention (KDA) 机制。它挑战了传统Transformer“所有层都必须使用全注意力”的惯例，通过将KDA与全注意力层以3:1的比例交错排列，取得了显著的效率提升。

它原生支持高达100万上下文长度。

它的KDA架构为后续的Kimi K2.5，K2.6，K2.7所沿用。
不过后续模型实在是大，所以没法本地测试。

• 开关推理都一样，输出到普通Token中，过程比较正常，偶尔用错参数会马上改正。
• 推理过程简洁，没有重复疑惑否定等。从简单的推理文字可以看出，这个模型很聪明。呃通过它的推理过程，我居然不得不修改一些不太明确的提示词。
  比如它认为提示词中的日期是假的，需要用工具取得真的日期。
  比如它认为工具可以执行一切指令，所以尝试了bash/zsh等。
  通过更加明确的提示词，它可以部分完成任务，这个部分完成和其它模型不太一样，让我想想怎么解释。
• 它能够完成任务，找出了最快的车次，然后告诉你没票了，要不要查另外的？整体的感觉是它不是笨到搞不清楚信息，而是故意和用户较劲。
• 它不伪造信息，遇到问题时会告诉你某些信息查不到。
• 然后它的注意力确实稍差，比如有时未能看清楚车次内部编号，导致给出了错误的信息。

日志性能部分：

Retrieval: 72754.86 ms, Answers: 23287.6 ms, Total: 96042.46 ms
Prompt Tokens: 43389, Completion Tokens: 898 <Kimi-Linear-48B-A3B-Instruct-IQ3_M> <38.56 tokens/s>

（2.3.6）ornith-1.0-9b-Q8_0 (8.87GB) ✅

• 结论：通过✅
• 工具：3轮。

刚刚（2026-06-26）deepreinforce-ai 发布的能自己改进自己的"编程特工"模型家族。基于 Gemma 4 和 Qwen 3.5 后训练。在 Terminal-Bench 2.1、SWE-Bench、NL2Repo 和 OpenClaw 等编码评测基准上，达到同尺寸开源模型中的最优水平。

采用强化学习（RL），不仅学会生成解决方案（rollouts），还学会生成驱动这些解决方案的框架结构（scaffold）。通过联合优化框架和最终方案，模型能够自主发现更优的搜索路径，并生成更高质量的代码解决方案。

它的发布页数据看着很不错，某些数据超越了更高级别的模型。实测似乎也很稳，没有后训练模型经常出现的顾此失彼的现象。

• 无法完全关闭推理，输出到普通token中，推理简洁正确。
• 它规划在同一轮中查询了车票价格和到站情况，所以轮次很少。

日志性能部分（已更新，接近服务端统计数据，准确了很多）：

Retrieval: 3217.78 ms, Answers: 43974.77 ms, Total: 55028.25 ms
Prompt Tokens: 20053, Completion Tokens: 1290, <ornith-1.0-9b-Q8_0> <29.34 tokens/s>

（2.3.7）ornith-1.0-35b-Q4km (19.7GB) ✅

• 结论：通过✅
• 工具：3轮。

同上是同一个家族的模型，从参数量看应该还是基于QWEN的。
它的发布页数据看着很不错，某些数据超越了更高级别的模型。
不过它的默认ctx-size似乎设置错成4096了，不主动设置就超出导致出错。
暂时还没别人量化它，只好用官方自己放出的gguf最小的版本。

• 可以关闭推理，关闭也可以通过测试。
• 它规划在同一轮中查询了车票价格和到站情况，所以轮次很少。
• 考虑到它评测数据很强，为难了它一下故意去查我确认无票的情况，关闭推理居然没出错也没幻觉。
• 打开推理后，模型在2轮时已经确认全部车次无票，并告知了用户（同级别模型这里最容易出错）。

日志性能部分（已更新，接近服务端统计数据，准确了很多）：

Retrieval: 2645.42 ms, Answers: 12350.32 ms, Total: 42285.5 ms
Prompt Tokens: 19521, Completion Tokens: 688, <ornith-1.0-35b-Q4km> <55.71 tokens/s>

（2.3.8）Mellum2-12B-A2.5B-Thinking-Q6k (10.1GB) ⚠️

• 结论：部分通过⚠️
• 工具：4轮。

它是JetBrains在2026年6月发布的一款开源大语言模型，属于Mellum 2系列。混合专家（MoE）架构：总参数量120亿，实际激活25亿参数进行计算。是一个专注于软件工程的全能助手，覆盖代码生成与编辑、调试、多步推理、工具调用、函数调用以及代理式编码任务。因此，"Thinking"模型特别适合处理复杂的编程和多步逻辑推理问题。

好些年没用JetBrain的东西，IDE越来越差，转赛道来搞LLM了？

然后"Thinking"是Mellum 2在指令微调后产生的两个变体之一，另一个是直接回答的"Instruct"版本。
简单说就是从模型上就分开了，必须推理 vs 不能推理。

• 无法关闭推理，关闭就输出到普通token（不要推理请用Instruct模型）。
• 通过率不够高，有时会搞错座位，时长等，小模型容易犯的注意力错误。
• 另一个Instruct模型看错的机率大得多。

日志性能部分（已更新，接近服务端统计数据，准确了很多）：

Retrieval: 1908.97 ms, Answers: 18526.28 ms, Total: 25991.15 ms
Prompt Tokens: 20658, Completion Tokens: 1888, <Mellum2-12B-A2.5B-Thinking-Q6k> <101.89 tokens/s>

---

（2.4）陪跑系列

这部分模型，要么太大，要么出问题的概率比较高。
在我的硬件条件下很难正常用起来。

（2.4.1）openPangu-Embedded-7B-V1.1-Q8_0 (7.9GB) ❌

• 结论：不通过❌
• 原因：无法调用工具

为啥放在这里，因为这个模型非常特殊。

它是开源盘古，基于昇腾 NPU 从零训练的高效大语言模型，参数量为 7B（不含词表Embedding）。训练了约 25T tokens，具备快慢思考融合与自适应切换能力。大概是2025年底发布的。规模有1b，7b，718b。

它的量化版本居然可以在x86架构+cuda生态下运行！！！
我把它用到企业知识库里，发现远超这个级别的模型，归纳总结，表达排版，都很不错。
而且从公布的评测分数可以看出：

• 它的知识能力，数学能力，都非常接近比它大好几倍的模型。对话，写作，指令遵循，综合表现优秀！
• 和大几倍的模型比，博士级推理能力稍差，代码能力更加弱一些。
• 它是把大量训练资源集中投入到知识、数学和推理上的 7B Dense 模型。单纯作为对话、RAG、推理模型，它已经接近 Gemma4-12B 和 Qwen3.5-9B 这档（但发布时间早半年）。

可惜它没有个中间版本，7b后面就是718b。目前暂时也没有新版本（加tool调用就好了）。
很想知道它在全栈国产化自主可控的环境里的表现啊！！！

（2.4.2）gpt-oss-20b.i1-IQ4_XS (11.2GB) ⚠️

• 结论：部分通过⚠️
• 工具：6轮。
• 原因：不稳定。

稍微老了点，也没有新的版本。
无法关闭推理，不太稳定，有时会陷入重复推理，有时自己又能救回来。
因为不稳定情况比较多，难以正常使用。

• 多次弄错参数后自动修正，但对于后天，G字头，等中文理解困难。
• 整体推理过程正确，但有时可以完成，有时返回了错误答案（不算离谱）。
• 用claude-distill的版本可以完成，但依然容易弄错。

日志性能部分：

Retrieval: 30364.5 ms, Answers: 12286.83 ms, Total: 42651.33 ms
Prompt Tokens: 55280, Completion Tokens: 2253 <gpt-oss-20b-Q8_0> <183.32 tokens/s>

PS: 更大的模型 GPT-OSS-58B-Q4_0(31.6GB)，从120B砍一刀下来的，也无法通过。
推理的过程很冗余，中途对于车次可能弄错字符串，有时会突然卡住不动。
最后输出格式出现问题，报异常退出了。

---

（2.4.3）Nemotron-3-Nano-30B-A3B-IQ4_NL (16.9GB) ❌

• 结论：不通过❌
• 工具：99轮 or 8轮。

它是英伟达（NVIDIA）于2025年12月发布的 Nemotron 3 系列中的首款开源模型。主打高吞吐量、低推理成本和高精度，专为构建 AI 智能体（Agent）而设计。简单来说，就是英伟达想在卖显卡之外，也下场做一个又快又好的“大模型样板间”。

它是唯一能调用工具超过程序硬上限的模型。
当然有时会因为完全重复调用超过3次而被停掉。
开了推理之后似乎好得多，但大量的推理信息在不算慢的速度下，铺天盖地，中途偶尔调用工具，从逻辑上看着没问题，但最终没等到它给出答案的那一天，它没回答！！！……

我很好奇，context size 设置对它没用吗，可以随便超？

老黄，样板间没做好噢！

• 不开推理，一直疯狂的换参数调用工具，包括和火车一点关系都没有的网站（携程都算有关系）。
• 开了推理，发现它没有无视提示词，而是思考否定加幻觉，Yes, but, oh wait, thus, but ……。
• 无法给出答案。

日志性能部分，有点奇怪，Usage data 里的 Token明显比看到的少太多……：

Retrieval: 337889.51 ms, Answers: 133562.53 ms, Total: 471452.04 ms
Prompt Tokens: 35726, Completion Tokens: 28715 <Nemotron-3-Nano-30B-A3B-IQ4_NL> <215.0 tokens/s>

（2.4.4）Mistral-Small-3.2-24B-Instruct-2506-IQ4_XS (11.9GB) ⚠️

• 结论：部分通过⚠️
• 工具：4轮。

它是由法国人工智能公司 Mistral AI 开发的大语言模型，发布得稍微早了点。

• 对中文的理解不够，有时会弄错日期。12306还好，其它网站可能不知道是啥。
• 几乎一次正确，有时会重复调用。
• 稍微有点慢啊。

日志性能部分：

Retrieval: 22067.46 ms, Answers: 22687.93 ms, Total: 44755.39 ms
Prompt Tokens: 17830, Completion Tokens: 492 <Mistral-Small-3.2-24B-Instruct-2506-IQ4_XS> <21.68 tokens/s>

（2.4.5）Ministral-3-14B-It-2512-IQ4_NL (7.3GB) ⚠️

• 结论：部分通过⚠️
• 工具：5轮。

它是由法国人工智能公司 Mistral AI 开发的大语言模型，2025年底发布。
比Mistral-Small-3.2要稍晚些，参数也小些。和最新的Gemma4-12B参数和文件大小方面比较接近，但评测被全面碾压。

它 完美通过了测试 。这部分有误，多跑几次有时正确，有时错误。
与此同时，同系列很大但量化过度的（Mistral-Small-4-119B-2603-UD-IQ1_M:勉强测了下）也无法通过测试，总是弄错日期或者给出不是正确的答案。

• 比较保守先查询了2个车站的信息，然后查全天车次，最快车次的票价等。
• 没有弄错参数，没有重复的调用，没有无意义的查询。
• 它不能稳定的通过测试，有时会给出错误的答案。

日志性能部分：

Retrieval: 13924.31 ms, Answers: 17124.99 ms, Total: 31049.29 ms
Prompt Tokens: 20310, Completion Tokens: 750 <Ministral-3-14B-It-2512-IQ4_NL> <43.81 tokens/s>

（2.4.6）LFM2.5-8B-A1B-Q8_0 (8.4GB) ❌

• 结论：不通过❌
• 工具：5轮。

这是Liquid AI 在 2026 年 5 月 28 日 发布的，专为边缘设备设计的高效 MoE（Mixture-of-Experts）模型。确实是非常小的专家呢。

难以理解工具调用后返回的具体命令和参数，导致连续调用错误，最后触发重复调用阈值。
开启思考后，会输出大量的推理信息。但最还是因为理解工具的问题，终无法完成任务。

更新程序后继续尝试，并更换了几个不同的量化模型，都无法完成任务。
出错的地方在于对提示词和工具不正确，不知道是语言问题还是本身能力不够。

（2.4.7）EXAONE-4.5-33B-IQ3_S (13.5GB) ✅😢

• 结论：通过✅
• 工具：5轮。

这是LG AI研究院首发开源视觉语言模型EXAONE 4.5：让AI同时“看图”又“读文”。它发布于2026年4月，可以参考技术报告的🔗论文地址。当然这里没有视觉能力的需求。

• 干净利落，没有多余的步骤，没有重复的问题。
• 但是极致的慢，慢到怀疑人生，慢到惊天地泣鬼神，慢到不想写通过（别人36秒，它大概36分钟）。我的统计偏快，后台的统计是0.73 t/s， draft acceptance = 0.97549 ( 398 accepted / 408 generated)。
• 关闭MTP后，速度提升到2.89 t/s。…… 额 ……
• 然后我测试了图片识别，Gemma几秒钟可以出的结果，它等了很久没动静，实在不想再等，关了。

日志性能部分：

Retrieval: 1002886.7 ms, Answers: 764270.76 ms, Total: 1767157.46 ms
Prompt Tokens: 17017, Completion Tokens: 1269 <EXAONE-4.5-33B.i1-IQ3_S> <1.66 tokens/s>

PS：顺便看了看同系更早的模型：

1. EXAONE-Deep-32B.i1-IQ3_XXS（11.6GB）- 推理正确但无法调用工具。
2. EXAONE-Deep-8B.i1-Q6_K（5.98GB）- 仅输出乱字符，似乎无法正常用，看不出问题在哪。

（2.4.8）ERNIE-4.5-21B-A3B-Q4 (12.0GB) ❌

• 结论：不通过❌

大概一年前，2025年6月，百度的文心一言4.5系列模型正式开源。

在目前的llama.cpp后端上，总是报输出格式不正确，无法成功完成正常对话。
非推理版本在早一些的llama.cpp上似乎可以输出一些内容，但是没有调用工具。

（2.4.9）Phi-4-reasoning.i1-IQ4_NL (7.8GB) ❌

• 结论：不通过❌

大概一年前，2025年5月，微软在官网开源了三个新版Phi-4小参数模型。
Phi-4-Reasoning的基础架构源自微软开源的Phi-4 模型，为了提升其推理能力，微软通过监督微调和强化学习相结合的训练方法行了深度强化。

推理版本会陷入无限重复，非推理版本反而可以规划出具体的步骤，但它们都不能调用工具。

（2.4.A）MiniMax-M2.1-REAP-50.i1-IQ1_S (22.2GB) ❌

• 结论：不通过❌

⚠️过于激进的量化产物，似乎最早来自玩笑（梗）也就是你可以拥有抽屉里的大模型。
实际模型最好采用Q3级别（底线），保险Q4-Q5，有条件 Q6-Q8。

它是MiniMax于2025年12月开源的新一代旗舰大语言模型。采用了混合专家（MoE）架构，总参数量约为2300亿，推理时仅激活约100亿参数。最新的模型是刚开源不久的MiniMax-M3。

这是被大刀砍后最激进的量化版本。
可以这样比喻，硬是把一个知识丰富的博士，逼成了半个记得超多信息的弱智。
每次都会陷入无限重复，速度大概 10.76 t/s，连个but, wait, no 都没有，祥林嫂式输出 ：

The user is presumably asking for train information about ticket prices, stops, and details. The user is presumably asking for train information about ticket prices, stops, and details. The user is presumably asking for train information about ticket prices, stops, and details. The user is presumably asking for train information about ticket prices, stops, and details…

再次尝试，把模型提高到IQ2_XS的量化级别(31.8GB)后，则模型可以正常推理。
但是对于工具返回的信息在理解或使用上有点问题，很难输出正确格式。
每次都差点就能正确，看着让人着急。最后逐渐陷入疯狂的重复。

再再次尝试，把模型提高到IQ3_XXS的量化级别(41.7GB)后，居然没有改善。
看来不是量化的问题，而是砍太狠了。
开始的推理步骤正常，总是发出不带空格的指令，重复同样的错误。

（2.4.B）Solar-Open-69B-REAP.i1-IQ3_XXS (25.0GB) ❌

• 结论：不通过❌

⚠️REAP，全称是 Router-weighted Expert Activation Pruning。它的核心是通过路由加权评估，“剪掉”MoE层中一部分被认为不重要的“专家”，减少模型体积。根据其发布方的数据，在强大的Qwen3-Coder-480B模型上，即使剪掉高达50% 的专家，REAP仍能保留约97.6% 的基础代码能力。

它由韩国AI公司 Upstage 主导开发，是韩国政府“自主AI基础模型”项目的重要成果，大概2026年1月发布。旨在服务“非通用语言”（特别是韩语）的大语言模型，致力于解决除英语和中文之外，其他语言在AI发展中面临的数据和性能鸿沟问题。采用 MoE（混合专家）架构，总参数量约1020亿，每次推理仅激活约120亿参数。

这是被大刀砍后的量化版本（最激进的量化版本也试过，仅机械重复）。
没有想到的是，这个Q3级别依然不行，看来不仅是量化会过头，REAP的砍一刀砍太大了也严重影响？或者说这个模型需要更高的量化版本？还是只会韩语，中文不行？

每次都会陷入无限重复，速度大概 8.70 t/s，输出最开始有逻辑，但经常死循环 ：

We need to interpret the user’s request. The user wants to query railway information on 12306 (railway query tool). Specifically: “后天从成都到北京的火车。找到G字头、有二等座、最快的车次。查询那趟车的票价和停站详情。” So they want to find train from Chengdu to Beijing, tomorrow (maybe “后天” meaning “tomorrow”? Actually “后天” maybe “后天” is “后天” meaning “tomorrow”?.. They want train with G字头 (maybe “G字头” meaning “G字头” maybe “G字头” is “G字头” meaning “G字头” is “G字头”?

（2.4.C）Hypernova-60B-2605.i1-IQ3_M (29.0GB) ❌

• 结论：不通过❌
• 原因：无法调用工具

它是由西班牙公司 Multiverse Computing 开发的一款高性能、高效率的开源大语言模型。被定位为一个重要的“欧洲主权AI”模型。其基础来源于一个参数规模大得多的模型（据称是 OpenAI 的 gpt-oss-120B）。2605代表了该模型在 2026 年 5 月发布的最新版本，在编程和科学方面比之前的版本有很大进步。

运行的结果是推理正常，调用工具变成了输出到token，导致无法继续。官方说：

The model is instruction-tuned and supports native tool calling (function calling with defined schemas, structured outputs, and agent-style workflows).

按理说不应该啊……
具体原因不明，但总之没能通过。

（2.4.D）Step-3.5-Flash-REAP-121B-A11B.i1-IQ2_S (33.3GB) ❌

• 结论：不通过❌
• 原因：工具逻辑和日期

它是是由中国大模型创业公司阶跃星辰 (StepFun) 开发的一款旗舰级语言推理模型，发布于2026年2月。Step-模型的新版 3.7-Flash 发布于 2026年5月。

这是被砍一刀的版本。

运行的结果是推理部分正常，但调用工具时没有根据推理的结果来（蛤）？
多调错几次工具后，日期也开始莫名其妙的开始弄错了。
把日期弄错成很早的一个日期后，就再也无法查询车次，到最后开始无限重复推理循环。

看来裁剪过度，导致注意力下降。某些简单的逻辑也开始出错了。

---

（三）意料之内的结论

评测条件并不算太公平。好在不像有些文章，为了突出Qwen，就用Qwen MOE甚至加MTP，去和Gemma Dense比速度。加上每个模型发布时大家都是一顿吹捧，以小博大，全面超越，让人难以选择。上述模型有些有更大的家族成员，还有些热门模型太大无法测试，比如Deepseek-V4，Minimax-M3，Kimi-k2.7。等等……

（3.1）简要总结

结论概括如下：

• 国外模型多对中文的理解力偏低，对省略主语和简称更加难以理解。
• 模型更替很快，通常旧模型都不如新模型。
• 幻觉有时很致命，如果我们需要逐个核实，则失去了LLM的意义。
• 需要自己平衡显存 vs 模型大小x量化，带来的性能损失（估计24GB才宽松些）。
• 从稳定角度，谷歌QAT别急着上，可以继续观望其变化。

如何模型选择的建议：

• 无脑直接选Qwen，特殊需求用Gemma。
• 严谨困难用Dense，快速响应用MOE。
• 量化数字越大越好，最低只能低到3。

---

（3.2）观察与思考

1. 量化对模型的影响：是每个模型厂商难以提前考虑的。模型的参数可以理解为模型的知识和推理能力，而再大的模型量化过度后都无法正常使用。

   • 过度量化到Q1级别时类似幼儿园小朋友，脑袋塞进了海量的模糊知识，但根本无法使用。
   • 模型量化到Q2级别时好像小学生，容易看错写错，比如车次中有几个0？成都东是指成都还是成东，英文还会思考后天是什么意思，明天？还是明天的明天？等等。基础错误太多无法推理。
   • 模型量化到Q3级别时就像中学生，基础知识比较全面但偶尔会犯错。
   • 显存不够，比喻继续不下去了。总结就是有再多的知识，但连基本的读写都出错，是无法正常逻辑推理的。

2. 稠密模型vs专家模型：在测试中发现了量化造成了影响后，又发现了另一个规律。
   同样规模同样量化的的模型家族。稠密模型更不容易犯错，专家模型更快但多测几次就露馅了。

   • 火车车次问题，切换明天/后天，二等座/商务座，北京/上海。故意选择缺票等情况。
   • 稠密模型：几乎每次都能回答正确。
   • 专家模型：数据靠前的容易正确，数据在中间偏后的，容易被忽略掉。也就是说用20-30B的MOE模型，在推理完全正常的情况下，偶尔它就是会给你错误的答案，还敢用吗……
   • Gemma逻辑性稍强，但和Qwen呈现相似的结果。
   • 多尝试一些奇怪的情况，稠密模型有时也会弄错，也就是说前面打勾通过的，很可能会过不了。

3. 模型本身：因为用的都是gguf量化模型，而且因为显存因素，很难用厂商自己发布的gguf。这就导致只能使用第三方的量化或者手并夕夕版本。

   • 看上去量化方式相同，文件尺寸几乎一致的两个模型，有可能一个能工作，另一个不能。
   • 作者在Coding，Agent方面进行了微调、再训练、加强的模型。可能会顾此失彼。虽然作者们通常会给出一些评测分数显示模型在某些方面有长足的进步。但实际效果嘛，难以全面超越原版模型……
   • 目前看来，只能选择官方版本，或者有经验的组织进行的量化（比如unsloth）。即便如此，如果发现模型表现怪异（重复工具调用，推理有缺陷）时，再怀疑模型本身能力前，最好多换几个gguf试试先。

4. 在线/本地模型能力区别巨大：

   • 本地Qwen/Gemma模型比2年前的在线模型比如GPT3.5，确实进步很大。但是对比目前的顶级在线模型还差得远，相当远……
   • 所以我很难理解本地4B，9B的coder模型。这不是讽刺，我真的理解不了……对我来说，我遇到的有些问题要和GPT讨论很久才能解决或拿出好的方案。deepseek，grok这些在线都完全没法用。所以真的理解不了，到底本地小规模coder模型，到底能解决什么问题😔

5. 接上条，本地16GB能跑的模型，只能到20-30B，Q3级别的GGUF。或者更小10B左右模型的Q8。由于模型参数级别和量化的影响。注意力不够的影响下，RAG内容过长，容易犯一些低级错误，导致后续推理出错。虽然明显能看出同级别的模型能力有强弱，但挑战它们的极限并不是明智的做法，最好是：

   • 分步实现：不要给大步骤太多或模糊的问题。
   • 人工纠错：提示LLM正确的信息，不要让它基于错误的内容继续。

6. 好累，感觉测不下去了。
   建议大家第一次当世界杯裁判……啊不，第一次测试LLM模型时，不要紧张。
   否则容易受伤！！！

   ---

   

---

（完）