Зачем подключать вторую модель
Когда AI-агент работает с проектом, ему приходится читать исходные файлы, разбирать журналы и искать сведения, относящиеся к задаче. Большой объём входных данных увеличивает расход токенов. При этом для следующего шага часто достаточно выбранных фрагментов и краткого предварительного разбора.
Мы хотели проверить разделение этой работы между двумя моделями. Локальная Qwen должна была готовить материал, а Codex — проверять выводы и решать основную задачу. Цель эксперимента состояла в том, чтобы уменьшить объём данных, который получает облачная модель, сохранив возможность проверить результат по исходникам.
Что использовали
Эксперимент проводили на домашнем компьютере с GeForce RTX 5080, 16 ГБ видеопамяти и 64 ГБ оперативной памяти DDR5. В LM Studio запустили Qwen 3 Coder 30B и связали её с Codex через собственный локальный модуль.
Это описание нашей конфигурации. Для другой модели и другого объёма контекста требования к памяти и скорость обработки могут отличаться. При повторении эксперимента имеет смысл начинать с типичного для своей работы файла и отдельно измерять время подготовки и размер результата.
Как распределили работу
Qwen первой получала большие файлы и журналы, выбирала релевантные фрагменты и готовила предварительный разбор. Codex получал сокращённый контекст, проверял выводы и продолжал основную работу. Исходные материалы оставались точкой проверки для спорных или неполных выводов.
Последовательность выглядела так:
- Определить задачу и передать локальной модели материалы для первичного анализа.
- Выбрать относящиеся к задаче фрагменты и подготовить краткий разбор.
- Передать подготовленный контекст в Codex.
- Проверить выводы и использовать их при решении основной задачи.
Лучше всего в нашем эксперименте работала простая параллельная схема. Qwen запускалась первой и анализировала материалы в фоне. Codex в это время продолжал работу и использовал результат, когда тот был готов. Такая организация полезна, когда у основного агента есть действия, которые можно выполнить до получения разбора.
Что показали замеры
На одном реальном исходном файле объём входных данных удалось сократить примерно с 57 000 до 9 100 токенов. После предварительного разбора в облако передавалось около 16% первоначального объёма этого файла.
За весь рабочий процесс экономия токенов облачной модели составила около 15–20%. Это другой масштаб измерения - помимо конкретного файла, у агента есть инструкции, другие материалы и последующие шаги. Поэтому сокращение одного входного файла примерно на 84% нельзя переносить на общий расход сессии.
Эти значения относятся к нашим рабочим замерам. Они показывают результат конкретной схемы на конкретных материалах и помогают оценить, стоит ли исследовать такой подход в своей задаче. Ускорение работы и экономию денег отдельно здесь не оцениваем: локальная обработка тоже занимает время и использует ресурсы компьютера.
Что нужно проверить перед использованием
Предварительный разбор может пропустить важную деталь. Поэтому стоит сохранять связь выбранных фрагментов с исходным материалом, проверять спорные выводы и давать основному агенту возможность запросить недостающий контекст. Чем сильнее сокращается входной файл, тем внимательнее нужно оценивать полноту отбора.
На практике я бы проверял три вещи - помогает ли отбор решить задачу, сколько токенов расходуется за весь процесс и сколько времени занимает получение итогового результата. Маленький промежуточный ответ сам по себе ещё не означает, что весь процесс стал выгоднее.
Где такой подход может пригодиться
Связку стоит рассматривать для задач, в которых регулярно приходится читать большие файлы, журналы или объёмные материалы проекта и выделять из них небольшую часть. Для команды разработки это может быть подготовка контекста перед разбором проблемы; для аналитической работы — первичный отбор материалов перед содержательной проверкой.
В нашем эксперименте домашний компьютер взял на себя первичный анализ и помог снизить расход токенов облачной модели. Следующий шаг при внедрении в рабочий процесс — проверить ту же схему на собственных типовых задачах, с понятными критериями качества, времени и затрат.
Обсудим похожую задачу
Если ваша команда регулярно разбирает большие объёмы документов, файлов или журналов с помощью AI, в Юнифай Консалт можем помочь оценить, какие этапы имеет смысл выполнять локально, как передавать контекст облачному агенту и как измерять результат всей системы. Начнём с вашей задачи, ограничений на данные и текущего процесса.