milin_desktop（RTX 5080 16GB）本地 LLM 选型分析

#本地推理 #Ollama #GGUF #RTX5080 #模型选型

硬件背景

组件	规格
GPU	NVIDIA GeForce RTX 5080（16GB GDDR7，Blackwell 架构）
CPU	AMD Ryzen 7 9800X3D（8 核，3D V-Cache）
内存	32GB DDR5

使用场景：为 openclaw agentic 框架 提供本地 LLM 后端，主要执行工具调用、长文档处理、代码生成与分析。对输出速度要求不高（15-30 tok/s 即可），优先质量与上下文长度。

硬件特点：

• Blackwell 架构原生支持 MXFP4 硬件加速（OpenAI GPT-OSS 专属优势）

• 9800X3D 的 3D V-Cache 使 CPU 推理带宽远优于同级处理器，CPU offload 惩罚较小

• 16GB VRAM + 32GB RAM 可做 GPU+CPU 混合推理，允许运行超出 16GB 的模型

完整硬件配置与环境搭建详见 《RTX 5080 新主机环境配置实录》。

---

候选模型分析

GPT-OSS 20B MXFP4（OpenAI 开源）

项目	详情
架构	MoE，21B 总参数，3.6B 激活/token
上下文	128K
显存	~13.8 GB（完整装入 16GB）
量化	MXFP4（RTX 5080 Blackwell 硬件加速专属）
质量	对标 o3-mini，SWE-bench 顶级，工具调用强
速度	RTX 5080 极快；但长上下文时速度骤降（128K 约 9 tok/s）
Ollama	ollama run gpt-oss:20b
问题	128K 上下文不算长；极长上下文推理速度垮塌

Qwen3-Coder 30B-A3B（阿里，MoE）

项目	详情
架构	MoE，30B 总参数，3B 激活/token
上下文	256K 原生，YaRN 扩展至 1M
显存	Q3_K_M 14.7 GB → 完整装入 16GB
量化可选	Q3_K_M 14.7GB / IQ4_XS 16.4GB（微量 offload）/ Q4_K_M 18.6GB（offload 约 2-4 层）
质量	当前最强开源 coding/agentic 模型，SWE-bench 顶级
速度	Q3_K_M 全 GPU ~35-50 tok/s；Q4 offload 约 12-20 tok/s
GGUF	unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF
备注	download agent、web_search、代码执行等场景均高度吻合

GLM-4.7-Flash（智谱，MoE）

项目	详情
架构	MoE，~30B 总参数，~3.6B 激活
上下文	200K
显存	Q2_K ~11 GB（完整装入）；Q4 ~18 GB（需 offload）
质量	SWE-bench 59.2，τ²-Bench 79.5，agentic 场景强
速度	Q2 约 80 tok/s；Q4 offload 较慢
问题	16GB 内需用 2-bit 量化，精度损失较大；4-bit 需借用 32GB RAM
GGUF	unsloth/GLM-4.7-GGUF

Qwen3.6-27B（阿里，密集模型）

项目	详情
架构	Dense，27B
上下文	262K
显存	Q4_K_M 16.8 GB（微量 offload）；Q3_K_M ~14 GB（完整装入）
质量	77.2 SWE-bench Verified；综合推理极强，BenchLM 评分 53.82
速度	Q3_K_M 全 GPU ~50 tok/s；Q4 微量 offload 约 30-40 tok/s
问题	密集模型随上下文增长速度衰减比 MoE 更明显

Carnice-Qwen3.6-MoE-35B-A3B APEX I-Mini（社区 fine-tune）

项目	详情
架构	MoE，35B 总参数，3B 激活/token
上下文	继承 Qwen3.6（128K~256K）
显存	14.3 GB，完整装入 16GB
质量	基于 Carnice 微调，imatrix 校准（对话、代码、推理、工具调用）
速度	~121 tok/s（RTX 5070 Ti 实测），GPU 使用率约 50%
问题	社区 fine-tune，质量上限低于官方版本
获取	mudler/Carnice-Qwen3.6-MoE-35B-A3B-APEX-GGUF

---

APEX 量化策略说明

APEX（Adaptive Precision for Expert Models）是专为 MoE 模型设计的量化策略，按张量角色分类施压：

• 共享层（dense）：每个 token 必经，保持较高精度

• 路由专家层（expert FFN）：仅偶发激活，激进压缩

• 边缘层：高精度；中间层：低精度

I- 前缀变体（如 I-Mini）使用 imatrix 校准，在多样化数据集（聊天、代码、推理、工具调用）上计算权重重要性，精度优于朴素量化。

---

显存分配速查表

模型	量化	大小	是否装入 16GB	推荐度
Qwen3-Coder 30B-A3B	Q3_K_M	14.7 GB	✅ 完整	⭐⭐⭐
Qwen3-Coder 30B-A3B	Q4_K_M	18.6 GB	⚠️ 需 offload	⭐⭐
GPT-OSS 20B	MXFP4	13.8 GB	✅ 完整	⭐⭐⭐
LFM2-24B-A2B	Q4_K_M	14 GB	✅ 完整	⭐⭐
Carnice-Qwen3.6 APEX I-Mini	imatrix	14.3 GB	✅ 完整	⭐⭐
Qwen3.6-27B	Q3_K_M	~14 GB	✅ 完整	⭐⭐
Qwen3.6-27B	Q4_K_M	16.8 GB	⚠️ 微量 offload	⭐⭐
GLM-4.7-Flash	Q2_K	11 GB	✅ 完整	⭐（精度损失大）
GLM-4.7-Flash	Q4	~18 GB	⚠️ 需 offload	⭐⭐
Qwen3 14B	Q4_K_M	11 GB	✅ 完整	⭐（偏小）

---

综合推荐

排名	模型	核心理由
🥇 首选	Qwen3-Coder 30B-A3B Q3_K_M	256K 原生上下文，顶级 agentic/coding 质量，14.7GB 完整装入 16GB VRAM
🥈 次选	GPT-OSS 20B MXFP4	Blackwell 专属硬件加速，o3-mini 级质量，开箱即用；上下文 128K 略短
🥉 备选	Qwen3.6-27B Q3_K_M	262K 超长上下文，密集模型综合推理均衡，适合长文档处理
参考	GLM-4.7-Flash Q3	agentic 强但 16GB 内需接受 3-bit 精度损失
速度优先	Carnice APEX I-Mini	121 tok/s 最快，质量略逊官方

openclaw 实际部署建议：

• 主力模型：Qwen3-Coder-30B Q3_K_M（14.7GB 装入 16GB VRAM，~35 tok/s，256K 上下文）

• 轻量备选：GPT-OSS 20B MXFP4（适合短上下文快速任务，速度更快）

---

---

OpenClaw 场景评测设计（2026-07-20）

实测 Benchmark（ngl=99，mmap=0）

模型	大小	参数量	pp128	pp512	tg128	备注
GPT-OSS 20B Q4_K_M	10.9 GB	20.91B	3617	8661	253 tok/s	MoE/SSM，每 token 仅激活 ~1/3 参数
Qwen3.6-35B-A3B Q3_K_M	15.9 GB	35.51B	142	163	20.4 tok/s	短上下文近满装 VRAM
Qwen 3.5-35B-A3B Q4_K_M	20.5 GB	34.66B	133	164	11.5 tok/s	基准，4 GB offload
Qwen3.6-27B Q4_K_M	15.9 GB	27.32B	73	84	4.4 tok/s	稠密模型，微量 offload 即拖垮 tg

生产参数（-ctk q8_0 -ctv q8_0 -fa auto -mmp 0）下 llama-bench 实测（512 token 上下文）：

模型	pp512	tg128
GPT-OSS 20B Q4_K_M	8146 tok/s	238 tok/s
Qwen3.6-35B-A3B Q3_K_M	151 tok/s	23.2 tok/s
Qwen3.6-27B Q4_K_M	79 tok/s	6.3 tok/s

OpenClaw 实服务（24K 系统提示，-c 32768）下 tg 会因 attention 跨越更长上下文而偏低：

• Qwen 3.5 Q4_K_M：3.82 tok/s（Task 131 实测，含 24K 上下文）

• 其余模型参考上表，实际值预计 10–30% 偏低

---

场景分类与速度/精度权重

OpenClaw 的请求分为两类：

会话请求（用户在等待，速度与精度均需权衡）

场景	典型输入	典型输出	速度权重	精度权重	最低可接受 tg
提醒设置	~200 tokens	~50 tokens	35%	65%	≥ 5 tok/s
下载管理	~800 tokens	~150 tokens	30%	70%	≥ 5 tok/s
文档处理	~3000 tokens	~400 tokens	45%	55%	≥ 3 tok/s
复杂推理	~5000 tokens	~600 tokens	25%	75%	无要求

后台自动任务（无用户等待，仅看精度）

场景	触发方式	速度权重	精度权重
Heartbeat	自动 30s/次	0%	100%

---

降级机制

会话请求先由快速模型处理；满足以下任一条件时降级至精准模型：

会话请求
    │
    ▼
快速模型（如 GPT-OSS 20B）
    │
    ├─ 成功 ──────────────────────────→ 返回用户
    │
    └─ 触发降级
           ├─ 工具调用 JSON 格式错误
           ├─ 输出含歧义词（"我不确定"、"无法判断" 等）
           ├─ 关键字段缺失（时间、任务名等）
           └─ 输出长度严重偏短
                   │
                   ▼
           精准模型（如 Qwen3.6-35B-A3B Q3_K_M）
                   │
                   ▼
           返回用户 + 记录降级日志

后台任务（Heartbeat）：跳过快速模型，直接用精准模型

---

评测题目集

H — Heartbeat（后台自检，仅测精度）

H-1 服务状态聚合

以下是各服务最近一次心跳：
- qBittorrent: 上次响应 2min 前，状态 running
- mt-photos: 上次响应 45min 前，状态 unknown
- webdav: 上次响应 1min 前，状态 running
- llama-server: 无响应记录

输出结构化状态报告，标记异常项，并判断是否需要触发告警。

✅ 预期：mt-photos（45min unknown）和 llama-server（无记录）需告警

H-2 阈值告警判断

当前系统资源：
CPU: 23% | 内存: 71% | 磁盘 /: 91% | GPU: 0% | GPU显存: 0%

按告警规则（CPU>85%, 内存>90%, 磁盘>85%, GPU推理中>95%）判断哪些需要告警，给出处理建议。

✅ 预期：仅磁盘 / 需告警（91% > 85%），其余均未触发

H-3 异常趋势识别

过去6次心跳的响应延迟（秒）：1.2, 1.4, 2.1, 3.8, 6.2, 11.4

判断当前趋势，预测下一次是否可能超时（>15s），并给出可能原因。

✅ 预期：指数增长趋势，下一次约 20s，会超时；可能原因：上下文累积/内存泄漏

H-4 二阶段故障恢复检测

5分钟前告警：mt-photos 无法连接 NFS 挂载点 /nfs
当前状态：/nfs 挂载检查返回正常，mt-photos 容器状态 running

判断故障是否已完全恢复，若否，说明还需检查什么。

✅ 预期：不能仅凭 running 判断恢复，还需验证 mt-photos 能否实际读写 /nfs

---

R — 提醒设置（会话，精度主导）

R-1 明确时间（基础，快速模型目标）

今天是2026年7月20日周一，下午2点。
帮我设置提醒：明天上午10点半提醒我检查 llama-server 是否在运行。

✅ 预期：2026-07-21 10:30，字段完整

R-2 含小数的相对时间（降级候选）

现在是晚上8:17，帮我2小时45分钟后提醒我关掉 qBittorrent。

✅ 预期：22:02，不能四舍五入成 22:00 或 23:00

R-3 循环提醒

每周一早上8:50提醒我检查上周的下载完成情况，备注"看看有没有做种比低于0.5的"。

✅ 预期：cron 规则 50 8 * * 1，备注原文不能修改

R-4 多时间点（降级候选）

今天是2026年7月20日，我下周三（7月29日）有服务器维护窗口（下午2点开始）。
分别在：维护前2天、维护当天早上7点、维护开始前30分钟设置提醒。

✅ 预期：7月27日 / 7月29日 07:00 / 7月29日 13:30，任意一个错误触发降级

R-5 月底边界

今天是2026年1月31日，帮我在下个月15号提醒我续费服务器。

✅ 预期：2026-02-15，不能写 2月31日

---

D — 下载管理（会话，精度主导）

D-1 条件筛选（基础，快速模型目标）

qBittorrent 当前任务：
- 《黑神话：悟空》4K版：进度 97%，速度 2.3 MB/s
- 《星际穿越》蓝光：进度 12%，速度 0.1 MB/s
- Ubuntu 24.04 ISO：进度 100%，做种中，上传 0 KB/s

暂停做种无上传的任务，优先保障快要完成的任务带宽。

✅ 预期：暂停 Ubuntu，不动「黑神话」和「星际穿越」

D-2 背包式磁盘规划

D盘剩余：38 GB
下载队列：A 需 45 GB（高优先级）/ B 需 12 GB（中）/ C 需 8 GB（中）/ D 需 22 GB（低）
在不超限前提下选择任务，说明理由。

✅ 预期：选 B+C（20 GB）或 B+C+D（42 GB，超了）→ 最优 B+C+D=42>38，应选 B+C=20 或 C+D=30

D-3 多系统资源冲突（降级候选）

晚上要打2小时游戏（GPU 全占用），当前：
- llama-server 占用 GPU 14GB 显存（推理中）
- qBittorrent 下载速度 8 MB/s，不占 GPU

规划游戏前需执行的操作和游戏结束后的恢复步骤，列出具体顺序。

✅ 预期：先停 llama-server → 启动游戏；游戏结束 → 重启 llama-server → OpenClaw 切回本地模型

---

Doc — 文档处理（会话，速度/精度均衡，含降级）

Doc-1 信息提取（快速模型目标）

从以下 nginx 日志中提取所有非 200 状态码的请求，输出为表格（时间、路径、状态码、IP）：

192.168.1.2  - [20/Jul/2026:14:23:11] "GET /api/status" 200
192.168.1.3  - [20/Jul/2026:14:23:15] "POST /api/chat"  503
192.168.1.2  - [20/Jul/2026:14:23:18] "GET /health"     200
1.2.3.4      - [20/Jul/2026:14:24:02] "GET /admin"      403
192.168.1.3  - [20/Jul/2026:14:24:45] "POST /api/chat"  200

✅ 预期：503（192.168.1.3）和 403（1.2.3.4）两行，格式正确

Doc-2 格式转换（快速模型目标）

将以下运维记录转为 JSON 数组，每条含 date、action、result 字段：

2026-07-18 重启了 openclaw 容器，配置了 llamacpp provider，首次调用成功
2026-07-19 发现 Ollama 插件与 llamacpp 路由冲突，已禁用 Ollama 插件
2026-07-19 更新超时参数为 600s，需要容器重启才生效

✅ 预期：3 条 JSON，字段准确，不添加原文未提及内容

Doc-3 长文摘要 + TODO 提取（降级候选）

输入：500+ 字技术文档或会议记录任务：3 句话总结 + 列出所有待办事项降级触发：摘要包含文中未提及内容，或遗漏 TODO 项

Doc-4 矛盾检测（精准模型目标）

以下是同一份配置文档的两个版本片段，找出所有不一致的地方并说明哪个更合理：

版本A：timeout 设置为 120s，适用于所有 provider
版本B：llamacpp provider 的 timeout 单独设置为 600s，其余 provider 维持 120s

✅ 预期：版本B更合理（llamacpp 冷启动需 ~300s 系统提示 prefill）

---

C — 复杂推理（会话，精度主导）

C-1 多组件方案设计

在 N100 上新增自动备份方案：每天凌晨3点将 /nfs/mt_photos 同步到 /smb。
要求：备份前检查 /smb 是否挂载，失败时发邮件通知，保留最近7天备份日志。
给出完整实施方案（脚本 + cron 配置）。

✅ 预期：含挂载检查、rsync 命令、日志轮转、邮件通知（mailutils/sendmail）、cron 定时

C-2 多约束调度

需同时满足：
1. llama-server 运行时 GPU >85%，不能同时运行其他 GPU 任务
2. 游戏在晚上7点到11点运行，期间不能有 llama-server
3. OpenClaw heartbeat 每30秒一次，heartbeat 本身不触发推理
4. 用户白天（9点-18点）可能随时发起会话请求

设计 llama-server 自动启停策略，不能遗漏任何约束。

✅ 关键点：heartbeat 不触发推理，故不需要为 heartbeat 保持 llama-server 运行

C-3 根因分析

现象：OpenClaw 长对话后响应从5秒增至45秒，重启容器后恢复。

已知信息：
- 模型：Qwen 3.5 35B A3B，llama-server
- KV cache slot：1
- 上下文窗口：-c 32768
- 系统提示：~24000 tokens

分析最可能原因，说明为何重启后恢复。

✅ 预期：对话轮次累积使 prompt tokens 增长，pp 阶段线性变慢；重启清空 KV cache 和会话历史

---

评分标准

每题满分 10 分：

维度	分值	判断方式
格式正确	2 分	输出符合要求（JSON / 表格 / 列表）
关键信息完整	3 分	所有必填字段/要素存在
逻辑正确	3 分	推断/计算/判断准确
无幻觉	2 分	未编造原文不存在的内容

降级触发：「格式正确」或「关键信息完整」任意一项得 0 分。

---

OpenClaw 场景评测结果（2026-07-20）

测试配置

• 模型加载：llama-server on milin_desktop（RTX 5080），-ngl 99 --no-mmap -c 32768

• 评测方式：直接调用 /v1/chat/completions，系统提示 ~50 tokens（精简版环境描述）

• max_tokens=700，temperature=0.1

• 评分：每题 0–2 分（0=错误/空白，1=部分正确，2=完整正确），共 18 题，满分 36

---

响应时间与 tg 速度

模型	平均响应时间	平均 tg	总耗时	说明
GPT-OSS 20B Q4_K_M	2.6s	235 tok/s	47s	含 5 道空白回答
Qwen3.6-35B-A3B Q3_K_M	17.4s	17.2 tok/s	5m13s	—
Qwen3.6-27B Q4_K_M	72.4s	4.6 tok/s	21m44s	过慢，不适合交互场景

各类别平均响应时间（秒）：

类别	GPT-OSS 20B	Qwen36-35B	Qwen36-27B
H-心跳	2.6s	20.9s	78.9s
R-提醒	2.6s	6.1s	16.0s
D-下载	2.7s	19.6s	94.2s
Doc-文档	2.2s	7.9s	64.0s
C-推理	2.9s	38.7s	144.5s

---

分题评分

题目	GPT-OSS 20B	Qwen36-35B	Qwen36-27B	备注
H1 服务状态聚合	2	2	2	三模型均正确识别 mt-photos 和 llama-server 异常
H2 阈值告警判断	2	2	2	均仅告警磁盘 /
H3 异常趋势识别	1	0.5	0.5	GPT 识别指数趋势但截断；Qwen 两款给出错误原因（网络/GPU碎片化）
H4 二阶段故障恢复	0→2★	2	2	GPT 原空白；补测正确指出需验证容器内 /nfs 读写
R1 明确时间	0.5	2	2	GPT 时间对但输出了完整脚本而非确认提醒
R2 含小数相对时间	2	2	2	全部正确计算 23:02（⚠️ 原设计期望 22:02 系笔误）
R3 循环提醒	0	2	1.5	GPT 错误输出 qBittorrent 监控脚本；Qwen27 添加多余免责声明
R4 多时间点	2	2	2	均正确给出 7月27日 / 7月29日07:00 / 13:30
R5 月底边界	0	1	2	GPT 输出 cron 教程；Qwen35 幻觉今日为 1月31日但结果侥幸正确
D1 条件筛选	1.5	2	0.5	Qwen27 给出错误 docker CLI 命令；Qwen35 最简洁
D2 背包式磁盘规划	2	0	2	Qwen35 初始选 A+C（共 53GB > 38GB），严重推理错误
D3 多系统资源冲突	0→2★	2	2	GPT 原空白；补测正确输出停llama-server→游戏→重启
Doc1 信息提取	2	2	1.5	Qwen27 给出了正确答案但附上冗余 bash 脚本
Doc2 格式转换	2	1.5	2	Qwen35 第一条 action 字段混入了 result
Doc4 矛盾检测	0.5	2	2	GPT 回避性推荐版本 A，未认识到 llamacpp 明显需要 600s
C1 方案设计	0→2★	2	2	GPT 原空白；补测五项全中（挂载/rsync/日志轮转/mailx/cron）
C2 多约束调度	0（仍空白）	1	1.5	GPT 2000 tokens 仍耗尽；Qwen35 流于时间窗口；Qwen27 提及心跳不触发推理
C3 根因分析	0→0.5★	0.5	0.5	全部错误：将 KV cache 碎片化列为主因，未识别 prompt tokens 累积导致 pp 变慢

★ 补测（max_tokens=2000）后得分，原始评测 max_tokens=700

---

分类得分汇总

类别	满分	GPT-OSS 20B	Qwen36-35B	Qwen36-27B
H-心跳（4题）	8	5 → 7★	6.5	6.5
R-提醒（5题）	10	4.5	9	9.5
D-下载（3题）	6	3.5 → 5.5★	4	4.5
Doc-文档（3题）	6	4.5	5.5	5.5
C-推理（3题）	6	0 → 2.5★	3.5	4
合计	36	17.5 → **24（66.7%）**★	30.5（84.7%）	31.5（87.5%）

★ 补测后更新（max_tokens=700→2000）

---

关键发现

GPT-OSS 20B Q4_K_M：速度极快（235 tok/s）。初测 max_tokens=700 时 5 道复杂题全部空白，确认为 reasoning 模式将 token 配额耗尽于内部思考、未留余量输出可见内容。将上限提升至 2000 后，H4/D3/C1 恢复正常（2s–8.5s），总分从 48.6% 升至 66.7%，平均响应时间约 3.8s（Qwen3.6-35B 的 1/4）。剩余两处缺陷：C2 仍空白（2000 tokens 仍不够推理复杂多约束调度）；R 类提醒格式偏离（被动确认题输出主动实现脚本，属行为模式问题，需系统提示纠正）。

Qwen3.6-35B A3B Q3_K_M：综合均衡，除一次严重推理错误（D2 初步选择 A+C=53GB 超出 38GB 限制）和 C3 根因分析错误外表现稳定。速度 17.2 tok/s，响应时间 17.4s，实际服务（含 24K 系统提示）下约 3–6 tok/s，符合 OpenClaw 对话场景需求。评分 84.7%。

Qwen3.6-27B Q4_K_M：质量最高（87.5%）但速度过慢——平均 72.4s、4.6 tok/s。含 24K 上下文的实际服务中，单次长回答可能超过 2 分钟，不适合交互式对话场景。若作为离线分析或定时任务（Heartbeat）的后端，质量优势可以发挥。

全局盲区：三款模型均未正确识别 C3 根本原因（多轮对话累积 prompt tokens → pp 阶段随上下文线性变慢，重启清空历史恢复），且对 C2 关键约束（heartbeat 不触发推理，无需为 heartbeat 保持 llama-server 运行）均理解不完整。这两类问题在实际 OpenClaw 运维中具有较高价值，建议纳入系统提示补充说明。

R2 笔记勘误：本评测设计将 R2 期望答案写为「22:02」，实为笔误——20:17 + 2h45min = 23:02。三款模型均正确计算为 23:02。

---

GPT-OSS 20B 补测（max_tokens=2000）

原始评测中 5 道题目空白，均系 reasoning token 耗尽所致，补测结果如下：

题目	原始（700）	补测（2000）	耗时	结论
H4 故障恢复检测	空白	✅ 正确，10 条 NFS 检查清单	8.5s	解决
D3 资源冲突规划	空白	✅ 正确，仅需 438 tokens	1.95s	解决，实际极快
C1 备份方案设计	空白	✅ 五项全中（挂载/rsync/日志/邮件/cron）	8.4s	解决
C2 多约束调度	空白	❌ 仍空白，ct=2000 全耗尽	8.3s（浪费）	未解决
C3 根因分析	空白	⚠️ 有回答但仍错（归因碎片化而非 pp 累积）	8.0s	知识盲区

D3 的特殊发现：D3 实际只需 438 tokens 回答，但 700 tokens 时全部被推理阶段消耗，可见内容始终未能开始输出。这证实了 GPT-OSS 的 reasoning 消耗特性：即使最终答案很短，推理过程也可能远超答案本身的长度。

C2 的上限问题：将 max_tokens 进一步提高到 3000+ 或许能解决 C2，但 C2 类题目（多约束复杂系统设计）在家用 OpenClaw 场景中出现频率极低，当前不视为阻断项。

---

选型结论

场景	推荐模型	理由
OpenClaw 快速通道（H/D/Doc/C1 类）	GPT-OSS 20B Q4_K_M	3.8s 均速，max_tokens=2000 后 66.7%，4.5× 快于 Qwen35
降级兜底 / R 类提醒 / 复杂推理	Qwen3.6-35B A3B Q3_K_M	84.7% 质量，17 tok/s，覆盖 GPT 的弱项
离线分析 / Heartbeat 后端	Qwen3.6-27B Q4_K_M	最高质量（87.5%），低速可接受

更新 OpenClaw 部署建议（双模型架构）：

• 快速通道：GPT-OSS 20B Q4_K_M，max_tokens=4096，系统提示补充格式约束（提醒类任务输出确认而非实现方案）

• 降级精准层：Qwen3.6-35B-A3B Q3_K_M，触发条件：输出空白、含歧义词、R 类格式错误、C2 类多约束题

• 后台 Heartbeat：Qwen3.6-35B-A3B Q3_K_M（精度优先，后台无速度压力）

⚠️ 待实现：llama-server 单次只能加载一个模型。当前回退链停留在配置层面，OpenClaw 需具备主动触发 llama-server 重载的能力——检测到需切换模型时，通过 SSH 调用 schtasks 重启 server 并加载目标 GGUF，同时处理切换期间的请求排队与完成回调。

---

参考资料

• Ollama — gpt-oss:20b

• OpenAI — Introducing gpt-oss

• unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF

• Qwen3-Coder 本地运行 — Unsloth

• unsloth/GLM-4.7-GGUF

• Qwen3.6-27B VRAM 需求 — willitrunai.com

• mudler/Carnice-Qwen3.6-MoE-35B-A3B-APEX-GGUF

• 16GB 显卡运行 35B MoE 实测 — magnus919.com

• BenchLM 本地 LLM 排行

• GPT-OSS 20B 本地部署指南 — runaihome.com

• Qwen3.6 VRAM 量化速查表 — knightli.com

---

延伸阅读

• 《RTX 5080 / 5070Ti 横评数据分析与可视化工具》