三个本地模型实际运行状况对比报告数据来源三份 llama-server 运行日志真实会话记录非理论值模型日志文件运行时段日志时长gemma-4-26bgoogle-gemma-4/llama_server_20260927_203847-045.log2026-09-27 20:38~53 分钟Ornith-1.5-35BOrnith-1.5-35B/llama_server_20260914_170912-045.log2026-09-14 17:09~6.1 小时366 分钟Qwen3.6-35B-Claude4.7OpusQwen3.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-1295024 线程 / 32G 内存共性启动参数--split-mode layer-ts、--cpu-moeexpert 权重放内存、--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-26bgemma-4-26B_q4_0-it.gguf项目实测值模型体积 / 量化13.77 GB / q4_026B MoE A4B约 3.8B 激活hybrid 注意力40 层中仅 10 层全注意力多模态✅ mmproj 1139.46 MiBgemma4v 投影器加载成功本次运行上下文n_ctx 262144 n_ctx_train无需 YaRNprefill 速度643~661 t/s全场最快、最稳44K prompt 69.1 s54K 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 tokenstruncated 0无截断本次会话规模13,429 次 graph 复用日志中的异常⚠️VirtualLock 12846383104-byte buffer failedWindows 无 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-A3BAPEX-MTP-I-Mini项目实测值模型体积 / 量化13.70 GB35B MoE A3B约 3B 激活含 nextn/MTP 层多模态✅ mmproj 857.60 MiB 加载成功本次运行上下文n_ctx 131072日志当时的配置当前 bat 已提升到 262144prefill 速度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 s5.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 GB35B MoE A3B约 3B 激活Claude 4.7 Opus 推理蒸馏版多模态✅ mmproj 857.60 MiB 加载成功本次运行上下文n_ctx 262144prefill 速度484~527 t/s首轮 527随长度衰减到 ~48499K 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-processingSWA/hybrid 架构 关闭 checkpoint无法复用前缀本次会话最大上下文99,244 tokenstruncated 0本次会话规模3,022 次 graph 复用运行 ~65 分钟日志中的异常⚠️embeddings enabled with n_batch (3072) n_ubatch (2048)被强制降为 2048--embeddings无用开销实际观察prefill / 生成都居中最突出的问题是每轮全量重算前缀——99K 的长会话每轮都要 200 秒左右重跑 prefill这是它最大的实用瓶颈。三、核心指标横向对比指标gemma-4-26bOrnith-1.5-35BQwen3.6-35B-Claude4.7Opus模型体积13.77 GB13.70 GB最小16.49 GB最大架构26B MoE A4B35B MoE A3B35B MoE A3B本次运行上下文262,144131,072262,144prefillt/s~650最快~400最慢~500生成t/s~13~18最快~14MTP 投机解码无有接受率 91%无多模态✅1139MB mmproj✅858MB mmproj✅858MB mmproj超长 prompt 等待54K / 82 s114K / 321 s99K / 205 s跨轮 prefix 复用❌❌❌日志内错误2 条警告01 条警告连续运行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峰值 2113.70GB 体积最小日志全程零错误、连续 6 小时稳定上下文曾吃满 114K。劣势prefill 三者最慢~400 t/s114K 要 5.4 分钟超长 prompt 的体验最差--cpu-moe使 prefill 受内存带宽限制加大 batch 收益有限。定位“写得快、读得慢”—— 中短输入、长输出。Qwen3.6-35B-A3B-Claude-4.7-Opus优势指标均衡prefill ~500、生成 ~14Claude 4.7 Opus 推理蒸馏指令遵循 / 推理风格更贴近高质量 agent 场景26 万上下文。劣势投机解码配置了却没生效每轮强制全量重 prefill长会话99K每轮约 200 s累积等待最痛体积最大16.49GB显存最紧--embeddings导致 batch 被降级。定位“均衡型 agent 推理模型”但长会话成本高。五、适用的任务建议任务类型首选理由基于实测长文档 / 整仓阅读理解、代码审阅、摘要问答输入极大、输出较短gemma-4-26bprefill 650 t/s54K 输入仅 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长会话每轮都要全量重 prefillQwen 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需设为-1Ornith bat 已设且不要让超时重试型客户端直连 8080否则 prefill 会被反复取消、永远跑不完。
三个本地26B/35B大模型实际运行状况对比报告
三个本地模型实际运行状况对比报告数据来源三份 llama-server 运行日志真实会话记录非理论值模型日志文件运行时段日志时长gemma-4-26bgoogle-gemma-4/llama_server_20260927_203847-045.log2026-09-27 20:38~53 分钟Ornith-1.5-35BOrnith-1.5-35B/llama_server_20260914_170912-045.log2026-09-14 17:09~6.1 小时366 分钟Qwen3.6-35B-Claude4.7OpusQwen3.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-1295024 线程 / 32G 内存共性启动参数--split-mode layer-ts、--cpu-moeexpert 权重放内存、--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-26bgemma-4-26B_q4_0-it.gguf项目实测值模型体积 / 量化13.77 GB / q4_026B MoE A4B约 3.8B 激活hybrid 注意力40 层中仅 10 层全注意力多模态✅ mmproj 1139.46 MiBgemma4v 投影器加载成功本次运行上下文n_ctx 262144 n_ctx_train无需 YaRNprefill 速度643~661 t/s全场最快、最稳44K prompt 69.1 s54K 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 tokenstruncated 0无截断本次会话规模13,429 次 graph 复用日志中的异常⚠️VirtualLock 12846383104-byte buffer failedWindows 无 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-A3BAPEX-MTP-I-Mini项目实测值模型体积 / 量化13.70 GB35B MoE A3B约 3B 激活含 nextn/MTP 层多模态✅ mmproj 857.60 MiB 加载成功本次运行上下文n_ctx 131072日志当时的配置当前 bat 已提升到 262144prefill 速度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 s5.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 GB35B MoE A3B约 3B 激活Claude 4.7 Opus 推理蒸馏版多模态✅ mmproj 857.60 MiB 加载成功本次运行上下文n_ctx 262144prefill 速度484~527 t/s首轮 527随长度衰减到 ~48499K 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-processingSWA/hybrid 架构 关闭 checkpoint无法复用前缀本次会话最大上下文99,244 tokenstruncated 0本次会话规模3,022 次 graph 复用运行 ~65 分钟日志中的异常⚠️embeddings enabled with n_batch (3072) n_ubatch (2048)被强制降为 2048--embeddings无用开销实际观察prefill / 生成都居中最突出的问题是每轮全量重算前缀——99K 的长会话每轮都要 200 秒左右重跑 prefill这是它最大的实用瓶颈。三、核心指标横向对比指标gemma-4-26bOrnith-1.5-35BQwen3.6-35B-Claude4.7Opus模型体积13.77 GB13.70 GB最小16.49 GB最大架构26B MoE A4B35B MoE A3B35B MoE A3B本次运行上下文262,144131,072262,144prefillt/s~650最快~400最慢~500生成t/s~13~18最快~14MTP 投机解码无有接受率 91%无多模态✅1139MB mmproj✅858MB mmproj✅858MB mmproj超长 prompt 等待54K / 82 s114K / 321 s99K / 205 s跨轮 prefix 复用❌❌❌日志内错误2 条警告01 条警告连续运行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峰值 2113.70GB 体积最小日志全程零错误、连续 6 小时稳定上下文曾吃满 114K。劣势prefill 三者最慢~400 t/s114K 要 5.4 分钟超长 prompt 的体验最差--cpu-moe使 prefill 受内存带宽限制加大 batch 收益有限。定位“写得快、读得慢”—— 中短输入、长输出。Qwen3.6-35B-A3B-Claude-4.7-Opus优势指标均衡prefill ~500、生成 ~14Claude 4.7 Opus 推理蒸馏指令遵循 / 推理风格更贴近高质量 agent 场景26 万上下文。劣势投机解码配置了却没生效每轮强制全量重 prefill长会话99K每轮约 200 s累积等待最痛体积最大16.49GB显存最紧--embeddings导致 batch 被降级。定位“均衡型 agent 推理模型”但长会话成本高。五、适用的任务建议任务类型首选理由基于实测长文档 / 整仓阅读理解、代码审阅、摘要问答输入极大、输出较短gemma-4-26bprefill 650 t/s54K 输入仅 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长会话每轮都要全量重 prefillQwen 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需设为-1Ornith bat 已设且不要让超时重试型客户端直连 8080否则 prefill 会被反复取消、永远跑不完。
