Что заявили и почему это не рядовое обновление

Kimi K2 от Moonshot AI — открытая MoE-модель примерно на 1 трлн параметров при ~32 млрд активных на токен. В обновлениях линейки заявлено окно до 1 млн токенов: рекорд сам по себе не уникален (Gemini, Claude, Qwen движутся туда же), но здесь важна комбинация — длинный контекст плюс открытые веса. Это значит, что модель можно развернуть в собственном контуре, а не только покупать как API-сервис.

Переведём в понятные единицы: при типичных для русского текста ~2 токенах на слово 1 млн токенов — это около 500 тыс. слов, то есть 1000+ страниц А4. Практически это весь пакет договоров по сделке, полный комплект техдокументации на линию оборудования или годовой архив переписки с подрядчиками в одном запросе.

Заявленный контекст ≠ рабочий контекст

Первое, что стоит проверить на своих данных, — эффективный контекст. Модели уверенно проходят тесты типа «иголка в стоге сена», но заметно теряют качество на задачах, где нужно сопоставлять факты из разных частей документа. На практике деградация часто начинается уже после 100–200 тыс. токенов, а не на заявленном миллионе.

Второй момент — «lost in the middle»: середина длинного промпта обрабатывается хуже начала и конца. Если вы кладёте в контекст 800 страниц, не стоит рассчитывать, что модель одинаково внимательно отнесётся к странице 400. Поэтому длинный контекст не отменяет поиск и отбор релевантных фрагментов — он меняет роль RAG: из «единственного способа уложиться в окно» он превращается в инструмент приоритизации.

Экономика одного длинного запроса

KV-кэш для 1 млн токенов — сотни гигабайт в FP16 для модели такого размера. Это память, которую нужно где-то держать, а не абстрактный параметр в описании. Отсюда практические следствия: квантизация кэша, MLA и paged attention, вытеснение на CPU — всё это становится обязательной частью архитектуры, а не оптимизацией «на потом».

Второй счёт — время prefill. Обработка миллиона токенов перед первым выходным токеном занимает секунды и десятки секунд даже на хорошем кластере, и это напрямую влияет на UX. Отсюда рабочая схема: кэширование префикса для повторяющихся документов и разделение запросов на «тяжёлые пакетные» (аудит массива документов ночью) и «быстрые интерактивные» (вопрос по 20 страницам).

Что это меняет для российских задач

Сценарии, которые раньше разбивались на десятки запросов, теперь решаются за один проход: сквозная проверка комплекта договоров на противоречия, сверка проектной документации с нормативами, разбор большой кодовой базы, анализ выгрузок из 1С и логов инцидентов. Для отраслей с режимом коммерческой тайны и требованиями 152-ФЗ открытые веса — ключевое преимущество: модель живёт в вашем периметре, данные не уходят наружу.

Но длинный контекст не решает проблемы прав доступа и разметки. Если в окно попадают документы разных подразделений, вы получаете утечку внутри компании. Разграничение доступа должно работать до формирования промпта, а не после.

Практические шаги

1. Соберите eval-набор из 30–50 реальных вопросов с эталонными ответами и источниками — без него сравнение схем бессмысленно.
2. Замерьте эффективный контекст на своих документах: подавайте 50, 100, 200, 500 тыс. токенов и смотрите, где падает точность.
3. Сравните три режима на одном наборе: полный контекст, чистый RAG, гибрид (отбор фрагментов + длинный контекст для связности).
4. Посчитайте TCO: память под KV-кэш, время prefill, стоимость запроса при вашем профиле нагрузки.
5. Заложите цитирование и проверку источников — при длинном контексте это единственный способ отловить галлюцинации.

Как мы можем помочь

АПС разворачивает приватные LLM в контуре заказчика, строит гибридные схемы RAG + длинный контекст и проводит замеры эффективного контекста на реальных корпоративных данных — от аудита договоров до разбора документации и интеграций с 1С. Обсудить проект