Вообще Google явно делает ставку на скорость моделей. Возможно, готовит тот самый пресловутый фундамент для RSI - ведь для того, чтобы быстро совершенствоваться, нужны быстрые инструменты. Ситуация была такова:
У Гугла до эпохи Fable - были Gemini Pro 3.1 (умная, для рассуждений и сложных задач) и Flash 3.1 (быстрая, для несложных, и очень дёшево), вполне конкурирующие с другими моделями.
После выхода Fable - все ждали Pro 3.5. И он был в работе, доступ даже раздали партнёрам Гугла, он мелькнул на LMArena, но... не вышел. Злые языки шептались, что он оказался далёк от SOTA-моделей конкурентов.
Зато вышел Flash 3.5 (буквально через пару недель пропатченный до 3.6). На тестах он кое-где умудрился обойти Opus, хотя в целом был середнячком, но главное - был ЧЕРТОВСКИ быстр, порядка 150-200 токенов/сек. Пишешь запрос, и через пять секунд модель выплёвывает буквально страницы текста, бегунок прокрутки стремительно убегает вверх. Впечатляет.
А недавно, буквально неделю назад, вышел Flash 3.7 - и это оказался прорыв. Он всё ещё быстр как молния, но результаты показывает почти на уровне SOTA. При этом он ОЧЕНЬ дешёвый.
Из личной статистики, на моих задачах (кодинг C#, Unity, отладка, работа со сценой через MCP) средний показатель "число запросов до решения задачи":
Gemini Pro 3.1 - 4-5 запросов.
Opus 4.6 - 2-3 запроса.
Gemini Flash 3.1 - 10-15 запросов (не решает).
Sonnet 4.6 - 3-4 запроса.
Gemini Flash 3.5/3.6 - 3-4 запроса.
Gemini Flash 3.7 - 2-3 запроса.
ChatGPT Sol 5.6 - 1-2 запроса.
Причём Sol очень медленный (либо очень дорогой) - дал задачу, ушёл пить чай, вернулся, а он только её завершает. Flash же работает практически мгновенно, основное время он тратит на вызовы инструментов.
В итоге получается, что "бросовый" Flash 3.7 достигает успеха с задачей куда быстрее, чем Sol, причём дешевле чуть не в 10 раз.
Вероятно, в этом и ставка Гугла - удешевить токен, чтобы токенами можно было "залить" любую задачу, в том числе и совершенствование моделей.
Интересно, но хотелось бы поглядеть на тесты против других моделей (хотя бы того же Gemini, старого 3.1 Pro и нового Flash 3.7). И в статье нет ничего про то, на какой карточке гоняете, и каковы очки на конкретных задачах (кодинг, документы, иное).
Про де-факто хранение состояния проекта самим ИИ - любопытное наблюдение, но не удивительное.
Как-то раз, работая с нейросетью над рефакторингом довольно большого исходника (тысячи строк), я "неудачно чихнул" - и своими руками удалил файл. А нами было переписано пол-файла, десяток мест, и коммит был пару часов назад - то есть все выстраданные мной правки канули в Лету.
В отчаянии я написал нейросети - так и так, я случайно убил файл, можешь попробовать восстановить что-нибудь? Да не вопрос, ответил Gemini, и "по памяти" (он даже к Гиту за последним состоянием не обратился) восстановил содержимое! Причём абсолютно корректно, не наврал ни одну строчку. Вот тогда я крепко удивился.
А всякие RTOS, стоящие скажем в умных холодильниках и утюгах, дверных звонках, или скажем каких-нибудь проекторах или самокатах, тоже требуют возрастной верификации?
Некоторое время назад я переехал на 3.5 Flash с 3.1 Pro. Хоть модель и рассуждает похуже, но скорость очень многое решает. Пока Pro предлагает одно решение, Flash даёт три. Учитывая, что агенты нынче доросли до работы в цикле "вноси правки и проверяй результат", то скорость тут решает.
И тут 3.6 прямо очень в тему - он не сильно умнее, но при этом ещё быстрее.
"Перестройка" была известна у нас по имени исполняемого файла, Toppler. Игрушка была прикольная, но абсолютно нечестная - иногда просто не было маршрута, по которому можно было спастись.
А в "Генерала" играю до сих пор. Игра очень интересная, жалко нет исходников.
Недавно Gemini 3.5 Flash грохнул мне каталог с долго и кропотливо подготавливаемыми данными, порядка сотни файлов. Причина - решил удалить временные файлы, но выбрал не тот каталог. Потом тоже извинялся, но что самое приятное - смог восстановить основное из контекста.
SiMoCo вообще супер комбайн был, такого уровня нынешнему софту ещё лет сто не видать. Но это вроде как от энтузиастов, а по-моему, что-то из официального софта было.
Тут хочу поспорить. При уровне графики плюс-минус как в Doom Eternal (который бегал совсем уж на тостерах) - в игру вшит неотключаемый RT. При этом он сильно поганит картинку шумом, который разработчики попытались скрыть постэффектом зернистости. Дальние объекты тупо тонут в шумах, и играешь так, как будто у Думгая зрение -2. Неприятненько с художественной точки зрения и сомнительно с технической.
Ждём бенчмарков на кодовой базе. И вопрос - а есть маленькие варианты, типа 4B или 9B? Такая громадина это хорошо, но для обычного разработчика представляет чисто академический интерес. А хотелось бы пощупать руками.
Потому что многие оценивают скорость ПК через его отзывчивость. Процитируя давнего Каганова: "По моему глубокому убеждению, компьютер должен летать под пальцами пользователя. Символы должны вылетать из-под курсора на миг раньше, чем пользователь нажмет на клавишу. Окна и задачи - открываться и закрываться на миг раньше, чем пользователь осознает, что он действительно решил это сделать. По крайней мере именно такое должно создаваться у пользователя впечатление. <...> Я захочу открыть 1000 окон - открой мне их в тот же миг, подели мощность процессора на 1000, и чтоб все работали! А когда я захочу их закрыть - убей их в ту же микросекунду. В ту же! <...> Это я имею право задуматься над клавиатурой, а ты, (дочь собаки), должна преданно глядеть на меня, затаив дыхание, и терпеливо ждать, пока я соизволю снова обратить на тебя свое внимание!"
Бесплатный. но не бесконечный. На отметке в 200-300 draw call - любая видеокарта начинает давиться, даже если бюджет кадра по другим параметрам и близко не исчерпан. Причём цифра в последние лет 10 как будто почти не растёт. Более того, батчинг потому и стал актуален, что draw call часто становятся бутылочным горлышком рендера.
В старые добрые времена встроенный плеер был вменяем для "быстренько и без заморочек поглядеть что за файл". VLC открывался гораздо дольше, а MPC был не везде.
Очень классная статья! Не скажу что понял всё, но вопросы с CSM мне оказались интересны. Как специалиста - спрошу у вас сложное как раз по теме рендера :)
Как XRay борется со взрывным ростом Draw Call при рендеринге леса? Допустим, у нас лес:
5 видов деревьев,
У каждого 3 LOD-а,
Каждое в 1 индивидуальный материал.
В итоге, выходит 15 независимых вариантов. Если у нас 4 каскада теней, то в худшем случае у нас выходит 5*3*4 = 60 draw call чисто на тени. А это довольно много!
Батчинг, конечно, может собрать кучу всего, но LOD-ы и прозрачность довольно сильно стреляют в коленку. Как с этим борется XRay?
Проблема в том, что flash 3.1 и 3.5 - штуки для очень разных задач. Flash был хорош для написания кучи рутинного кода по заранее расписанному подробному плану. При помощи "дорогих" Claude или Gemini Pro планируем, а "бесплатный" Flash без всяких рассуждений просто пишет код как из пулемёта. На этом достигалась приличная скорость и экономия токенов.
А вот 3.5 как будто подкрутили для решения аналитических задач, но делает он это не слишком аккуратно. По моему опыту, flash 3.5 - это такой очень резвый и инициативный интерн, который сразу развивает бурную деятельность по задаче. Везде лезет, читает десяток файлов вокруг нужного места, что-то роет, копает, копает на огромной скорости, куда-то что-то пишет, за всё берётся, дёргает MCP, ошибается, исправляет сам себя... код пишет по-прежнему неплохо, но проблема в том, что токены при этом всё-таки начинают кончаться. Просадить в ноль лимит по Flash 3.1 - надо было очень сильно постараться, а вот по 3.5 они всё-таки иссякают.
Вообще Google явно делает ставку на скорость моделей. Возможно, готовит тот самый пресловутый фундамент для RSI - ведь для того, чтобы быстро совершенствоваться, нужны быстрые инструменты. Ситуация была такова:
У Гугла до эпохи Fable - были Gemini Pro 3.1 (умная, для рассуждений и сложных задач) и Flash 3.1 (быстрая, для несложных, и очень дёшево), вполне конкурирующие с другими моделями.
После выхода Fable - все ждали Pro 3.5. И он был в работе, доступ даже раздали партнёрам Гугла, он мелькнул на LMArena, но... не вышел. Злые языки шептались, что он оказался далёк от SOTA-моделей конкурентов.
Зато вышел Flash 3.5 (буквально через пару недель пропатченный до 3.6). На тестах он кое-где умудрился обойти Opus, хотя в целом был середнячком, но главное - был ЧЕРТОВСКИ быстр, порядка 150-200 токенов/сек. Пишешь запрос, и через пять секунд модель выплёвывает буквально страницы текста, бегунок прокрутки стремительно убегает вверх. Впечатляет.
А недавно, буквально неделю назад, вышел Flash 3.7 - и это оказался прорыв. Он всё ещё быстр как молния, но результаты показывает почти на уровне SOTA. При этом он ОЧЕНЬ дешёвый.
Из личной статистики, на моих задачах (кодинг C#, Unity, отладка, работа со сценой через MCP) средний показатель "число запросов до решения задачи":
Gemini Pro 3.1 - 4-5 запросов.
Opus 4.6 - 2-3 запроса.
Gemini Flash 3.1 - 10-15 запросов (не решает).
Sonnet 4.6 - 3-4 запроса.
Gemini Flash 3.5/3.6 - 3-4 запроса.
Gemini Flash 3.7 - 2-3 запроса.
ChatGPT Sol 5.6 - 1-2 запроса.
Причём Sol очень медленный (либо очень дорогой) - дал задачу, ушёл пить чай, вернулся, а он только её завершает. Flash же работает практически мгновенно, основное время он тратит на вызовы инструментов.
В итоге получается, что "бросовый" Flash 3.7 достигает успеха с задачей куда быстрее, чем Sol, причём дешевле чуть не в 10 раз.
Вероятно, в этом и ставка Гугла - удешевить токен, чтобы токенами можно было "залить" любую задачу, в том числе и совершенствование моделей.
Штука по цене 1.8 мегарубля - это СВОЯ карта?! Богато живёте :)
Интересно, но хотелось бы поглядеть на тесты против других моделей (хотя бы того же Gemini, старого 3.1 Pro и нового Flash 3.7). И в статье нет ничего про то, на какой карточке гоняете, и каковы очки на конкретных задачах (кодинг, документы, иное).
Про де-факто хранение состояния проекта самим ИИ - любопытное наблюдение, но не удивительное.
Как-то раз, работая с нейросетью над рефакторингом довольно большого исходника (тысячи строк), я "неудачно чихнул" - и своими руками удалил файл. А нами было переписано пол-файла, десяток мест, и коммит был пару часов назад - то есть все выстраданные мной правки канули в Лету.
В отчаянии я написал нейросети - так и так, я случайно убил файл, можешь попробовать восстановить что-нибудь? Да не вопрос, ответил Gemini, и "по памяти" (он даже к Гиту за последним состоянием не обратился) восстановил содержимое! Причём абсолютно корректно, не наврал ни одну строчку. Вот тогда я крепко удивился.
А всякие RTOS, стоящие скажем в умных холодильниках и утюгах, дверных звонках, или скажем каких-нибудь проекторах или самокатах, тоже требуют возрастной верификации?
Жалко, а я только раскатал губу на фоне недавних успехов Гугла во Flash-моделях, которые сейчас быстрее всего, что есть на рынке.
Некоторое время назад я переехал на 3.5 Flash с 3.1 Pro. Хоть модель и рассуждает похуже, но скорость очень многое решает. Пока Pro предлагает одно решение, Flash даёт три. Учитывая, что агенты нынче доросли до работы в цикле "вноси правки и проверяй результат", то скорость тут решает.
И тут 3.6 прямо очень в тему - он не сильно умнее, но при этом ещё быстрее.
"Перестройка" была известна у нас по имени исполняемого файла, Toppler. Игрушка была прикольная, но абсолютно нечестная - иногда просто не было маршрута, по которому можно было спастись.
А в "Генерала" играю до сих пор. Игра очень интересная, жалко нет исходников.
Эх, вот бы 4B-версию иметь с хорошим сжатием...
Недавно Gemini 3.5 Flash грохнул мне каталог с долго и кропотливо подготавливаемыми данными, порядка сотни файлов. Причина - решил удалить временные файлы, но выбрал не тот каталог. Потом тоже извинялся, но что самое приятное - смог восстановить основное из контекста.
SiMoCo вообще супер комбайн был, такого уровня нынешнему софту ещё лет сто не видать. Но это вроде как от энтузиастов, а по-моему, что-то из официального софта было.
Ага, на КПК это называлось ActiveSync. Я тогда думал что это "необходимый минимум"... а оказалось что "роскошный максимум"?
P.S. Даже на старом Siemens S75 был инструментарий для этого, но за давностью лет из памяти название выветрилось из головы.
Тут хочу поспорить. При уровне графики плюс-минус как в Doom Eternal (который бегал совсем уж на тостерах) - в игру вшит неотключаемый RT. При этом он сильно поганит картинку шумом, который разработчики попытались скрыть постэффектом зернистости. Дальние объекты тупо тонут в шумах, и играешь так, как будто у Думгая зрение -2. Неприятненько с художественной точки зрения и сомнительно с технической.
Ждём бенчмарков на кодовой базе. И вопрос - а есть маленькие варианты, типа 4B или 9B? Такая громадина это хорошо, но для обычного разработчика представляет чисто академический интерес. А хотелось бы пощупать руками.
Нервно потеребил телефон в кармане - и получил кирпич. Это они удобно придумали.
Потому что многие оценивают скорость ПК через его отзывчивость. Процитируя давнего Каганова: "По моему глубокому убеждению, компьютер должен летать под пальцами пользователя. Символы должны вылетать из-под курсора на миг раньше, чем пользователь нажмет на клавишу. Окна и задачи - открываться и закрываться на миг раньше, чем пользователь осознает, что он действительно решил это сделать. По крайней мере именно такое должно создаваться у пользователя впечатление. <...> Я захочу открыть 1000 окон - открой мне их в тот же миг, подели мощность процессора на 1000, и чтоб все работали! А когда я захочу их закрыть - убей их в ту же микросекунду. В ту же! <...> Это я имею право задуматься над клавиатурой, а ты, (дочь собаки), должна преданно глядеть на меня, затаив дыхание, и терпеливо ждать, пока я соизволю снова обратить на тебя свое внимание!"
Бесплатный. но не бесконечный. На отметке в 200-300 draw call - любая видеокарта начинает давиться, даже если бюджет кадра по другим параметрам и близко не исчерпан. Причём цифра в последние лет 10 как будто почти не растёт. Более того, батчинг потому и стал актуален, что draw call часто становятся бутылочным горлышком рендера.
В старые добрые времена встроенный плеер был вменяем для "быстренько и без заморочек поглядеть что за файл". VLC открывался гораздо дольше, а MPC был не везде.
Очень классная статья! Не скажу что понял всё, но вопросы с CSM мне оказались интересны. Как специалиста - спрошу у вас сложное как раз по теме рендера :)
Как XRay борется со взрывным ростом Draw Call при рендеринге леса? Допустим, у нас лес:
5 видов деревьев,
У каждого 3 LOD-а,
Каждое в 1 индивидуальный материал.
В итоге, выходит 15 независимых вариантов. Если у нас 4 каскада теней, то в худшем случае у нас выходит 5*3*4 = 60 draw call чисто на тени. А это довольно много!
Батчинг, конечно, может собрать кучу всего, но LOD-ы и прозрачность довольно сильно стреляют в коленку. Как с этим борется XRay?
Проблема в том, что flash 3.1 и 3.5 - штуки для очень разных задач. Flash был хорош для написания кучи рутинного кода по заранее расписанному подробному плану. При помощи "дорогих" Claude или Gemini Pro планируем, а "бесплатный" Flash без всяких рассуждений просто пишет код как из пулемёта. На этом достигалась приличная скорость и экономия токенов.
А вот 3.5 как будто подкрутили для решения аналитических задач, но делает он это не слишком аккуратно. По моему опыту, flash 3.5 - это такой очень резвый и инициативный интерн, который сразу развивает бурную деятельность по задаче. Везде лезет, читает десяток файлов вокруг нужного места, что-то роет, копает, копает на огромной скорости, куда-то что-то пишет, за всё берётся, дёргает MCP, ошибается, исправляет сам себя... код пишет по-прежнему неплохо, но проблема в том, что токены при этом всё-таки начинают кончаться. Просадить в ноль лимит по Flash 3.1 - надо было очень сильно постараться, а вот по 3.5 они всё-таки иссякают.