三个本地模型实际运行状况对比报告
数据来源：三份 llama-server 运行日志（真实会话记录，非理论值）
模型 日志文件 运行时段 日志时长 gemma-4-26b google-gemma-4/llama_server_20260927_203847-045.log2026-09-27 20:38 ~53 分钟 Ornith-1.5-35B Ornith-1.5-35B/llama_server_20260914_170912-045.log2026-09-14 17:09 ~6.1 小时（366 分钟） Qwen3.6-35B-Claude4.7Opus Qwen3.6-Claude4.7Opus-35B/llama_server_20260926_211005-045.log2026-09-26 21:10 ~65 分钟
一、测试环境（三者一致）
- 构建：
llama-b9297-bin-win-cuda-12.4-x64 - 硬件：CUDA0 = RTX 4060 8G（主）、CUDA1 = Quadro RTX 3000 12G（副）；CPU i9-12950（24 线程 / 32G 内存）
- 共性启动参数：
--split-mode layer+-ts、--cpu-moe（expert 权重放内存）、--no-mmap、--mlock、KV cacheq8_0、-fa on、--ctx-checkpoints 0、--reasoning off - 接口：llama-server 监听
0.0.0.0:8080，由 8001 token 代理转发
二、三个模型的实际运行状况
1. gemma-4-26b（gemma-4-26B_q4_0-it.gguf）
| 项目 | 实测值 |
|---|---|
| 模型体积 / 量化 | 13.77 GB / q4_0（26B MoE A4B，约 3.8B 激活；hybrid 注意力，40 层中仅 10 层全注意力） |
| 多模态 | ✅ mmproj 1139.46 MiB（gemma4v 投影器）加载成功 |
| 本次运行上下文 | n_ctx = 262144（= n_ctx_train，无需 YaRN） |
| prefill 速度 | 643~661 t/s（全场最快、最稳；44K prompt = 69.1 s，54K prompt = 82.3 s） |
| 生成速度 | 12.9~17.6 t/s，典型 ≈13 t/s |
| 投机解码 | ❌ 无（no implementations specified for speculative decoding） |
| 单轮最长输出 | 2460 tokens 生成耗时213.6 s（≈11.5 t/s） |
| 本次会话最大上下文 | 67,342 tokens（truncated = 0，无截断） |
| 本次会话规模 | 13,429 次 graph 复用 |
| 日志中的异常 | ⚠️VirtualLock 12846383104-byte buffer failed（Windows 无 SeLockMemoryPrivilege，--mlock实际未生效）；⚠️pooling_type [-1] but [1] specified（--embeddings --pooling mean对纯聊天无用） |
实际观察：超长 prompt 的预处理极快（54K 仅 82 秒），但生成偏慢。日志中大量"长 prompt 输入 + 短回答"模式（每轮 4.8 万~5.4 万 token 输入、几百 token 输出），是典型的"整仓/长文档阅读"用法。
2. Ornith-1.5-35B-A3B（APEX-MTP-I-Mini）
| 项目 | 实测值 |
|---|---|
| 模型体积 / 量化 | 13.70 GB（35B MoE A3B，约 3B 激活；含 nextn/MTP 层） |
| 多模态 | ✅ mmproj 857.60 MiB 加载成功 |
| 本次运行上下文 | n_ctx = 131072（日志当时的配置；当前 bat 已提升到 262144） |
| prefill 速度 | 356~452 t/s（三个模型中最慢；随上下文增长从 452 降到 356） |
| 生成速度 | 13.5~21.3 t/s（三个模型中最快，MTP 生效时可达 20+ t/s） |
| 投机解码 | ✅MTPdraft-mtp实际生效，--spec-draft-n-max 1；累计接受 17,842 / 生成 19,523 ≈ 91.4%（单轮区间 77%~100%） |
| 超长 prompt 实测 | 114,567 tokens 的 prefill 耗时 321 s（5.4 分钟），生成 204 tokens |
| 本次会话最大上下文 | 114,771 tokens（接近 131072 上限，truncated = 0） |
| 本次会话规模 | 19,288 次 graph 复用，连续运行 6 小时无重启 |
| 日志中的异常 | 无（全程 0 错误、0 截断、0 取消） |
实际观察：本质是"长会话 / 长输出"型模型。MTP 让解码速度成为三者最快，但--cpu-moe让 expert 走内存带宽，导致 prefill 成为三者最慢——超长 prompt 的等待成本很高（114K ≈ 5.4 分钟）。日志中 prompt cache 本次为关闭状态（--cache-ram N未开）。
3. Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled
| 项目 | 实测值 |
|---|---|
| 模型体积 / 量化 | 16.49 GB（35B MoE A3B，约 3B 激活；Claude 4.7 Opus 推理蒸馏版） |
| 多模态 | ✅ mmproj 857.60 MiB 加载成功 |
| 本次运行上下文 | n_ctx = 262144 |
| prefill 速度 | 484~527 t/s（首轮 527，随长度衰减到 ~484；99K prompt = 205 s） |
| 生成速度 | 11.2~15.8 t/s，典型 ≈14 t/s（长推理输出时降到 ~11 t/s） |
| 投机解码 | ⚠️ 配置了 checkpoint 式投机（speculative decoding will use checkpoints）但未真正生效（no implementations specified） |
| 跨轮缓存 | ❌ 每轮都forcing full prompt re-processing（SWA/hybrid 架构 + 关闭 checkpoint，无法复用前缀） |
| 本次会话最大上下文 | 99,244 tokens（truncated = 0） |
| 本次会话规模 | 3,022 次 graph 复用，运行 ~65 分钟 |
| 日志中的异常 | ⚠️embeddings enabled with n_batch (3072) > n_ubatch (2048)，被强制降为 2048（--embeddings无用开销） |
实际观察：prefill / 生成都居中，最突出的问题是"每轮全量重算前缀"——99K 的长会话每轮都要 200 秒左右重跑 prefill，这是它最大的实用瓶颈。
三、核心指标横向对比
| 指标 | gemma-4-26b | Ornith-1.5-35B | Qwen3.6-35B-Claude4.7Opus |
|---|---|---|---|
| 模型体积 | 13.77 GB | 13.70 GB（最小） | 16.49 GB（最大） |
| 架构 | 26B MoE A4B | 35B MoE A3B | 35B MoE A3B |
| 本次运行上下文 | 262,144 | 131,072 | 262,144 |
| prefill（t/s） | ~650（最快） | ~400（最慢） | ~500 |
| 生成（t/s） | ~13 | ~18（最快） | ~14 |
| MTP 投机解码 | 无 | 有（接受率 91%） | 无 |
| 多模态 | ✅（1139MB mmproj） | ✅（858MB mmproj） | ✅（858MB mmproj） |
| 超长 prompt 等待 | 54K / 82 s | 114K / 321 s | 99K / 205 s |
| 跨轮 prefix 复用 | ❌ | ❌ | ❌ |
| 日志内错误 | 2 条警告 | 0 | 1 条警告 |
| 连续运行 | 53 分钟 | 6.1 小时 | 65 分钟 |
四、优劣对比
gemma-4-26b
- 优势：prefill 吞吐最高且稳定（650 t/s），喂长 prompt 最省时间；体积小、加载快；多模态已实测可用。
- 劣势：无 MTP，生成最慢（~13 t/s）；长输出（2400+ token）单轮要 3.5 分钟；
--mlock在 Windows 上失效，模型页可能被换出；--embeddings --pooling mean属于无用开销并产生警告。 - 定位：“读得快、写得慢”—— 长输入、短输出。
Ornith-1.5-35B-A3B
- 优势：唯一真正跑起 MTP 的模型，生成最快（~18 t/s，峰值 21+）；13.70GB 体积最小；日志全程零错误、连续 6 小时稳定；上下文曾吃满 114K。
- 劣势：prefill 三者最慢（~400 t/s，114K 要 5.4 分钟），超长 prompt 的体验最差；
--cpu-moe使 prefill 受内存带宽限制，加大 batch 收益有限。 - 定位：“写得快、读得慢”—— 中短输入、长输出。
Qwen3.6-35B-A3B-Claude-4.7-Opus
- 优势：指标均衡（prefill ~500、生成 ~14）；Claude 4.7 Opus 推理蒸馏，指令遵循 / 推理风格更贴近高质量 agent 场景；26 万上下文。
- 劣势：投机解码配置了却没生效；每轮强制全量重 prefill，长会话（99K）每轮约 200 s，累积等待最痛；体积最大（16.49GB），显存最紧；
--embeddings导致 batch 被降级。 - 定位：“均衡型 agent 推理模型”，但长会话成本高。
五、适用的任务建议
| 任务类型 | 首选 | 理由（基于实测） |
|---|---|---|
| 长文档 / 整仓阅读理解、代码审阅、摘要问答（输入极大、输出较短） | gemma-4-26b | prefill 650 t/s，54K 输入仅 82 s，等待最短 |
| 长文写作、报告生成、长链推理（输出 token 多） | Ornith-1.5-35B | 生成 ~18 t/s + MTP 接受率 91%，长输出总耗时最低 |
| 多轮 agent / 工具调用 / 指令遵循密集任务（prompt 中等） | Qwen3.6-35B-Claude4.7Opus | 推理蒸馏、指令遵循好；但需把 prompt 压在 ~50K 以内，否则每轮重算代价大 |
| 图片理解 / 多模态问答 | 三者均可 | 三个 mmproj 都已加载成功；gemma4v 对图片尺寸上限更敏感（勿加--image-min-tokens） |
| 超长上下文（>100K token 一次性灌入） | gemma-4-26b（若 128K 够用）或 Ornith（需吃满） | gemma prefill 最快；Ornith 实测能吃 114K 但等待 5 分钟级 |
| 需要长时间连续服务、稳定性优先 | Ornith-1.5-35B | 日志连续 6.1 小时零错误 |
| 显存/内存最紧张时 | Ornith-1.5-35B | 体积 13.70GB，三者最小 |
六、实测暴露的共性问题与优化建议
三者都无法复用跨轮前缀（SWA/hybrid 架构 +
--ctx-checkpoints 0），长会话每轮都要全量重 prefill：- Qwen 99K ≈ 205 s / 轮、Ornith 114K ≈ 321 s / 轮、gemma 54K ≈ 82 s / 轮。
- 这是当前长会话最大的时间成本，应在选型时优先考虑"prompt 长度 vs 模型"的匹配。
--cpu-moe是双刃剑：换来 131K~262K 长上下文，但 prefill 变成内存带宽瓶颈（Ornith 最明显），生成也变慢。若某模型不需要超长上下文，去掉--cpu-moe可显著提速。--mlock在 Windows 上无效（gemma 日志明确报VirtualLock ... failed），需要真正锁内存时应改用其他方式或接受换页风险。--embeddings --pooling mean对纯 chat 场景无收益：gemma 产生 pooling 警告，Qwen 因n_batch(3072) > n_ubatch(2048)被强制降 batch。建议移除。Ornith 的
--image-min-tokens 1024需谨慎：若配套 mmproj 缺少image_max_pixels/image_min_pixels键，mtmd 会把 token 下限换算成像素下限从而触发clip_init中止（gemma 已踩过此坑并移除该参数）；建议换 mmproj 时复查这一项。长 prompt 超时防护依赖 8001 代理的 SSE 心跳：服务端
--timeout需设为-1（Ornith bat 已设），且不要让"超时重试型"客户端直连 8080，否则 prefill 会被反复取消、永远跑不完。
