Что показал тест MiMo 2.6 с plan mode и без него
Пользователь под ником PilgrimofHaqq2 сравнил MiMo 2.6 в двух режимах на одной задаче: сгенерировать SVG-изображение пеликана. В plan mode модель сначала уточнила стиль, сцену и размер за один раунд вопросов и ответов, затем записала весь SVG одним вызовом (11,1 КБ у Flash и 22,1 КБ у Pro) и собрала все правки рендера в один раунд редактирования. Итог: 12 вызовов у Flash и 17 у Pro.
Без plan mode итераций больше. Flash сделал 3 раунда правок рендера и потерял около 10 вызовов на проверке изображения. Pro уложился в 2 раунда правок, но получил 4 сбоя инструментов. Главный вывод теста: plan mode даёт меньше, но более крупных вызовов, а не меньше работы в целом. Исходный разбор опубликован в r/LocalLLaMA 27 сентября 2026 года.
Оговорка сразу: это один пользовательский тест на одной задаче, а не воспроизводимый бенчмарк. Дальше разобраны цифры, механика процесса и границы, за которые выводы переносить не стоит.
Как plan mode меняет ход работы модели
Разница между режимами видна в структуре шагов. Plan mode разбивает работу на три крупных этапа вместо десятка мелких.
Один раунд уточнений вместо серии догадок
В plan mode MiMo 2.6 выяснила стиль, сцену и размер будущего изображения за один раунд вопросов и ответов. Это снимает необходимость возвращаться к этим параметрам позже: к моменту записи файла требования уже зафиксированы. Без plan mode модель, судя по числу итераций в тесте, уточняла параметры по ходу работы, и часть вызовов уходила на переделки, а не на приближение к результату.
Весь SVG одним вызовом: 11,1 КБ у Flash и 22,1 КБ у Pro
Второй шаг плана: запись всего файла за один вызов. У Flash получилось 11,1 КБ, у Pro 22,1 КБ. Один крупный вызов записи заменяет серию мелких, каждый из которых добавляет фрагмент. Разница в размере между 11,1 и 22,1 КБ относится к вариантам модели, а не к режиму: оба значения получены в plan mode.
Правки рендера одним раундом
Третий шаг: все правки рендера собраны в один раунд редактирования. Именно группировка правок даёт итоговые 12 вызовов у Flash и 17 у Pro. Без plan mode правки шли несколькими раундами: 3 у Flash и 2 у Pro. Для модели это разница между одной большой правкой и несколькими последовательными проходами по файлу.
Цифры теста: вызовы и токены у Flash и Pro
| Метрика | Flash с plan mode | Flash без plan mode | Pro с plan mode | Pro без plan mode |
|---|---|---|---|---|
| Всего вызовов | 12 | не указано | 17 | не указано |
| Размер SVG одним вызовом | 11,1 КБ | не указано | 22,1 КБ | не указано |
| Раунды правок рендера | 1 | 3 | 1 | 2 |
| Сгенерированные токены | 27,2 тыс. | 20,4 тыс. | не указано | не указано |
| Потери и сбои | не зафиксированы | около 10 вызовов на проверке изображения | не зафиксированы | 4 сбоя инструментов |
Таблица собрана из данных одного теста. Пустые ячейки означают, что соответствующих чисел в источнике нет, а не нулевые значения.
Flash: 12 вызовов с plan mode против потерь без него
С plan mode Flash уложился в 12 вызовов и сгенерировал 27,2 тыс. токенов. Без plan mode вызовов стало больше, причём около 10 из них ушли на проверку изображения и к результату не приближали, а объём генерации оказался ниже: 20,4 тыс. токенов. Парадокс виден прямо в этих двух числах, и к нему стоит присмотреться отдельно.
Pro: 17 вызовов с plan mode и 4 сбоя инструментов без него
С plan mode Pro сделал 17 вызовов и записал SVG на 22,1 КБ. Без plan mode хватило 2 раундов правок, но добавились 4 сбоя инструментов. Один из них сгенерировал 3 743 токена и отбросил их: вызов редактирования отклонили из-за отсутствующего аргумента. Данных по общему объёму токенов для Pro в источнике нет, поэтому сравнивать его с Flash по этому показателю нельзя.
Почему без plan mode вызовы теряются
В обоих прогонах без плана потери возникали в двух местах: на визуальной проверке результата и на уровне самих вызовов инструментов.
Рассинхрон визуальной проверки: crop-чтения и устаревшие превью
У Flash без plan mode примерно 10 вызовов ушли на проверку изображения. Причина в деталях, которые перечислены в разборе: несовпадающие crop-чтения, увеличенные виды, один устаревший превью-рендер. Каждый такой шаг расходует вызов, но не даёт информации о том, что реально записано в файле. Модель проверяет то, что уже изменилось, или не тот фрагмент, который нужно оценить, и запускает проверку заново.
Отброшенные вызовы инструментов: 3 743 токена впустую
У Pro без plan mode зафиксировано 4 сбоя инструментов. Самый дорогой из них сгенерировал 3 743 токена и отбросил их полностью: вызов редактирования отклонили, потому что в нём не хватало аргумента. Токены уже потрачены на генерацию текста, но полезного действия не произошло. Это чистые потери генерации, которые не видны по числу успешных вызовов. Полный список наблюдений приведён в исходном разборе.
Меньше вызовов - не значит меньше токенов
Самый контринтуитивный результат теста: Flash с plan mode сгенерировал 27,2 тыс. токенов, а Flash без plan mode - 20,4 тыс. Вызовов в plan mode меньше, а генерации больше примерно на треть.
Из этих чисел следует простая мысль: plan mode укрупняет шаги, а не сокращает суммарную работу. Один вызов на запись всего SVG и один раунд правок рендера - это большой объём текста за раз. Несколько мелких итераций дают тот же результат меньшим числом токенов, зато большим числом вызовов и большим числом потерь. Тест не содержит разбивки токенов по шагам, поэтому точное соотношение между уточнениями, записью файла и правками установить нельзя.
Обратный вывод тоже делать рано. Данные есть только по Flash и только на одной задаче с SVG, так что утверждение «plan mode всегда дороже по токенам» источник не подтверждает.
Когда plan mode у MiMo 2.6 действительно полезен
По одной задаче нельзя вывести универсальное правило, но критерии выбора из теста читаются.
Задачи, где plan mode экономит вызовы
Plan mode подходит там, где требования можно зафиксировать заранее, а результат записывается целиком за один шаг: генерация цельного файла, разметки, SVG, документа. В тесте именно так и произошло: один раунд уточнений, один вызов записи, один раунд правок. Если промежуточная визуальная проверка не нужна на каждом шаге, группировка правок уменьшает число обращений к инструментам.
Задачи, где выгоднее работать без плана
Без плана разумно работать там, где результат правится итеративно и каждая правка проверяется сразу: интерфейсы, вёрстка, анимации, всё, что нужно смотреть глазами после каждого изменения. При этом важно помнить итог теста: у Flash без plan mode правки шли раундами, но именно там возникли потери около 10 вызовов. Выбор режима зависит от задачи, а не от одного показателя.
Если критична стоимость токенов, plan mode экономию не гарантирует: в этом тесте у Flash вышло наоборот.
Насколько можно доверять этим цифрам
Ограничения стоит держать в голове, прежде чем переносить выводы на свой сценарий:
- Все данные взяты из одного теста пользователя PilgrimofHaqq2 на задаче генерации SVG-пеликана. Это не воспроизводимый бенчмарк с фиксированной методикой.
- В источнике описана только одна переменная: наличие или отсутствие plan mode. Версии, настройки и условия запуска MiMo 2.6 не указаны.
- Сравнение объёма токенов приведено только для Flash. Для Pro аналогичных данных нет.
- Число вызовов у обоих вариантов без plan mode в источнике не приводится, есть только раунды правок и зафиксированные потери.
- Выводы касаются генерации одного SVG-файла. На других типах задач поведение не проверялось.
Цифры из теста показывают, как один конкретный прогон распределил вызовы и токены, и не описывают MiMo 2.6 в целом.
Как проверить plan mode на своей задаче
Своё сравнение даёт больше, чем перенос чужих чисел. Порядок действий простой:
- Возьмите одну реальную задачу и зафиксируйте её формулировку. Менять промпт между прогонами не нужно, иначе сравнение потеряет смысл.
- Прогоните задачу дважды: с plan mode и без него, на одном и том же варианте модели.
- Считайте четыре показателя: число вызовов, объём сгенерированных токенов, число сбоев инструментов и качество результата.
- Отдельно посмотрите, сколько вызовов ушло на проверку промежуточного результата и не дало полезной информации.
- Сравните итог по задаче, а не по отдельной метрике: меньше вызовов при худшем результате не выигрыш.
Метрики из разбора выше стоит воспринимать как ориентир порядка величин, а не как норматив. Если выбираете между вариантами MiMo 2.6 и альтернативами вроде GLM 5.3 Flash, пригодится разбор сравнения MiMo 2.6 Flash и GLM 5.3 Flash: там собраны критерии, по которым модели стоит сопоставлять на своих задачах. Данные теста с SVG-пеликаном полезно держать рядом как пример честной фиксации вызовов и потерь.