上下文窗口预算如何算LLM Wiki 4K到1M Token分配策略源码解析【免费下载链接】llm_wikiLLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。项目地址: https://gitcode.com/GitHub_Trending/ll/llm_wikiLLM Wiki是一款把文档自动整理成互链知识库的跨平台桌面应用而「上下文窗口预算」Context Budget是它高效使用大模型的关键机制从 4K 小模型到 1M 长上下文旗舰模型LLM Wiki 都按固定比例自动拆分 Token 预算让索引、页面内容和模型回答各得其所。本文带你完整读懂这套 4K 到 1M Token 分配策略的源码逻辑。为什么需要上下文窗口预算大模型的上下文窗口如 8K、128K、1M是「提问 知识 回答」共享的一块公共池子。如果全部塞满资料模型就没有空间输出了预留太少又浪费长上下文模型的算力。LLM Wiki 的做法是把预算计算抽成一个纯函数模块 context-budget.ts与 UI 完全解耦方便单独测试见 context-budget.test.ts。┌─────────────────────────────────────────────────────┐ │ 上下文窗口 (100%) │ ├──────┬───────────────┬──────────────────┬───────────┤ │索引 │ Wiki 页面 │ 历史系统提示 │ 模型回答 │ │ 5% │ 50% │ ~30% │ 15% │ └──────┴───────────────┴──────────────────┴───────────┘四段式预算5% 索引 50% 页面 15% 回答核心入口是computeContextBudget()输入模型的最大上下文长度以字符计输出四个预算预算项占比作用responseReserve15%强制留空保证模型有空间写回答indexBudget5%放整个 Wiki 的页面标题索引pageBudget50%检索到的 Wiki 页面正文总预算maxPageSize动态单页截断上限防止一页独吞预算剩下的约 30% 不做硬约束系统提示词大小基本固定对话历史按条数maxHistoryMessages而非字节限制这部分只作为弹性余量。 一个贴心设计如果配置为 0 或缺失预算会回退到 200K 字符的默认值老配置不会因此报错。4K 到 1M十档预设怎么配用户在设置页通过滑块选择上下文窗口档位定义在 context-size-selector.tsx4K → 8K → 16K → 32K → 64K → 128K → 200K → 256K → 512K →1M不同档位下预算的实际数值源码注释中的字符单位1 Token ≈ 3 字符上下文窗口回答预留 15%索引 5%页面预算 50%单页上限8K1,2284094,0964,096压缩至页面预算32K4,9151,63816,3845,000触底 5K 下限128K19,6606,55365,53619,66030% 线性200K30,72010,240102,40030,72030% 线性1M150,00050,000500,000150,00030% 线性单页上限的三条边界规则maxPageSize是整个算法里最精巧的部分避免「一页超长页面挤掉其他所有内容」下限 5,000 字符即使是很小的配置也要保证塞得下一页短文线性缩放正常情况取页面预算的 30% 增长永远 ≤ 页面总预算8K 这类小配置里 5K 下限会超过页面预算本身此时强制压缩——否则单页会被chat-panel的tryAddPage整体拒收。15% 响应预留的第二个用途响应预留不只是「不填满」在 llm-providers.ts 中Anthropic 协议的默认max_tokens就是由它推导的——responseReserve / 3字符转 Token并封顶 16,3848K 窗口 → 默认输出上限仅 409 Token200K 窗口 → 10,240 Token1M 窗口 → 触及 16,384 封顶这比写死 4,096 聪明得多窗口越大默认放给模型的回答空间越大长文档问答不再被截断。文档摄入阶段另有独立预算聊天之外把原始文档「摄入」Wiki 时ingest.ts 使用computeIngestSourceBudget()单独算账扣除项更细扣除项规则回答预留复用 15%responseReserve稳定上下文预留min(25% × 窗口, max(12K, 实际长度))指令预留max(12K, 8% × 窗口)保底 12K 字符可用上限窗口剩余量且不超过 60% 窗口同时computeIngestGenerationMaxTokens()按窗口分档128K / 256K / 512K决定摄入生成的最大输出 Token小窗口小输出大窗口放开写。总结一套预算两种场景维度聊天场景摄入场景核心函数computeContextBudget()computeIngestSourceBudget()知识预算50% 页面 5% 索引扣除稳定/指令预留后的余量回答预留15%兼作max_tokens推导复用 15% 预留保护机制单页 30% 上限 5K 下限12K 指令保底 60% 上限封顶一句话概括LLM Wiki 的上下文窗口预算 固定比例切蛋糕5/50/15 边界规则防独吞单页上限 场景化微调摄入独立记账从 4K 的本地小模型到 1M 的长上下文旗舰都能稳定工作。想动手验证直接跑 context-budget.test.ts 里的边界用例即可。【免费下载链接】llm_wikiLLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。项目地址: https://gitcode.com/GitHub_Trending/ll/llm_wiki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 上下文窗口预算如何算：LLM Wiki 4K到1M Token分配策略源码解析
上下文窗口预算如何算LLM Wiki 4K到1M Token分配策略源码解析【免费下载链接】llm_wikiLLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。项目地址: https://gitcode.com/GitHub_Trending/ll/llm_wikiLLM Wiki是一款把文档自动整理成互链知识库的跨平台桌面应用而「上下文窗口预算」Context Budget是它高效使用大模型的关键机制从 4K 小模型到 1M 长上下文旗舰模型LLM Wiki 都按固定比例自动拆分 Token 预算让索引、页面内容和模型回答各得其所。本文带你完整读懂这套 4K 到 1M Token 分配策略的源码逻辑。为什么需要上下文窗口预算大模型的上下文窗口如 8K、128K、1M是「提问 知识 回答」共享的一块公共池子。如果全部塞满资料模型就没有空间输出了预留太少又浪费长上下文模型的算力。LLM Wiki 的做法是把预算计算抽成一个纯函数模块 context-budget.ts与 UI 完全解耦方便单独测试见 context-budget.test.ts。┌─────────────────────────────────────────────────────┐ │ 上下文窗口 (100%) │ ├──────┬───────────────┬──────────────────┬───────────┤ │索引 │ Wiki 页面 │ 历史系统提示 │ 模型回答 │ │ 5% │ 50% │ ~30% │ 15% │ └──────┴───────────────┴──────────────────┴───────────┘四段式预算5% 索引 50% 页面 15% 回答核心入口是computeContextBudget()输入模型的最大上下文长度以字符计输出四个预算预算项占比作用responseReserve15%强制留空保证模型有空间写回答indexBudget5%放整个 Wiki 的页面标题索引pageBudget50%检索到的 Wiki 页面正文总预算maxPageSize动态单页截断上限防止一页独吞预算剩下的约 30% 不做硬约束系统提示词大小基本固定对话历史按条数maxHistoryMessages而非字节限制这部分只作为弹性余量。 一个贴心设计如果配置为 0 或缺失预算会回退到 200K 字符的默认值老配置不会因此报错。4K 到 1M十档预设怎么配用户在设置页通过滑块选择上下文窗口档位定义在 context-size-selector.tsx4K → 8K → 16K → 32K → 64K → 128K → 200K → 256K → 512K →1M不同档位下预算的实际数值源码注释中的字符单位1 Token ≈ 3 字符上下文窗口回答预留 15%索引 5%页面预算 50%单页上限8K1,2284094,0964,096压缩至页面预算32K4,9151,63816,3845,000触底 5K 下限128K19,6606,55365,53619,66030% 线性200K30,72010,240102,40030,72030% 线性1M150,00050,000500,000150,00030% 线性单页上限的三条边界规则maxPageSize是整个算法里最精巧的部分避免「一页超长页面挤掉其他所有内容」下限 5,000 字符即使是很小的配置也要保证塞得下一页短文线性缩放正常情况取页面预算的 30% 增长永远 ≤ 页面总预算8K 这类小配置里 5K 下限会超过页面预算本身此时强制压缩——否则单页会被chat-panel的tryAddPage整体拒收。15% 响应预留的第二个用途响应预留不只是「不填满」在 llm-providers.ts 中Anthropic 协议的默认max_tokens就是由它推导的——responseReserve / 3字符转 Token并封顶 16,3848K 窗口 → 默认输出上限仅 409 Token200K 窗口 → 10,240 Token1M 窗口 → 触及 16,384 封顶这比写死 4,096 聪明得多窗口越大默认放给模型的回答空间越大长文档问答不再被截断。文档摄入阶段另有独立预算聊天之外把原始文档「摄入」Wiki 时ingest.ts 使用computeIngestSourceBudget()单独算账扣除项更细扣除项规则回答预留复用 15%responseReserve稳定上下文预留min(25% × 窗口, max(12K, 实际长度))指令预留max(12K, 8% × 窗口)保底 12K 字符可用上限窗口剩余量且不超过 60% 窗口同时computeIngestGenerationMaxTokens()按窗口分档128K / 256K / 512K决定摄入生成的最大输出 Token小窗口小输出大窗口放开写。总结一套预算两种场景维度聊天场景摄入场景核心函数computeContextBudget()computeIngestSourceBudget()知识预算50% 页面 5% 索引扣除稳定/指令预留后的余量回答预留15%兼作max_tokens推导复用 15% 预留保护机制单页 30% 上限 5K 下限12K 指令保底 60% 上限封顶一句话概括LLM Wiki 的上下文窗口预算 固定比例切蛋糕5/50/15 边界规则防独吞单页上限 场景化微调摄入独立记账从 4K 的本地小模型到 1M 的长上下文旗舰都能稳定工作。想动手验证直接跑 context-budget.test.ts 里的边界用例即可。【免费下载链接】llm_wikiLLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。项目地址: https://gitcode.com/GitHub_Trending/ll/llm_wiki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考