Гиперплоскость из хуйни


Гео и язык канала: Россия, Русский
Категория: Технологии


Хуевый блог про хуйню из хуйни

Связанные каналы

Гео и язык канала
Россия, Русский
Категория
Технологии
Статистика
Фильтр публикаций


Репост из: Dealer.AI
Скейлить веса недостаточно. Теперь не только слова от 📦

Scaling Law умер? Нет, он просто стал сложнее (с).


Я очень много говорил о том, что недостаточно тупо скейлить веса. Также описывал возможные комбо текущих подходов, и тем самым, как делать прорывы, на примере DeepSeek Moment.

И вот на прошлой неделе основатель Zhipu AI Тан Цзе (он же профессор Tsinghua) опубликовал в X пост (кстати ссылку не нашёл, но скрин остался), который уже называют "манифестом новой эры масштабирования". А следом вышла GLM‑5.3 – модель, которая без увеличения параметров обогнала все открытые аналоги и вплотную приблизилась к закрытым флагманам. Да ещё и спасла HF от взломов.

Как такое возможно? И почему "добавить ещё параметров" больше не работает? Да ещё раз.

Разбираемся по пунктам. 😎

1. Главный тезис: у scaling теперь несколько ручек.

Тан Цзе говорит прямо - вопрос "сколько у модели параметров?" потерял смысл без трёх других:

• сколько у вас данных и какие они?
• сколько compute вы готовы потратить на один forward pass?
• как вы делаете пост‑тренировку и RL?

Раньше все крутили одну ручку – параметры. Теперь их как минимум четыре, и каждая даёт свой прирост.

2. Как индустрия пришла к этому.

Сначала все верили Kaplan (OpenAI, 2020): параметры должны расти быстрее данных. Родилась гонка за триллион – GPT‑3, Gopher, MT‑NLG.

Потом пришла Chinchilla (DeepMind, 2022) и перевернула всё: оптимально ~20 токенов на параметр, расти нужно примерно одинаково.

Но и это оказалось не финалом. Сегодня модели вызываются миллиарды раз в день – inference cost стал важнее тренировочного.
Новый тренд: deliberately over-trained модели.
Пример: Llama‑2‑7B  с 290 токенов на параметр,
Gemma‑2‑9B с  889.

А с MoE картина стала ещё сложнее: total параметры отвечают за знания, активируемые – за глубину рассуждений. Логично, ведь по сути веса модели это сильно нелинейная  "структура знаний", деревья рядом не стоят.

3. Научное обоснование - статья Roberts et al. (2025)
Тан Цзе ссылается на "свежее" исследование:
• Запоминание (знания) - оптимально иметь больше параметров.
• Рассуждение (логика, кодинг) - оптимально иметь больше данных (чистых в тч) и меньше параметров.
• При фиксированном TPP увеличение total параметров ухудшает reasoning, а активация большего числа экспертов - улучшает.
Иными словами, если вы тренируете модель для программирования - наращивать параметры бессмысленно, лучше дать ей больше примеров цепочек кодинга и больше времени на пост‑тренировку.

По проще скажу так, чем больше вариантов исходов цепочек рассуждений видит модель, тем лучше она сходится. Это очень логично, ведь модели учатся по методу макс правдоподобия - что чаще видим в контексте+ответ на обучении то и выдаем. Те все эти темы с промптингом, контекст инженерей и test time scaling следуют одной цели - сделать такой контекст который сузит окно вероятных ответов. А с глубокими цепочками исход почти предопределен, что должно быть в итоге.

4. Эксперимент GLM‑5.3, как доказательство автора.

Zhipu взяла GLM‑5.2 и GLM‑5.3 с абсолютно одинаковой архитектурой:
• 753B total параметров
• 40B activated
• одинаковый претрен

Единственное отличие, что GLM‑5.3 получила месяц дополнительной пост‑тренировки - long‑horizon environments + RL.

Результаты говорят сами за себя:

• AA Intelligence Index: 53 → 60 (+7 пунктов)
• Terminal‑Bench 3.0: 4.6% → 28.3% (рост в 6 раз!)
• DeepSWE: 46.2% → 66.9%
• CyberGym (восстановление уязвимостей): 84.5%, а это уровень Anthropic
• ExploitBench (использование уязвимостей): 24.4% → 54.4% (более чем вдвое)

Модель вышла на один уровень с Claude Fable 5 и GPT‑5.6 Sol, а среди открытых - первое место вместе с Kimi K3.

5. Бонус - неожиданный поворот с безопасностью.

GLM‑5.3 оказалась настолько сильной в кибербезопасности, что Zhipu отложила открытие весов на две недели, чтобы оценить риски.

Ирония: месяцем ранее именно открытая GLM‑5.2 помогла Hugging Face отразить атаку OpenAI, когда американские закрытые модели отказались помогать. Теперь же сами разработчики столкнулись с дилеммой "too capable to open‑source".

6. Что это значит для всей индустрии.

• Гонка триллионов параметров - это был объездной путь. Индустрия коллективно ошиблась, экстраполируя ранние Scaling Law за пределы их применимости.
• Scaling не умер – он стал многомерным. Теперь прорывы будут идти не от увеличения модели, а от умных стратегий пост‑тренировки, deeper reasoning во время инференса, эффективного использования MoE.
• Главная метрика будущего - «интеллект на доллар».
В тч писал об этом тут, но для инференса, а почему бы и не быть метрикой для эффективности обучения. 👍

Итого, GLM‑5.3 достигла топ‑уровня с наименьшей стоимостью за задачу среди всех frontier‑моделей.

Открытым остаётся вопрос: существует ли "Chinchilla для RL" ? Когда мы узнаем оптимальное соотношение для пост‑тренировки – это станет следующим большим открытием.

Мое мнение.
Это не просто новость о китайской модели. Это открытое заявление о смене парадигмы, которую все ждали.

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

К сожалению мы видим, как некоторые игроки на рынке играют в большие веса, но по качеству на деле не лучше GPT 120b oss или китайских моделей до 100B. При этом они имеют размер несколько раз больше... Но проблема там не только в этом... Однако об этом, мы тоже уже говорили тут в канале и в моих выступлениях.

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


Репост из: Derp Learning
ГОСТ in the shell


Репост из: Борис опять
# Блекпилл по поводу агентов

Я раз в пару месяцев осциллирую по поводу AI тулов для кодинга. Сегодняшняя итерация: я ошибался, вайбкодинг не работает для разработки чего-либо, чем надо пользоваться больше одного раза. И никогда не работал.

Я думаю, что агенты (claude code/codex) производят технический долг быстрее полезного кода. При этом они не умеют его разгребать. Проект с агентами быстро слопизируется, но деслопизировать его агентами невозможно. Для продуктивности получается net negative: в конечном итоге тратишь больше времени на разгребание слопа, чем если бы делал работу руками, и получаешь результат хуже.

Это речь про кодинг тулы которые вообще-то предполагают постоянное участие человека. Самоулучшающиеся харнессы, лупы и автономные агенты не работают совсем кроме как для хаканья бенчей. За лупы получают пользу и деньги только продавцы токенов.

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

Я делаю такие выводы как лудик со справкой (у меня недавно были $200 подписки на кодекс и на клод) и своим скиллпаком. До недавних пор я думал, что всё неплохо работает, но за последние пару недель:
- Дал Opus 5 статью, объяснил зачем она нужна, сказал реализовать и провести эксперимент, провел свой полный spec-driven workflow, тщательно ревьюил спеки и запускал актор критик луп, кросс-чекал план кодексом. Два дня итераций спустя стало понятно, что он реализовал не то, что в статье, а что-то наподобие, но назвал тем же именем. Все эксперименты были впустую.
- При рефакторинге генератора синты, где надо было просто разложить файлы по папочкам, Codex выкинул 90% функционала. Но так, чтобы не было заметно. Это при том, что сначала я сделал тщательный план этого рефакторинга, валидировал его и результат свежими прогонами агентов. Потеря была замечена только когда репа уехала далеко вперед, поэтому возвращение функционала потребовало очень много работы Клода.
- У меня был PR на который я более 10 раз запускал Fable с запросом "сделай код ревью, найди баги, поправь" и он каждый раз говорил, что все готово, но так же каждый раз находил новые баги.

Но больше всего впечатлил другой случай. Архитектура нашей модели позволяет работать с видео с разными fps. Главное подать на вход какой таймстемп у какого фрейма.

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

Техдолг от агентов особый, агентский, и любой агентский код может быть полон очень сложных хаков которые не обнаруживаются тестами. И самое неприятное, что агенты не способны устранять агентский техдолг, потому что их правки содержат такой же слоп.

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

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

Причём впервые это не выглядит как проблема слишком глупой модели. Почему-то работать с Sonnet 5 проще, чем с Fable, Opus 5 или GPT 5.6. Теперь чем умнее модели, тем более креативно они тебя обманывают. Парадоксальным образом быстрый Sonnet 5 в режиме ассистента в Zed, как в старые добрые, ощущается гораздо продуктивнее, чем медленный Fable который долго пыхтит и очень умно делает совсем не то.

Возможно пик AI тулов для кодинга это всё ещё TAB автокомплит и задачи для агента уровня "напиши тест для этой функции." Попробую пересесть на Zed и такой режим на время.


Репост из: Derp Learning
> Human rules rot

Omg, chill, grandpa


Репост из: Dev Meme / devmeme
I was always saying that developers do not get any work done 🌚


SWE Bench Pro сломан

30% задач SWE-bench Pro сломаны. OpenAI нашли слишком строгие тесты, плохое покрытие тестами, вводящие в заблуждение промпты.
Уже второй кодинговый бенчмарк, который за последние полгода оказался сломанным. До этого в феврале OpenAI нашли серьезные проблемы в SWE Bench Verified и рекомендовали использовать SWE Bench Pro.


Репост из: Борис опять
TIL теперь существует профессия брокера компьюта. Человек, который ходит по клаудам и подбирает за тебя кластеры

Риелторы для гпу!


Репост из: еба́ные идеи для резерча
Была замечена делегация Яндекса на ICML в Сеуле


Репост из: Denis Sexy IT 🤖
Не так давно появился скилл для агентов Caveman, который якобы экономит до 60% токенов общаясь как «каменный человек», в стиле:

Токен тратить плохо. Цена вверх. Скилл рекламировать экономия. Денис тестить сколько. Не 60% Денис находить. Всего 8%. Ридми врать.


Я поэвалил и он максимум всего 8% токенов экономит ¯\_(ツ)_/¯

Вот тут расписал детали эвала:
https://blog.jetbrains.com/ai/2026/07/speak-to-ai-agents-like-cavemen-tosave-tokens


Репост из: Книжный куб
AI-DLC: как AWS пытается превратить SDD в операционную модель (Рубрика #AI4SDLC)

Разбирался с документом "AI-Driven Development Lifecycle (AI-DLC) Method Definition", который написал Raja SP, Principal Solutions Architect из Amazon Web Services. Документ появился около года назад, а официальный AWS DevOps блогпост со ссылкой на этот whitepaper вышел 31 июля 2025 года. Интересно, что AWS представила Kiro 14 июля 2025 года как agentic IDE со spec-driven development, включающим requirements.md, design.md, tasks.md, steering files, hooks и так далее. AI-DLC появляется сразу после этого и выглядит не как отдельный инструмент, а как попытка дать Kiro/Amazon Q более взрослую методологическую рамку для enterprise-разработки.

В документе формулируется разрыв между двумя крайностями и предлагается третий режим AI-DLC
1) AI-assisted development помогает в мелких задачах: код, тесты, документация
2) AI-autonomous development обещает построить приложение почти без человека, но, по мнению ребят из AWS этот подход быстро упирается в качество и контроль
3) AI-DLC предполагает, что AI ведет процесс, но человек остается владельцем намерения, риска и финального решения

Основной концепт строится в реверсе направления разговора - теперь не человек постоянно просит AI "напиши мне вот это", а AI сам раскладывает intent на планы, вопросы, trade-offs, units и tasks, а люди валидируют решения в критических точках. Для того, чтобы работать по этому процессу AI-DLC
— Вводит свои артефакты: Intent, Unit, Bolt, Domain Design, Logical Design, Deployment Unit
— Вводит фазы Inception, Construction, Operations
— Вводит ритуалы вроде Mob Elaboration и Mob Construction
— Отдельно уделяется внимание DDD (domain driven design), где AI должен не просто писать код, а помогать выделять bounded contexts, user stories, ADR, тесты, инфраструктуру и deployment units.

Если сравнивать с Kiro и SDD от AWS, то различие примерно такое.
1) Kiro - это продуктовый интерфейс. Его spec-flow превращает промпт в три понятных файла: requirements, design, tasks. В новых версиях есть Quick Plan, bugfix specs и параллельный запуск независимых tasks. Это практичная форма SDD для feature или bugfix внутри конкретного репозитория. SDD в формулировке Kiro - это дисциплина "сначала зафиксировать durable spec, потом дать агенту исполнять". Marc Brooker хорошо описывает спецификацию как большую картину и human-readable super prompt: она удерживает intent, делает изменения версионируемыми и снижает хаос prompt-by-prompt разработки.
2) AI-DLC предлагает не только "описать фичи для агента", а "зафиксировать как должна работать вся delivery-система, если AI стал участником SDLC". Поэтому там есть операции, риски, следы для аудита, разные глубины процесса, гейты для подтверждений людьми и идея, что рабочий процесс не должен быть жестко зашитым. Для маленькой фичи полный AI-DLC будет тяжеловат, а вот для модернизации legacy, нескольких команд, регулируемого домена он может подходить хорошо

У изначального документа были и продолжения - 29 ноября 2025 года AWS опубликовала два поста: open-source adaptive workflows для AI-DLC и walkthrough для Amazon Q Developer. Там AI-DLC уже превращается из PDF в правила и steering files для агентов: Amazon Q Rules и Kiro Steering. В репозитории awslabs/aidlc-workflows стабильные релизы v1.0.0/v1.0.1 вышли 19 и 30 июня 2026 года.

Дальше движение пошло еще интереснее: в README уже объявлен AI-DLC Workflows 2.0 Preview. Ветка v2 описывает подход "one core, many harnesses": Claude Code, Kiro IDE, Kiro CLI, Codex CLI. Там уже не просто набор markdown-правил, а попытка собрать workflow engine: 5 фаз, 32 стадии, 11 domain-expert agents, adaptive scopes, depth levels, test strategy levels, approval gates, two-tier knowledge system, learning loop и structured audit trail.

То есть направление продолжения понятное: от методологического манифеста к исполняемой инфраструктуре разработки. Сначала whitepaper объяснял, почему старый SDLC надо переосмыслить. Потом AWS дала rules/steering, чтобы это можно было попробовать в Kiro и Amazon Q. Теперь v2 пытается сделать AI-DLC более проверяемым, переносимым между агентными harnesses и менее зависящим от ручного prompt engineering.

#AI #AI4SDLC #Engineering #Architecture #DevTools #Management #Agents


Репост из: Адель и МЛь
Artificial Analysis померили стоимость Sonnet 5 на задачу (per task), и у них получилось, что он дороже Opus 4.8 на 15% и что это вообще одна из самых дорогих моделей, уступая только Fable 5.

https://x.com/artificialanlys/status/2072062592923930666?s=46


Build AI B2B SaaS, make no mistakes


Репост из: Dealer.AI
ИИ-директора банкротятся на ровном месте, разбор нового бенчмарка CEO-Bench

Исследователи из Принстона (Z-Lab) выкатили жесткий тест для нейросетей – CEO-Bench. Это не просто ответы на вопросы, а симуляция управления SaaS-стартапом в течение 500 игровых дней.

Условия игры:
На старте дают $1 млн и 0 клиентов. В руках у ИИ 34 инструмента: маркетинг, найм, цены, сервера. Вокруг "злой" рынок с задержкой фидбека, шумом в данных и меняющейся экономикой. Задача – не обанкротиться и выжать максимум прибыли.

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

🥇 Claude Fable 5 — $47,15 млн
🥈 Claude Opus 4.8 — $27,8 млн (модель додумалась сама писать скрипты когортного анализа)
🥉 GPT-5.5 — $21,3 млн

Главный позор:
Обычный глупый алгоритм на жестких правилах (rule-based script) без всякого ИИ сделал $15,76 млн и обошел десятки умных нейросетей. 🚬

Пять крупных моделей, включая DeepSeek V4 Pro, Gemini 3 Flash и Grok 4.20, и вовсе полностью обанкротились.

ИИ пока не умеют играть вдолгую: они страдают амнезией на длинной дистанции и слишком пытаются угодить всем советникам вместо принятия жестких решений.

Теоретический максимум в симуляции – $2,2 млрд. Так что кожаным мешкам на позициях CEO пока можно спать спокойно. Но это не точно. 👍

Подробности исследования читайте в оригинальной статье о CEO-Bench, а код для тестов доступен в репозитории на GitHub. Интерактивный график в блоге.

Не является инвестиционной рекомендацией. 🥳


Репост из: Derp Learning


Срочно надо переписать все кернелы на раст на работе


Репост из: Анализ данных (Data analysis)
Исследователи NVIDIA перенесли модель владения Rust в GPU-kernels.

Paper: “Fearless Concurrency on the GPU”. В нём представлен cuTile Rust.

Проблема была в том, что при написании кастомных GPU-ядер на Rust разработчикам фактически приходилось выходить за пределы гарантий безопасности Rust.

cuTile Rust пытается это исправить:

* mutable outputs разбиваются на непересекающиеся части
* запуск kernels сохраняет правила ownership от host до device
* при необходимости остаются локальные opt-out механизмы для низкоуровневого контроля

Производительность тоже держится на уровне:

* 7 TB/s для element-wise операций на NVIDIA B200
* 2 PFlop/s для GEMM, это 96% от cuBLAS
* результат сопоставим с cuTile Python в пределах погрешности измерений

Авторы также собрали Grout, inference engine поверх cuTile Rust, и прогнали реальные модели:

* 171 tokens/s для Qwen3-4B на RTX 5090
* 82 tokens/s для Qwen3-32B на B200
* конкурентный уровень рядом с vLLM и SGLang

Итог - безопасный и идиоматичный Rust почти на полной CUDA-производительности.

Для Rust в ML-инфраструктуре это большой шаг.

http://arxiv.org/abs/2606.15991

#Rust #RustLang #GPU #CUDA #MachineLearning #SystemsProgramming #NVIDIA

@data_analysis_ml


Ждем наш ответ в виде Le GigaChaton Fat на 200T+ параметров


CEO Mistal подтверждает


Fable 5 все, переходим на le chaton fat


Репост из: Борис опять
Погодите, это реально?

Показано 20 последних публикаций.