Ornith 35B 搭配 DFlash 草稿模型，本地推理获 30–40% 加速

近日，Reddit 用户 hurdurdur7 在 r/LocalLLaMA 板块分享了一组本地推理实测：在 llama.cpp 中将 Ornith 35B 与 Qwen3.6 35B DFlash 草案模型组合进行 speculative decoding（推测式解码），实现了可观的 token 生成速度提升。

实测核心结果

• 在混合 JavaScript 代码与维基百科文本、上下文长度约 50k 的测试条件下，主模型 token 生成速度提升约 30–40%
• 草稿模型的接受率约为 80%
• 提示词处理（prompt processing）阶段出现明显性能下降，这是推测式解码常见的代价

作者坦言并不确定 Ornith 35B 与 Qwen3.6 35B DFlash 是否为最佳搭配，但称「已经足够好用」，并强调该方案远非银弹，更适合对输出吞吐敏感、对首 token 延迟不敏感的场景，例如长文本生成或代码补全。

关键配置参数

用户给出的启动命令中，与推测式解码相关的核心参数包括：

• 主模型：bartowski/deepreinforce-ai_Ornith-1.0-35B-GGUF，Q8_0 量化
• 草稿模型：williamliao/Qwen3.6-35B-A3B-DFlash-GGUF，Q8_0 量化
• 草案层数：-sm layer
• 最大草案 token 数：--spec-draft-n-max 4
• 推测解码类型：--spec-type draft-dflash

其他通用参数包括上下文长度 255000、KV cache 量化 f16、Flash Attention 开启、采样温度 0.6、top-p 0.95、top-k 20，并通过 --chat-template-kwargs 保留思考模式（preserve_thinking: true）。

适用场景与局限

该方案对希望在本机部署 35B 级别模型、又追求更高生成速度的用户具有一定参考价值。不过需要注意几点：

• 草稿模型本身也要加载到显存或内存，对硬件提出了更高要求
• Prompt 处理阶段的减速可能拖累短对话和工具调用类应用的首响延迟
• 80% 接受率仅在作者的特定测试分布下测得，未必能复现到所有任务

对追求极致本地推理体验的开发者而言，这是一组可复现的参考配置；但作为通用方案，仍需结合自身硬件与任务类型谨慎评估。