为什么 Bonsai-demo 的投机解码默认关闭看懂单槽位限制背后的取舍【免费下载链接】Bonsai-demoBonsai Demo项目地址: https://gitcode.com/GitHub_Trending/bo/Bonsai-demoBonsai-demo 是 Bonsai / Ternary-Bonsai 本地模型部署演示仓库其投机解码DSpark drafter可让 27B 解码在 CUDA 上提速 1.8–2.4 倍。但它默认关闭、且强制单槽位运行——这不是偷懒而是两个关键取舍它禁用了跨请求 prompt 缓存复用并把服务限制为同时只处理一个请求。本文用大白话讲清原理、实测收益、以及为什么 Open WebUI 智能体演示特意不走这条路帮你判断自己该不该开启。投机解码是什么小模型打草稿大模型批改把 27B 主模型想象成一位严谨的教授每个 token 都亲手写稳但慢。投机解码给教授配了一个草稿员——27B 模型随附的dspark drafter伴生小模型约 0.6 GB它一次抢答 4 个 token教授只需一次性验证整段草稿对了就全部收下错了从错的那位退回。温度 0 时输出与不开投机解码完全一致不是近似加速drafter 是目标专属的每个 drafter 只加速它配对的那个模型demo 会自动下载匹配文件接受率随任务波动代码、数学类最划算闲聊类收益最小一行开启BONSAI_SPECULATIVE1 怎么用在 macOS / Linux 上只需给启动脚本加一个环境变量BONSAI_SPECULATIVE1 ./scripts/start_llama_server.shWindowsPowerShell$env:BONSAI_SPECULATIVE 1 .\scripts\start_llama_server.ps1脚本会自动找到 drafter 并追加--spec-type draft-dspark --spec-draft-n-max 4 -ngld 999 -np 1等参数见 start_llama_server.sh并把上下文自动抬高到 16384——因为每个请求都会重新 prefill而 27B 是思考模型常在可见回答前先想 1.5–2k token上下文小了会截断回答。完整说明见 SPECULATIVE.md。⚠️ 小细节--spec-draft-n-max必须等于 drafter 的块大小当前为 4设小了会在第一轮草稿就崩溃。实测收益代码数学最猛闲聊打折社区基准community-benchmarks/汇总的 27B 数据硬件模型不开开启加速NVIDIA DGX Spark (GB10) CUDATernary-27B28.6 t/s70.0 t/s代码任务2.45xNVIDIA L40S 48 GB CUDATernary-27B74.3 t/s~150 t/s2.06x数学 2.4xNVIDIA L40S 48 GB CUDABonsai-27B (1-bit)107.5 t/s~169 t/s1.60xDGX Spark 上的分任务矩阵更说明问题数学 2.62x、代码 2.49x、推理 2.32x闲聊只有 1.97x——收益强依赖任务类型。数据中心级 CUDA GPU 上一个写快排的提示词约从 70 tok/s 提到 135 tok/s接受率 ~0.9。为什么默认关闭三个真实代价SPECULATIVE.md 专门有一节 Trade-offs核心就两条1️⃣ 跨请求 prompt 缓存复用被禁用普通模式下多轮对话的历史前缀会被缓存第二轮、第三轮的首 token很快。开启投机解码后每个请求都重新处理整段对话历史多轮聊天的首 token 延迟反而变差。单看生成速度是快了但对话的整体体验被拉回。2️⃣ 单槽位限制-np 1一次只处理一个请求这是标题里说的单槽位限制。脚本强制-np 1意味着服务同一时刻只服务一个请求第二个请求只能排队多人/多标签页并发使用吞吐体验下降不适合把它当成对外多用户的常驻 API 服务3️⃣ Open WebUI 智能体演示因此坚持走缓存路径正是因为上面两条SPECULATIVE.md 明确写道Open WebUI 的智能体演示刻意留在普通缓存路径上投机解码只存在于独立聊天服务器上。智能体场景工具调用、代码解释器、多轮检索高度依赖 prompt 缓存开了反而更慢。此外还有一个隐性代价上下文被自动抬到 16384KV 缓存内存占用随之上升小显存设备要留意。什么平台、什么场景适合开场景建议NVIDIA GPU 上跑代码生成 / 数学题27B✅ 开1.8–2.6x 实测收益日常闲聊、多轮长对话❌ 别开缓存损失抵消解码收益多用户并发服务❌ 单槽位会排队Apple Silicon (Metal)❌ 官方不推荐仅三值代码/数学约 1.2x聊天/推理和 1-bit 系列反而变慢如何验证投机解码真的生效了每次 API 响应的timings对象里会带draft_n和draft_n_accepted两个字段draft_n缺失或为 0说明投机没跑起来。也可以在另一个端口起一个不带 drafter 的普通服务用同一提示词对比 tok/s 做 before/after 展示方法见 SPECULATIVE.md。 变量参考BONSAI_SPECULATIVE的完整说明见 environment_variables.md。写在最后一句话总结这次 trade-off投机解码用缓存复用 并发槽位换解码速度。如果你是在 CUDA 显卡上写代码、做数学、跑推理的单用户场景它是实打实 2 倍级的免费提速如果你是多轮聊天、多人服务或 Mac 用户保持默认关闭就是更优解。这也正是 Bonsai-demo 把它做成一行环境变量 opt-in、而不是默认打开的原因。【免费下载链接】Bonsai-demoBonsai Demo项目地址: https://gitcode.com/GitHub_Trending/bo/Bonsai-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为什么 Bonsai-demo 的投机解码默认关闭？看懂单槽位限制背后的取舍
为什么 Bonsai-demo 的投机解码默认关闭看懂单槽位限制背后的取舍【免费下载链接】Bonsai-demoBonsai Demo项目地址: https://gitcode.com/GitHub_Trending/bo/Bonsai-demoBonsai-demo 是 Bonsai / Ternary-Bonsai 本地模型部署演示仓库其投机解码DSpark drafter可让 27B 解码在 CUDA 上提速 1.8–2.4 倍。但它默认关闭、且强制单槽位运行——这不是偷懒而是两个关键取舍它禁用了跨请求 prompt 缓存复用并把服务限制为同时只处理一个请求。本文用大白话讲清原理、实测收益、以及为什么 Open WebUI 智能体演示特意不走这条路帮你判断自己该不该开启。投机解码是什么小模型打草稿大模型批改把 27B 主模型想象成一位严谨的教授每个 token 都亲手写稳但慢。投机解码给教授配了一个草稿员——27B 模型随附的dspark drafter伴生小模型约 0.6 GB它一次抢答 4 个 token教授只需一次性验证整段草稿对了就全部收下错了从错的那位退回。温度 0 时输出与不开投机解码完全一致不是近似加速drafter 是目标专属的每个 drafter 只加速它配对的那个模型demo 会自动下载匹配文件接受率随任务波动代码、数学类最划算闲聊类收益最小一行开启BONSAI_SPECULATIVE1 怎么用在 macOS / Linux 上只需给启动脚本加一个环境变量BONSAI_SPECULATIVE1 ./scripts/start_llama_server.shWindowsPowerShell$env:BONSAI_SPECULATIVE 1 .\scripts\start_llama_server.ps1脚本会自动找到 drafter 并追加--spec-type draft-dspark --spec-draft-n-max 4 -ngld 999 -np 1等参数见 start_llama_server.sh并把上下文自动抬高到 16384——因为每个请求都会重新 prefill而 27B 是思考模型常在可见回答前先想 1.5–2k token上下文小了会截断回答。完整说明见 SPECULATIVE.md。⚠️ 小细节--spec-draft-n-max必须等于 drafter 的块大小当前为 4设小了会在第一轮草稿就崩溃。实测收益代码数学最猛闲聊打折社区基准community-benchmarks/汇总的 27B 数据硬件模型不开开启加速NVIDIA DGX Spark (GB10) CUDATernary-27B28.6 t/s70.0 t/s代码任务2.45xNVIDIA L40S 48 GB CUDATernary-27B74.3 t/s~150 t/s2.06x数学 2.4xNVIDIA L40S 48 GB CUDABonsai-27B (1-bit)107.5 t/s~169 t/s1.60xDGX Spark 上的分任务矩阵更说明问题数学 2.62x、代码 2.49x、推理 2.32x闲聊只有 1.97x——收益强依赖任务类型。数据中心级 CUDA GPU 上一个写快排的提示词约从 70 tok/s 提到 135 tok/s接受率 ~0.9。为什么默认关闭三个真实代价SPECULATIVE.md 专门有一节 Trade-offs核心就两条1️⃣ 跨请求 prompt 缓存复用被禁用普通模式下多轮对话的历史前缀会被缓存第二轮、第三轮的首 token很快。开启投机解码后每个请求都重新处理整段对话历史多轮聊天的首 token 延迟反而变差。单看生成速度是快了但对话的整体体验被拉回。2️⃣ 单槽位限制-np 1一次只处理一个请求这是标题里说的单槽位限制。脚本强制-np 1意味着服务同一时刻只服务一个请求第二个请求只能排队多人/多标签页并发使用吞吐体验下降不适合把它当成对外多用户的常驻 API 服务3️⃣ Open WebUI 智能体演示因此坚持走缓存路径正是因为上面两条SPECULATIVE.md 明确写道Open WebUI 的智能体演示刻意留在普通缓存路径上投机解码只存在于独立聊天服务器上。智能体场景工具调用、代码解释器、多轮检索高度依赖 prompt 缓存开了反而更慢。此外还有一个隐性代价上下文被自动抬到 16384KV 缓存内存占用随之上升小显存设备要留意。什么平台、什么场景适合开场景建议NVIDIA GPU 上跑代码生成 / 数学题27B✅ 开1.8–2.6x 实测收益日常闲聊、多轮长对话❌ 别开缓存损失抵消解码收益多用户并发服务❌ 单槽位会排队Apple Silicon (Metal)❌ 官方不推荐仅三值代码/数学约 1.2x聊天/推理和 1-bit 系列反而变慢如何验证投机解码真的生效了每次 API 响应的timings对象里会带draft_n和draft_n_accepted两个字段draft_n缺失或为 0说明投机没跑起来。也可以在另一个端口起一个不带 drafter 的普通服务用同一提示词对比 tok/s 做 before/after 展示方法见 SPECULATIVE.md。 变量参考BONSAI_SPECULATIVE的完整说明见 environment_variables.md。写在最后一句话总结这次 trade-off投机解码用缓存复用 并发槽位换解码速度。如果你是在 CUDA 显卡上写代码、做数学、跑推理的单用户场景它是实打实 2 倍级的免费提速如果你是多轮聊天、多人服务或 Mac 用户保持默认关闭就是更优解。这也正是 Bonsai-demo 把它做成一行环境变量 opt-in、而不是默认打开的原因。【免费下载链接】Bonsai-demoBonsai Demo项目地址: https://gitcode.com/GitHub_Trending/bo/Bonsai-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考