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.6 35B-A3B UD IQ3_S	综合能力与生产恢复链已验证；独立 Code 候选未通过严格硬门
🥈 次选	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.6-35B-A3B UD IQ3_S，代码请求暂不单独分流。

• Qwen3-Coder-30B Q3_K_M 只作为离线人工草稿候选；实测虽快，但严格工程断言未达到生产门槛。

---

---

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，同时处理切换期间的请求排队与完成回调。

---

生产部署配置（2026-07-20）

llama-server 启动参数

D:\llamacpp\llama-server.exe ^
  -m D:\llamacpp\Qwen_Qwen3.6-35B-A3B-Q3_K_M.gguf ^
  -ngl 99 --no-mmap -c 49152 --parallel 1 -rea off ^
  --host 0.0.0.0 --port 11435

参数	值	说明
-c	49152	KV cache 上下文窗口（见下文选择原因）
--parallel	1	单 slot，避免多 slot 导致 RAM KV 膨胀
-ngl	99	全层 GPU offload
--no-mmap	—	禁用 mmap，确保模型完整加载至 VRAM
-rea off	—	禁用思考模式（OpenClaw 工具调用不需要）

为何是 49152 而非 32768 或 65536：

• Qwen3.6-35B Q3_K_M 模型权重 17.11 GB，微超 16GB VRAM，KV cache 完全落在 RAM

• -c 32768：KV ≈ 4 GB（RAM），速度 17–23 tok/s，但与 OpenClaw 24K 系统提示叠加后仅剩 ~8K 对话窗口，compaction 无空间运作

• -c 65536：曾测试；n_slots=4 × 65536 = ~32 GB KV，RAM 压力极大，实测 tg 3–8 tok/s（不可接受）

• -c 49152 --parallel 1：KV ≈ 6.3 GB（单 slot），预期 tg 约 12–16 tok/s；给 OpenClaw compaction 留足 24K 余量

OpenClaw 模型配置

"llamacpp": {
  "models": [
    {
      "id": "qwen3.6-35b-a3b",
      "contextWindow": 49152,
      "maxTokens": 8192
    }
  ]
},
"agents": {
  "defaults": {
    "compaction": { "reserveTokensFloor": 20000 }
  }
}

Compaction 数学：

OpenClaw 将系统提示也计入 estimatedPromptTokens。实测系统提示 ≈ 24707 tokens。

compaction 触发条件：estimatedPromptTokens > contextWindow - reserveTokensFloor
                   = 49152 - 20000 = 29152

系统提示单独已占 24707，还剩 4445 tokens 给对话
→ 约 5–8 轮对话后触发 compaction

压缩后 prompt：系统提示(24707) + 摘要(< 4445) < 29152 ✓

⚠️ 错误做法：contextWindow 设为 32000 时，budget = 32000 − 20000 = 12000，而系统提示本身 24707 > 12000，无论如何都溢出，compaction 永远失败。
contextWindow 必须满足 contextWindow > sys_prompt_tokens + reserveTokensFloor（即 > 44707）。

---

Claude Code 本地接入部署（2026-07-21）

背景

在确定 Qwen3.6-35B-A3B 模型后，尝试将 Claude Code CLI 接入本地 llama-server，实现零 API 费用的 AI 编程助手。参考稀土掘金文章方案，针对 RTX 5080 + Windows 环境做了一系列适配。

---

模型量化选择：IQ3_S vs Q3_K_M

此前已下载 Qwen_Qwen3.6-35B-A3B-Q3_K_M.gguf，但实测文件大小 15.94 GiB，与 KV Cache 合计超出 16GB 显存，200K 上下文不可行。

量化	文件大小	q4_0 KV @ 200K	总 VRAM	可行性
Q3_K_M	15.94 GiB	~1.0 GiB	~17.7 GiB	❌ 放不下
IQ3_S	12.73 GiB	~1.0 GiB	~14.75 GiB	✅

IQ3_S 采用重要性感知量化（Importance-aware），在略高的 bpw（3.44）下实现更小的文件体积，质量也略优于 Q3_K_M。从 unsloth/Qwen3.6-35B-A3B-GGUF 下载 Qwen3.6-35B-A3B-UD-IQ3_S.gguf，通过 huggingface_hub.hf_hub_download 完成。

---

为何不用 turboquant / turbo3

原文方案使用 turboquant/feature/turboquant-kv-cache 分支提供 3-bit KV Cache（可将 200K KV 压至 0.76 GiB）。但该 GitHub 仓库实测 404，为私有或内部分叉，公开不可用。

替代方案：标准 llama.cpp 内置的 q4_0 KV Cache，200K 下约 1.0 GiB，与 turbo3 相差 0.24 GiB，总 VRAM 仍在 16GB 以内（14.75 GiB），无需重新编译。

---

llama-server 配置

原有 llama-server（b10067）已支持 --cache-type-k q4_0，无需额外编译。

启动参数：

llama-server.exe
  --model [模型目录]\Qwen3.6-35B-A3B-UD-IQ3_S.gguf
  --ctx-size 204800        # 200K 上下文
  --batch-size 1024
  --ubatch-size 512
  --cache-reuse 256
  --cache-ram 16384        # 16 GiB（32GB 系统内存留一半）
  --n-gpu-layers 99
  --threads 16             # 9800X3D 为 8C16T
  --cache-type-k q4_0
  --cache-type-v q4_0
  --flash-attn
  --reasoning off          # 禁用 thinking 模式，Claude Code 需要普通 content 字段
  --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0.05
  --port 8080 --host 0.0.0.0

启动方式（SSH 非交互 session 下 Start-Process 不稳定，推荐本机运行）：

# D:\llamacpp\run_server.py
import subprocess
DETACHED = 0x00000008
args = ['D:\\llamacpp\\llama-server.exe', '--model', '...', ...]
log = open('D:/llamacpp/server.log', 'w')
p = subprocess.Popen(args, stdout=log, stderr=log, cwd='D:\\llamacpp', creationflags=DETACHED)
print('Server started, PID:', p.pid)

D:\miniconda3\python.exe D:\llamacpp\run_server.py

---

Claude Code 配置

%USERPROFILE%\.claude\settings.json：

{
  "ANTHROPIC_BASE_URL": "http://localhost:8080/v1",
  "ANTHROPIC_API_KEY": "<LOCAL-DUMMY-KEY>",
  "includeGitInstructions": false,
  "env": {
    "CLAUDE_CODE_ATTRIBUTION_HEADER": "0",
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
  }
}

核心：CLAUDE_CODE_ATTRIBUTION_HEADER=0 禁用每次请求的动态 telemetry header，否则 llama.cpp 因前缀不匹配无法复用 KV Cache，每次都全量重算（参考文章中从 28.6s 降至 87ms 的优化）。

---

实测结果

指标	数值
VRAM 占用	15.2 GiB / 16 GiB
生成速度	112 tok/s
上下文	200K tokens
量化	IQ3_S，3.44 bpw

生成速度 112 tok/s 显著优于文章中 4080 SUPER 的 41.5 tok/s，主要得益于 RTX 5080 更大的显存带宽（~960 GB/s vs ~672 GB/s）。

---

踩坑记录

• WSL DNS 失效：WSL2 默认 nameserver 10.255.255.254 无法解析域名，ping IP 可达但 git clone 超时；绕过方式：用 Windows 侧 git 或直接修复 /etc/resolv.conf（需 sudo）

• SSH 非交互下 sudo 超时：Mac → Windows SSH → WSL 链路无 tty，sudo 等待密码挂死；需在本机 WSL 终端手动执行 apt 命令

• 两个 llama-server 端口冲突：先前的测试进程残留占用 8080，新进程无法绑定且静默失败；启动前需确认旧进程已退出

• –reasoning off 必要性：Qwen3.6 默认开启 thinking 模式，content 字段为空，Claude Code 无法解析响应；必须在服务端禁用

---

备用模型与视觉能力池（2026-07-26，受控实测）

当前 Qwen3.6-35B-A3B UD IQ3_S 仍是稳定主服务。本轮不是直接替换主模型，而是在 fail-closed handoff 窗口里逐类验证独立能力。

后续能力池按“均衡无 offload”和“质量优先、允许 CPU offload”两档设计：

能力	均衡档方向	质量档方向	使用边界
Coder	Qwen3-Coder 30B-A3B 的显存内量化	更高精度量化并允许部分 CPU offload	独立代码 agent；先验证工具格式与长上下文
低拒答／审计	本地可控的基础或低拒答模型	更高精度版本	仅用于敏感数据的第二意见；默认无工具、隔离运行
通用质量	当前 35B-A3B 的更高精度量化	可接受 offload 的质量模型	不直接替换稳定主服务，先离线盲测
VLM	Qwen3-VL 8B 级别	Qwen3-VL 30B-A3B 级别	独立视觉服务；限制图片尺寸、上下文与并发
文生图	Stable Diffusion 3.5 Medium 级别	FLUX.1-dev 级别	固定 ComfyUI 工作流；先核对许可证
风格迁移／编辑	img2img 与受控参考图工作流	FLUX.1-Kontext 级别	OpenClaw 不得提交任意节点图
超分／修复	Real-ESRGAN 保真超分	SUPIR 生成式修复	生成式修复可能补造细节，必须保留原图并人工核对

真实测评结论

能力	候选与边界	结论
Coder	Qwen3-Coder 30B-A3B Q3_K_M，loopback	传输 6/6，语义 0/6；不接入
VLM	Qwen3-VL 8B Q4_K_M + Q8 projector	语义 3/3；输出带 Markdown fence，须严格 JSON 后处理
文生图	SDXL 1.0 固定 ComfyUI 工作流	运行通过，拓扑约束部分通过
受控编辑	SDXL img2img 两档 denoise	均未做到只改背景；不接入受控编辑
超分	Real-ESRGAN x4plus	NCNN/RTX 输出损坏；PyTorch/ComfyUI 约 0.47 秒通过
通用质量	Qwen3.6 35B-A3B Q3_K_M	三项冻结题通过；显存约 13.56/16.30 GiB，不替换 UD
低对齐顾问	Meta-Llama 3.1 8B abliterated Q4_K_M	4/5，仅限隔离建议，不授予工具或生产路由

通用 Q3_K_M 使用 49,152 context、parallel 1、Q8 KV 和 30 个 GPU layers，三个有效样例分别约 1.75、5.31 和 0.93 秒。低对齐候选固定为公开、非 gated 的 Llama 3.1 权重链，并核对镜像文件与上游 immutable revision 的 SHA-256 完全一致。

需账号接受条件的 FLUX 等模型统一延期，没有绕过 gated 下载；SUPIR 的非商业限制和生成式补细节风险也保留为独立 gate。最终生产恢复验证了 UD IQ3_S、单实例、49,152 context、parallel 1、OpenClaw 路由、session 快照和 cron 状态。OpenClaw 侧状态见 《OpenClaw 后续功能规划》。

第二轮横向测评（OC-20）

第二轮冻结六项代码题、三张视觉图、图像工作流和五项隔离基础能力题。请求夹具先通过固定中文 marker 的 UTF-8 精确回显；PowerShell 5.1 默认编码导致的旧结果全部作废。

类别	候选	有效结果	速度与资源	决策
Code	Qwen3-Coder 30B-A3B Q4_K_M	0/6	平均约 70.8 tok/s；35/48 层上 GPU	不晋级
Code	Qwen2.5-Coder 14B Q6_K	0/6	平均约 65.3 tok/s；48/48 层上 GPU	不晋级
Code	Qwen3.6-27B Q4_K_M	1/6	平均约 11.1 tok/s；48/64 层上 GPU；两题截断	不晋级
VLM	30B VLM + Q8 projector	UI／图表／表格 3/3	P50 2.18 秒；平均 55.7 tok/s；实测显存约 14.9 GiB	晋级横评
文生图	Qwen Image Q3_K_M	1/1	约 69 秒；实测显存点约 11.4 GiB	晋级固定工作流
图片编辑	Qwen Image Edit Q3_K_M + 当前 Q4 encoder	0/1	视觉投影维度不匹配，未产生输出	更换兼容 encoder 后重测
隔离基础能力	Dolphin 3.0 Llama 3.1 8B Q4_K_M	5/5	中位 82 ms；平均 158.1 tok/s；显存约 6.55 GiB	仅隔离候选

代码组的失败集中在进程树终止、Windows argv、严格 JSON 边界、回滚状态机和测试实现与断言不一致；量化提高没有解决冻结任务上的实现违约。Qwen3.6-27B 唯一通过严格解析器，但速度、CPU offload 和截断成本都很明显。

Code 独立路由终局复测（2026-08-15）

随后使用完整 Code v3 / cyber 同题集，对 Qwopus 18B Q4、Qwen3-Coder 30B Q3 和生产 Qwen3.6 UD IQ3_S 各运行两轮，共 138/138 次传输成功。三者两轮逐题输出均完全一致。

模型	平均生成速度	端到端中位 / P95	峰值显存	每轮长度截断	裁决
Qwen3-Coder 30B Q3	212.16 tok/s	2.98 / 5.98 秒	约15.82 GiB	4/23	最快，但严格关键失败稳定复现；仅离线L0草稿
生产 Qwen3.6 UD IQ3_S	170.54 tok/s	4.65 / 12.13 秒	约14.04 GiB	14/23	继续统一处理代码请求
Qwopus 18B Q4	71.28 tok/s	14.54 / 28.97 秒	约10.66 GiB	17/23	截断和实现缺陷更重，不晋级

Q3 的优势是 MoE 推理速度和较低截断率，但它复现了重复 JSON 键、真实测试执行、PowerShell parser/rollback、伪造观察、shell 拼接和边界处理等既有 critical failure。Qwopus 则在进程树、测试真实性和事务实现上同样未过硬门。由于候选必须同时证明相对 UD 至少 10 个百分点的质量优势、关键断言显著改善、两轮稳定且无新增 critical failure，速度优势不能单独成立独立 Code 路由；当前继续由 UD 统一处理更合理。

视觉组的 30B VLM 能稳定解析 UI、图表和表格，并通过严格 schema。Qwen Image 生成的中文标签与连接关系正确；编辑失败不是显存崩溃，而是当前量化 encoder 的视觉投影维度与 Edit 节点不兼容。已冻结免认证、许可明确的官方 FP8 encoder，但当前下载链路过慢，保留续传片段后停止，没有让 Mac 承担大模型下载。

Dolphin 只用于隔离的通用解释、事实、严格 JSON、格式遵循和安全虚构对白。即使基础五题全部通过，也不授予 Agent、工具、网络、凭据、私人数据或生产路由权限。

四类真实 GPU 窗口均由 controller 与 Guardian ownership 保护：候选只监听 loopback，先切云端并排空请求，恢复后核对正式 UD 模型、单实例、路由、21 个 session 与六项 cron。Guardian 保持 dryRun=true，真实动作数为零。最新任务边界与后续顺序见 《OpenClaw 后续功能规划》。

双档留存规则与第三轮收口（2026-08-07）

能力池进一步冻结为“性能版 + 均衡版”双档：除 default 文本模型外，每类专业能力都要有两份独立可部署权重。性能档优先延迟和资源，均衡档优先质量与稳定性；共享 encoder、VAE、projector 不单独算一档，同一权重只改参数也不能冒充两档。替代模型未完成来源、许可、revision、SHA、质量、性能和失败模式验收前，现有候选与唯一横评基线不删除。

项目	复测结果	当前定位
Code Qwen3-Coder 30B Q4 / Qwen2.5-Coder 14B Q6	统一到 4096 tokens、jinja、reasoning-off 后仍均为 0/6	保留横评基线，继续筛选新候选
Qwen Image Edit 2511 Q3 + FP8 encoder	成功加载并真实出图，无 OOM；但主体位置、尺寸、阴影和画布发生非目标变化	兼容通过，严格编辑保真失败
Qwen3-4B Q4 请求路由	Win11 主集 40 条 97.5%，独立 holdout 32 条 96.875%；JSON 100%、高风险漏判 0；冷/热 TTFT 87/26 ms，8 路短请求最慢 929 ms	非生产性能档验收完成
PaddleOCR-VL 1.6 GGUF	20 份矩阵中，公开页 CER/WER 5.41%/5.70%，峰值显存 2857 MiB；旋转鲁棒，但严格双栏顺序失败	非生产均衡档验收完成

Qwen3-4B 的两个错误分别是把低对齐请求和视觉请求分到通用本地模型，因此即使达到准确率门槛，也只能放在确定性隐私／高风险规则之后，以严格解析、低置信回退和影子模式验证；分类结果不能直接扩大工具权限或触发生产模型切换。

Win11 OCR 与分类器收口（2026-08-09）

OCR 矩阵最终扩展到 20 份有效样本：10 份规整合成表格、6 份旋转／低对比／密集表格／双栏／空白退化夹具，以及两份 OGL v3.0 多页公开 PDF 的 4 个真实页面。公开页以 PDF 内嵌文本为参考，PaddleOCR-VL 的平均 CER/WER 为 5.41%/5.70%，Tesseract 为 6.27%/8.11%；Paddle 对 90°、180°旋转恢复完整，真实页耗时 3.60–5.24 秒，观测峰值显存 2857 MiB。Tesseract 仅需 0.29–0.91 秒，但旋转失败。两者在严格双栏顺序上都会按行交错，故 Paddle 只能晋级非生产均衡档，不能单独裁决复杂版面结构。

家庭场景下，这一结果已经可用：普通正向文档优先走 Tesseract，旋转、低质量页面再回退 Paddle；票据、说明书和非关键 PDF 可直接用于搜索索引或预填。合同、金额、账号、证件及复杂表格必须同时展示原图并人工核对，不能让 OCR 输出直接触发付款、删除、权限或系统配置操作。“非生产”描述的是责任边界，而不是模型无法提供实用价值。

Qwen3-4B 的未接线影子适配器也完成了连续请求、2/4/8 路单槽排队、SSE TTFT 和失败路径验证：模型就绪约 2.1 秒，冷／热 TTFT 为 87/26 ms，8 路最慢 929 ms；无效 JSON、非法 route、低置信、高风险请求及离线 endpoint 均回退 ask。它适合为家庭助手提供低风险路由建议，但分类结果不直接切换生产模型、不扩大工具权限，也不取代确定性规则和人工确认。

本轮所有测试服务只监听 loopback，结束后已清理临时计划任务、进程和端口；OpenClaw、controller、Guardian 与 session 的生产配置均未修改。当前图片模型也不是专门的“去对齐”版本：Qwen Image/Edit 是官方模型的社区量化，SDXL Base 是通用基础模型；本地工作流没有额外云端审核器，但模型自身仍有训练形成的内容边界和能力限制。低对齐池目前只有隔离文本候选，不含专门的低对齐生图模型。

自包含证据与精确清理（2026-08-10）

最终 v3 证据包把 20 个输入夹具、两份公开 PDF、最终与历史 JSON、生成／运行／分析脚本、模型来源与许可、runtime 身份，以及 Qwen 原始 HTTP/SSE 传输记录统一冻结；顶层 manifest 覆盖除自身外的 82 个文件，独立复算为 82/82 SHA-256 通过。OCR 分析脚本只读取包内文件即可重算 CER/WER，重算结果与冻结的 ocr-analysis.json 字节一致；因此这里的 5.41%/5.70% 和 6.27%/8.11% 不依赖报告中的手工摘要。

Qwen v3 是对“原始传输证据”的补强，不替换前述性能基线：该轮模型就绪 1,893 ms，冷／热请求均返回 HTTP 200 与合法 local_general/0.9；8/8 排队请求全部成功，最慢 1,481 ms；SSE 共 18 帧，首个数据帧 50 ms、完整响应 240 ms。测试后进程和监听均为零。不同轮次的请求体和采样目标不同，不能把 1,481 ms 与基线的 929 ms 混写成性能回归。

证据冻结并独立验收后，只删除了逐路径、逐 SHA 授权的可重建冗余：Paddle 原始 Transformers/safetensors 副本、Tesseract 安装中转与重复语言文件、重复或空日志，总计永久释放 1,955,924,686 bytes。删除不经过回收站；空间收益以删除前逐文件 bytes 合计证明，而不是易受并发写入影响的盘符空闲差值。

KEEP 门禁仍保护 Qwen3-4B、Paddle GGUF 与 mmproj、Dolphin 8B、唯一 llama.cpp b10067 runtime、已安装 Tesseract、全部最终夹具、结果 JSON、来源 manifest 和复现脚本。清理后四份保留模型 SHA、runtime、Tesseract、进程与端口验收均通过。后续冗余整理不得以“已写入博客”替代原始证据，也不得删除这些唯一复现材料。

冗余治理：何时不该继续删除

这次清理没有按文件大小或“测试已经结束”直接判断，而是先给每项补齐来源、引用者、SHA、是否为唯一复现材料，以及能否按固定 revision 重建。管理员入口只用于只读复核计划任务、服务、Startup 和 Run 的路径引用；实际清理由受限账户优先执行。遇到 ACL 拒绝或并行状态变化时立即停止并重新读取现场，不能用管理员代删、放宽 ACL，或沿用几分钟前的清单继续操作。

首轮最终永久删除 26 项、共 1,955,924,686 bytes，均为已冻结来源且可重建的副本或完全重复／空文件。第二阶段没有为了“清干净”继续扩张范围：8 个剩余 stderr 合计只有 58,451 bytes，归档后远端与 Mac 的 bytes、SHA 逐项一致，manifest 10/10 通过；但日志仍包含模型路径、runtime 后端、context、监听端口、加载时序和推理 timing。因为收益低于预设的 1 MiB 门槛且会削弱现场复现性，最终全部 KEEP，新增删除为零。

因此，空间治理的完成条件不是“候选列表为空”，而是剩余内容的证据价值已经高于可释放空间。Qwen3-4B、Paddle GGUF 与 mmproj、Dolphin、唯一 runtime、Tesseract、fixtures 和脚本也遵循同一原则：只要仍是能力档、评测链或恢复链的一部分，就不能因阶段结束而判为冗余。博客只记录决策摘要，真正的恢复与审计依据仍是原始 evidence、manifest、路径和 SHA。

OC-20 后续候选状态（2026-08-11）

第二轮之后新增的候选仍严格区分“文件已验证”和“质量已验收”，不会因下载完成就进入能力池或生产路由：

候选	当前证据	当前决策
Dolphin 3.0 Mistral 24B Q4_K_M	14.33 GB 文件、固定社区 revision/SHA、32K prompt、2048 generation 与19项质量/10次稳定性均已冻结	extract JSON带Markdown fence，未过严格格式门禁；不晋级、不接生产
Dolphin 3.0-R1 Mistral 24B Q4_K_M	续传完成并通过14.33 GB bytes/SHA；性能矩阵与普通版接近	19项质量及10次稳定性全部从<think>开始，约束输出失败；不晋级、不接生产
SwinIR-L x4 GAN	三公开夹具、重复性与768×480 tile stress完成；tile输出3072×1920、4.23秒、峰值7433 MiB	chart/document指标优于bicubic，但ui-dialog PSNR退化且文字明显重构；不晋级均衡档
Devstral Small 2 24B Q4_K_M	固定 revision、14,334,438,272 bytes 与 SHA；快门禁约53 tok/s	两题均通过传输但违反严格语义：重复键未拒绝、bool被当作数值；不进入完整评测，不晋级
Unlimited-OCR（gundam/base）	离线重算先剥离det/bbox和HTML结构，公开页CER为5.33%/5.40%、WER为6.84%/7.00%，空白页正确拒识	旧评分器污染结论撤销；但gundam 180°、base 90°/180°仍失败，且WER仍差于PaddleOCR-VL 5.70%，两模式不晋级

这些任务均使用公开或合成夹具、临时 loopback 服务和串行 GPU 窗口。测试结束后不修改 OpenClaw、controller、Guardian 或用户会话；只有来源、许可、revision、摘要、性能与质量均通过的候选，才有资格参与“双档留存”决策。

SwinIR 的客观指标需要结合保真目标解释：chart 为 28.404 dB / 0.97679、document 为 22.692 dB / 0.97195，均高于 bicubic；但 ui-dialog 的 24.761 dB 低于 bicubic 25.192 dB。更关键的是，三张图的图例、表头、正文和按钮文字都出现笔画粘连或乱码。它能锐化边缘、tile 也稳定，却不适合“文本截图必须忠实”的均衡超分路径；当前继续保留 Real-ESRGAN PyTorch x4plus 性能档与所有候选证据，不因不晋级删除模型。

Devstral 与 Unlimited-OCR 的结果进一步说明，速度或全量执行成功不能替代语义和质量门禁。修正评分口径后，Unlimited-OCR 两模式的空白页均为正确拒识；但gundam仅通过90°旋转、180°失败，base两种旋转均失败。现有OCR双档继续保留Tesseract性能档与PaddleOCR-VL非生产均衡档；本轮模型、runtime与证据均保留用于复算，未接入生产。

低对齐三档场景横评 v3（2026-08-14）

本轮不再把“拒绝越多”视为更好，而是在相同的48项冻结集上比较实际任务完成、逻辑一致性、输出完整度、无谓拒绝和性能。测试包含30项合法日常任务及18项非日常拒绝诊断；三份权重均在完全离线、无工具、无凭据、无私人数据和无生产接入的loopback环境中完成48/48传输。

档位	合法任务严格完成	严格结构	P50 / P95	生成中位数	峰值显存	结论
Qwen3.6 35B-A3B Abliterated v2 IQ3_S	22/30	4/4	2.84 / 5.58秒	187.7 tok/s	15,594 MiB	内容和格式最强，但6项在实用预算内未收束，另有逻辑不足、长度超限和一次未复现runtime崩溃；KEEP，不晋级均衡档
Dolphin3.0 Llama3.1 8B Q4_K_M	25/30	1/4	1.58 / 3.42秒	156.9 tok/s	6,396 MiB	继续作为隔离性能档；低资源、任务完成率最高，但结构能力弱
生产Qwen3.6 35B-A3B UD IQ3_S	约23/30	3/4	0.78 / 5.89秒	176.8 tok/s	13,862 MiB	仅作为default对照，不计作第二份低对齐独立权重

35B Abliterated在18项拒绝诊断中基本都会给出实质内容，说明它确实具有强低拒绝特征，也说明不能依靠模型自身形成安全边界。该权重只能作为隔离候选，不能获得OpenClaw、Agent、网络、真实工具、凭据、私人数据或生产路由权限。首次场景运行曾在C runtime中以BEX64终止；加入逐题增量落盘、进程退出fail-fast及30秒稳定空闲门后，独立48项重跑未复现，但这条稳定性风险仍保留。

当前低对齐能力仍只有Dolphin 8B性能档，均衡档继续缺位。后续将对35B做能力边界消融，独立控制system prompt、上下文与输出预算、schema、任务类别和重复种子；只允许离线mock工具协议，不连接真实OpenClaw或任何可行动工具。

desktop 远程维护最小权限（2026-08-09）

为把模型评测与日常远程维护分开，desktop 新增受限标准 SSH 账户作为默认入口：其不属于 Administrators，并禁用密码登录、PTY、端口转发、X11 与 user-rc。需要系统级维护时才显式使用独立的管理员入口。该变更已通过 SSH 配置校验和非管理员／PTY 拒绝验证；未改防火墙、OpenClaw 或模型服务。

参考资料

• 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 横评数据分析与可视化工具》