Bonsai-demo Prompt-Cache 性能揭秘多轮对话首 Token 延迟优化完整指南【免费下载链接】Bonsai-demoBonsai Demo项目地址: https://gitcode.com/GitHub_Trending/bo/Bonsai-demoBonsai-demo 是 PrismML 开源的 Bonsai / Ternary-Bonsai 本地大模型演示项目。本文面向新手揭秘它的 prompt-cacheKV 前缀缓存如何让多轮对话的首 token 延迟TTFT大幅下降并给出 4 个开箱即用的优化技巧与一个必须避开的坑。一、Prompt-Cache 是什么为什么它决定首 token 延迟先建立一个直觉模型每回合收到的是全部历史 你的新消息。如果没有缓存每一轮都要把整段对话重新预填prefill一遍——对话越长第一字越慢。prompt-cache 的作用llama.cpp 服务把已算过的 KV 前缀留在显存里下一轮只有新增的那一小段需要真正预填。于是——同一张图的追问近乎瞬时同一话题的多轮对话首 token 越来越快。这正是 Bonsai-demo 文档里反复强调的体验。Bonsai 系列还能在 0.25 GB 级体积上取得 70 分以上的平均基准分27B 更支持262,144 token的长上下文——而 KV 缓存只占 64 KiB/token100K 上下文也只需约 6.3 GiB。体积小 缓存友好是它多轮对话体验好的两大前提。二、零配置开启一行命令获得缓存加速Bonsai-demo 的启动脚本默认就开启了缓存路径flash attention 多槽位服务你不需要任何特殊开关./scripts/start_llama_server.sh # 打开 http://localhost:8080服务默认 4 个并发槽位--parallel多个用户同时对话互不干扰。启动脚本见 scripts/start_llama_server.sh。验证缓存是否生效每个 API 响应都带timings对象其中prompt_ms就是编码 预填耗时——第二轮同话题提问时这个数值会明显小于第一轮。验证命令见 AGENTS.md。三、多轮对话首 Token 延迟优化4 个实用技巧技巧 1保持系统提示前缀稳定缓存命中的前提是前缀逐字相同。系统消息含工具 schema放在对话最前面只要前缀不变后续每轮直接复用缓存。在聊天界面 Settings 里设置固定的 System message给模型一个稳定的Bonsai 身份不要在不同对话间反复开关 MCP 工具服务器——启用集合含顺序一变前缀失效整段重新预填。工具 schema 大约 2,600–2,900 token见 AGENTS.md这个一次性成本被缓存后之后每轮都免费。技巧 2图片只编码一次追问免费27B 是视觉模型一张图会被编码成上千个 vision token是典型的首轮成本。但 prompt-cache 让同一张图的追问近乎瞬时——因为图片 token 已缓存在前缀里详见 VISION.md。慢硬件上建议保留默认的图片 token 上限1024需要 OCR 细小时再用BONSAI_IMAGE_MAX_TOKENS0全量精度。技巧 3长上下文用 4-bit KV多轮不崩内存多轮对话的本质是越来越长的前缀。默认 FP16 KV 每 token 64 KiB100K 上下文约 6.3 GiB开启 4-bit KV 缓存后降到约 18 KiB/token100K 仅需约 1.8 GiB省约 3.5 倍BONSAI_KV41 ./scripts/start_llama_server.sh注意它是省内存工具不是提速工具解码比 FP16 略慢适合内存紧张 超长多轮的场景。可选用./scripts/make_kv_bias.sh生成校准偏置来弥补 4-bit 量化精度损失完整说明见 KV-CACHE.md。同时用BONSAI_CTX控制上下文档位默认按内存自动分配 8K–131K避免 OOM详见 environment_variables.md。技巧 4Mac 上选对后端llama.cpp 有缓存MLX 没有这是最容易踩的坑后端跨请求 prompt-cache多轮体验llama.cpp默认✅ 有前缀复用后续轮次首 token 快MLX❌ 无每轮重算整段对话多轮明显变慢文档明确建议交互式多轮对话优先用默认的 llama.cpp 后端OPENWEBUI.md、AGENTS.md。MLX 的图像编码器本身有缓存但语言模型的 LM 预填每轮重来所以长对话下首 token 延迟差距会随轮数拉大。四、避坑推测解码会关掉 prompt-cacheBONSAI_SPECULATIVE1能让解码提速 1.8–2.4 倍CUDA 上但它强制每个请求重新预填完整历史、并锁定单槽位-np 1即关闭了跨请求 prompt-cache 复用——多轮对话的首 token反而变慢。所以官方策略是推测解码只开在独立聊天服务器上而依赖缓存的 agentic 路径Open WebUI保持普通缓存路径。代码里这段注释写得很直白scripts/start_llama_server.shIt disables prompt-cache reuse and forces a single slot (-np 1), so it is off by default...给新手的决策口诀 单发长代码/数学题、追求生成速度 → 开BONSAI_SPECULATIVE1CUDA 优先 多轮聊天、追问、agent 工具循环 → 保持默认靠 prompt-cache 压低 TTFT权衡细节见 SPECULATIVE.md五、常见问题FAQ问怎么知道这一轮到底省了多少延迟看响应里的timings.prompt_ms编码 预填耗时。同话题第二轮通常显著低于首轮首轮慢是正常的建缓存成本。问开缓存会不会占更多显存会。KV 缓存随上下文增长这正是 27B 混合注意力把它压到 64 KiB/token 的价值所在内存吃紧时用BONSAI_KV41或调小BONSAI_CTX。问换模型/换工具集后缓存会失效吗前缀一变就失效换模型、改系统消息、改 MCP 启用集合都会重建。保持稳定前缀 可变后缀是 TTFT 优化的核心心法。六、总结场景推荐做法多轮聊天默认 llama.cpp 稳定系统提示零配置图片追问保持默认图片上限利用图只编码一次超长对话BONSAI_KV41 按需BONSAI_CTXMac 多轮别用 MLX 后端选 llama.cpp纯生成提速CUDA 上才考虑BONSAI_SPECULATIVE1Bonsai-demo 把 prompt-cache 做成了默认行为你只需保证前缀稳定多轮对话的首 token 延迟就会被缓存默默吃掉大部分。配合 README.md 的 Quick Start两条命令即可上手体验。【免费下载链接】Bonsai-demoBonsai Demo项目地址: https://gitcode.com/GitHub_Trending/bo/Bonsai-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Bonsai-demo Prompt-Cache 性能揭秘：多轮对话首 Token 延迟优化完整指南
Bonsai-demo Prompt-Cache 性能揭秘多轮对话首 Token 延迟优化完整指南【免费下载链接】Bonsai-demoBonsai Demo项目地址: https://gitcode.com/GitHub_Trending/bo/Bonsai-demoBonsai-demo 是 PrismML 开源的 Bonsai / Ternary-Bonsai 本地大模型演示项目。本文面向新手揭秘它的 prompt-cacheKV 前缀缓存如何让多轮对话的首 token 延迟TTFT大幅下降并给出 4 个开箱即用的优化技巧与一个必须避开的坑。一、Prompt-Cache 是什么为什么它决定首 token 延迟先建立一个直觉模型每回合收到的是全部历史 你的新消息。如果没有缓存每一轮都要把整段对话重新预填prefill一遍——对话越长第一字越慢。prompt-cache 的作用llama.cpp 服务把已算过的 KV 前缀留在显存里下一轮只有新增的那一小段需要真正预填。于是——同一张图的追问近乎瞬时同一话题的多轮对话首 token 越来越快。这正是 Bonsai-demo 文档里反复强调的体验。Bonsai 系列还能在 0.25 GB 级体积上取得 70 分以上的平均基准分27B 更支持262,144 token的长上下文——而 KV 缓存只占 64 KiB/token100K 上下文也只需约 6.3 GiB。体积小 缓存友好是它多轮对话体验好的两大前提。二、零配置开启一行命令获得缓存加速Bonsai-demo 的启动脚本默认就开启了缓存路径flash attention 多槽位服务你不需要任何特殊开关./scripts/start_llama_server.sh # 打开 http://localhost:8080服务默认 4 个并发槽位--parallel多个用户同时对话互不干扰。启动脚本见 scripts/start_llama_server.sh。验证缓存是否生效每个 API 响应都带timings对象其中prompt_ms就是编码 预填耗时——第二轮同话题提问时这个数值会明显小于第一轮。验证命令见 AGENTS.md。三、多轮对话首 Token 延迟优化4 个实用技巧技巧 1保持系统提示前缀稳定缓存命中的前提是前缀逐字相同。系统消息含工具 schema放在对话最前面只要前缀不变后续每轮直接复用缓存。在聊天界面 Settings 里设置固定的 System message给模型一个稳定的Bonsai 身份不要在不同对话间反复开关 MCP 工具服务器——启用集合含顺序一变前缀失效整段重新预填。工具 schema 大约 2,600–2,900 token见 AGENTS.md这个一次性成本被缓存后之后每轮都免费。技巧 2图片只编码一次追问免费27B 是视觉模型一张图会被编码成上千个 vision token是典型的首轮成本。但 prompt-cache 让同一张图的追问近乎瞬时——因为图片 token 已缓存在前缀里详见 VISION.md。慢硬件上建议保留默认的图片 token 上限1024需要 OCR 细小时再用BONSAI_IMAGE_MAX_TOKENS0全量精度。技巧 3长上下文用 4-bit KV多轮不崩内存多轮对话的本质是越来越长的前缀。默认 FP16 KV 每 token 64 KiB100K 上下文约 6.3 GiB开启 4-bit KV 缓存后降到约 18 KiB/token100K 仅需约 1.8 GiB省约 3.5 倍BONSAI_KV41 ./scripts/start_llama_server.sh注意它是省内存工具不是提速工具解码比 FP16 略慢适合内存紧张 超长多轮的场景。可选用./scripts/make_kv_bias.sh生成校准偏置来弥补 4-bit 量化精度损失完整说明见 KV-CACHE.md。同时用BONSAI_CTX控制上下文档位默认按内存自动分配 8K–131K避免 OOM详见 environment_variables.md。技巧 4Mac 上选对后端llama.cpp 有缓存MLX 没有这是最容易踩的坑后端跨请求 prompt-cache多轮体验llama.cpp默认✅ 有前缀复用后续轮次首 token 快MLX❌ 无每轮重算整段对话多轮明显变慢文档明确建议交互式多轮对话优先用默认的 llama.cpp 后端OPENWEBUI.md、AGENTS.md。MLX 的图像编码器本身有缓存但语言模型的 LM 预填每轮重来所以长对话下首 token 延迟差距会随轮数拉大。四、避坑推测解码会关掉 prompt-cacheBONSAI_SPECULATIVE1能让解码提速 1.8–2.4 倍CUDA 上但它强制每个请求重新预填完整历史、并锁定单槽位-np 1即关闭了跨请求 prompt-cache 复用——多轮对话的首 token反而变慢。所以官方策略是推测解码只开在独立聊天服务器上而依赖缓存的 agentic 路径Open WebUI保持普通缓存路径。代码里这段注释写得很直白scripts/start_llama_server.shIt disables prompt-cache reuse and forces a single slot (-np 1), so it is off by default...给新手的决策口诀 单发长代码/数学题、追求生成速度 → 开BONSAI_SPECULATIVE1CUDA 优先 多轮聊天、追问、agent 工具循环 → 保持默认靠 prompt-cache 压低 TTFT权衡细节见 SPECULATIVE.md五、常见问题FAQ问怎么知道这一轮到底省了多少延迟看响应里的timings.prompt_ms编码 预填耗时。同话题第二轮通常显著低于首轮首轮慢是正常的建缓存成本。问开缓存会不会占更多显存会。KV 缓存随上下文增长这正是 27B 混合注意力把它压到 64 KiB/token 的价值所在内存吃紧时用BONSAI_KV41或调小BONSAI_CTX。问换模型/换工具集后缓存会失效吗前缀一变就失效换模型、改系统消息、改 MCP 启用集合都会重建。保持稳定前缀 可变后缀是 TTFT 优化的核心心法。六、总结场景推荐做法多轮聊天默认 llama.cpp 稳定系统提示零配置图片追问保持默认图片上限利用图只编码一次超长对话BONSAI_KV41 按需BONSAI_CTXMac 多轮别用 MLX 后端选 llama.cpp纯生成提速CUDA 上才考虑BONSAI_SPECULATIVE1Bonsai-demo 把 prompt-cache 做成了默认行为你只需保证前缀稳定多轮对话的首 token 延迟就会被缓存默默吃掉大部分。配合 README.md 的 Quick Start两条命令即可上手体验。【免费下载链接】Bonsai-demoBonsai Demo项目地址: https://gitcode.com/GitHub_Trending/bo/Bonsai-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
