Kimi K3 100 万 Token 长上下文实战：整本书、整仓库怎么喂

长上下文是 Kimi 这条产品线的招牌能力，kimi-k3 把窗口做到了 1,000,000 Token，输入输出共享这个额度。直观感受一下这个量级：一次请求里装下一本完整的技术书、一个小型代码仓库的全部核心文件、或者一个团队一整年的会议记录，都是可行的。但「装得下」和「用得好」是两回事——窗口越大，越需要有意识地控制输入质量与成本。这篇讲清楚什么时候值得用满窗口、怎么控制 Token 花费、以及常见的坑。

100 万 Token 到底能装多少

不同语言的 Token 密度差别很大，下面的换算是工程上的粗略估计，精确数字以 tokenizer 实测为准：

几个参照物：一本 500 页的技术书大约 25 万到 40 万英文词；一个中型 Web 项目的核心源码通常在几万行；一年周会的会议记录通常不超过 30 万字。这些都在 100 万 Token 的容纳范围内——这就是「整本书级」上下文的实际含义。

哪些场景值得用满窗口

窗口大不等于每次都要喂满。值得用长上下文的场景有三类：

第一类：跨章节依赖的全文理解。 合同、招股书、长篇研究报告这类文档，结论分散在不同章节，前后条款互相引用。分块处理会丢掉交叉引用，一次全文精读才能建立完整语境。比如审一份技术合作协议，违约条款可能引用第三方的定义条款，只有全文都在窗口里，模型才能给出一致的解读。

第二类：整仓库级代码问答。 中小项目的核心文件全部放进上下文，模型能回答「这个函数被谁调用」「改这个接口会影响哪些模块」这类跨文件问题，不需要搭检索链路。超过窗口的大仓库，先做一轮文件筛选（只放核心模块、入口文件、类型定义），再整体投喂。

第三类：超长对话或流水线累积上下文。 长周期项目里，前期决策、历史结论需要一直在场。100 万 Token 够一个项目数月的完整决策链，不需要频繁做摘要压缩。

两段式打法：先定位，再精读

直接把所有材料倒进窗口，成本高且噪声大。实践中更省的打法是两段式：

第一段：粗筛。 用小模型或者关键词检索，从全部材料里挑出与问题相关的部分。这一步的目标不是回答问题，而是把材料从「全部」缩到「相关」。

第二段：精读。 把筛出的材料整体投给 kimi-k3，让它带着完整语境做分析、推理、生成。

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["EXAIV_API_KEY"],
    base_url="https://exaiv.com/api/ai/v1",
)

# 第二段：把筛选后的全文交给 kimi-k3 精读
resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "你是合同审查助手，只基于给出的文本回答"},
        {"role": "user", "content": f"以下是协议全文，找出所有对乙方不利的条款并说明理由：\n\n{contract_text}"},
    ],
)
print(resp.choices[0].message.content)

这个打法的关键收益是：精读阶段的上下文里没有无关材料，模型注意力不会被稀释，回答质量比「全文一把梭」更稳。

成本控制

长上下文的成本结构很明确：输入 Token 是大头。控制成本有四个抓手：

一、按需投喂。 问「这个函数做什么」不需要整个仓库，只放相关文件。长上下文是能力上限，不是默认用法。

二、稳定前缀复用。 系统提示、文档固定部分放在 messages 前部并保持不变，让前缀缓存命中。kimi-k3 支持自动前缀缓存，重复请求同一段长文档时命中缓存能显著降单价。

三、裁剪噪声。 日志、HTML 标签、base64 图片这类高 Token 低信息密度的内容先清洗再投喂。100 万 Token 里如果有 30% 是日志噪声，等于白花 30% 的钱。

四、控制输出长度。 输出同样占窗口额度，max_tokens 设一个合理上限，避免模型跑题写长文。

常见的坑

坑一：中间丢失。 超长上下文里，位于窗口中间位置的信息有时不如首尾信息被充分利用。缓解办法是把最重要的指令放在系统提示和用户消息的结尾，关键材料放在首尾位置。

坑二：一次性投喂全部历史。 多轮对话累积的历史消息全部保留，窗口会被对话历史吃掉。定期做对话摘要压缩，把「结论」留在上下文，把「过程」淘汰掉。

坑三：把长上下文当记忆用。 模型没有跨请求记忆，每次请求都是独立的。需要持久记忆时，要么每次请求都带上必要的背景材料，要么自己维护一份摘要文件在请求时注入。

坑四：忽略 tokenizer 差异。 中英混排、代码、特殊符号的 Token 密度差异很大，按字符数估算 Token 不可靠。上线前用真实数据实测一次 Token 数，再定预算。

FAQ

本文回答什么

• 100 万 token 上下文到底能装什么
• 长文档怎么分析
• 长上下文成本怎么控

场景速查

前瞻

目录与权重会持续更新；本文的接入与调用约定以发布时的官方文档为准。

来源与核验

本文关键事实来自 Kimi K3 官方模型卡（上下文规格）与平台 tokenizer 实测，并于 2026-11-09 核验。模型 ID、价格与可用性以平台实时目录为准，正文刻意不写死会过时的数字；示例代码按发布时的接口契约编写，接入前请以官方文档为准。

适用边界与受众

面向：要处理长文档或长仓库的开发者。覆盖：长上下文使用模式、成本控制与边界。不覆盖：RAG 架构设计或向量库选型。

编辑说明与更正

本文由 EXAIV 内容团队按可核实事实编写，发布前逐条核对来源与代码；如内容过期或发现错误，以官方发布页与实时目录为准，并通过页面反馈入口告知我们更新。

相关阅读

• Kimi K3 完全接入指南 — 接入与调用基础
• RAG 知识库实战指南 — 检索与长上下文配合
• Qwen KV Cache 与长上下文 — 缓存机制原理
• Token 用量与成本追踪 — 成本监控方法
• 结构化输出完全指南 — JSON 输出细节