КПД

Если учитель доступно объяснил материал - он хороший харнесс, а если плохо - то плохой.

Недавний блогпост от Alex Zhang, навеял мысль, что харнесс можно рассматривать как автокодировщик. Харнесс задает то, как обратывается вход, а также выходное распределение. Он может быть замороженным, а может и оптимизируемым (Darwin Godel Machine, Ouroboros). Harness are AutoEncoders - хорошее название для статейки, чтобы набрать классов в твиттере...

📄 Блогпост 🌵 Стартап Cactus Compute выпустил крохотную модель Needle 2 с весом чекпоинта всего 14 Mb для tool calling и работы со структурированными входа для edge устройств. Исходная модель имеет 45M параметров, поверх нее применяется CQ-2bit квантизация (некая проприетарная техника). Квантизация получается в процессе обучения (Quantization Aware Training). ⚡ Скорость На префилле скорость 800+ tok/s, и 500+ tok/s на декоде на Raspberry Pi 5. Еще оно якобы быстро генерит на VR устройствах и Samsung-ах. 🏗️ Архитектура Архитектура основана на ихней же работе Simple Attention Network. Там немало архитектурных прибамбасов: • mHC • Engram • Hadamard MLP. Дабы сэкономить на параметры, параметризуют веса как произведение диагональной на Адамарову матрицу. • GQA + Sliding Attention + синки для тулов Needle 2 производит меньше операций на токен против традиционной трансформерной архитектуры. 📚 Обучение На обучение потратили 115B токенов из проприетарных токенов и 38B на посттрейн, что на порядки меньше, чем у LFM. 📊 Бенчмарки Модель оценивают на бенчмарках: • Mobile Actions • Droid Call • Seal-Tools • BFCL v4 🎯 Оно выходит по качеству близко к Function Gemma 270M, LFM 2.5 230M, Apple FM, будучи при этом гораздо меньше.

Дарио, когда увидел openweight endpoint.

Про совсем компактные модели Мне нравится идея крутить локальные модели, но не нравится идея забивать всю память ими. Мне всегда казалось, что самый лучший способ сделать подобную edge модель — попробовать создать что-то, что будет достаточно умным, чтобы мочь делать выводы из данных, но не иметь собственных знаний. Да и зачем модели собственные знания, когда есть тривиально настраивающийся поиск в интернете и тулколлинг? Мои коллеги из AIRI подумали о том же и сделали Optimal Cognitive Core, про который я уже писал — затюненные reasoning версии Qwen-3-0.6B и Qwen-3-1.7B, которые оптимизированы под работу с внешним контекстом и RAG. Модели в целом подходят под мои требования к железу — веса занимают 1.2 и 3.4 гб в их родном BF16, ещё столько же на длинный контекст (так как это Qwen3, там GQA, это вам не модный нынче гибрид), итого, с пивком потянет. Другой вопрос, что эти модели слишком малы, чтобы быть применимыми для general purpose задач — всё таки это 600M и 1.7B dense. В этом размере обычно бывают забавные попугаи, который могут делать парафразу или простенькую классификацию после файнтюна, но не более. Следующий способ ужать модель в память моего MacBook Air M4 — использовать квантизацию. Тут отличились PrismML, сделав Bonsai-27B, бинарный- и тернарный кванты Qwen-3.6-27B. 27B модель в тернарном кванте занимает всего 7.2 гб после запуска инференса и вполне себе бегает на маках. К сожалению, Qwen-3.6-27B это dense модель, так что на моём маке она уж совсем медленная — если верить тому, что я нашёл в сети, генерация там будет в районе 13-14 токенов в секунду, чтение контекста — 100-150 токенов в секунду. Кроме того, это QAT (или вообще PTQ, подробностей мало), причём который скорее всего не затачивали на русский — так что я не ожидаю, что итоговая модель за пределами своего калибрационного сета/сета, на котором делали QAT сможет показать что-то интересное. Буквально в ответ на Bonsai появился Maple-Preview. Это 20B A1B MoE, которую специально затачивали под локальный инференс на маках ещё на этапе проектирования архитектуры, обучая свою модель с нуля в тернарной точности — то есть это не квантизация чьей-то модели. В итоге, получилась модель размером в 5.31 гб, 7.5 гб с учётом 131к контекста — почти в полтора раза меньше, чем бинарный квант Bonsai — который выдаёт аж 218 токенов в секунду на M4 Mac Mini и 127 токенов в секунду на iPhone (каком — непонятно). Модель практически не знает русского, да и в целом, мало знает (путает, в какой игре босса зовут Psycho Mantis), но если дать ей поиск, она вполне себе справляется с ответами на простые вопросы. Бенчей по тулколлам они не дают, в целом, понятно почему — я прогнал Tau-2 (в качестве user sim я использовал Qwen3-235B-A22B-Instruct-2507), на Airline скор 0.48, на Retail 0.175, на Telecom 0.427. Это не соннет и тем более не квен, но на то это и Maple Preview, они специально пишут, что учить модель на агентов будут дальше. При всех плюсах квантизации, это всё ещё почти половина доступной мне памяти. Поэтому есть ещё и третий способ как снизить использование оперативки: выгружать все веса на SSD и стримить экспертов у MoE с диска. Уже есть turbo-fieldfare, который запускает Gemma-4-26B на маке с использованием всего 2 гб памяти и есть Mference, форк turbo-fieldfare, который расширяет поддержку на Qwen-3.6-25B, DeepSeek V4 Flash и Inkling-Small 276B. Оно действительно использует очень мало памяти, но ценой того, что скорость генерации и чтения контекста падает до десятков токенов в секунду. Кажется, Apple делает что-то похожее в своей новой Siri, правда, активируя экспертов на весь промпт, а не на токен как в этих фреймворках. И тут появляется интересная идея — а что если мы возьмём Maple Preview, которая суперэффективная, с маленькими экспертами и обучавшаяся в тернарной битности, и внесём её в Mference? Так мы сможем, в теории, получить ещё меньшее использование памяти и относительно нормальную скорость генерации — потому что модель оптимизировалась под это на этапе архитектуры. Сказано — сделано. Спасибо кодексу и моей подписке за 200$, спустя 20 часов и 30% от недельного лимита я получил паритет с официальной имплементацией на teacher forced top-10 токенах в The Raven Эдгара Аллана По. Модель, в зависимости от контекста, занимает от 500 до 1200 мб памяти (!), на MacBook Air M4 читает и генерит со скоростями 40 и 20 тпс соответственно, может дёргать тулы и генерить текст. Такое не жалко оставить всегда включённым в фоне — кушать не просит, пусть лежит, если надо спрошу, он ответит. Попробую дотащить до мейна потом, но сейчас уже можно попробовать запуститься в моём форке на гитхабе. Зачем это нужно? Имхо, есть два режима использования подобных моделей. Первый — интерактивный чат. Там важно, чтобы модель отвечала быстро и имела низкий латенси. Второй — когда модель в фоне, почти не используя память и не мешаясь остальным модулям системы, что-то анализирует — классифицирует сообщения, достраивает граф знаний, фильтрует почту, пишет сводку, что-то медленно ресёрчит в интернете. Во втором режиме требований к латенси нет, так что скорости в 20 тпс вполне себе достаточно. Ну а чтобы переключиться из одного режима в другой, нужно всего лишь загрузить всю модель в оперативку с SSD — что делается довольно быстро, буквально за пару секунд. Если модель умеет в тулколлы — Maple Preview умеет не слишком хорошо, но на то она и Preview — то можно строить агентные пайплайны без требований к латенси и всегда иметь умного помощника, готового к работе оффлайн даже на старых телефонах. И это прекрасно — мне было бы очень приятно, если бы будущее было локальным. Код Суперинтересный пост от DeepGrove про то как они дизайнили модель

Лайфак по использованию агентов.

Если не запускать GPT Sol и Claude Opus на любой чих, то подписка расходуется не так быстро.

Когда месяц еще только начался, а ты израсходовал на вайбкодинг почти всю месячную квоту. https://youtu.be/W7rnkwrgEm0?si=Ug5Ah5GYNy_Eqh5d

🧪 Метод Основными задачи при разработке кернела были: • Уменьшить обьем CPU работы и CPU-GPU синхронизации • Максимально эффективно перекрывать вычисления и коммуникации Рассматриваются два типа dispatching Push-based dispatch (традиционный подход) 1. Router для каждого токена определяет его экспертов. 2. Для каждого токена выполняется: Отправить этот токен эксперту №7. То есть именно токен "толкается" (push) в буфер нужного эксперта.

T0 ---> Expert 2 T1 ---> Expert 7 T2 ---> Expert 2 T3 ---> Expert 5 :ale Проблемы Если тысячи потоков одновременно хотят записать данные эксперту 7, они начинают конкурировать за • atomic counter, • место в буфере, • память. Получается много случайных записей и плохая эффективность памяти. Pull-based dispatch Идея разворачивается наоборот. Сначала известно, какие токены принадлежат каждому эксперту (например, после сортировки). После этого сам эксперт приходит за своими токенами. Expert 2: беру токены [0,2,9,15] Expert 5: беру токены [3,8] Expert 7: беру токены [1,4,5,6]

Теперь данные читаются большими непрерывными кусками. Никаких scatter-записей больше не требуется. Pull позволяет организовать данные так, чтобы чтение стало почти непрерывным, что улучшает пропускную способность памяти и снижает накладные расходы на scatter/atomic операции. Кернел валидируют на разных MoE моделях - GLM-5.2, Qwen-3.5-397B, Kimi-K2.7, DeepSeek V4 Pro. Удается добиться ускорения ~2x против бейзлайнов на форварде, и ~1.5x на обратном проходе. Выкладывание в открытый доступ данного кернела - хороший подарок компаниям, которым завезли NVL72, и они не знают, как их эффективно использовать.

Mixture-of-Kittens: our open-source MoE megakernel for NVL72s 📄 Блогпост 💻 Код Ребята из курсора реализовали MXFP8 мегакернел под названием Mixture-of-Kittens, где пофьюжены все операции для слоя смеси экспертов, специализированный под GB300 NVL72s. В отличие от MegaMoE от команды Дипсика 🐋, этот кернел не только под инференс, а под обучение.

Лаба Song Han (одного из апостолов EfficientDL) из MIT выпустила репозиторий со скиллом для агентов, направленным на оптимизацию кернелов под Hopper и Blackwell. Репозиторий содержит скрипты для того, чтобы лезть в разные базы знаний, блоги, PR-ы и прочие артефакты про тензорные ядра и Hopper- / Blackwell- архитектуные особенности. Оно содержит знания про CUDA, CuTe DSL, PTX, Triton. TileLang, cuTile. За всякие штуки, связанные с параллелизмом на мультихостах оно не шарит, как сразу открещиваются в дисклеймере.

step: 11 loss: 9.8672 grad_norm: 2.8441 tps: 5,471 time/step: 2.99s tflops: 198,319.19 mfu: 63563.84% memory: 243.85GiB

MFU > 60000% Такое даже Уроборосу не снилось)

Бывает и такое, что Reviewer #2 ставит тебе Accept. Но ревью настолько короткое и несодержательное, что Area Chair не примет во внимание...

Интересная по описанию либа Humming от InclusionAI. Позиционируется как легковесный, высокопроизводительный фреймворк с JIT-компилированными GEMM-операциями (под NVIDIA GPU). ⚙️ Он предлагает широкий ассортимент кернелов под разные конфигурации квантованных весов и активаций: • 🧮 Веса можно квантовать почти в любую целочисленную битность от 1 до 8, а также в разные варианты FP. • ⚡ Активации можно квантовать в FP16/BF16/FP8/FP4/INT8/INT4. FP8 поддерживается только начиная с Hopper, а FP4 — с Blackwell. 🧩 Ещё он работает с MoE и позволяет прикручивать адамаровы повороты в квантизацию. 🤷‍♂️ Утверждается, что он выдаёт SOTA-скорость и эффективность, но никаких чисел в README, да и вообще нигде, не приводится. 📊 Квантованных чекпоинтов с замерами качества и скорости тоже нигде нет. 🤔 Выглядит потенциально интересно для ресерча, но как будто не хватает нормальной доки и полноценного описания бенефитов. Могли бы Claude Code постараться напрячь, раз он у них и так многое делает.

🧪 Метод и эксперименты В данной работе фокусируются на 2-битном weight-only-сжатии ризонящих моделей. В аппендиксе есть эксперименты с FP4, со сжатием активаций и KV-кэшей. Квантизуют модели Qwen3-8B / Qwen3-32B через GPTQ. Оказывается, что квантизация сильно меняет поведение трейсов ризонинга: 🔄 Число циклов резко возрастает, особенно для меньшей модели. 📏 Многие трейсы не вписываются в заданный лимит токенов. ⚠️ Блок <think> часто оказывается незакрытым. 💡 При этом сам ответ появляется в среднем чуть ли не раньше в трейсе, но модель его не выводит. 📈 Длина ризонинга сильно увеличивается. Из этого следует, что, кроме просадки качества, мы ещё теряем в эффективности из-за того, что генерируем больше токенов. Как и в прошлой статье, замечают, что длина ризонинга у квантизованных моделей обратно коррелирует с качеством. Причина как раз в этих зацикливаниях. При этом результат сильно зависит от выбора задачи: на ризонинг-бенчмарках типа AIME / GPQA-Diamond эффект сильно заметен. На простых задачах — ARC-C, ARC-E, PIQA, WinoGrande — просадка и в 2 битах очень умеренная. Вообще, я думал, что эти бенчмарки likelihood-based и гоняются с выключенным <think>. Вводят четыре режима деградации качества: 🟢 Стабильный. Без заметной просадки. 🟡 Заметная, но умеренная просадка. Трейсы ещё не ломаются, но есть нарушения в плане фактологии и commonsense. 🟠 Значительная деградация. Генерация часто не завершается. 🔴 Полный коллапс. В первую категорию попадает Qwen3-32B на простых задачах. По мере усложнения задач и уменьшения размера модели растёт степень деградации. Дабы как-то подлечить просадку, предлагают два решения: 📝 (+P) FP16-модель пишет план, а квантизованная исполняет. Это заметно поднимает качество и правит многие ошибки ризонинга, но точность всё ещё ощутимо ниже базовой модели. 🔁 (+L) Loop Rescue. Если модель зацикливается, но выдаёт ответ, выписываем промежуточный ответ. Если ответа нет, просим FP16-модель сгенерировать его с нуля. На простых задачах смысла в этом не так много, так как и просадки, и зацикливания нет. Но на сложных задачах и ризонинг укорачивается, и качество заметно улучшается. На простых задачах end-to-end speedup с учётом длины генерации находится в районе 2×, а на сложных — несколько процентов с просадкой порядка 20% в среднем. 📌 Выводы Занятная и интересная стратегия по выправлению ризонинга. Для production-grade-системы, понятное дело, просадки качества слишком велики, но и 2-битная квантизация без свистоплясок — это действительно тяжёлый случай. Интересно было бы дообучить квантизованную модель через какой-нибудь RL с penalty на циклы.

Extreme Low-Bit Inference in Reasoning Models: Failure Modes and Targeted Recovery 📄 Статья 💻 Код Вдогонку про влияние квантизации на ризонинг. Ребята из Brain Lab выпустили интересное исследование, показывающее, как ломается ризонинг у квантизованных моделей, а также пару стратегий, помогающих предотвратить зацикливание генерации.

🧪 Метод и эксперименты Авторы рассматривают следующие варианты квантизации: * 🔹 weight-only AWQ в 3 и 4 бита; * 🔹 weight-only GPTQ в 3 и 4 бита; * 🔹 weight + activation + KV-cache-квантизация в 4 и 8 бит при помощи FlatQuant. Качество оценивают на задачах по математике, общим научным вопросам (GPQA-Diamond) и кодингу (LiveCodeBench). В качестве моделей рассматривают дистиллы дипсика и QwQ (почему не Квен / Квен-3.5?). Менее агрессивные квантизации не так сильно меняют выход, но 3-битная квантизация весов и 4-битная квантизация весов + активаций заметно просаживают качество и одновременно увеличивают длину ризонинга. Причём длина ризонинга и качество имеют негативную корреляцию: чем длиннее ризонинг, тем хуже качество. Анализируя ответы, авторы замечают, что сильно повышается доля токенов — overthinking markers — вида “Wait”, “But”, “Alternatively” и т. п. Кроме того, они обычно соответствуют позициям, где KL-дивергенция между выходами исходной и квантизованной моделей велика. Для того чтобы побороть явление overthinking, предлагают занижать логиты, отвечающие за 50 вручную отобранных overthinking-токенов. В качестве бейзлайнов рассматривают случайные токены и токены с низкой / высокой KL-дивергенцией между сжатой и несжатой моделями. 📈 Занижение логитов отобранных токенов консистентно улучшает качество на 5–15%, при этом длина ризонинга сокращается на 10–20%. В основном прирост качества достигается как раз за счёт решения проблемы overthinking — доля таких ошибок снижается в два и более раза. Из альтернативных стратегий пенализация high-KL-токенов тоже работает неплохо, но хуже, чем пенализация вручную отобранных. Пенализация случайных токенов ничего не даёт, а low-KL-токенов только просаживает качество и удлиняет ризонинг. 💡 Гипотеза авторов о природе явления состоит в том, что токены с высокой энтропией имеют сильно размазанное распределение вероятностей, поэтому даже малый шум может привести к выбору другого токена — чаще всего как раз одного из overthinking-токенов. 📝 Выводы Интересное наблюдение и простое решение для повышения качества работы, которое легко внедряется. Было бы хорошо проверить справедливость полученных в работе выводов на квантизации больших и не очень МоЕшек в агентских задачах. Сохранил исходную стилистику, терминологию и неформальные формулировки.