Метод ⚙️

Задачи на вход подаются в следующем формате:

- 🧩 Системная инструкция
- 📚 Контекст задачи, на основе которого надо дать ответ. Разбивается на чанки примерно одного и того же размера.
- ❓ Вопрос
- 🧭 Инструкция по использованию Declarative Attention (DA)

Определяются 3 вида внимания, размечаемых специальными хэштегами:

- 🌐 <global> — модель смотрит на весь контекст задачи.
- 🎯 <focus> — модель смотрит только на нужный чанк контекста.
- 📍 <local> — модель смотрит только на последние сгенерированные токены.

Системная инструкция, вопрос и инструкция по использованию DA всегда есть в текущем общем контексте.

Текст разбивается на чанки следующим образом:

- ✂️ Стремимся побить все как можно ближе к 2048 токенам. При этом стараемся найти как можно более явный логический блок — раздел, абзац, предложение, по которому проводим разбиение. На крайняк просто пытаемся хотя бы не разделить слово пополам.
- 🏷️ Сегменты размечаются хэштегами — начало/конец чанка. Хэштеги подбираются так, чтобы быть непохожими на секции в оригинальном тексте.

Эффективный инференс реализован через vLLM с блочно-разреженной маской. Размеры чанков паддятся до 16/32, чтобы вписаться в ограничения по размерам.

Эксперименты 🧪

Свой метод они валидируют на семействах Gemma-4, Qwen-3.5/3.6.

Замеряют на задачах с длинным контекстом и обычно довольно коротким ответом: Needle-in-a-Haystack из RULER, задачи из LongBench-v1 / LongBench-v2.

Для ablation рассматривают версию своего метода с тем же форматом промпта и сегментированием по чанкам, но без блочно-разреженной маски.

На больших моделях просадки довольно небольшие — 1–3%, но все же статзначимые. Просадка обусловлена разреженностью, а не форматом промпта.

Блочная разреженность дает ускорение, но как наши вставки влияют на длину ответа? Есть ли ускорение по конечному времени обработки запроса? ⏱️

Авторы замечают, что эти вставки и специфичный формат действительно заметно увеличивают в среднем число токенов в ответе. При этом с включенной маской число сгенерированных токенов растет не так сильно. Однако end-to-end все же оказывается, что можно добиться уменьшения времени ответа до 0.73–0.77 от исходного.

Эффективность метода сильно зависит от размера модели. Мелкие модели (Gemma4-E4B и Qwen3.5-4B) плохо справляются с задачей. Им не удается вписаться и строго соблюдать специфичный формат разметки. С увеличением размера модели качество следования формату и умение находить нужный чанк из контекста растет.

Далее замечают, что экономия токенов растет с длиной контекста, но становятся более ярко выраженными и просадки качества. Кроме того, на длинных контекстах модель дольше считает, что ей надо проводить время в `<global>`-режиме, что ограничивает достижимое ускорение.

В среднем модель делает 1–2 попытки `<focus>`-контекста.

Выводы 💭

Идея концептуально интересная и красивая. Однако область применимости ограничена. Авторы сами замечают, что их метод не работает с включенным ризонингом. В текущей постановке есть реальный профит, если контекст большой, а ответ короткий.

Да и задачи в основном сводятся к иголкам в сене. На задачах по типу «много иголок» или со сложным образом распределенной информацией такой метод, скорее всего, не заведется.

Кроме того, современные разреженные внимания, как в DeepSeek-V4.1-Flash и Qwen-3.8-Flash-Next, в процессе обучения, скорее всего, находят нужные паттерны, причем более надежно и эффективно, чем такая вот эвристика.

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

Чтобы отмечать его как Reciprocal Reviewer...

Herdr — современная замена tmux

TL;DR

Если вы используете tmux или zellij, не важно с агентами или без, обязательно попробуйте Herdr. Назад вы вряд ли вернетесь. Как минимум потому, что в Herdr работает мышка. Попробовать можно тут: https://github.com/herdrdev/herdr

Таймлайн личных наблюдений:

- Я узнал про Herdr, когда у него было около 400 звезд на гитхабе. Уникальность и полезность инструмента были очевидны, и сразу захотелось рассказать.
- Когда дошли руки до моего первого поста про Herdr, было уже около 4000 звезд.
- Сейчас у репозитория почти 40000 звезд. Проект был принят в YC Combinator и получил $6M инвестиций.

Чем хорош Herdr?

💪 От самой базы ... (ее уже достаточно, чтобы заменить tmux):

- Персистентные сессии. Это как в tmux: можно запустить фоновую активность и закрыть терминал.
- Организация сессий в боковой панели. Это уже гораздо лучше, чем в tmux: в одном Herdr окне можно иметь много сессий и вкладок со всех проектов, которые у вас есть на одной машине, и легко в них ориентироваться, ничего не настраивая.
- Работает мышка. Как же это удобно. Все что должно скроллиться и нажиматься скроллится и нажимается.
- Сессии со всех машин в одном окне. Вы говорите herdr и получаете одно окно терминала со всеми сессиями и вкладками со всех (удаленных) машин, которые подключите.

🦾 ... и до агентских фичей:

- Нативные уведомления. Если во вкладке запущен агент, то из терминала приходят нативные OS уведомления, когда агенту нужен ваш ответ.
- Автоматическая детекция агентов. Если во вкладке запущен агент, то она отдельно выделяется в боковой панели.
- Agent-friendly CLI. Агенты могут сами управлять сессиями, вкладками и панелями через CLI.

https://github.com/herdrdev/herdr

А код вам сгенерирует Клод, если вам надо.

Ссылка

Вместо того, чтобы заниматься всякой фигней, типа уравнения Навье-Стокса, лучше бы OpenAI показали робота, который может снимать обои и шпаклевать стены.

Efficient pretraining with token superposition

📄 Статья
📝 Блог

Обучать LLM становится всё дороже и дороже, поэтому проблема экономии ресурсов встаёт всё более остро.

Одним из перспективных направлений повышения эффективности обучения является изменение процедуры токенизации. Была статейка, где исследовался вопрос compute-optimal токенизации в зависимости от размера словаря и модели.

В данной же статье предлагают на первом этапе претрейна усреднять эмбеддинги нескольких подряд идущих токенов на входе модели и предсказывать bag-of нескольких следующих токенов на выходе, тем самым пытаясь моделировать несколько токенов за раз.

⚙️ Метод

💡 Идея довольно проста: некоторую долю r от обучения подаём на вход и пытаемся предсказать несколько следующих токенов, а именно:

- 🔤 Токенизируем текст как обычно.
- 📊 После прогона через матрицу эмбеддингов усредняем s подряд идущих токенов. Проходимся по тексту непересекающимися окнами размера s.
- 🎯 На выходе предсказываем s следующих токенов без учёта порядка.

Итоговый лосс — просто усреднение кросс-энтропии для каждого следующего токена.

💸 Экономия достигается за счёт того, что на обучении мы гоняем в s раз меньше токенов через модель. Т. е. за тот же бюджет прогонов токенов через LLM модель видит в r·s + (1 − r) раз больше данных из корпуса.

После окончания этой стадии переходим к стандартному обучению на исходных токенах.

🧪 Эксперименты

Метод валидируют на трёх dense llama-like моделях (270M, 600M, 3B) и (10B-A1B) MoE.

При заданном количестве FLOPs и даже Wall time по итоговому лоссу оно оказывается лучше бейзлайна, который просто учится на токенах. И вроде даже метрики чуть получше, хоть и все едва лучше рандома.

📈 Оптимальнее всего ставить r в диапазоне от 0.2 до 0.4. Если меньше, то слишком мала доля обучения на усреднённых токенах, чтобы дать выигрыш; если больше — модель не успевает перестроиться на стандартное обучение.

Оптимально по качеству ставить s в диапазоне 5–8.

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

Output-усреднение сродни MTP, а MTP вроде бы считается полезным для ускорения сходимости.

🤔 А вот почему input-усреднение хорошо работает, не очень очевидно. Авторы говорят про какую-то регуляризацию, smoothing латентного пространства. Но без чёткого понимания.

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

Всякие манипуляции с RoPE, попытки адаптировать их под усреднение токенов ни к чему не привели.

⚠️ Кроме того, авторы отмечают, что в случае ограниченного количества данных их метод менее data-efficient, так как использует огрублённые токены, тем самым теряя часть информации.

💡 Выводы

Дешёвый и простой способ удешевить претрейн. Вопрос — в масштабируемости на большие сетапы. Кажется, что сильное огрубление токенов работает, пока сама модель ещё очень плоха и ничего не умеет. А когда она начинает выдавать адекватные метрики, слишком много ценной информации может теряться, ограничивая достижимое качество.

From AR to Diffusion: Efficiently Adapting Large Language Models with Strictly Causal and Elastic Horizons
📄 Статья

Рубрика - гуру эффектного сравнения.

Берешь более новую AR модельку с высокими скорами на бенчах, адаптируешь ее типа под диффузию теряя 30% качества, но зато дешево.

С ней не сравниваешься, а только с моделями позапрошлого поколения, бьешь их.

Stonks!

🧠 Negative Self-Distillation: Learning to Reason by Avoiding Flaws

📄 Статья

Обыкновенно при обучении / алайнменте LLM мы либо явно учим модель на хороших ответах, либо запускаем её в какую-то среду, где она учится находить решение, максимизирующее некоторую награду.

Однако в результате часто оказывается, что модель становится чрезмерно уверенной в себе после такой процедуры обучения.

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

🛠️ Метод

Авторы предлагают довольно интересную схему генерации негативного условия:

- 📝 Берём задачу.
- 🤖 Текущая student-модель обычным образом генерирует начальное решение.
- 🧩 Затем модели дают и исходную задачу, и её собственное решение и отдельным meta-prompt просят придумать инструкцию, которая могла бы направить рассуждение по плохому пути.
- ⚠️ Полученная инструкция добавляется к задаче и используется для построения negative teacher.

При этом gold answer не используется. Поэтому модель не обязана знать, где решение действительно ошибочно. Ей нужно найти потенциально уязвимое место или предложить вредную стратегию рассуждения.

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

Вместо этого вводят gating на разницу вероятностей референсной модели (с правильной инструкцией) и negative teacher. Если negative teacher не повысил или не сильно повысил вероятность данного токена, то данный токен не влияет на итоговый лосс. Это позволяет избежать штрафа за обычные лингвистические конструкции.

Кроме того, чтобы лосс был ограничен, вместо неправдоподобия оптимизируют сигмоидальный штраф.

Для стабильности накидывают KL-дивергенцию с исходной моделью с каким-то весом, но не ванильный вариант, а importance-weighted estimator на одном примере.

📊 Эксперименты

Свой метод валидируют они на семействе моделей Qwen3 (1.7B, 4B, 8B). Оценивают качество на AIME, HMMT и ещё паре математических бенчей.

Сравниваются с OPSD, Intuitor, TTRL (вариант GRPO).

Учат все на MATH.

Метод выдаёт метрики чуть лучше, чем бейзлайны и исходная модель, и якобы успешно справляется с проблемой overconfidence и исследует больше различных опций.

Из приятного: шаг обучения ещё дешевле, чем у бейзлайнов. GRPO требует сэмплирования группы роллаутов, а тут достаточно одного семпла. А OPSD нужно больше top-k вероятностей для успешной работы.

KL на исходную модель важен: без него обучение разваливается и модель коллапсирует.

💭 Выводы

Идея занимательная. Но валидация будто бы на маленьком масштабе, и работает, наверное, когда модель уже сама по себе достаточно хороша, но иногда её клонит не туда, а такое дообучение позволяет избегать ошибок в некоторых случаях. Нет валидации поверх base/sft чекпоинтов. Неизвестно, насколько оно масштабируется на промышленные RL-сетапы с множеством сред.

Метрики, которые мы заслужили.

Карточка модели на лицехватс

🧩 Disaggregated Quantization: Specializing LLM Prefill and Decode

📄 Статья

Обычно для префилла и декода используется одна и та же модель, более того — одни и те же веса.

Однако с вычислительной точки зрения эти операции сильно различаются:

- 🧮 На префилле много вычислений, поэтому обычно упираемся в скорость матричных операций.
- 💾 На декоде же упираемся в скорость памяти.

Поэтому кажется логичным оптимизировать каждый из этапов по-своему.

И потому команда из IST и NVIDIA с первым авторством @black_samorez предлагает подход, оптимизирующий качество и скорость за счёт разного сжатия на этих двух стадиях.

⚙️ Метод

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

Задачи можно разделить на:

- 🔢 decode-heavy — когда генерируется длинный ответ, цепочки рассуждений и тому подобное;
- 📚 prefill-heavy — объёмный вход, но короткий ответ.

Можно ожидать, что в первом случае важнее сохранить точность на этапе декода, а во втором — на префилле. И действительно, оказывается, что при прогоне более интенсивного этапа в более низкой точности (а другого — в bf16, скажем) качество просаживается заметно сильнее, чем если делать наоборот. Сжатие и на префилле, и на декоде (в NVFP4) ожидаемо даёт ещё большую ошибку.

Format disaggregated quantization предлагает следующее. Исходно у нас есть квантизованные веса в какой-то точности (NVFP4, LUT-3bit, LUT-2bit). На префилле переквантовываем веса в NVFP4 (для LUT-форматов) и используем эффективные GEMM для FP4. На декоде — weight-only квантизация.

LUT* — lookup table

🔬 FULLY-DISAGGREGATED QUANTIZATION

Чтобы улучшить качество, предлагается дообучать специализированные квантизованные модели под префилл и декод.

Делается это следующим образом:

- 🔹 Промпт прогоняем через prefill-модель, а ответ — через decode-модель. Каждая из экспертных моделей инициализируется весами исходной модели.
- 🔹 Лосс считаем только по токенам ответа, но градиент через KV протечёт и в prefill-модель, позволяя оптимизировать и качество префилла.
- 🔹 Prefill- и decode-модели учатся через QAD (Quantization Aware Distillation) — через KL между логитами квантизованных моделей и исходной модели.

Это позволяет немного поднять качество.

💽 OFFLOADED DISAGGREGATED PREFILL

Чтобы не грузить две модели в памяти, префилльные блоки можно подгружать по очереди, набирая KV-кэш, а затем сгружать обратно на диск. Если префилл и генерация достаточно долгие, то замедление от перекачки весов с SSD в VRAM не сильно замедляет инференс, зато позволяет экономить память ускорителя вычислений.

🛠️ Prefillers

А ещё можно обучать специальный NVFP4-префиллер под заданную замороженную квантизованную модель, дабы заранее компенсировать ошибку квантования.

📊 Эксперименты

Метод валидируют на семействах Qwen3 / Gemma3. В качестве decode-heavy задач рассматриваются всякие математические задачи (AIME, MATH500), а для prefill-heavy — long-context-бенчмарки из RULER.

Format disaggregation консистентно даёт лучшее качество, чем наивная weight + activation-квантизация, при примерно той же скорости как префилла, так и декода. Full disaggregation даёт некоторое улучшение качества, а оффлоадинг позволяет сэкономить VRAM.

Для больших моделей (Qwen3.8-2.4T, Kimi-K3) дезагрегация в W4A4 даёт небольшой, но всё же прирост качества.

Обучение префиллеров для разных GGUF-квантов Qwen3.8-27B позволяет при той же скорости инференса на декоде заметно поднять качество, особенно в случае сильного сжатия, как IQ1_S и IQ1_M.

✅ Выводы

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

Scaling Laws for Looped Mixture of Experts

📄 Статья

Есть MoE, которые как-то скейлятся (по разреженности / гранулярности).

Есть Looped-модели, где несколько прогонов дают качество потенциально выше, чем однократный прогон.

И для них по отдельности есть свои законы масштабирования.

Но если мы хотим Looped MoE, то как скейлить разреженность и число рекурсий?

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

🛠 Метод

Типичный scaling law имеет вид:

L(N, D) = A N^α + B D^β + c

🔄 Скейлинг по рекурсии

Ранее делали попытки вывести scaling law для looped-моделей, считая, что эффективное количество параметров N_eff масштабируется линейно с глубиной рекурсии либо убывает как-то степенным образом. Но на практике на самом деле быстро наступает насыщение, потому авторы предлагают экспоненциальное затухание, ограниченное сверху (κ₁, κ₂ — некоторые константы, R — глубина рекурсии).

N_eff(R) = N + κ₁ N_loop (1 − e^(−(R−1)/κ₂))

И опыт показывает, что такое лучше согласуется с экспериментом.

🧩 Скейлинг по рекурсии для MoE

Для MoE ситуация несколько интереснее, потому что при повторном прогоне могут активироваться другие эксперты, потому несколько прогонов могут извлечь больше информации. В пределе бесконечного числа экспертов ожидаем, что эффективное число параметров должно линейно масштабироваться с глубиной рекурсии. Отсюда возникает идея сделать константы κ₁, κ₂ функциями от m — разреженности модели.

N_eff(R, m) = N_act + κ₁(m) N_loop (1 − e^(−(R−1)/κ₂(m)))

κⱼ(m) = κⱼ m

🧪 Эксперименты

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

📈 Наблюдение 1. Масштабирование рекурсии приводит к выходу на плато, но чем больше экспертов, тем выше польза (прирост N_eff против R = 1).

⏳ Наблюдение 2. Чем дольше мы учим и чем больше разреженность, тем полезнее делать больше рекурсий.

💾 Наблюдение 3. Чем больше у нас VRAM и рекурсия, тем выгоднее иметь высокую разреженность.

⚖️ Наблюдение 4. При фиксированном бюджете на вычисления при нехватке памяти лучше инвестировать в рекурсию, при обилии — в разреженность MoE.

Потом пытаются понять, как это скажется на масштабе при обучении на downstream.

Учат бейзлайновый MoE и вдвое меньший как по числу активных, так и по числу общих параметров. При фиксированном бюджете обучения удаётся выжать около паритета при R = 4, 5 на MMLU/GSM8k, но уступая всё же в среднем по бенчам.

💡 Выводы

Вопрос оптимального масштабирования Looped MoE, безусловно, интересен, ибо потенциально даёт путь к более мощным, но компактным по общему числу параметров моделям. Однако, судя по экспериментам, всё же при заданном числе FLOPs на инференсе при том же претрейне Looped-модель будет слабее более жирной.

"Горячие" эксперты

Теперь уже даже время прочтения блога это ориентир не для человека, а для LLMки.

https://reflection.ai/blog/introducing-beam