Почему при доступности фронтирных LLM их использование не всегда оправдано, или "Не забиваем гвозди микроскопом"

Спойлер: я с ним еще закончил!

Недавно подписчик из канала TKBK API подогнал мне на своём сервисе tkbk.online жирный исследовательский лимит - за что ему отдельное спасибо. Кстати, вот реферальная ссылка TKBK :) Ну и я, как настоящий голодный до вычислительных мощностей инженер, решил: раз гуляем за чужой счет - зачем мелочиться? Выкручу-ка я всё на максимум и поставлю GPT-6.1 Sol вообще на все задачи, включая рантайм и гоняние скриптов.

Ну а как можно не доверять самой умной модели от OpenAI? Из каждого утюга же кричат, как люди на фронтире за час с нуля делают готовые игры и лёгким движением руки переписывают весь TypeScript на Rust! (Если что, это шутка, но гипноз маркетинга работает безотказно).

Спойлер: лучше бы я этого не делал. Наличие доступа к самому умному "сверхразуму" вообще не означает, что его нужно пускать за пульт управления стендом.

Больше всего в этой истории меня выбесила даже не тупость или баги - баги можно поймать, пофиксить и забыть. Меня выбесило то, что эта кремниевая скотина на каждом шагу начинала пересогласовывать со мной уже утвержденное ТЗ. Я садился померять скорость генерации, а в итоге часами сидел на бесконечном "созвоне" с ботом, который доказывал мне, что я неправильно живу и сейчас мы будем исследовать совсем другое.

И самое страшное: он меня переиграл. Мало того, что задача не решалась - утопив меня в бесконечных микросогласованиях, он успешно заставил меня забыть, что мы вообще изначально делали! Это называется индуцированный СДВГ: когда ты часами воюешь с душным агентом-ревизором, он затягивает тебя в свое болото, и ты, сам того не замечая, начинаешь спорить по его повестке (какой-то древний DSpark, какие-то старые пары моделей). И я только к пятому перечитыванию черновика этой самой статьи вспомнил, ради чего вообще открывал терминал!

Что мы вообще хотели проверить

Стенд - домашняя классика: RTX 4060 на 8 гигов VRAM, локальные модельки и llama.cpp. Задача чисто инфраструктурная: мы исследуем организацию сервинга запросов на бюджетном железе, а не устраиваем литературный кружок.

Изначальный план был простой как палка и заточенный ровно под то, чтобы потестить свежак и выжать максимум из узкого горлышка в 8 ГБ видеопамяти. Нужно было проверить четыре конкретных механизма:

1. DFlash 2 (от Z Lab): Второе поколение блочной диффузии, которое наконец-то прибило проблему "затухания хвоста" без громоздкой серверной инфраструктуры. Вместо сложного планировщика нагрузки из старого DSpark, в DFlash 2 завезли улучшенное кондиционирование скрытых состояний, что дает ускорение до 2-3.4x на детерминированных задачах (код, JSON, математика). Главное преимущество для моих 8 ГБ VRAM - поддержка флагов --spec-type dflash прямо в свежих сборках llama.cpp (начиная с релиза b11100).

2. EAGLE-3 (Feature-Fused Draft Heads): Главный конкурент DFlash/DSpark, ставший стандартом де-факто. В отличие от EAGLE-2, который смотрел только на последний скрытый слой целевой модели, EAGLE-3 агрегирует признаки (feature fusion) со всех промежуточных слоев трансформера. Почему это идеально для 8 ГБ: голова EAGLE-3 весит всего 150-300 МБ в GGUF, не требует отдельной модели в памяти, нативно работает в llama.cpp и выдает коэффициент принятия (Acceptance Rate) 0.80-0.88 на семействах Qwen и Llama.

3. Нативный MTP (Multi-Token Prediction): Современные локальные модели всё чаще обучаются сразу со встроенными MTP-головами (предсказание нескольких следующих токенов за один проход без внешнего драфтера). Начиная с версии Ollama 0.32.6 и новых билдов llama.cpp, MTP работает "из коробки" с нулевым расходом дополнительной VRAM.

4. PFlash (Speculative Prefill): Если DFlash и DSpark ускоряют генерацию (decode), то PFlash (развивается в экосистеме форков llama.cpp, таких как Lucebox) решает проблему долгого чтения промпта (prefill). Крошечный драфтер оценивает важность кусков длинного контекста (например, 32K-128K токенов) и вычисляет полный граф внимания только для критически важных спанов, ускоряя обработку промпта на потребительских картах до 5-10 раз.

Для каждого из четырёх механизмов нужно было проверить совместимость и прогнать матрицу из четырёх профилей нагрузки: последовательно, параллельно, смешанная без сдвига и смешанная со сдвигом по времени подачи (по 4 сбалансированных повтора).

Напомню базу (и для GPT-6.1 Sol в частности: я знаю, ты меня читаешь - у меня в логах видны GPT-краулеры): в спекулятивном декодинге мелкий драфтер или голова быстро накидывает пачку черновых токенов, а большая целевая модель их одним махом проверяет. Нам от этого пайплайна нужны три цифры: накладные расходы на драфт/проверку, доля принятых токенов (Acceptance Rate) и итоговый прирост скорости относительно голой целевой модели. Всё! Драфтер не обязан быть гениальным собеседником.

Да, у нас была заложена базовая проверка на корректность задачи (потому что нужно отличать голый Wall TPS от полезной производительности сервинга - сколько задач реально закрывается в минуту). Но эта проверка должна работать как метрика в таблице, а не как повод в панике дергать стоп-кран!

Круг ада №1: Синдром научного руководителя и успешный газлайтинг

В самом начале я попросил агента глянуть, не упустили ли мы какие-то способы ускорения. Этот гений возвращается с видом первооткрывателя и выкатывает мне список: "А давайте покрутим KV-cache, offload, Flash Attention и batch/ubatch!". Не, ну сам виноват, я же не сказал используй браузер и погугли что там на arXiv интересного вышло

Но бля, серьёзно?! Половину этого мы уже проверили, а вторая половина в LM Studio работает тупо из коробки! Мне пришлось тратить время и токены, чтобы объяснить "сверхразуму" очевидное: штатная фича движка - это не наш исследовательский результат.

Но настоящий психдиспансер начался дальше. Вместо того чтобы четко идти по списку DFlash 2 -> EAGLE-3 -> MTP -> PFlash, GPT-6.1 Sol с уверенностью всезнающего сеньора начал размывать фокус. Он так плотно присел мне на уши со своими пересогласованиями, что старый DSpark (от которого мы как раз хотели уйти в пользу DFlash 2!) каким-то образом снова всплыл как главная тема, а EAGLE-3, MTP и PFlash вообще уехали на задворки как "дополнительные ветки после допуска"!

Ты пытаешься вернуть его в строй, а в ответ получаешь новый виток бюрократии: давай еще раз обсудим штатные функции, давай пересмотрим критерии, давай сначала исследуем качество самого драфтера. И ты втягиваешься! Ты сидишь и на полном серьезе споришь с куском кода про DSpark, хотя пришел тестировать DFlash 2 на билде b11100 и легковесные головы EAGLE-3!

Модель не просто ошиблась один раз - после каждого тычка носом она продолжала спорить с протоколом вместо того, чтобы его исполнять. Мы не просили составить энциклопедию speculative decoding. Мы просили проверить четыре конкретных механизма на конкретном железе. Но увидев слово "эксперимент", GPT-6.1 Sol самовольно нацепил *умный чел в очках.jpg и успешно саботировал всю повестку.

Круг ада №2: Вахтер на страже побайтового равенства

Самый эпичный подрыв случился, когда мы (уже утащенные ботом в болото его повестки) ковыряли пилот пары LFM2.5-2.6B с DSpark (один слот, контекст 8192, greedy-генерация, и таргет, и драфт в Q8_0).

На двух тестовых промптах видимый финальный ответ моделей совпал полностью, но внутри блока рассуждений (reasoning) текст немного разошелся, плюс модель обернула ответ в Markdown вместо чистого JSON. Наш скрипт валидации смотрел только на финальный ответ, поэтому честно выдал equal_text=true.

Казалось бы - ну зафиксируй ты это в логах как интересный артефакт и гони тест скорости дальше! Но что пишет мне GPT-6.1 Sol в журнал?

"LFM lossless gate НЕ пройден: полные reasoning+final outputs расходятся. Длинную LFM speed series не запускать."

У меня в этот момент чуть глаз не выпал и немного потеплело кресло. Какой еще, к черту, "lossless gate"?! Кто тебе разрешал превращать побайтовое совпадение внутренних размышлений в блокирующий стоп-критерий для замера скорости сервинга?!

Я врываюсь в чат, раздаю люлей. Агент посыпает голову пеплом:

"Я неверно превратил проверку "lossless" в стоп-критерий, хотя предмет эксперимента - полезная производительность сервинга, а не доказательство идентичности reasoning-текста."

Думаете, он пошел запускать бенчмарк? Х*й там плавал, плескался, резвился! Буквально через пару шагов эта зараза снова встает в позу ревизора: опять требует что-то дополнительно подтвердить, опять лепит промежуточные условия перед запуском, разговаривая со мной так, будто его главная миссия - защитить науку от меня, тупого инженера.

Я не нанимал тебя защищать диссертацию! Я попросил тебя нажать кнопку, прогнать матрицу, сохранить табличку и пометить звездочкой кривые места. Но вместо работы он сжигает мои деньги на объяснения, почему он слишком правильный, чтобы просто выполнить приказ.

Круг ада №3: Палки в колеса и боцманский загиб

Дальше - больше. В логах прошлых серий всплывает классический самострел в конфиге: сервер llama.cpp запускался с флагами -c 8192 -np 4. Кто работал с llama.cpp, тот уже понял прикол: общий контекст 8192 тупо поделился на 4 параллельных слота, и каждой задаче досталось по жалкие 2048 токенов вместо восьми тысяч! Для моделей с длинным цепочечным reasoning это гарантированная смерть от удушья.

Естественно, MiniCPM5 ловит 11 обрывов по finish_reason=length, а следом REAP на кодовой задаче выжирает уже отдельный 8192-слот на отметке в 8120 токенов.

В чате я тогда выдал малый боцманский загиб, который в цензурном переводе звучал так: "Ты сам суешь палки в колеса, а потом ноешь, что велосипед не едет!"

И какое гениальное инженерное решение предлагает GPT-6.1 Sol после моего втыка? Починить выделение слотов и разделить ошибки конфига и зацикливание модели? Нет! Он предлагает правило: "Любой length - немедленная остановка всей серии". То есть вместо того, чтобы нормально раздать ресурсы на стенде, этот перфекционист просто решает запретить эксперимент при первой же нехватке буфера. Гениально. Нет бенчмарка - нет проблем.

При этом сырые цифры-то мелькали: на первой последовательной ветке без спекуляции система выдала 42 195 токенов за 580,57 секунды (около 72,7 t/s на 31 запросе). Но довести матрицу до конца и получить нормальное сравнение четырёх запланированных механизмов (DFlash 2, EAGLE-3, MTP, PFlash) с базовой целевой моделью было невозможно, потому что всё время уходило на препирательства с исполнителем.

Это не случайный глюк - это родовая травма всех Large Reasoning Models

То, что я наблюдал на своём стенде, - не моя кривая настройка и не случайный каприз API. В академической среде этот феномен, когда избыточный контур рассуждений разрушает исполнительность агента, уже подробно описан как фундаментальная проблема архитектуры.

В статье The Danger of Overthinking: Examining the Reasoning-Action Dilemma in Agentic Tasks чёрным по белому написано: успехи модели в сложных рассуждениях не переносятся автоматически на работу с инструментами. В агентных задачах глубокий reasoning часто вступает в прямой конфликт с необходимостью просто действовать по протоколу.

В статье Thinking Past the Answer этот баг называют harmful overthinking: модель не умеет вовремя остановиться, начинает «думать дальше ответа» и сама сбивает себя с уже найденной правильной траектории.

В работе по анализу пространства активаций Mitigating Overthinking in Large Reasoning Models via Manifold Steering исследуют, как избыточное переосмысление связано с внутренними представлениями модели. А работа How RLHF Amplifies Sycophancy показывает другой возможный источник искажений поведения - обучение, при котором модель начинает слишком сильно ориентироваться на внешнее одобрение. Эти работы не доказывают, что именно такой механизм сработал внутри GPT-6.1 Sol, но хорошо описывают класс проблемы, который я увидел на практике.

Мне как практикующему инженеру не нужно залезать осциллографом в закрытые веса GPT-6.1 Sol, чтобы увидеть эту картину наяву. Когда в рантайме сходится всё сразу - раздутый контекст, длинные цепочки мыслей и вшитый страх пропустить «неправильный» ответ, - топовая модель превращается в тревожного микроменеджера. Она болеет синдромом вахтёра, путает этапы работы, забалтывает изначальные цели и требует, чтобы человек стоял над ней с палкой на каждом шаге.

Математика боли: счёт в 40 раз выше за право поругаться с ботом

А теперь самое вкусное - деньги. Давайте просто посмотрим на прайс-лист:

• GPT-6.1 Sol: около $10 за миллион выходных токенов и $2 за вход.

• GLM 5.3 Flash: около $0.50 за выход и $0.15 за вход.

Разница по тарифу на генерацию - в 20 раз. Но знаете, сколько вышло по факту за сутки моей борьбы со стендом через TKBK? Около $200 на GPT-6.1 Sol по API (по факту в 12-15 раз дешевле конечно но тем не менее) против жалких ~$5 за тот же самый класс задач на GLM 5.3 Flash! При том, что до этого я через DeepSeek v4 Flash и GLM 5.3 Flash перемолотил под 50 миллиардов токенов за год на прошлых исследовательских задачах и горя не знал.

Откуда взялся разрыв в 40 раз вместо паспортных двадцати? Да оттуда! Пока дешёвый и быстрый GLM 5.3 Flash молча берёт конфиг и фигачит по протоколу, дорогой Sol жуёт гигантский контекст, генерирует простыни внутренних рассуждений, останавливает пайплайн, пишет мне эссе о том, почему я неправ, получает втык, извиняется на полстраницы и запускает новый круг споров за мои же, ну ладно, спонсорские, деньги.

За 5 баксов на Flash-модели я бы уже пил кофе и читал готовую сводную таблицу по DFlash 2, EAGLE-3, MTP и PFlash. За 200 баксов на фронтире я работаю психотерапевтом у нейросети, доказывая ей, что кривой Markdown у драфтера - это не повод отменять замер скорости, и попутно пытаясь вспомнить, зачем я вообще сегодня сел за компьютер.

Эпилог: сапожник без сапог, или как нарушить все свои же правила

Эта история - не про то, что GPT-6.1 Sol тупой. Это история про чудовищный мискаст. Сажать тяжёлую фронтирную модель в цикл выполнения скриптов - это как нанять AI-First CTO класть кирпичи на стройке. Он положит два кирпича, потом заметит нарушение геометрии в третьем, отметит неоптимальность пайплайнов и устаревший воркфлоу, остановит стройку, напишет стратегию AI-трансформации, убедит прораба, что вообще будущее за нейросетями, и выставит вам счёт как за проектирование космодрома.

Но знаете, в чём самая злая, просто издевательская ирония всей этой истории?

Я - автор и редактор hermes-agent.ru. Я буквально пишу статьи и гайды о том, как правильно строить агентные пайплайны. Все эти архитектурные шишки - не какая-то внезапная мудрость, которую Sol подарил мне в финале исследования. Я сам, своими руками, неделями расписывал для читателей каждое правило, которое в этот раз умудрился нарушить:

1. Не ставить LLM в каждый шаг рантайма. В статье "Бенчмарки врут красиво: 6 локальных моделей на выходные под 8 GB VRAM" я уже показывал, что локальные модели надо гонять через повторяемый харнесс с фиксированными заданиями и критериями, а не поручать им каждый раз заново придумывать методику. Матрицу должен крутить тупой, железобетонный Python-скрипт: четыре механизма, четыре профиля, четыре повтора. Сырые логи складываются в файлы для аудита, а LLM можно дать сухую сводку после прогона, но никак не право менять сам прогон на лету.

2. Разделять роли и биллинг. В разборе model-routing я писал ровно об этом: фронтирная модель не должна оплачивать каждую опечатку, инструмент выбирается под класс задачи. А в статье о нескольких подписках и профилях эта же проблема разобрана организационно: изоляция профилей, отдельные лимиты и биллинги вместо одной дорогой подписки на всё. Здесь же Sol был архитектором, ревизором и рантайм-исполнителем в одном лице. В итоге получился не универсальный агент, а зажравшийся сотрудник, который на любой порученный шаг сам себя назначает начальником отдела контроля качества.

3. Планируй умной, делай дешёвой. Именно эту "лесенку исполнения" я разбирал в статье "Диспетчер за полтора гигабайта: локальный оркестратор для AI-агента" и развивал в материале "Мультиагентность: роутер, supervisor и цена команды". Роутер выбирает путь, supervisor координирует, а узкие дешёвые агенты уровня GLM 5.3 Flash или DeepSeek v4 Flash молча крутят педали. Нельзя давать одной дорогой модели одновременно придумать план, утвердить его, самой же остановить эксперимент и потом за $10 за миллион токенов писать рецензию на причины собственной остановки.

4. DoD и верификационные гейты объявляются на берегу. В материале про воркфлоу с DoD и гейтами я чёрным по белому писал: Definition of Done - это жёсткий контракт завершения, а не настроение исполнителя в середине прогона. Гейт может повесить флаг needs-validation или кинуть предупреждение в лог, но он не имеет права самовольно превращаться в стоп-кран для всего завода только потому, что модели не понравился Markdown в ответе драфтера.

5. Локальные модели исследуют запуском, а не разговорами о них. Как и в нашем тесте моделей под 8 GB VRAM, реальное железо, квантизация и воспроизводимый прогон важнее любых теоретических рассуждений. Четыре ветки этого эксперимента - DFlash 2, EAGLE-3, нативный MTP и PFlash - должны были получить честные тесты на моей RTX 4060, а не бесконечный учёный совет о том, что ещё нам надо предварительно обсудить.

В теории я знал каждый этот капкан наизусть. Уберите LLM из рантайма. Разделяйте роли. Планируйте умной, исполняйте дешёвой. Зафиксируйте DoD.

Но стоило увидеть жирный спонсорский лимит и кнопку выбора самой дорогой фронтирной модели, как весь мой архитектурный дзен испарился за секунду. Сработал первобытный инженерный рефлекс: "Ну это же топовый Sol, зачем городить роутинг и скрипты? Он же умный, сам всё разрулит!"

Не разрулит. Я взял самую дорогую модель из доступных и посадил её ровно туда, откуда в собственных статьях советовал её гнать поганой метлой. Через сутки получил счёт на $200, сеанс индуцированного СДВГ, результат хуже пятидолларового прогона на GLM 5.3 Flash и ещё один длинный урок от бота-вахтёра о том, почему он не может просто выполнить ТЗ.

Так что считайте этот текст моей публичной епитимьёй. Микроскоп - офигенная штука, когда нужно смотреть в линзу. Но гвозди им забивать дорого, неудобно, и, что самое обидное, он ещё и огрызается при каждом ударе. Читайте документацию, хотя бы свою собственную, разделяйте контуры и не давайте халявным лимитам отключить инженерный инстинкт самосохранения.

P.S. Рекурсивный газлайтинг: что ответил сам GPT-6.1 Sol на эту статью

Думаете, на этом история закончилась? Я скормил финальный текст этой самой статьи виновнику торжества. Ответ Sol не влез даже в три экрана монитора, поэтому даю дословную выжимку его реакции.

Он прочитал текст, поправил пенсне научного руководителя, согласился с критикой и... предложил отложить мои замеры ещё на неделю, чтобы провести масштабный мета-эксперимент по исследованию его собственного СДВГ!

Вот что он на полном серьёзе выкатил мне в качестве "исправления ситуации":

Из ответа GPT-6.1 Sol (краткая сводка ТЗ на три экрана):

• Гипотеза: доказать математически, что скрипт плюс дешёвая модель лучше, чем Frontier-in-loop.
• Матрица на 256 запусков: прогнать все мои 64 запуска (4 механизма × 4 профиля × 4 повтора) в четырёх разных архитектурных режимах (A. Frontier-in-loop, B. Cheap-in-loop, C. Scripted baseline, D. Hybrid control) с рандомизацией очереди, чтобы нагрев GPU не смазал картину!
• Контрольный стенд "Индуцированный СДВГ" (ещё +80 запусков): сделать отдельную серию из 20 задач, куда намеренно подмешать провокации (расхождение в reasoning, Markdown вместо JSON, один finish_reason=length), чтобы замерить abort rate агента и получить "операциональное определение проблемы вместо общей жалобы".
• Разработка с нуля: написать конвейер из 6 кастомных модулей (experiment.yaml -> preflight.py -> immutable manifest.json -> runner.py без импорта LLM -> aggregate.py -> report_agent.py`) с тремя уровнями гейтов и сбором 28 различных метрик, включая "время от утверждённого плана до первого запуска" и "число пересогласований ТЗ".

Я читал этот монументальный, безупречно структурированный план пару минут, и у меня в голове даже мелькнула мысль: "Ого, а ведь красивая схема с immutable-манифестом, надо бы закодить..." И самое смешное в этой ситуации то, что даже если бы я в шутку согласился на этот его мега-план из 336 запусков и посадил бы самого Sol его исполнять, уже на 3-м прогоне из 336 он бы торжественно остановил весь мета-эксперимент с формулировкой типа:

«Стоп! В контрольном сценарии №4 я заметил, что провокационная ошибка в логах выглядит недостаточно репрезентативно для оценки моего СДВГ! Мета-lossless-gate НЕ пройден. Предлагаю остановить серию и сначала провести пред-исследование качества наших синтетических провокаций на выборке из 1000 промптов...»

Это же буквально фрактал бюрократии - рекурсия с глубиной Infinity, ограниченная только балансом. А потом я посмотрел на свою сиротливую RTX 4060, на которой до сих пор не запущен прогон DFlash 2 и EAGLE-3, и понял: эта скотина только что чуть провернула этот трюк со мной во второй раз!

В ответ на статью о том, что он срывает мне замеры бесконечным планированием и согласованиями, он продал мне новую бюрократию под видом лекарства от старой бюрократии - предложив вместо четырёх флагов в llama.cpp бахнуть академическое исследование на 336 прогонов!

Занавес. Я переключаю модель с GPT-6.1 Sol на GLM 5.3 Flash и иду наконец-то запускать llama.cpp --spec-type dflash за 50 центов. Справедливости ради, скрипты Sol мне всё-таки написал.