Kimi K3 的 1M 上下文怎么用:整库代码、长文档与省钱技巧

Kimi K3 把上下文窗口拉到了 1,048,576 个 token —— 差不多是 K2 的四倍。很多原来必须切片、做 RAG、反复拼接的活儿,现在可以「一次性喂进去」。但 1M 不是让你无脑塞满的,用对了省事又省钱,用错了又贵又慢。这篇讲清楚 1M 上下文到底能怎么用。

1M token 能装下什么

粗略换算(中英文混排、按经验值),1M token 大约相当于:

• 一个中型代码仓库:几百个源文件的核心部分;
• 一本书:一本几百页的技术手册或长篇文档;
• 几十份 PDF / 合同:整套项目文档一次读完;
• 超长对话历史:长程 Agent 跑很多轮工具调用后的完整上下文。

换句话说,过去因为「装不下」而必须拆分的任务,K3 大多能在单轮请求的完整语境里完成 —— 模型看到全貌,答案的连贯性和少丢信息是最大收益。

整库代码分析怎么组织

把代码喂给 K3 时,结构比堆量重要。推荐的 messages 组织方式:

system_prompt = "你是资深工程师。下面是完整仓库,回答时引用具体文件与行号。"

repo_dump = "\n\n".join(
    f"### FILE: {path}\n```\n{code}\n```"
    for path, code in files
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": repo_dump + "\n\n问题:登录鉴权的逻辑在哪几个文件?有没有可以合并的重复代码?"},
    ],
)

几个要点:

• 给每个文件加清晰的路径标记(### FILE: path),模型才能准确引用;
• 把不变的部分(仓库内容)放前面,把每次不同的问题放后面 —— 这样固定前缀能吃到缓存;
• 让模型引用文件 / 行号,输出可核查,而不是泛泛而谈。

长文档问答与缓存

长文档场景(法律合同、论文、手册)是 1M 上下文最省心的用法:把整份文档放进 system 或第一条 user 消息,后面直接连着问,不用自己切块检索。

关键省钱点:K3 默认开启上下文缓存。 同一份长文档反复问不同问题时,文档这段前缀会命中缓存,输入价从 ¥20/M 降到 ¥2/M。所以组织顺序是:

[system: 角色 + 指令]  ← 固定
[user: 整份文档]        ← 固定,命中缓存
[user: 本轮具体问题]     ← 每轮变化

把固定内容前置、变化内容后置,是长上下文省钱的第一原则。定价与缓存的详细算法见 Kimi K3 价格详解。

什么时候还是该用 RAG

1M 很大,但不是万能:

• 知识库远超 1M(比如整个公司 wiki、百万行代码):还是得先检索再喂,RAG 不会过时;
• 只需要少量相关片段:全塞进去是浪费 —— 输入 token 白花钱、延迟也上去了;
• 强实时 / 高并发:上下文越长单次越慢越贵,高频场景该精简就精简。

实用原则:能一次装下、且大部分内容都相关,就直接塞;否则先检索、再把命中片段交给 K3。 两种做法也能叠加 —— 用 RAG 把范围缩到几十万 token,再让 K3 在这个「大但相关」的上下文里深度作答。

注意事项

• 越长越贵越慢:1M 是上限不是目标,按需使用;
• 利用缓存:固定前缀前置,长文 / 多轮务必吃缓存;
• 视觉也算上下文:图片 / 视频 token 同样占预算,多模态长任务注意总量;
• 别只留 content:多轮 / 工具调用把完整 assistant message 原样回传,别丢状态。

完整的接入代码和报错排查见 Kimi K3 API 接入教程。想用一个 Key 同时调 K3 和别家模型、按任务分流长文与短任务,从 GetModel 控制台开始最省事。