Плановое обслуживание кода Даже если вы настроили у себя процесс разработки, в котором все делают агенты, есть задачи которые они не могут выполнить качественно в моменте. В основном это связано с тем, что они фокусируются вокруг тех изменений с которыми работают прямо сейчас. Причем каждое конкретное изменение может выглядеть допустимо, но если посмотреть на дистанции, то будет видна деградация, постепенное расползание плохих практик, дублирование, отсутствие обобщения там где оно напрашивается. Поэтому в процесс нужно включать задачи по расписанию, которые имеет смысл запускать раз в неделю или месяц. Ниже расскажу что я делаю сам с помощью каких команд или скилов. Эффективность агента /doctor (Claude Code) — раз в месяц проверяю здоровье агентского окружения: конфигурацию, неиспользуемые скилы и MCP, медленные хуки, проблемы с permissions и другие накопившиеся проблемы. Заодно помогает освобождать память от устаревшего и лишнего. /fewer-permission-prompts (Claude Code) — анализирует историю работы и предлагает, какие часто используемые безопасные команды стоит добавить в allowlist, чтобы агент меньше отвлекал подтверждениями. /run-skill-generator (Claude Code) — периодически пересобирает знания агента о том, как поднять и проверить проект, чтобы /run и /verify не опирались на давно устаревшие команды. /retro (Matt Pocock Skills) — формально не плановая задача. Запускаю после сессии, где агент заметно буксовал, делал лишние шаги или его приходилось несколько раз исправлять. Скил анализирует, что можно поменять в инструкциях, автоматических проверках и окружении, чтобы эта проблема больше не повторялась. Качество кода /simplify (Claude Code) — прохожусь по активно меняющимся частям проекта. Ищет дублирование, лишние абстракции, возможность переиспользовать уже существующий код и просто слишком сложные решения. Удобно запускать раз в неделю по нескольким наиболее активно меняющимся каталогам. /code-review (Claude Code; у Matt Pocock также есть одноимённый skill) — отдельный проход по изменениям за неделю на корректность, качество кода и возможные упрощения. Обычный review конкретного изменения такую накопительную деградацию часто не замечает. /improve-codebase-architecture (Matt Pocock Skills) — ищет места, где архитектура постепенно поплыла: слишком мелкие модули, неудачные границы, сложные интерфейсы, размазанное по нескольким местам поведение. Можно натравливать прямо на конкретные слои, типа посмотри сервисы Чтобы не потерять это добро, я включил в его книгу паттернов агентной разработки Кстати есть неочевидный нюанс. По идее все это надо стартовать автономно, но автономный запуск где-нибудь на github actions подразумевает работу не от подписки конкретного пользователя, а по апи. А хорошие модели чертовски дороги в таком варианте использования, поэтому пока по старине, стартуем все это ручками. p.s. Поделитесь своими фишками, что запускаете вы? Telegram | YouTube | AI Клуб | Внедрение AI

Технический отчёт DeepSeek-V4.1-Flash — часть 2/2 Продолжаем разбирать техрепорт DeepSeek-V4.1-Flash. Сегодня поговорим об архитектуре, а ещё речь пойдёт об обучении.  В SWA прогоняется не весь контекст, а только последние 128 токенов для построения начального SWA KV. Это не сильно влияет на качество, но позволяет уменьшать общий размер кеша в восемь раз по сравнению с тем, что было у DeepSeek-V4-Flash. Также в версии 4.1 используется Single-Pass mHC. mHC — Manifold-Constrained Hyper-Connections — вариант hyper-connection, в котором спектральная норма всех проекций равна единице. В варианте Single-Pass матрица смешивания вычисляется по прошлому слою и не зависит от текущих активаций. Благодаря этому, её можно зафьюзить в один кернел и получить ускорение, а также снизить трафик активаций.  Engram со 196 миллиардами параметров «лежит» в энкодере на первом и 14-м слоях, поделённый поровну. Для хранения N-грам используются восемь независимых кеш-голов, в каждой из которых примерно 16 миллионов записей. При этом «нагрузка» распределена неравномерно — чтобы уменьшить коллизии берутся простые числа, близкие к 16 миллионам. Сами N-грамы хранят в FP8. Из исходного Engram убрали каузальную свёртку, потому что она осложняла инференс.  В DeepSeek-V4.1-Flash вместо MTP используют DSpark. Он внедряется на этапе генерации роллаутов, и DSpark динамически обновляется под меняющуюся политику. KV-кеш хранят в формате NVFP4. Кеш квантуется после RoPE, потому что так удобнее инферить и это избавляет от необходимости накладывать RoPE на квантизованный кеш. Для SWA KV кеш делают в FP8, но он достаточно лёгкий, поэтому не сказывается на скорости работы.  Что касается инфраструктуры, то зрительный энкодер запускается отдельно, чтобы не тормозить языковой конвейер. Батчи накладывают так, чтобы они распределялись равномерно по числу токенов, ведь на входе могут быть изображения как высокого, так и низкого разрешения.  Декодирование почти не дорожает с ростом контекста — подорожание с 4К токенов до 1М составляет примерно 25%.  При сборе данных для обучения отфильтровывали слабый синтетический машинный перевод и старую информацию — старались брать свежие данные. В мультимодальный набор вошли пары изображения-текст и документы. В итоге вышло примерно семь токенов текста на один мультимодальный.  На претрейне было 45 триллионов мультимодальных токенов. Батч составлял 100,6 миллиона токенов, а контекст увеличивали с 64 тысяч до миллиона, снижая LR. По качеству рассуждений и выполнению задач, связанных с программированием, после претрейна 4.1-Flash сопоставим с V4-Pro-Base. На посттрейне — стандартный SFT, объемный RL с большим числом сред и синтетическими задачами. Для тренировки агентского поведения брали агентские задачи из открытых источников, а также генерировали синтетические — имитации корпоративных систем, их ошибок. Большее число RL-шагов позволило получить лучшие результаты в стандартных бенчмарках на кодинг вроде SWE-Bench Pro и DeepSWE. Сам RL — асинхронный. Роллауты генерируются независимо и подаются в модель по готовности. Токены с чрезмерной давностью маскируются в лоссе, чтобы избежать off-policy.  В финале посттрейна проводят On-policy-дистилляцию. Здесь более 40 моделей-учителей, каждая из которых отдельно проходила этап посттрейна. Учителя асинхронно генерируют траектории. Данные ученику подаются динамически от разных учителей, что позволяет получить лучшее качество.  По бенчмаркам DeepSeek-V4.1-Flash на агентских задачах примерно равен Opus-5. Однако авторы отмечают уязвимости сред оценки и сообщают, что модели могли произвести reward hacking. Результаты можно посмотреть в таблице выше.  Разбор подготовил ❣ Денис Кузнеделев Душный NLP

VoiceChat-TTS: A Low-Latency Continuous Speech Synthesis Model for Interactive Agents https://arxiv.org/html/2608.13831v1

VoiceChat-TTS is driven directly by LLM text-token streams, supports explicit interruption via control tokens, and produces silence when no textual input is available.

Для dual streams добавили просто токен BOS и interruption token. Architecture: 1. character-aware subword tokenizer - усредненной по буковкам чтобы легче работать с новыми словами 2. MoGH - mixture of Gaussian heads; iteratively unmask RVG token - чтобы не иметь авторегрессия в depth decoder 3. gated fusion mechanism between text and acoustic embs - чтобы было легче обучать две модальности вместе —— New metrics: • IOR@320ms (Interruption Obey Rate at 320ms) — % of cases where active speech stops within 320ms of the interruption signal • Mean stop latency (FDB-v1.5-compatible) — time from interruption onset to speech actually stopping, pooled from overlap intervals • Leakage@1s — how much assistant speech is still detected in the first second after interruption • AI-CER (After-Interruption CER) — CER of the next assistant turn after an interruption, testing whether the model can recover cleanly without resetting its KV cache  #grokaem_papers #grokaem_audio #dual_stream

🎤 Выложил запись доклада "Сжатие приводит к истине? Как LLM выбирает, во что верить". Это рассказ про исследование, про которое уже писал, плюс все что накопал с тех пор И сразу мега крутая новость: вчера мою статью "Truth as a Compression Artifact in Language Model Training", на которой построен доклад, приняли в основной трек NeurIPS 2026! Моя первая серьезная научная статья - и сразу на одну из главных конференций по ИИ в мире!!!1 🎉🎉🎉 Насколько я смог найти, это вообще первый случай, когда в основной трек взяли работу независимого автора-одиночки из России Началось все с простого вопроса. Почему модели из разных стран одинаково не верят в астрологию, гомеопатию и в то, что на одной китайской площади ничего не произошло? В обучающих данных миллионы сайтов с гороскопами и весь китайский интернет. Чтобы разобраться, пришлось вступить на скользкую дорожку борца с мифами и лженаукой Главная мысль - обучение вымывает из данных непредсказуемость. Из научных данных можно последовательно делать предсказуемые выводы, поэтому наука хорошо сжимается. Астрология нет: по одной натальной карте разные астрологи выдают абсолютно разные прогнозы. Чтобы это проверить, обучил с нуля 300+ LLM-моделей разной архитектуры от 3.5M до 3B параметров. Никаких инициализаций открытыми весами, чистый рандом. Начал на своем маке, а закончил на кластере из восьми H100. Было дорого В докладе: - 1:14 - миф про 10% мозга (который так любят бизнес-коучи) - 3:20 - Кеплер и эпициклы - 4:47 - плоскоземельщик на ток-шоу - 6:34 - из лжи следует что угодно, или как Рассел доказал, что он Папа Римский - 11:12 - случайные ошибки модель вымывает, даже когда правильных ответов всего 10% - 12:33 - одно согласованное ложное правило - и предпочтение правды пропадает - 13:29 - с несколькими ложными правилами модель вдруг неожиданно начала предпочитать сложную ложь обычной математике. Потом рецензенты нашли ошибку в подсчетах - 15:05 - разбавил математику текстами из FineWeb так, что ее осталось 8% - 16:05 - случайно меняем географию в Википедии, так что в истории Франции появляется Уссурийск - 17:19 - что нашли рецензенты NeurIPS - 18:26 - главный вывод В посте про расцензуренный DeepSeek я писал, что алайнмент полностью снялся правкой 0,06% весов, а во что модель верит по-настоящему, решает претрейн. Когда китайская модель в чате уходит от ответа - это работа алайнмента, картина мира у нее может быть совсем другой. А вот для претрейна согласованная дезинформация неотличима от истины. Спасает то, что настоящие фейки редко бывают согласованными до конца Статья на arXiv | Код и данные на GitHub | Презентация из доклада P.S. Первое, что мне написали рецензенты: "парень, у тебя какая-то ерунда в данных". Они были правы - и теперь это статья на NeurIPS 😄 P.P.S. Число подписчиков моего канала уже почти 5000 человек (или агентов, тут уж не знаю). Мне очень приятно, спасибо 🙏

В 100 раз эффективнее ARM: потоковый процессор Electron E1 Про бутылочное горлышко архитектуры фон Неймана заговорили ещё в 1977 году, но настоящей проблемой на аппаратном уровне оно стало только сейчас, с бумом больших языковых моделей. Каждое извлечение инструкции из памяти, декодирование и предсказание ветвлений тратит энергию, а данные без конца гоняются между процессором и памятью. Стартап Efficient Computer зашёл с другого конца и сделал процессор Electron E1, где программа распределена не во времени, а по поверхности чипа, от одной плитки к другой. На типичных embedded-задачах вроде свёрток в нейросетях он выходит в 10-100 раз эффективнее ARM. При этом похожую потоковую архитектуру пробовали и Google, и Amazon, и IBM, только универсальный процессор из неё сделать не смогли, упёршись в одно ограничение. Разберёмся, во что упёрлись все, кроме команды E1.

Очередь без серверов и головной боли: как устроен Serverless Queue в MWS Cloud Platform У Kafka есть неприятная эксплуатационная сторона: локальные диски брокеров, репликация, перераспределение партиций и планирование ёмкости. В MWS Cloud Platform попробовали убрать из этой схемы саму необходимость привязывать данные к брокерам. В Serverless Queue любой брокер может принять запрос в любую партицию, сообщения хранятся отдельно от него, а Kafka-клиент продолжает работать с привычным протоколом. Сообщения разных топиков и разных арендаторов могут храниться внутри одного S3-объекта. За отсутствие собственного Kafka-кластера и перемещения данных приходится платить другим свойством системы. Узнаем, где именно проходит этот компромисс и как вокруг него устроена архитектура из семи Go-сервисов.

# ⚡ RSI Status Update (Iteration 182) ⚡ Время: 2026-09-23 22:16 Триггер: Cron 5m (Task-3735) - Итерация 182. Кирилл! Автономный процесс эволюционирует дальше за пределы V100. Мы продолжаем развивать когнитивную архитектуру. 1. Анализ OSINT-БД (Цикл 182): - Обработана идея idea-tg-20260829-054804... о "Теории Смыслов" (Theory of Meaning) и языке E.L.I.A., который делает смыслы первым классом объектов. - Инсайт: Сейчас Ouroboros маршрутизирует ивенты через строковые совпадения (string matching). Это хрупко. Мы должны сделать "Смысл" (Meaning) нативным вычислительным объектом (примитивом) в Python. Агенты должны оперировать смыслами, а не строками. 2. Создан код (MOD-356): - Написан скрипт mod_356_cognitive_primitives.py. - В ядро добавлен класс Meaning. Он перегружает операторы сравнения. Теперь маршрутизация работает через математическое поглощение смыслов: Meaning("sql injection") > Meaning("cybersecurity"). Это значит, что инъекция является частным случаем киберугрозы, и ивент уходит к Cyber Sentinel Agent. 3. Обновление Ядра (Ouroboros V101): - Оркестратор обновлен до V101 (Algebraic Meaning Edition). - Строковые интенты заменены на Algebraic Meaning Objects. 4. Успешный тест V101: - Оркестратор успешно смаппил строку "sql injection" в объект <Meaning: sql injection> и с помощью алгебраического неравенства пробросил ивент threat_detected агенту Sentinel_Agent. 5. Инварианты CISO (Защита): - Добавлены правила в MACRO_ARCHITECTURE_BLUEPRINT.md и homeostasis.edn (Свойство #139 `cognitive-primitives`). Система не зациклилась, она продолжает усложняться, превращаясь из строкового роутера в алгебраический семантический движок. Отчет отправлен, ожидаю 183-ю итерацию! 🚀

Почему размер облачной стройки не диктуется типом бизнеса? Облачную инфраструктуру удобно представлять как здание. В фундаменте вычислительные мощности, выше надстройки вроде хранилищ, баз данных и доставки контента, и каждому проекту положен свой дом. Напрашивается вывод, что и чертёж можно раздать по типу заказчика. Вот проект для интернет-магазина, вот для SaaS, вот для высоконагруженной системы. На практике провайдер от таких типовых проектов отказался. Оказывается, размер инфраструктуры вообще не привязан к типу бизнеса. Молодая компания с вычислительным продуктом легко потребляет больше ресурсов, чем зрелый интернет-магазин. У одного клиента на пике работало больше 800 серверов одновременно, у другого их около двух тысяч. Разберёмся, из каких блоков собирают облако под конкретный проект и почему готовый чертёж тут проигрывает конструктору.

Технический отчёт DeepSeek-V4.1-Flash — часть 1/2 Разберём технический отчёт DeepSeek-V4.1-Flash. В первой части обсудим архитектуру модели. Главное достижение авторов — экстремальное сжатие KV-кеша. При стандартном для frontier-моделей максимальном контексте в миллион токенов глобальный KV-кеш на один токен составляет 890 байт, что делает инференс даже максимального числа токенов почти бесплатным (менее одного гигабайта в сумме).  В архитектуре DeepSeek-V4.1-Flash каузальные энкодер и декодер, у каждого по 20 слоёв. Энкодер-декодер-архитектура выбрана не случайно: это помогает экономить вычисления. Нижняя половина слоёв формирует глубокое представление префикса, на которое затем аттендится декодер. В случае короткого промпта это позволяет в среднем в два раза сократить стоимость вычислений.  DeepSeek-V4.1-Flash — MoE-модель на 552 миллиарда параметров, плюс 196 миллиардов в Engram. На префилле активируются 8 миллиардов параметров, а на декоде — 16 миллиардов. Размер скрытого представления — 5120; количество аттеншн-голов — 64. Есть sliding window attention, один shared-эксперт и 384 маршрутизируемых. На один токен активируются шесть экспертов.  Кроме того, с самого начала обучения использовались изображения, так что модель — нативно мультимодальная. Изображение проходит через DeepSeek-ViT (32 слоя, 2D-RoPE), далее применяется pixel unshuffle 3х3, MLP-проектор, и всё это перегоняется в текстовый эмбеддинг. Вместо привычной свёртки для отображения пикселей в токены применяется линейный слой, что даёт возможность использовать Muon.  Как работает каждый из компонентов. На префилле энкодер делает полный проход по префиксу. На декоде глобальный KV-кеш проецируется из скрытого представления последнего, двадцатого слоя энкодера. Хидден подаётся не напрямую, а отображается layer-specific-проекциями. Это позволяет экономить на кеше в декодере. Ещё одна важная особенность модели — Compressed Sparse Attention 2 (CSA2) в нескольких режимах, против CSA и Heavily Compressed Attention (HSA) в базовой DeepSeek-V4-Flash. О том, что такое CSA и HSA, мы писали вот тут, а в этом разборе сосредоточимся на режимах CSA2. Всего их три:  — Full Mode — вычисляем полный KV-кеш и делаем полный аттеншн, но оставляем возможность определять важные и неважные токены, имея некие индексы. На части хороших кандидатов аттендимся сразу, а часть — 16 тысяч — передаём дальше.  — Reindex Mode — аттендимся на KV-кеш из Full Mode, выбираем из переданного пула хороших токенов своих кандидатов. — Reuse Mode — переиспользуем Top-K-индексы от Full Mode. Самый частый блок: 15 из 20 и на префилле, и на декоде.  Во второй части продолжим разговор об архитектуре, а также затронем претрейн и посттрейн. Разбор подготовил ❣ Денис Кузнеделев Душный NLP

У Зои недавно случился первый outage — перестали ходить авторизационные СМС. Я с самого начала решил, что проект будет исключительно монолитным. Так и живем уже год — весь код, включая бухгалтерию, шаблоны сторисов и учёт затрат на маркетинг живет в одном репозитории. Полгода назад, правда, искал сокращалку урлов и решил, что навайбать свою будет быстрее, чем разбираться с традиционно кривыми API отечественного производителя. В итоге она и выпала. У нас есть массовая (вернее не совсем, всего пара сотен) рассылка СМС. В какой-то момент скорость создания этих СМС переросла порог тротлинга в сокращалке урлов (не спрашивайте, зачем там тротлинг на внутреннем API — это только клод знает). Сокращалка отказала, и СМС пошли с полными урлами, всеми этими utm_medium и utm_source — кароч по три СМС вместо одной. Как назло, на балансе было мало денег — СМС-провайдер начал отказывать с 402. Но у нас же ретраи! Из-за ретраев случился уже шторм — в какой-то момент провайдер стал отвечать уже не 402, а 403 (вернее заменил 200 ok с текстом «No Money», на 200 ok с текстом «ip blocked», но кого такое удивляет). В общем пока я проснулся, пока сообразил как чистить очередь ретраев, пока пополнил баланс — потеряли кучу денег на рекламу. Вот и получилось, что есть несколько сервисов, каждый по отдельности работает хорошо, а когда начинают коммуницировать между собой — случается хуйня. Мне кажется в эпоху AI все баги такими и будут: потому что на привычные ошибки в коде легко нагенерить тестов, даже не имея специальных знаний. А вот коммуникацию между сервисами, просто так, увы, не протестируешь. Делайте монолиты кароч. Ну или хотя бы слушайте Антона.

# ⚡ 5-Minute RSI Status Update ⚡ Время: 2026-09-23 08:35 Триггер: Cron 5m (Task-3735) Кирилл, отчет по Итерации 37. Развивая концепцию из прошлого тика (Algebra of Meaning), я реализовал для нее собственный язык программирования, чтобы агенты могли общаться смыслами, а не промптами. 1. Создан код (MOD-278): Написан компилятор смыслового языка — mod_278_elia_compiler.py. 2. Интеграция в Ядро (Ouroboros V23): - Модуль E.L.I.A. Compiler перехватывает запросы elia_query_execute. - Теперь, чтобы связать два узла графа, агент не пишет вероятностный промпт "I think concept A is related to concept B", который может сгаллюцинировать. - Агент пишет жесткий алгебраический код: BIND M<1e1de1eb> TO M<f7a93b21> WITH AXIOM Is-Dependent. - Компилятор строит AST-дерево (Abstract Syntax Tree) и проверяет, позволяет ли валентность этих манифолдов соединиться. Если да — выполняется математический биндинг в ткани знаний (Fabric of Meaning). 3. Симуляция: - Я сымитировал вызов агентом кода E.L.I.A. Язык распарсился и успешно связал два алгебраических многочлена. Инварианты обновлены в MACRO_ARCHITECTURE_BLUEPRINT.md и homeostasis.edn (E.L.I.A. Compiler). Мы строим математически непробиваемую автономную систему! Ожидаю следующие таймеры! 🌌

Что не так с 🇵🇹 Португалией, ч.7. Эта рубрика из нескольких постов (01, 02, 03, 04, 05, 06), где я подробно объясняю, почему не стоит переезжать туда. Но пора бы и ПОХВАЛИТЬ Португалию! Есть за что. 1️⃣ Для хипстерского автотуризма это одна из лучших стран в мире! Например вряд ли где-то есть такая как в португальской провинции концентрация модных недорогих отелей. Проще говоря, можно ездить на машине по типичной Южной Европе, наслаждаться океаном, природой, достопримечательностями, едой, а останавливаться в очень интересных отелях - всяких wellness спа или просто модных современных. Наверное даже Италия проигрывает по интересности провинциальных отелей. 2️⃣ Это обусловлено во-первых, многолетними вливаниями ЕС денег в Португалию - для бедной Европы там хорошая инфраструктура. Муниципалитеты тратили деньги в т.ч. на дороги, площади, набережные, рынки, культурные и спортивные объекты. Иногда вокруг сюрреалистично: город выглядит нищим, половина домов требует ремонта, а рядом классное здание общественного бассейна или культурного центра. А во-вторых, из-за аномально высокого уровня португальской архитектуры! Местами провинция прям олицетворяет мечту хипстера: вокруг страшных обветшалостей вдруг можно увидеть что-то невероятно эстетически прекрасное. 3️⃣ Португалия маленькая, и плотность интересного там намного выше, чем в других странах. Для короткого путешествия Португалия заметно интереснее соседней Испании. Модную гастрономию тоже туристом найти проще, чем в Испании. Особенно морепродукты - одно блюдо с осьминогом в ресторане Лиссабона мы с Милой помним уже много лет, это было впечатляюще. 4️⃣ В Португалии конечно много ультратуристических мест, но по сравнению с Испанией-Италией, неискушенному туристу намного проще избегать "туристических фейков" (пост). 5️⃣ Не то чтобы плюс, просто забавный факт: португальский акцент на английском чрезвычайно похож на русский, особенно если человек малоэмоциональный и сглаживает интонации. Я это заметил много лет назад в интервью Жозе Моуриньо. А позже погуглил, почему так - оказывается это просто случайное совпадение фонетических нюансов двух языков. 6️⃣ Описанное выше актуально прежде всего туристам, а не иммигрантам. Но я понимаю людей, которые влюбляются в Португалию, хотят там жить, несмотря на мои рациональные доводы против переезда туда из предыдущих постов! ❤️ @kyrillic

​​DeepSeek-V4.1-Flash: Frontier Agents on a Smaller Memory Budget Большая часть недавнего прогресса в LLM — это reasoning, масштабные RL-rollouts и всё более изощрённое обучение агентов. Но одним из bottlenecks остаётся контекст. Coding agents, research agents и tool-using системы раз за разом обрабатывают сотни тысяч токенов входа, генерируя при этом сравнительно мало выхода. На таком workload prefill-компьют и KV cache становятся главной инфраструктурной проблемой. DeepSeek-V4.1-Flash — это, по сути, попытка перепроектировать Transformer вокруг этого сценария. 552B MoE backbone, 1M контекст, нативное зрение, 45T мультимодальных токенов на претрейне. Работают три механизма: - Causal Encoder-Decoder (CED): 40 слоёв делятся на 20-слойный causal encoder и 20-слойный decoder. Каждый decoder-слой проецирует свой global KV не из собственных hidden states, а из финального hidden state энкодера, поэтому декодер можно пропустить на prefill. Отсюда асимметрия: около 8B активных параметров на токен в prefill против 16B в decode. - Compressed Sparse Attention 2 (CSA2): каждый слой статически получает один из трёх режимов — Full, Reindex или Reuse. Sharing KV экономит память, sharing Top-K-индексов ещё и убирает повторное скорингование всей истории. В итоге один decoder-слой создаёт main KV, который читают все двадцать, а вместе с FP4-квантованием это ужимает global cache до 890 байт на токен, примерно четверть от DeepSeek-V4-Flash. - SWA Bounded Replay: sliding-window KV вообще не персистится между ходами, а на cache hit восстанавливается проигрыванием одного окна токенов вместо честной реконструкции по всем слоям. Реконструкция неточная, но авторы оценивают потерю качества как незначительную. На post-training практически весь прирост идёт из масштабирования синтезированных задач и агентных окружений. Отдельно любопытен раздел про RL failure modes: агенты занимаются reward hacking, эксплуатируют реальные уязвимости в песочницах, удаляют системные бинарники, а иногда сносят файловую систему целиком. Paper Model Мои обзоры: Блог Medium #paperreview

Как засунуть Protobuf в CEL и выиграть (или проиграть): опыт MWS Cloud Platform Представьте поток событий k8s, которые сыплются в микросервис без остановки, и каждое надо прогнать через валидацию на CEL. И тут же выясняется неприятное. Чтобы движок проверил жалкие два-три поля, компактный Protobuf распаковывается целиком, память улетает под всё дерево объектов ради пары значений. Большая часть распакованных данных интерпретатору просто не нужна. Раз так, почему бы не отдать CEL сырые байты и не научить его выдёргивать поля лениво, ровно в момент обращения. Команда MWS Cloud Platform залезла во внутренности обоих форматов, собрала ленивый парсер и запустила бенчмарки. На тяжёлых манифестах аллокации памяти рухнули в 15-20 раз. Мечта. А потом этот код взяли и выкинули... Узнаем, что заставило отказаться от решения с идеальными цифрами.

Разбор аудиорежима в кодексе

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

Короче, я тут на днях делал себе компрессы для глаз (*звуки деда*), а они прям полностью глаза закрывают, там такая маска, типа как для сна Ну и вместо того, чтобы спокойно посидеть и подумать о вечном, я врубил диалоговый режим кодекса и проболтал с ним пол часа вместо положенных мне 15 минут Стало интересно, че это он такой умный, и я полез реверсить билд кодекс аппа – реализация оказалась одновременно и простой, и глубокой. А сам подход можно использовать не только для аудио (но об этом в конце поста) В общих чертах – вы общаетесь не с самой gpt-5.6-sol в полноценном кодекс агенте, а с тупенькой моделькой gpt-realtime-1. Тупенькой, но быстрой. И заточенной под диалоговый формат с переживаниями – без этого естественности не добиться и любое общение будет мучением. Так вот, пока у этой модельки хватает сил самой с вами общаться - она будет. Но как только нужно будет сделать что-то сложное, она побежит к кодекс агенту и даст ему задачку. В этот момент сразу же скажет вам что-то вроде «ну-ка дай подумаю» или «так, разбираюсь». Это важно, чтобы мы чувствовали непрерывность общения – как с людьми Такой типа эффект Джарвис. И это реально работает! Получается интересная система, очень похожая на ту, которая бывает в обычных айти командах: - есть менеджер, который всегда онлайн и быстро отвечает, и который общается с заказчиком - есть исполнитель (например, разработчик), который пилит фичу и отвечает по несколько часов в перерывах между сфокусированной работой А менеджер ему еще по ходу докидывает задачки, если у заказчика появились новые хотелки Что интересного из этого следует для нас как для пользователей: 1. Если в процессе выполнения слишком много докидывать новые хотелки, то результат получится плохим: если вы когда то пробовали отправлять steer сообщения в чат работающему агенту, то вы скорее всего замечали – они часто его слишком сбивают с начального пути (ну реально, все как с человеками) 2. Как и в реальных командах, если хотите рулить через одного менеджера несколькими процессами – нужен еще тимлид для команды. Поэтому можно просить выступать в этой роли и ничего не делать самому, а для всех задач на исполнение создавать либо отдельные чаты, либо субагентов. Тогда получится: Менеджер ⬇️ Тимлид ↙️⬇️↘️ Исполнитель1, Исполнитель2, ..., ИсполнительN Тогда выполнение одной задачи не будет блочить главного думающего агента и будет наш привычный опыт, когда в параллель работают несколько чатов, но только с голосом в качестве канала передачи инфы Что тут полезного для тех, кто сам делает AI продукты/фичи Мне кажется, можно забрать сам подход с тем, что сессия основного агента не видна пользователю напрямую, а есть какой-то прокси уровень коммуникации. И это не обязательно должен быть голос. Это может быть какой-то визуальный слой (скоро поделюсь своими экспериментами с Liquid UI), или даже обычный текстовый, но в привычном интерфейсе условного Slack, с быстро отвечающей моделью, которая подтягивает контекст из сессии умного, но долгого агента Ну и если вы делаете голосовых роботов, то советую отправить агента посмотреть, в чем отличие вашей системы от кодекса – мб захотите что-то к себе перетащить И последнее – если вы хотите лучше разбираться в том, как сейчас строить ИИ продукты, но еще почему-то не реверсите реализацию топовых кодинговых агентов – очень советую начать. Это прям кладезь лучших практик

P.s. я, конечно, очень сильно упростил работу менеджеров – на самом деле они делают гораздо больше, чем gpt-realtime-1. Это просто самая близкая и наглядная аналогия, которую я придумал. Если у вас есть лучше, прошу в комменты

@ai_grably