Pi + DeepSeek V4 实践：模型分流与 Token 全链路优化

Pi + DeepSeek V4 实践：模型分流与 Token 全链路优化

TL;DR — 默认模型设为 deepseek-v4-flash，model-router 自动分流复杂任务到 deepseek-v4-pro，配合 Caveman 压缩回复、tokenomy 分级限 Token、pi-rtk 缩减输入，实现高效的 LLM 使用方案。

核心收获

• 分层分配：默认 deepseek-v4-flash 处理日常任务，deepseek-v4-pro 处理复杂任务，按需路由不浪费
• 自动分流：model-router 关键词匹配，80% 任务走 Flash，20% 复杂任务走 Pro，无需手动切
• 输入 -68%：pi-rtk 砍代码冗余 + DCP 剪旧上下文 + tokenomy 分级限 Token + pi-tokensaver 细粒度优化，四层叠加
• 输出 -75%：caveman 去掉废话保留技术信息，一条回复 500 → 120 Token，极限压缩
• 缓存命中：DeepSeek cache_control 支持 Prompt 缓存，命中后输入 Token 再降 50%
• 质量保障：pi-reasonix Pro 模型推理增强 + model-router 置信检查闭环，压缩不丢准确度

---

图表摘要：三层架构 — ① 模型层（v4-pro 处理架构/审阅/调试，v4-flash 处理日常编码）→ ② 插件层（rtk/DCP/tokenomy/tokensaver 缩减输入，model-router 分流，caveman 压缩输出）→ ③ Skill 层（6 个技能覆盖搜索、追问、写作、发布全流程）。输入 -68%，输出 -75%。

---

为什么换 DeepSeek

日常改 bug、写测试、查文档这些场景，很多时候并不需要最强模型。DeepSeek V4 Flash 有 128K 上下文窗口，输出上限 8K Token，处理日常编码任务绰绰有余。遇到架构设计、复杂代码审阅、多模块交叉调试这类场景，才需要上 Pro——后者支持深度推理模式（thinking: true），配合 pi-reasonix 效果更佳。

Pi 原生支持 30 多种模型，/model 或 Ctrl+L 随时切换，切换成本接近零。问题不是"能不能用 DeepSeek"，而是"怎么让 DeepSeek 在大多数场景自动干活，只在必要时才上贵的模型"。

---

模型分流

两个模型，各司其职

图表摘要：用户输入 → model-router 按关键词分流 → plan/design/review/debug 走 Pro（深度推理），implement/fix/test/explain 走 Flash（快速响应）。80% 日常任务自动走 Flash，无需手动切换。

安装 model-router 后，它会根据你输入的关键词自动选模型：

• 说"帮我设计一个缓存方案" → 识别到 design → 走 Pro
• 说"修这个按钮的样式" → 识别到 fix → 走 Flash

路由规则配置在 model-router.json，可以自定义：

{
  "rules": [
    { "matches": ["plan", "design", "review", "debug"], "tier": "high" },
    { "matches": ["implement", "fix", "test", "edit"], "tier": "medium" },
    { "matches": ["explain", "what is", "how to"], "tier": "low" }
  ]
}

实际开发中一个请求往往混合多种意图——比如"review 一下代码，顺便 implement 修复"同时命中了 high 和 medium 两个 tier。model-router 默认按首个命中规则处理，规则数组顺序直接影响结果——如果 implement/fix 排在最前面，包含 review 的请求也可能被 Flash 接走。建议把高优先级规则（review/debug/design）放在数组顶部，或扩展 router 增加"复杂度加权评分"：结合输入长度、代码块占比、"架构/权衡/为什么"等语义特征动态计算置信度，再映射到 tier。

---

Token 节省

选对模型只是第一步。真正的大头是控制每次对话的 Token 用量。

全链路流程

图表摘要：Token 节省全链路 — 输入阶段：pi-rtk 砍代码冗余 → DCP 剪旧上下文 → tokenomy 分级限 Token → tokensaver 细粒度优化 → 模型层：model-router 自动 80/20 分流 → 输出阶段：caveman 压缩回复 75% → 最终输出（技术细节保留）。

注：以上 -68% 输入 / -75% 输出比例基于日常编码场景（代码 + 简短注释）。对于长文档总结、设计讨论等非代码场景，pi-rtk 对纯文本基本不生效，压缩率会下降至 30%-50% 左右，主要依赖 DCP + tokenomy + caveman。建议根据自身任务类型调整预期。

pi-rtk + DCP

pi-rtk 负责砍代码里的冗余——import 块、重复的类型声明、长路径前缀、未使用的变量引用等。对于典型的 TypeScript/React 项目，import 和类型声明能占到 prompt 的 20-30%，rtk 可以自动识别并裁剪。DCP（dynamic-context-pruning）管的是对话历史——当讨论从"修 API 超时"转向"改 UI 布局"，之前的 API 诊断上下文自动砍掉。一个走代码层面，一个走对话层面，叠加不冲突，合计可节省 40-55% 输入 Token。

tokenomy + pi-tokensaver

tokenomy 按任务复杂度分三档控制 Token 预算：

复杂度	模型	思考级别	场景
Simple	Flash	minimal	快速问答
Medium	Flash	low	日常编码
Complex	Pro	medium	架构设计

同时还做行截断（超 200 字符砍掉）、上下文精简（只留前后各 12 行）、持久记忆（60 条关键事实跨会话复用）。

pi-tokensaver 在 tokenomy 基础上做更细的优化——检测重复模式、冗余错误栈、过长路径前缀这些。两者叠加能省约 30% 的上下文 Token。

caveman

安装 @nielpattin/pi-caveman 后，加一行 "caveman": "on" 就能启用。它让 Pi 去掉回复里的废话——冠词、过渡语、客套话，保留技术术语和代码。一条回复从 500 Token 砍到 ~120，省 75%。实际效果对比：

压缩前（~180 Token）："没问题！我可以帮您解决这个缓存方案的设计问题。让我们先分析一下您当前的场景。您提到的是一个 Redis 缓存方案的选型，对于这个问题，我建议您从以下几个方面来入手。首先需要明确您的缓存策略..."

压缩后（~45 Token）："Redis 缓存选型：① write-through vs write-behind ② TTL + 主动失效策略 ③ 缓存穿透/击穿/雪崩防护"

技术要点全部保留，废话全部裁掉。

压缩的风险在于"硬信息"丢失——配置路径、版本号、API 参数、异常栈上下游等细节在过度压缩时可能被裁掉，导致用户无法准确复现问题，反而需要多轮对话重新获取。建议搭配 pi-ask-user 做关键细节确认：当输出涉及路径、版本、参数变更时，自动触发一次追问，既省了 Token，又避免了压缩导致的重试成本。

遇到需要详细说明的场景，说 stop caveman 就恢复了。

pi-reasonix

一口气上了这么多优化手段，回复质量会不会降？reasonix 就是干这个的——只在走 Pro 模型时增强推理，确保压缩后的回复仍然准确。

更进一步：结合模型回答置信度判断，当置信度低于阈值时自动升级到 Pro + reasonix 重新推理，可形成闭环——避免"看似简单实则复杂"（如解释递归代码、多模块依赖链路）的任务因 Flash 推理深度不够导致回答偏差、用户 reroll 浪费 Token。目前 Pi 插件体系已有 pi-ask-user（关键中断）+ model-router（分流），三者串联能形成"路由 → 推理 → 置信检查 → 降级/升级"的完整链路。

Prompt 缓存

DeepSeek V4 支持 Prompt 缓存（cache_control 指令），命中后输入 Token 可降至零。对于高频重复场景——固定代码库上下文、模板化测试生成、相同项目结构的多次查询——缓存能进一步优化响应速度和 Token 用量。Pi 的 /settings 中通过 defaultHeaders 即可注入缓存指令，无需额外插件。

---

优化效果汇总

插件	优化对象	典型降幅	技术原理
pi-rtk	输入代码冗余	-20~-30%	裁剪 import、类型声明、无用引用
DCP	输入对话历史	-20~-30%	自动清理已过期的上下文
tokenomy	输入 Token 上限	-10~-15%	分档限 Token + 行截断
pi-tokensaver	输入细节冗余	-10~-15%	去重、精简路径、压缩错误栈
model-router	模型选择	80% 走 Flash	关键词路由，高优先级任务走 Pro
caveman	输出冗余	-75%	去冠词、过渡语，保留技术信息
reasonix	推理性	—	仅在 Pro 任务增强推理深度
Prompt 缓存	重复输入	-50%（命中时）	cache_control 指令

---

安装的插件

插件	干什么
pi-rtk	代码级输入缩减
pi-dynamic-context-pruning	对话级上下文修剪
tokenomy	分级限 Token
pi-tokensaver	细粒度 Token 优化
model-router	自动分流模型
pi-caveman	输出压缩
pi-reasonix	Pro 模型推理增强
pi-hermes-memory	跨会话持久记忆
pi-subagents	并行子代理
pi-ask-user	关键操作前确认

Pi 配置详解

插件都装好了，接下来改三个 JSON 配置文件（都在 .pi/config/ 目录下）。

settings.json

{
  "defaultProvider": "deepseek",
  "defaultModel": "deepseek-v4-flash",
  "caveman": "on"
}

defaultProvider + defaultModel 决定了每次对话默认用哪个模型，省去每次手动 /model 切换。caveman: "on" 全局启用输出压缩——日常回复自动裁剪废话，遇到需要详细说明时说 stop caveman 即可恢复。

models.json

{
  "providers": [{
    "id": "deepseek",
    "name": "DeepSeek V4",
    "models": [{
      "id": "deepseek-v4-flash",
      "contextWindow": 128000,
      "maxOutput": 8000,
      "apiEndpoint": "https://api.deepseek.com/v1",
      "compat": { "provider": "openai-compatible" }
    }, {
      "id": "deepseek-v4-pro",
      "contextWindow": 128000,
      "maxOutput": 8000,
      "thinking": true,
      "apiEndpoint": "https://api.deepseek.com/v1",
      "compat": { "provider": "openai-compatible" }
    }]
  }]
}

DeepSeek 兼容 OpenAI API 格式，"compat": { "provider": "openai-compatible" } 让 Pi 自动处理请求格式转换，不用手动适配 API 差异。Pro 模型额外加了 "thinking": true，配合 pi-reasonix 的推理增强。

model-router 的配置前面已经给出（见「模型分流」一节），核心是把高优先级规则放在 rules 数组前面。缓存通过 /settings 的 defaultHeaders 字段注入 cache_control 指令。

三个文件放好后重启 Pi，/model 就能看到 DeepSeek V4 两个模型——但 model-router 会自动接管选择，你基本不用手动切。

---

后续

如果遇到具体配置问题（model-router 规则调优、caveman 压缩行为调整、缓存命中率优化），欢迎在评论区交流。也推荐看看 Pi 官方仓库 和安装的几个插件 README——很多细节都在里面。

---

本文发布于 https://www.cnblogs.com/miku196