Как использовать контекст 1M в Kimi K3: репозитории и документы

Kimi K3 расширил окно контекста до 1 048 576 токенов — это примерно вчетверо больше, чем у K2. Множество задач, которые раньше требовали нарезки, RAG и бесконечной сшивки, теперь можно «скормить разом». Но 1M — это не приглашение бездумно набивать окно до отказа. При грамотном использовании это экономит и силы, и деньги; при неверном — работает медленно и дорого. Разберём, как на деле применять контекст в 1M.

Что вмещается в 1M токенов

По грубой оценке (смешанный текст, на основе практического опыта) 1M токенов — это примерно:

• средний репозиторий кода: ядро из нескольких сотен исходных файлов;
• целая книга: технический справочник или длинный документ на сотни страниц;
• десятки PDF / договоров: весь комплект документов проекта, прочитанный за один проход;
• очень длинная история диалога: полный контекст долго работающего агента после множества раундов вызовов инструментов.

Иначе говоря, задачи, которые прежде приходилось дробить, потому что они «не помещались», 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), чтобы модель могла точно на него ссылаться;
• ставьте неизменную часть (содержимое репозитория) в начало, а меняющийся от запроса к запросу вопрос — в конец, тогда фиксированный префикс попадёт в кэш;
• просите модель ссылаться на файлы / номера строк, чтобы вывод можно было проверить, а не получить общие слова.

Q&A по длинным документам и кэширование

Сценарии с длинными документами (юридические договоры, статьи, руководства) — это самое беспроблемное применение контекста 1M: помещаете весь документ в system или первое сообщение user, а дальше просто задаёте вопросы, без ручной нарезки и поиска.

Главный способ сэкономить: в K3 кэширование контекста включено по умолчанию. Когда вы многократно задаёте разные вопросы к одному длинному документу, префикс этого документа попадает в кэш, и цена входа падает с ¥20/M до ¥2/M. Поэтому порядок организации таков:

[system: роль + инструкции]     ← фиксировано
[user: весь документ]           ← фиксировано, попадает в кэш
[user: вопрос текущего раунда]  ← меняется каждый раунд

Ставить фиксированное содержимое в начало, а изменяемое — в конец: это первое правило экономии на длинном контексте. Подробный расчёт цен и кэширования см. в разборе цен Kimi K3.

Когда всё же стоит использовать RAG

1M — это много, но не панацея:

• база знаний намного больше 1M (вся корпоративная wiki, миллион строк кода): по-прежнему нужно сначала искать, а потом подавать — RAG не устареет;
• нужны лишь несколько релевантных фрагментов: набивать всё подряд расточительно — вы впустую тратите входные токены, а задержка растёт;
• высокая реальность времени / высокая нагрузка: чем длиннее контекст, тем медленнее и дороже каждый вызов, так что для высокочастотных сценариев его стоит урезать.

Практическое правило: если помещается за один проход и большая часть содержимого релевантна — подавайте как есть; иначе сначала ищите, а затем передавайте найденные фрагменты в K3. Оба подхода можно и совмещать — с помощью RAG сузить объём до нескольких сотен тысяч токенов, а затем дать K3 глубоко ответить в этом «большом, но релевантном» контексте.

На что обратить внимание

• чем длиннее, тем дороже и медленнее: 1M — это потолок, а не цель, используйте по мере необходимости;
• используйте кэш: ставьте фиксированный префикс в начало и обязательно попадайте в кэш на длинных документах / многораундовых диалогах;
• визуал тоже входит в контекст: токены изображений / видео тоже расходуют бюджет, следите за общим объёмом в длинных мультимодальных задачах;
• не оставляйте только content: в многораундовых сценариях / при вызовах инструментов возвращайте полное сообщение assistant как есть, не теряйте состояние.

Полный код интеграции и разбор ошибок см. в руководстве по API Kimi K3. Если хотите одним ключом вызывать K3 и модели других провайдеров, распределяя длинные и короткие задачи по нагрузке, проще всего начать с панели GetModel.