Пользователь на локальной системе с двумя RTX 5090 дал одну и ту же задачу двум моделям: исправить несколько багов в коде, который изначально написан AI. Qwen 3.8 27B нашла и починила несколько багов за 5-10 минут. Qwen 3.8 Flash Next на ту же работу потратила около 2,5 часов. Автор кейса опубликовал наблюдение в r/LocalLLaMA.
Разница объясняется двумя слоями. Первый: пропускная способность. На этом железе 27B выдаёт инфилл около 2000-3000 токенов и 100-150 токенов/с на выходе, Flash Next - примерно 1600-2300 токенов инфилла и 60-100 токенов/с. Второй слой весомее: правки кода Flash Next закончила примерно за 2 часа до фактического завершения работы, и после этой точки код больше не менялся. Значит, последние два часа ушли на тесты, перепроверки и другие шаги агентного цикла, а не на написание исправлений.
Оговорка, важная для всех выводов ниже: это единичный практический кейс одного пользователя, а не независимый бенчмарк. Настройки запуска, фреймворк, версии моделей и объём кода в источнике не раскрыты. Точная причина поведения Flash Next тоже не установлена, поэтому дальше речь о вероятных механизмах и о том, что можно проверить на своей системе.
Что произошло в кейсе: 27B за 10 минут, Flash Next за 2,5 часа
Исходные данные: железо, модели и задача
Условия кейса выглядят так:
- система с двумя видеокартами RTX 5090, обе модели запускались локально;
- задача одна и та же: исправить несколько багов в коде, изначально сгенерированном AI;
- автор не программист, он формулирует запрос на исправления и обновления и даёт модели работать самостоятельно;
- Qwen 3.8 27B справилась за 5-10 минут;
- Qwen 3.8 Flash Next завершила работу примерно через 2,5 часа.
Практика с AI-сгенерированным кодом важна для понимания контекста. Автор не читает диффы построчно и не проверяет каждую правку вручную, поэтому вся ответственность за объём работы и момент остановки лежит на агенте. Если такой агент решает продолжить цикл, никто снаружи его не остановит.
Прямой ответ: три уровня причин
Разрыв во времени раскладывается на три уровня, и влияют они по-разному:
- Скорость генерации токенов. 27B быстрее и на инфилле, и на выходе. Но ускорение в 1,5-2,5 раза не превращает 2,5 часа в 10 минут.
- Поведение агентного цикла. Flash Next завершила правки примерно за 2 часа до финального завершения. Эти два часа она что-то делала без изменения кода.
- Стратегия завершения задачи. Порог остановки и условия, при которых агент считает работу выполненной, определяют, сколько лишних шагов он сделает.
Первый уровень объясняет минуты, второй и третий - часы. Причину поведения Flash Next в течение тех двух часов источник не раскрывает: указано только, что это были тесты или другие действия. Дальше разберём механику каждого уровня.
Скорость генерации: насколько 27B быстрее Flash Next на двух RTX 5090
Что такое инфилл и токены/с и почему они важны
Две метрики описывают разные фазы работы модели.
- Инфилл (скорость обработки входного контекста) показывает, как быстро модель читает и разбирает то, что ей подали: код проекта, историю сообщений, результаты предыдущих шагов. На длинных контекстах эта фаза заметно влияет на отзывчивость.
- Выходные токены в секунду показывают, как быстро модель пишет ответ: патч, объяснение, вызов инструмента.
Обе метрики измеряются на конкретном железе и зависят от квантизации, длины контекста и загрузки видеокарт. Поэтому цифры одного пользователя нельзя переносить на другую конфигурацию без проверки. О том, почему в реальных задачах важнее смотреть на распределение задержек, а не на пиковые значения, разбирается в материале про сравнение Qwen3.8 Flash Next, Qwen3.8-27B и других моделей на четырёх DGX Spark.
Почему разницы в токенах/с недостаточно для объяснения 2,5 часов
Посчитаем на цифрах из кейса. 2,5 часа - это 9000 секунд. При выходной скорости 60 токенов/с модель успела бы сгенерировать около 540 000 токенов, если бы писала непрерывно. Даже при скорости 100 токенов/с речь о сотнях тысяч токенов. Исправление нескольких багов в небольшом AI-сгенерированном проекте в такой объём не укладывается.
Разница в скорости тоже не закрывает пропасть. Соотношение между 100-150 и 60-100 токенов/с даёт ускорение примерно в 1,5-2,5 раза, а не в 15-30 раз, которые отделяют 10 минут от 2,5 часов. Тот же эффект описан в разборе про DeepSeek-V4-Flash-Vision Q8 и Qwen3.8-Flash-Next Q8: высокий показатель tokens/s не гарантирует, что задача будет решена быстрее.
Вывод по этому разделу: инфилл и выходные токены/с дают 27B фору в начале и при каждой правке, но основное время у Flash Next ушло не на генерацию кода. Считать надо не токены, а количество и характер шагов агента.
Агентный цикл Flash Next: почему модель работала ещё 2 часа после правок
Как устроен агентный цикл и где он может зацикливаться
Агентный режим превращает модель из генератора текста в исполнителя. Типовой цикл выглядит так:
- разобрать задачу и составить план;
- внести изменение в файл;
- запустить тесты или сборку;
- прочитать вывод и решить, что делать дальше;
- либо внести следующую правку, либо объявить работу завершённой.
Зацикливание возникает на шагах 3-4. Если тест падает по причине, не связанной с задачей, если вывод неоднозначный или если модель не уверена, что фикс применён, она запускает проверку заново. Каждый прогон добавляет токены контекста, а вместе с ними растёт время инфилла, то есть цикл замедляется сам себя.
В кейсе прямо указано: код перестал меняться за 2 часа до конца. Дальше модель выполняла тесты или что-то ещё. Что именно происходило в эти два часа, источник не описывает, поэтому назовём это гипотезой: правки были готовы, а завершить цикл агент не смог или не захотел. Возможные варианты - повторные прогоны тестов, перечитывание файлов, проверки состояния окружения, ожидание результата команды.
Склонность к лишним шагам это известная особенность Flash Next. В тесте на Aider базовая версия заметно уступала доработанной Swift-1.5-Qwen3.8-Flash-Next по расходу токенов и медианному времени: 6991 токен против 17646 и 608 секунд против 1542 при сопоставимом качестве. Разница объяснялась тем, что базовая модель чаще уходит в длинные цепочки рассуждений.
Почему 27B мог остановиться раньше
У 27B в этом кейсе цикл оказался коротким: нашла баги, исправила, отчиталась. Возможные объяснения, которые нельзя подтвердить по имеющимся данным:
- модель строже следовала инструкции «исправь и заверши», а не расширяла задачу до полного тестирования;
- объём проверок на её стороне был меньше, потому что она быстрее проходила шаги и реже возвращалась назад;
- сама формулировка задачи для неё оказалась проще, а Flash Next могла интерпретировать её шире.
Ни одно из этих объяснений не подтверждено, потому что настройки, промпты и логи агента в источнике не приведены. Утверждать, что 27B всегда останавливается вовремя, нельзя: это наблюдение одного запуска на одной задаче.
Стратегии завершения задачи: как заставить Flash Next остановиться вовремя
Формулировка промпта и условие остановки
Первое, что стоит менять, это текст запроса. Формулировка с явной границей работы снижает число лишних шагов:
Исправь перечисленные баги. Не запускай дополнительные тесты и не рефактори то, что не относится к перечисленным проблемам. После внесения правок заверши работу и выведи список изменённых файлов.
Ограничение у этого приёма есть. Если системная инструкция агента или настройки фреймворка требуют прогонять тесты после каждого изменения, модель может проигнорировать просьбу не тестировать. Тогда промпт даст частичный эффект, а время сократится за счёт отказа от рефакторинга и косметических правок.
Ограничение итераций и таймауты
Технические ограничители работают надёжнее формулировок, потому что не зависят от того, как модель поняла задачу:
- максимальное число шагов. Агент останавливается принудительно после заданного количества итераций. Два часа работы после готового патча в этот лимит уже не влезают;
- таймаут на шаг и на задачу в целом. Не даёт отдельной команде или сессии висеть неопределённо долго;
- лимит на повторные запуски одного инструмента. Если тест вызывается третий раз подряд с тем же результатом, разумно завершать цикл, а не заходить на четвёртый круг;
- ограничение объёма контекста. Чем длиннее история шагов, тем медленнее инфилл на каждом следующем шаге.
Названия и наличие этих параметров зависят от конкретного фреймворка или клиента, и в исходном кейсе они не указаны. Проверять надо в документации своего инструмента: где задаётся предел итераций и что происходит при его достижении.
Разделение правок и тестирования
Разбивка задачи на два запроса даёт контроль над тем, на каком этапе уходит время:
- первый запрос только на исправление кода, без тестов;
- второй запрос отдельно на прогон тестов и разбор падений;
- третий, если нужен, на правки по результатам тестов.
Так видно, сколько заняли сами правки, а сколько проверки. Если время уходит на второй этап, проблема в тестах или окружении, а не в модели. Если на первый, стоит смотреть на длину контекста, размер проекта и параметры генерации.
Ещё один практический приём: смотреть логи агента после завершения. По ним видно, какие команды выполнялись в те два часа, повторялись ли они и был ли код уже готов к тому моменту. Без логов любые выводы о причинах задержки остаются догадками. Похожая логика применима и к оценке Flash Next в агентном кодинге в целом, что подробно разобрано в материале про NVFP4-версию Qwen3.8-Flash-Next и сравнение с 27B-моделями.
Когда выбирать 27B, а когда Flash Next: практические критерии
Сценарии для 27B: быстрые правки и простые задачи
Qwen 3.8 27B подходит, когда задача локальная и ограниченная по объёму:
- исправить конкретные баги в небольшом файле или модуле;
- внести однотипные обновления в уже работающий AI-сгенерированный код;
- получить результат за минуты и сразу проверить его руками;
- работать на двух RTX 5090, где модель выдаёт 100-150 токенов/с на выходе.
Ограничение тоже есть: если задача требует долгого автономного перебора вариантов, короткий цикл 27B может остановиться раньше, чем проблема решена. Тогда часть работы придётся формулировать новым запросом.
Сценарии для Flash Next: автономные проверки и сложные задачи
Flash Next оправдывает затраченное время там, где нужны множественные итерации: прогон тестов, разбор падений, проверка нескольких гипотез, работа с крупным проектом. Её сильная сторона в способности держать длинную цепочку шагов, а слабая - в том, что эта цепочка плохо останавливается без внешнего контроля.
Практический подход такой: запускать Flash Next с лимитом итераций и явным условием завершения, а результат разбирать по логам. Если цикл уходит в лишние проверки, сокращать допустимое число шагов или переносить тестирование в отдельный запрос. Универсального значения лимита нет: он зависит от размера проекта и того, сколько проверок реально нужно.
Для автора кейса с AI-сгенерированным кодом рабочая схема выглядит так: небольшие правки отдавать 27B и проверять результат самому, а Flash Next подключать на сложных задачах с тестами, удерживая её в рамках по шагам.
Что осталось за кадром: ограничения кейса и что проверить самостоятельно
Почему один кейс - не статистика
На время выполнения задачи влияет набор факторов, и ни один из них в источнике не зафиксирован:
- версии и квантизация обеих моделей;
- фреймворк и его настройки: лимит итераций, режим рассуждений, температура;
- длина контекста и объём проекта, который подавался модели;
- количество багов и их сложность;
- состояние системы: загрузка видеокарт, фоновые процессы, доступная память.
Наблюдение сделано одним пользователем и не подтверждено независимыми измерениями. Оно описывает конкретную ситуацию, а не свойство моделей. Переносить эти цифры на другую конфигурацию без собственной проверки не стоит.
Как провести собственный тест и на что смотреть
Повторить кейс у себя можно за один вечер. План такой:
- зафиксировать одну задачу и одинаковый набор файлов для обеих моделей;
- засечь время до последнего изменения кода, а не только до окончания работы;
- засечь общее время выполнения задачи;
- сохранить логи агента и посмотреть, что происходило между этими двумя моментами;
- сравнить не только время, но и объём израсходованных токенов.
Разница между временем последней правки и общим временем это ключевая метрика. Именно она показывает, сколько агент тратит на действия вокруг задачи. Если разрыв воспроизводится, дальше имеет смысл уменьшать предел итераций и отделять тестирование в самостоятельный запрос, пока цикл не станет предсказуемым.