15 исследовательских работ по ИИ, которые должен прочитать каждый AI-инженер
» Attention Is All You Need (Transformers)
https://arxiv.org/abs/1706.03762
» LoRA: Low-Rank Adaptation (низкоранговая адаптация)
https://arxiv.org/abs/2106.09685
»PEFT (Parameter-Efficient Fine-Tuning, параметроэффективный fine-tuning)
https://arxiv.org/abs/2303.15647
»An Image is Worth 16×16 Words (Vision Transformer, ViT)
https://arxiv.org/abs/2010.11929
»Auto-Encoding Variational Bayes (VAE, вариационные автоэнкодеры)
https://arxiv.org/abs/1312.6114
»Generative Adversarial Networks (GANs, генеративно-состязательные сети)
https://arxiv.org/abs/1406.2661
»BERT
https://arxiv.org/abs/1810.04805
»High-Resolution Image Synthesis with Latent Diffusion Models (синтез изображений высокого разрешения с помощью латентных диффузионных моделей)
https://arxiv.org/abs/2112.10752
»Retrieval-Augmented Generation (RAG, генерация с дополнением извлечёнными данными)
https://arxiv.org/abs/2005.11401
»Language Models are Few-Shot Learners (GPT-3, языковые модели как few-shot learners)
https://arxiv.org/abs/2005.14165
»Switch Transformers (MoE, Mixture of Experts — смесь экспертов)
https://arxiv.org/abs/2101.03961
»Learning to Summarize with Human Feedback (RLHF, обучение суммаризации с помощью обратной связи от людей)
https://arxiv.org/abs/2009.01325
»LLaMA: Open and Efficient Foundation Language Models (открытые и эффективные базовые языковые модели)
https://arxiv.org/abs/2302.13971
»RoFormer: Rotary Position Embedding (RoPE, вращательное позиционное кодирование)
https://arxiv.org/abs/2104.09864
»InstructGPT
https://arxiv.org/abs/2203.02155
Читать научные статьи это одно. Понимать, почему каждая из них изменила направление развития области, — именно это делает AI-инженера сильнее.
» Attention Is All You Need (Transformers)
https://arxiv.org/abs/1706.03762
» LoRA: Low-Rank Adaptation (низкоранговая адаптация)
https://arxiv.org/abs/2106.09685
»PEFT (Parameter-Efficient Fine-Tuning, параметроэффективный fine-tuning)
https://arxiv.org/abs/2303.15647
»An Image is Worth 16×16 Words (Vision Transformer, ViT)
https://arxiv.org/abs/2010.11929
»Auto-Encoding Variational Bayes (VAE, вариационные автоэнкодеры)
https://arxiv.org/abs/1312.6114
»Generative Adversarial Networks (GANs, генеративно-состязательные сети)
https://arxiv.org/abs/1406.2661
»BERT
https://arxiv.org/abs/1810.04805
»High-Resolution Image Synthesis with Latent Diffusion Models (синтез изображений высокого разрешения с помощью латентных диффузионных моделей)
https://arxiv.org/abs/2112.10752
»Retrieval-Augmented Generation (RAG, генерация с дополнением извлечёнными данными)
https://arxiv.org/abs/2005.11401
»Language Models are Few-Shot Learners (GPT-3, языковые модели как few-shot learners)
https://arxiv.org/abs/2005.14165
»Switch Transformers (MoE, Mixture of Experts — смесь экспертов)
https://arxiv.org/abs/2101.03961
»Learning to Summarize with Human Feedback (RLHF, обучение суммаризации с помощью обратной связи от людей)
https://arxiv.org/abs/2009.01325
»LLaMA: Open and Efficient Foundation Language Models (открытые и эффективные базовые языковые модели)
https://arxiv.org/abs/2302.13971
»RoFormer: Rotary Position Embedding (RoPE, вращательное позиционное кодирование)
https://arxiv.org/abs/2104.09864
»InstructGPT
https://arxiv.org/abs/2203.02155
Читать научные статьи это одно. Понимать, почему каждая из них изменила направление развития области, — именно это делает AI-инженера сильнее.
arXiv.org
Attention Is All You Need
The dominant sequence transduction models are based on complex recurrent or convolutional neural networks in an encoder-decoder configuration. The best performing models also connect the encoder...
Forwarded from AI VK Hub
Несмотря на взрывной рост рекомендательных трансформеров, генеративных рекомендаций и так далее, классические методы на основе матричных факторизаций всё ещё применяются в рекомендательных системах.
Преимущество современных подходов в том, что они позволяют работать с пользователем в долгосрочной перспективе и учитывать её при построении рекомендаций. Так делают, например, PinnerFormer, OneRec. При этом матричные факторизации обычно работают жадно: набираем top-K по похожести между эмбеддингами в данный момент времени.
Исследователи AI VK Михаил Трапезников и Максим Утушкин предложили подход, который снимает это ограничение и позволяет рекомендательным системам учитывать будущие изменения состояния пользователя.
Решение подробно изложено в статье Planning over Matrix-Factorization MDPs for Candidate Generation. Статья принята на воркшоп по Customer Journey на KDD 2026.
Подход
Исследователи работали с популярной моделью матричных факторизаций ALS (Alternating Least Squares), ориентируясь на механику обновления профилей в сервисе Profile Stream в VK. В нём эмбеддинг пользователя не просто фиксируется после обучения, а обновляется по явной формуле после каждого батча новых пользовательских взаимодействий.
Исследователи применили технику MCTS (Monte Carlo Tree Search) — представили возможные последовательности рекомендаций в виде дерева, чтобы найти путь в дереве, соответствующий оптимальной последовательности рекомендаций. Для офлайн-экспериментов при построении дерева рассматривались набор действий из top-K по близости эмбеддингов и оптимистичная среда.
Вершина дерева — текущее состояние, ветви из вершины — k возможных рекомендаций. При переходе по ветви считаем, что пользователю понравилась рекомендация (оптимистичный сценарий), попадаем в новое состояние — и там всё повторяется.
Процесс
Можно представить процесс в виде RL-среды:
🔸 Состояние — текущее эмбеддинговое представление пользователя
🔸 Действие — показ айтема пользователю
🔸 Награда — сумма близостей к понравившимся айтемам
🔸 Обновление состояния происходит согласно формулам обновления в ALS
Такое представление открывает возможность применения различных RL-подходов, которые позволяют не просто работать с сиюминутными наградами, но и планировать на несколько шагов вперёд.
В работе рассматривались датасеты MovieLens-1M, KuaiRec, Yambda и VK-LSVD. Сравнения производились под протоколами Leave-last-n и Global time split. Первый откладывает последние взаимодействия каждого пользователя, второй режет данные по глобальной временной отсечке — это ближе к проду.
Результат
➡️ На Leave-last-n планирование обходит обычный статический top-K на всех датасетах. В частности, на срезах VK-LSVD Recall@10 растёт примерно в полтора раза
➡️ На Global time split выигрыш сохраняется на MovieLens-1M и VK-LSVD
Главное, что доказало исследование — использование обучения с подкреплением поверх относительно легковесной ALS возможно. В дальнейшем планируются исследования стохастической динамики среды из логов и дистилляции агента в быструю политику в духе MuZero.
#aivkhub #rl #mcts #als
Преимущество современных подходов в том, что они позволяют работать с пользователем в долгосрочной перспективе и учитывать её при построении рекомендаций. Так делают, например, PinnerFormer, OneRec. При этом матричные факторизации обычно работают жадно: набираем top-K по похожести между эмбеддингами в данный момент времени.
Исследователи AI VK Михаил Трапезников и Максим Утушкин предложили подход, который снимает это ограничение и позволяет рекомендательным системам учитывать будущие изменения состояния пользователя.
Решение подробно изложено в статье Planning over Matrix-Factorization MDPs for Candidate Generation. Статья принята на воркшоп по Customer Journey на KDD 2026.
Подход
Исследователи работали с популярной моделью матричных факторизаций ALS (Alternating Least Squares), ориентируясь на механику обновления профилей в сервисе Profile Stream в VK. В нём эмбеддинг пользователя не просто фиксируется после обучения, а обновляется по явной формуле после каждого батча новых пользовательских взаимодействий.
Исследователи применили технику MCTS (Monte Carlo Tree Search) — представили возможные последовательности рекомендаций в виде дерева, чтобы найти путь в дереве, соответствующий оптимальной последовательности рекомендаций. Для офлайн-экспериментов при построении дерева рассматривались набор действий из top-K по близости эмбеддингов и оптимистичная среда.
Вершина дерева — текущее состояние, ветви из вершины — k возможных рекомендаций. При переходе по ветви считаем, что пользователю понравилась рекомендация (оптимистичный сценарий), попадаем в новое состояние — и там всё повторяется.
Процесс
Можно представить процесс в виде RL-среды:
Такое представление открывает возможность применения различных RL-подходов, которые позволяют не просто работать с сиюминутными наградами, но и планировать на несколько шагов вперёд.
В работе рассматривались датасеты MovieLens-1M, KuaiRec, Yambda и VK-LSVD. Сравнения производились под протоколами Leave-last-n и Global time split. Первый откладывает последние взаимодействия каждого пользователя, второй режет данные по глобальной временной отсечке — это ближе к проду.
Результат
Главное, что доказало исследование — использование обучения с подкреплением поверх относительно легковесной ALS возможно. В дальнейшем планируются исследования стохастической динамики среды из логов и дистилляции агента в быструю политику в духе MuZero.
#aivkhub #rl #mcts #als
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
10 типов evals для AI-инженеров:
1) Golden set (эталонный набор)
→ Фиксированный набор тестовых кейсов, который никогда не меняется и запускается после каждого изменения.
→ Используйте как базовый ориентир, чтобы понимать, изменилось ли поведение системы вообще.
2) LLM as judge (LLM в роли оценщика)
→ Вторая модель оценивает результат по заранее написанному критерию.
→ Используйте, когда ответ открытый и нет точного значения для сравнения.
3) Rubric scoring (оценка по критериям)
→ Несколько отдельных оценок по направлениям: корректность, стиль, безопасность, стоимость.
→ Используйте, когда одна общая оценка скрывает, какая именно часть стала хуже.
4) Trajectory eval (оценка траектории агента)
→ Оценивается не только итоговый ответ, но и весь путь, которым агент к нему пришёл.
→ Используйте, когда правильный результат, полученный неправильным способом, может создать проблемы позже.
5) Tool unit tests (юнит-тесты инструментов)
→ Проверка каждого инструмента отдельно, с тестовыми данными и без участия модели.
→ Используйте всегда. Большинство проблем агентов — это проблемы инструментов, которые просто выглядят как ошибки модели.
6) Regression suite (регрессионный набор)
→ Повторный запуск старых сценариев с новой версией промпта или модели и сравнение результатов.
→ Используйте перед каждым изменением промпта, потому что у промптов нет системы типов.
7) A/B-тестирование в проде
→ Разделение реального трафика между двумя версиями и сравнение результатов, а не субъективных ощущений.
→ Используйте, когда офлайн-оценки перестали отражать реальное поведение пользователей.
8) Human review (проверка человеком)
→ Берётся часть запусков, и человек вручную оценивает качество.
→ Используйте для калибровки LLM-оценщика, потому что без проверки он может постепенно начать ошибаться.
9) Shadow run (теневой запуск)
→ Новая версия работает параллельно на реальном трафике, но её ответы никто не видит.
→ Используйте перед рискованным релизом, когда одна ошибка может дорого обойтись.
10) Red team (атакующее тестирование)
→ Специально пытайтесь сломать систему: jailbreak, prompt injection, утечки данных, злоупотребление инструментами.
→ Используйте до того, как к системе получат доступ внешние пользователи, а не после инцидента.
Офлайн-evals показывают, что система работает.
Онлайн-evals показывают, что она всё ещё работает в реальных условиях.
Нужны оба подхода, но не обязательно запускать все десять.
Начните с тех двух, которые смогли бы предотвратить вашу последнюю серьёзную ошибку.
1) Golden set (эталонный набор)
→ Фиксированный набор тестовых кейсов, который никогда не меняется и запускается после каждого изменения.
→ Используйте как базовый ориентир, чтобы понимать, изменилось ли поведение системы вообще.
2) LLM as judge (LLM в роли оценщика)
→ Вторая модель оценивает результат по заранее написанному критерию.
→ Используйте, когда ответ открытый и нет точного значения для сравнения.
3) Rubric scoring (оценка по критериям)
→ Несколько отдельных оценок по направлениям: корректность, стиль, безопасность, стоимость.
→ Используйте, когда одна общая оценка скрывает, какая именно часть стала хуже.
4) Trajectory eval (оценка траектории агента)
→ Оценивается не только итоговый ответ, но и весь путь, которым агент к нему пришёл.
→ Используйте, когда правильный результат, полученный неправильным способом, может создать проблемы позже.
5) Tool unit tests (юнит-тесты инструментов)
→ Проверка каждого инструмента отдельно, с тестовыми данными и без участия модели.
→ Используйте всегда. Большинство проблем агентов — это проблемы инструментов, которые просто выглядят как ошибки модели.
6) Regression suite (регрессионный набор)
→ Повторный запуск старых сценариев с новой версией промпта или модели и сравнение результатов.
→ Используйте перед каждым изменением промпта, потому что у промптов нет системы типов.
7) A/B-тестирование в проде
→ Разделение реального трафика между двумя версиями и сравнение результатов, а не субъективных ощущений.
→ Используйте, когда офлайн-оценки перестали отражать реальное поведение пользователей.
8) Human review (проверка человеком)
→ Берётся часть запусков, и человек вручную оценивает качество.
→ Используйте для калибровки LLM-оценщика, потому что без проверки он может постепенно начать ошибаться.
9) Shadow run (теневой запуск)
→ Новая версия работает параллельно на реальном трафике, но её ответы никто не видит.
→ Используйте перед рискованным релизом, когда одна ошибка может дорого обойтись.
10) Red team (атакующее тестирование)
→ Специально пытайтесь сломать систему: jailbreak, prompt injection, утечки данных, злоупотребление инструментами.
→ Используйте до того, как к системе получат доступ внешние пользователи, а не после инцидента.
Офлайн-evals показывают, что система работает.
Онлайн-evals показывают, что она всё ещё работает в реальных условиях.
Нужны оба подхода, но не обязательно запускать все десять.
Начните с тех двух, которые смогли бы предотвратить вашу последнюю серьёзную ошибку.
Связка Kimi K3 и Tinker позволяет почти полностью автоматизировать исследовательский цикл.
Поскольку большая часть инфраструктуры для обучения уже скрыта под капотом, изменения, которые вносит Kimi, остаются сосредоточены именно на эксперименте. Благодаря этому проще отслеживать, что изменилось, и направлять следующие запуски.
При попытке воспроизвести работу Self-Distilled RLVR модель с первого раза собрала базовую реализацию, затем провела 19 экспериментов с шестью конфигурациями и оформила итоговый отчёт. Заодно она сама подготовила его версию на китайском языке.
Попробовать авторесёрч с Kimi можно самостоятельно на openresearch.sh.
Для воспроизведения эксперимента используйте пример из репозитория:
https://github.com/alphaXiv/rlsd-6a0be1c4
Поскольку большая часть инфраструктуры для обучения уже скрыта под капотом, изменения, которые вносит Kimi, остаются сосредоточены именно на эксперименте. Благодаря этому проще отслеживать, что изменилось, и направлять следующие запуски.
При попытке воспроизвести работу Self-Distilled RLVR модель с первого раза собрала базовую реализацию, затем провела 19 экспериментов с шестью конфигурациями и оформила итоговый отчёт. Заодно она сама подготовила его версию на китайском языке.
Попробовать авторесёрч с Kimi можно самостоятельно на openresearch.sh.
Для воспроизведения эксперимента используйте пример из репозитория:
https://github.com/alphaXiv/rlsd-6a0be1c4
Война ИИ-моделей за нерешённые математические задачи официально началась. 😆
GPT-5.6 вслед за Fable опровергла ещё одну известную гипотезу — Диница — Гарга — Гоеманса, которая оставалась открытой около 30 лет.
Самое любопытное, что сессия выглядела вполне обычно: без специальных подсказок, сложного промптинга и подробных инструкций. Модель просто нашла контрпример.
Но на этом история не закончилась. Илон Маск в ответ поделился результатом Grok 4.5, который опроверг другую гипотезу из теории графов, над которой математики бились около 30 лет.
Речь о гипотезе Graffiti №284. В Slack просто отправили исходный пост, после чего Capy на базе Grok 4.5 Medium решила проверить утверждение и за восемь минут нашла новый контрпример.
GPT-5.6 вслед за Fable опровергла ещё одну известную гипотезу — Диница — Гарга — Гоеманса, которая оставалась открытой около 30 лет.
Самое любопытное, что сессия выглядела вполне обычно: без специальных подсказок, сложного промптинга и подробных инструкций. Модель просто нашла контрпример.
Но на этом история не закончилась. Илон Маск в ответ поделился результатом Grok 4.5, который опроверг другую гипотезу из теории графов, над которой математики бились около 30 лет.
Речь о гипотезе Graffiti №284. В Slack просто отправили исходный пост, после чего Capy на базе Grok 4.5 Medium решила проверить утверждение и за восемь минут нашла новый контрпример.
Please open Telegram to view this post
VIEW IN TELEGRAM
Тем временем, Kimi K3 взломала последнюю версию Redis с помощью 0-day уязвимости, которую сама обнаружила.
Всё, что потребовалось — 27 минут работы 32 агентов.
https://github.com/berabuddies/redis-poc
Всё, что потребовалось — 27 минут работы 32 агентов.
https://github.com/berabuddies/redis-poc
This media is not supported in your browser
VIEW IN TELEGRAM
CPU, GPU, TPU, NPU и LPU: в чём разница
Сегодня для AI-нагрузок используются пять основных аппаратных архитектур. Каждая по-своему балансирует между универсальностью, параллелизмом и доступом к памяти.
CPU — универсальный процессор с небольшим количеством мощных ядер. Он хорошо справляется со сложной логикой, ветвлениями, операционными системами и базами данных, но менее эффективен в повторяющихся матричных вычислениях.
GPU использует тысячи более простых ядер, которые параллельно выполняют одинаковые операции над разными данными. Именно поэтому GPU стали основной платформой для обучения нейросетей.
TPU ещё сильнее специализированы под AI. Их основа — массивы MAC-блоков, через которые веса, активации и промежуточные результаты передаются без постоянного обращения к памяти. Выполнением управляет компилятор, а сама архитектура изначально создавалась Google для нейросетевых задач.
NPU оптимизированы для энергоэффективного инференса на устройствах. Они используют MAC-массивы и встроенную SRAM, но работают с низкопотребляющей системной памятью вместо HBM. Такие процессоры устанавливают в смартфоны, ноутбуки, носимые устройства и IoT-системы. К этому типу относятся Apple Neural Engine и NPU от Intel.
LPU — архитектура Groq, созданная для обработки языковых моделей. Она исключает внешнюю память из критического пути: веса хранятся во встроенной SRAM, а выполнение полностью планируется компилятором. Это устраняет промахи кеша и накладные расходы на планирование во время работы.
Главный недостаток LPU — ограниченный объём памяти на одном чипе, поэтому для запуска крупной модели приходится объединять сотни процессоров. Однако это позволяет заметно снизить задержку.
Эволюция AI-железа движется от универсальных CPU к всё более специализированным архитектурам. На каждом этапе часть гибкости обменивается на производительность и энергоэффективность.
Общая задача всех этих архитектур — сократить перемещение данных. Сами вычисления не являются главным ограничением: сложнее обеспечить вычислительные блоки данными с достаточной скоростью.
Та же проблема возникает и на программном уровне. Во время инференса LLM один GPU может ежедневно создавать терабайты KV-кеша, большая часть которого затем удаляется и пересчитывается. Это одна из причин высокой стоимости агентных нагрузок.
Сегодня для AI-нагрузок используются пять основных аппаратных архитектур. Каждая по-своему балансирует между универсальностью, параллелизмом и доступом к памяти.
CPU — универсальный процессор с небольшим количеством мощных ядер. Он хорошо справляется со сложной логикой, ветвлениями, операционными системами и базами данных, но менее эффективен в повторяющихся матричных вычислениях.
GPU использует тысячи более простых ядер, которые параллельно выполняют одинаковые операции над разными данными. Именно поэтому GPU стали основной платформой для обучения нейросетей.
TPU ещё сильнее специализированы под AI. Их основа — массивы MAC-блоков, через которые веса, активации и промежуточные результаты передаются без постоянного обращения к памяти. Выполнением управляет компилятор, а сама архитектура изначально создавалась Google для нейросетевых задач.
NPU оптимизированы для энергоэффективного инференса на устройствах. Они используют MAC-массивы и встроенную SRAM, но работают с низкопотребляющей системной памятью вместо HBM. Такие процессоры устанавливают в смартфоны, ноутбуки, носимые устройства и IoT-системы. К этому типу относятся Apple Neural Engine и NPU от Intel.
LPU — архитектура Groq, созданная для обработки языковых моделей. Она исключает внешнюю память из критического пути: веса хранятся во встроенной SRAM, а выполнение полностью планируется компилятором. Это устраняет промахи кеша и накладные расходы на планирование во время работы.
Главный недостаток LPU — ограниченный объём памяти на одном чипе, поэтому для запуска крупной модели приходится объединять сотни процессоров. Однако это позволяет заметно снизить задержку.
Эволюция AI-железа движется от универсальных CPU к всё более специализированным архитектурам. На каждом этапе часть гибкости обменивается на производительность и энергоэффективность.
Общая задача всех этих архитектур — сократить перемещение данных. Сами вычисления не являются главным ограничением: сложнее обеспечить вычислительные блоки данными с достаточной скоростью.
Та же проблема возникает и на программном уровне. Во время инференса LLM один GPU может ежедневно создавать терабайты KV-кеша, большая часть которого затем удаляется и пересчитывается. Это одна из причин высокой стоимости агентных нагрузок.
This media is not supported in your browser
VIEW IN TELEGRAM
Похоже, платные сервисы для извлечения данных из документов становятся всё менее нужными.
Zipstack создала open-source платформу Unstract, которая превращает PDF, сканы и изображения в структурированный JSON с помощью LLM-моделей, которыми вы уже пользуетесь.
Достаточно загрузить счёт, банковскую выписку, KYC-форму, налоговую декларацию или другой документ и указать, какие данные нужно извлечь. Unstract найдёт нужные поля и вернёт готовый JSON, который можно сразу отправить в базу данных.
Главное отличие от традиционных решений — не нужно настраивать отдельную модель под каждого поставщика или писать регулярки для каждого шаблона. Схема извлечения описывается обычным языком и работает с разными вариантами документов.
Unstract умеет:
→ извлекать данные из PDF, сканов и изображений
→ создавать схемы через обычные текстовые инструкции
→ разворачиваться как REST API или ETL-пайплайн
→ подключаться к Claude и другим агентам через MCP
→ работать с S3, GCS, Snowflake, BigQuery, Postgres и другими хранилищами
→ использовать OpenAI, Anthropic, Gemini, Mistral, Ollama, Bedrock и другие модели
По сути, Unstract берёт тысячи документов, которые никто не успевает читать вручную, и превращает их в чистые структурированные данные, готовые для продакшена.
https://github.com/Zipstack/unstract
Zipstack создала open-source платформу Unstract, которая превращает PDF, сканы и изображения в структурированный JSON с помощью LLM-моделей, которыми вы уже пользуетесь.
Достаточно загрузить счёт, банковскую выписку, KYC-форму, налоговую декларацию или другой документ и указать, какие данные нужно извлечь. Unstract найдёт нужные поля и вернёт готовый JSON, который можно сразу отправить в базу данных.
Главное отличие от традиционных решений — не нужно настраивать отдельную модель под каждого поставщика или писать регулярки для каждого шаблона. Схема извлечения описывается обычным языком и работает с разными вариантами документов.
Unstract умеет:
→ извлекать данные из PDF, сканов и изображений
→ создавать схемы через обычные текстовые инструкции
→ разворачиваться как REST API или ETL-пайплайн
→ подключаться к Claude и другим агентам через MCP
→ работать с S3, GCS, Snowflake, BigQuery, Postgres и другими хранилищами
→ использовать OpenAI, Anthropic, Gemini, Mistral, Ollama, Bedrock и другие модели
По сути, Unstract берёт тысячи документов, которые никто не успевает читать вручную, и превращает их в чистые структурированные данные, готовые для продакшена.
https://github.com/Zipstack/unstract
This media is not supported in your browser
VIEW IN TELEGRAM
Kimi K3 обучила тернарную модель с нуля.
Каждый линейный слой в ней тернарный: каждый вес строго равен −1, 0 или +1.
И… это работает. Причём почти ничего не стоит.
Архитектура и датасет те же, что и в stories15M Андрея Карпаты. Его модель с полной точностью используется как базовая, а эта — её тернарный аналог.
Итоговый val loss с тернарными весами: 1,6074.
У версии той же модели с полной точностью: 1,5970. Разница: всего +0,01.
Во время обучения forward pass модели всегда выполнялся только с тернарными весами. FP32-веса служили лишь вспомогательной структурой для вычисления градиентов. То есть тернарные веса — не сжатая копия модели. Они и есть сама модель. FP32-чекпоинт можно просто выбросить.
После того как линейные слои стали почти бесплатными — 1 байт на вес и никаких умножений — FP32-матрица эмбеддингов начала занимать 70% всего хранилища модели.
Удешевляешь очевидную часть — и сразу обнаруживается настоящий bottleneck.
https://github.com/brianbell-x/ternary15M
веса - https://huggingface.co/brianbellx/ternary15M
Каждый линейный слой в ней тернарный: каждый вес строго равен −1, 0 или +1.
И… это работает. Причём почти ничего не стоит.
Архитектура и датасет те же, что и в stories15M Андрея Карпаты. Его модель с полной точностью используется как базовая, а эта — её тернарный аналог.
Итоговый val loss с тернарными весами: 1,6074.
У версии той же модели с полной точностью: 1,5970. Разница: всего +0,01.
Во время обучения forward pass модели всегда выполнялся только с тернарными весами. FP32-веса служили лишь вспомогательной структурой для вычисления градиентов. То есть тернарные веса — не сжатая копия модели. Они и есть сама модель. FP32-чекпоинт можно просто выбросить.
После того как линейные слои стали почти бесплатными — 1 байт на вес и никаких умножений — FP32-матрица эмбеддингов начала занимать 70% всего хранилища модели.
Удешевляешь очевидную часть — и сразу обнаруживается настоящий bottleneck.
https://github.com/brianbell-x/ternary15M
веса - https://huggingface.co/brianbellx/ternary15M
This media is not supported in your browser
VIEW IN TELEGRAM
Кто-то смог запустить CUDA-код на Apple Silicon без переписывания исходников под Metal.
Для этого разработчики собрали цепочку компиляторов, которая автоматически переводит CUDA в код для GPU Apple. В работе использовали GPT-5.6 Sol.
Решение проверили не на простом демо, а на полноценной 3D-симуляции жидкости с сортировкой частиц, атомарными операциями и построением списков соседей.
На одном чипе Apple симуляция выполнилась за 6 секунд, тогда как на CPU тот же код работал около минуты. GPU при этом был загружен полностью, а заметных потерь из-за трансляции не обнаружили.
Если подход окажется применим к другим проектам, часть существующего CUDA-софта можно будет запускать на Mac без ручного портирования. Проект выложен в открытый доступ.
https://github.com/mosaic-group/openfpm/pull/18
Для этого разработчики собрали цепочку компиляторов, которая автоматически переводит CUDA в код для GPU Apple. В работе использовали GPT-5.6 Sol.
Решение проверили не на простом демо, а на полноценной 3D-симуляции жидкости с сортировкой частиц, атомарными операциями и построением списков соседей.
На одном чипе Apple симуляция выполнилась за 6 секунд, тогда как на CPU тот же код работал около минуты. GPU при этом был загружен полностью, а заметных потерь из-за трансляции не обнаружили.
Если подход окажется применим к другим проектам, часть существующего CUDA-софта можно будет запускать на Mac без ручного портирования. Проект выложен в открытый доступ.
https://github.com/mosaic-group/openfpm/pull/18
NVIDIA сократили время запуска DeepSeek-V4 Pro с 8 минут до менее чем 2 минут, перенеся веса в память GPU по самому быстрому маршруту — через GPU-to-GPU RDMA.
Этого удалось добиться с помощью NVIDIA ModelExpress (MX) — сервиса распределения весов и управления кешем в NVIDIA Dynamo. Тот же подход ускоряет не только инференс, но и постобучение с использованием RL.
MX переиспользует кеши ядер, а воркеры инференса получают обновлённые веса напрямую с других GPU через NIXL. Это позволяет отказаться от централизованной рассылки и вывести перенос весов за пределы критического пути.
Этого удалось добиться с помощью NVIDIA ModelExpress (MX) — сервиса распределения весов и управления кешем в NVIDIA Dynamo. Тот же подход ускоряет не только инференс, но и постобучение с использованием RL.
MX переиспользует кеши ядер, а воркеры инференса получают обновлённые веса напрямую с других GPU через NIXL. Это позволяет отказаться от централизованной рассылки и вывести перенос весов за пределы критического пути.
// Управление контекстом агентных систем //
Отличное чтение на выходные.
Сохраните в закладки.
Продакшен-агенты чаще ломаются не из-за слабого рассуждения, а из-за того, что накапливается в их контексте. История диалога, большие промпты, огромные описания инструментов и постоянно растущие результаты их вызовов добавляются на каждом шаге.
Обычно эту проблему пытаются решить через хранение и извлечение: создают место, куда можно складывать воспоминания, а затем находить их при необходимости. Однако новое исследование утверждает, что такой взгляд слишком узкий, и предлагает более широкую дисциплину — Agentic Context Management.
Она состоит из пяти базовых операций:
* проектирование;
* загрузка;
* определение области контекста;
* предвосхищение;
* сжатие с консолидацией.
При наивном накоплении стоимость токенов растёт квадратично относительно длины диалога. Грубая суммаризация снижает рост до линейного, но в какой-то момент приводит к резкому падению точности. Только сжатие, проверенное на сохранение исходного смысла, позволяет получить линейную стоимость без потери важной информации.
В референсной реализации сообщается о результате 92% на LongMemEval и 93,2% на LoCoMo.
Почему это важно?
Управление контекстом становится полноценной продакшен-задачей, которая затрагивает всю организацию. Эти пять операций дают структурированный способ понять, на что именно расходуется ваш токен-бюджет.
Статья: https://arxiv.org/abs/2607.21503
Отличное чтение на выходные.
Сохраните в закладки.
Продакшен-агенты чаще ломаются не из-за слабого рассуждения, а из-за того, что накапливается в их контексте. История диалога, большие промпты, огромные описания инструментов и постоянно растущие результаты их вызовов добавляются на каждом шаге.
Обычно эту проблему пытаются решить через хранение и извлечение: создают место, куда можно складывать воспоминания, а затем находить их при необходимости. Однако новое исследование утверждает, что такой взгляд слишком узкий, и предлагает более широкую дисциплину — Agentic Context Management.
Она состоит из пяти базовых операций:
* проектирование;
* загрузка;
* определение области контекста;
* предвосхищение;
* сжатие с консолидацией.
При наивном накоплении стоимость токенов растёт квадратично относительно длины диалога. Грубая суммаризация снижает рост до линейного, но в какой-то момент приводит к резкому падению точности. Только сжатие, проверенное на сохранение исходного смысла, позволяет получить линейную стоимость без потери важной информации.
В референсной реализации сообщается о результате 92% на LongMemEval и 93,2% на LoCoMo.
Почему это важно?
Управление контекстом становится полноценной продакшен-задачей, которая затрагивает всю организацию. Эти пять операций дают структурированный способ понять, на что именно расходуется ваш токен-бюджет.
Статья: https://arxiv.org/abs/2607.21503
arXiv.org
Agentic Context Management: Solving Agent Memory and Cost by...
Production AI agents' failures are less often due to an inability to reason well and more often because they cannot manage what is in their reasoning context: conversation histories, large...
В основе Kimi 3 лежит новый механизм под названием delta attention, который не хранит постоянно растущий KV-кеш. Именно поэтому модель может работать с контекстом в миллион токенов без взрывного роста потребления памяти.
Но прежде чем разбираться в delta attention, нужно понять, как работает обычный attention.
По сути, это поиск по таблице. Каждый токен хранит:
- key — что-то вроде адреса;
- value — содержимое по этому адресу.
Чтобы сформировать выход, токен отправляет
Обычный attention хранит каждую такую пару key-value в виде списка — по одной записи на токен. Этот список и называется KV-кешем.
Он растёт вместе с длиной последовательности, поэтому каждому новому токену приходится просматривать весь кеш, чтобы сформировать результат. Если удвоить длину контекста, удвоятся и объём хранения, и количество операций поиска. Отсюда берутся квадратичная стоимость и быстро растущее потребление памяти.
Delta attention сохраняет сам механизм поиска, но избавляется от списка.
Вся история сжимается в одну матрицу фиксированного размера, которая продолжает работать как таблица поиска. Передаёте ей ключ — она возвращает значение, которое прошлый контекст связал с этим ключом.
Неважно, тысяча токенов в контексте или миллион - размер матрицы остаётся прежним.
Самая сложная часть это запись новых данных.
Нельзя просто добавить новую пару в матрицу фиксированного размера (новые записи начнут накладываться на старые и смешиваться с ними). Delta rule решает эту проблему в два шага для каждого токена. Они показаны в нижней части схемы.
→ Сначала чтение, затем запись.
Матрице передаётся ключ нового токена, после чего проверяется, какое значение память уже возвращает по этому адресу — то есть её текущая оценка.
→ Записывается не само значение, а разница.
Текущая оценка сравнивается со значением, которое нужно сохранить. В матрицу записывается только расхождение между ними. Это расхождение и называется delta. Оно корректирует старую ассоциацию, а не накладывает поверх неё новую.
Матрица также позволяет старым записям постепенно затухать. Благодаря этому память фиксированного размера может продолжать поглощать длинную последовательность, не переполняясь.
Именно в этом заключается разница, показанная на схеме.
Обычный attention запоминает всё, сохраняя каждую запись, и платит за это квадратичной стоимостью повторного сканирования.
Delta attention запоминает, постоянно перезаписывая одну матрицу, и работает с линейной стоимостью.
Но компромисс здесь реальный.
Сжатая матрица не может хранить каждый токен абсолютно точно, поэтому восстановление конкретного токена становится приблизительным. Именно поэтому в реальных моделях обычно комбинируют оба подхода: несколько слоёв full attention оставляют для точного поиска, а остальные работают в линейном режиме.
Вся разница сводится к одному глаголу:
Обычный attention добавляет. Delta attention корректирует.
Подробнее: https://kimi.com/blog/kimi-k3
Но прежде чем разбираться в delta attention, нужно понять, как работает обычный attention.
По сути, это поиск по таблице. Каждый токен хранит:
- key — что-то вроде адреса;
- value — содержимое по этому адресу.
Чтобы сформировать выход, токен отправляет
query, сравнивает его со всеми ключами в последовательности и получает смесь значений, ключи которых подошли лучше всего. Именно это показано в верхней части схемы.Обычный attention хранит каждую такую пару key-value в виде списка — по одной записи на токен. Этот список и называется KV-кешем.
Он растёт вместе с длиной последовательности, поэтому каждому новому токену приходится просматривать весь кеш, чтобы сформировать результат. Если удвоить длину контекста, удвоятся и объём хранения, и количество операций поиска. Отсюда берутся квадратичная стоимость и быстро растущее потребление памяти.
Delta attention сохраняет сам механизм поиска, но избавляется от списка.
Вся история сжимается в одну матрицу фиксированного размера, которая продолжает работать как таблица поиска. Передаёте ей ключ — она возвращает значение, которое прошлый контекст связал с этим ключом.
Неважно, тысяча токенов в контексте или миллион - размер матрицы остаётся прежним.
Самая сложная часть это запись новых данных.
Нельзя просто добавить новую пару в матрицу фиксированного размера (новые записи начнут накладываться на старые и смешиваться с ними). Delta rule решает эту проблему в два шага для каждого токена. Они показаны в нижней части схемы.
→ Сначала чтение, затем запись.
Матрице передаётся ключ нового токена, после чего проверяется, какое значение память уже возвращает по этому адресу — то есть её текущая оценка.
→ Записывается не само значение, а разница.
Текущая оценка сравнивается со значением, которое нужно сохранить. В матрицу записывается только расхождение между ними. Это расхождение и называется delta. Оно корректирует старую ассоциацию, а не накладывает поверх неё новую.
Матрица также позволяет старым записям постепенно затухать. Благодаря этому память фиксированного размера может продолжать поглощать длинную последовательность, не переполняясь.
Именно в этом заключается разница, показанная на схеме.
Обычный attention запоминает всё, сохраняя каждую запись, и платит за это квадратичной стоимостью повторного сканирования.
Delta attention запоминает, постоянно перезаписывая одну матрицу, и работает с линейной стоимостью.
Но компромисс здесь реальный.
Сжатая матрица не может хранить каждый токен абсолютно точно, поэтому восстановление конкретного токена становится приблизительным. Именно поэтому в реальных моделях обычно комбинируют оба подхода: несколько слоёв full attention оставляют для точного поиска, а остальные работают в линейном режиме.
Вся разница сводится к одному глаголу:
Обычный attention добавляет. Delta attention корректирует.
Подробнее: https://kimi.com/blog/kimi-k3
«Mathematics of Neural Networks» — компактный вводный материал по deep learning с упором на математику.
Книга постепенно разбирает базовые идеи современных нейросетей: supervised learning, искусственные нейроны и функции активации, feed-forward сети, stochastic gradient descent, глубокие нейросети, инициализацию весов, CNN, automatic differentiation и backpropagation, а также оптимизаторы Adam, RMSProp и Adagrad.
Отдельно затрагиваются equivariance, группы Ли, однородные пространства и geometric deep learning.
Материал рассчитан на студентов и тех, кто хочет сначала выстроить прочную математическую базу по нейросетям, а уже потом переходить к более сложным источникам. Несмотря на вводный уровень, изложение остаётся достаточно строгим и хорошо показывает математические принципы, лежащие в основе современных deep learning-систем.
https://arxiv.org/pdf/2403.04807
Книга постепенно разбирает базовые идеи современных нейросетей: supervised learning, искусственные нейроны и функции активации, feed-forward сети, stochastic gradient descent, глубокие нейросети, инициализацию весов, CNN, automatic differentiation и backpropagation, а также оптимизаторы Adam, RMSProp и Adagrad.
Отдельно затрагиваются equivariance, группы Ли, однородные пространства и geometric deep learning.
Материал рассчитан на студентов и тех, кто хочет сначала выстроить прочную математическую базу по нейросетям, а уже потом переходить к более сложным источникам. Несмотря на вводный уровень, изложение остаётся достаточно строгим и хорошо показывает математические принципы, лежащие в основе современных deep learning-систем.
https://arxiv.org/pdf/2403.04807
This media is not supported in your browser
VIEW IN TELEGRAM
11 методов оценки LLM, которые стоит знать AI-инженерам:
Две eval-метрики могут поставить одни и те же две модели в противоположном порядке — и при этом обе будут правы.
Например, модель может перефразировать эталонный ответ и получить почти ноль по BLEU, но при этом оказаться почти на вершине по BERTScore для того же самого результата.
И ни одна из метрик не ошибается: BLEU измеряет совпадение формулировок, а BERTScore лучше улавливает смысл.
Именно поэтому оценка LLM разбита на несколько подходов, каждый из которых опирается на свои предположения.
Reference-based — когда есть ground truth:
BLEU
ROUGE
BERTScore
Judge-based — когда ground truth нет:
G-Eval
LLM-as-Judge
LLM juries
Human и deterministic:
Human eval
DAG
Для агентов:
Trajectory accuracy
Multi-turn eval
Как gate перед продом: Safety eval
На практике большинство этих метрик уже реализованы в Opik — open-source проекте с 20k+ звёзд на GitHub. Он позволяет запускать evals поверх traced production data и начать работу буквально с нескольких строк кода.
GitHub: https://github.com/comet-ml/opik
Но сами метрики лишь показывают, какой кейс сломался.
Остальная работа обычно всё ещё делается вручную: нужно открыть trace, понять, на каком span всё пошло не так, изменить prompt или описание tool, повторно запустить кейс и проверить, что исправление не сломало что-то ещё.
Сооснователь автора сделал подробный walkthrough с кодом, который автоматизирует этот цикл с помощью Opik.
В нём показан полный workflow: неудачный trace диагностируется, исправление прогоняется на том же input, где возникла ошибка, а затем этот input остаётся в eval set как regression case, чтобы проблема не повторилась.
Две eval-метрики могут поставить одни и те же две модели в противоположном порядке — и при этом обе будут правы.
Например, модель может перефразировать эталонный ответ и получить почти ноль по BLEU, но при этом оказаться почти на вершине по BERTScore для того же самого результата.
И ни одна из метрик не ошибается: BLEU измеряет совпадение формулировок, а BERTScore лучше улавливает смысл.
Именно поэтому оценка LLM разбита на несколько подходов, каждый из которых опирается на свои предположения.
Reference-based — когда есть ground truth:
BLEU
ROUGE
BERTScore
Judge-based — когда ground truth нет:
G-Eval
LLM-as-Judge
LLM juries
Human и deterministic:
Human eval
DAG
Для агентов:
Trajectory accuracy
Multi-turn eval
Как gate перед продом: Safety eval
На практике большинство этих метрик уже реализованы в Opik — open-source проекте с 20k+ звёзд на GitHub. Он позволяет запускать evals поверх traced production data и начать работу буквально с нескольких строк кода.
GitHub: https://github.com/comet-ml/opik
Но сами метрики лишь показывают, какой кейс сломался.
Остальная работа обычно всё ещё делается вручную: нужно открыть trace, понять, на каком span всё пошло не так, изменить prompt или описание tool, повторно запустить кейс и проверить, что исправление не сломало что-то ещё.
Сооснователь автора сделал подробный walkthrough с кодом, который автоматизирует этот цикл с помощью Opik.
В нём показан полный workflow: неудачный trace диагностируется, исправление прогоняется на том же input, где возникла ошибка, а затем этот input остаётся в eval set как regression case, чтобы проблема не повторилась.
«An Introduction to Real Analysis» Джона К. Хантера — бесплатный набор университетских лекционных материалов и строгое введение в математический анализ.
Книга начинается с множеств, функций и чисел, а затем переходит к последовательностям, рядам, топологии вещественных чисел, пределам, непрерывности, дифференцированию, последовательностям и рядам функций, степенным рядам, интегралу Римана и его приложениям, а также метрическим, нормированным и топологическим пространствам.
Материал подойдёт студентам, которые уже знакомы с calculus и хотят перейти к более строгой, основанной на доказательствах математике. Изложение понятное, а уровень соответствует университетскому курсу по real analysis.
Полная версия конспектов доступна на сайте автора:
https://math.ucdavis.edu/~hunter/intro_analysis_pdf/intro_analysis.html
Книга начинается с множеств, функций и чисел, а затем переходит к последовательностям, рядам, топологии вещественных чисел, пределам, непрерывности, дифференцированию, последовательностям и рядам функций, степенным рядам, интегралу Римана и его приложениям, а также метрическим, нормированным и топологическим пространствам.
Материал подойдёт студентам, которые уже знакомы с calculus и хотят перейти к более строгой, основанной на доказательствах математике. Изложение понятное, а уровень соответствует университетскому курсу по real analysis.
Полная версия конспектов доступна на сайте автора:
https://math.ucdavis.edu/~hunter/intro_analysis_pdf/intro_analysis.html
В открытом доступе есть один из самых известных учебников MIT по computer science — Structure and Interpretation of Computer Programs (SICP).
Это больше 650 страниц не столько про конкретный язык, сколько про то, как вообще думать о программах и вычислениях.
Вместо очередного фреймворка здесь разбираются базовые идеи: абстракции, рекурсия, higher-order functions, состояние, lazy evaluation, устройство интерпретаторов, компиляция и register machines.
SICP много лет использовался в MIT как вводный материал по computer science, и его ценность как раз в том, что он учит смотреть на код глубже, чем на набор синтаксических конструкций.
Книга доступна бесплатно целиком:
https://web.mit.edu/6.001/6.037/sicp.pdf
Это больше 650 страниц не столько про конкретный язык, сколько про то, как вообще думать о программах и вычислениях.
Вместо очередного фреймворка здесь разбираются базовые идеи: абстракции, рекурсия, higher-order functions, состояние, lazy evaluation, устройство интерпретаторов, компиляция и register machines.
SICP много лет использовался в MIT как вводный материал по computer science, и его ценность как раз в том, что он учит смотреть на код глубже, чем на набор синтаксических конструкций.
Книга доступна бесплатно целиком:
https://web.mit.edu/6.001/6.037/sicp.pdf
Kimi K3 получилась куда интереснее, чем просто «ещё одна огромная MoE-модель».
По сути Moonshot взяли архитектурные идеи из Kimi Linear и масштабировали их с 48B до 2.8T параметров. Сейчас K3 — крупнейшая open-weight модель.
Из нового появился LatentMoE — подход, где большие linear layers дополнительно сжимают через down-projection. Общий вектор здесь понятный: сделать такую гигантскую модель дешевле и эффективнее на инференсе.
Поэтому обычные компоненты постепенно заменяются более оптимизированными версиями: MoE → LatentMoE, стандартный attention → multi-head latent attention и Kimi Delta Attention.
Отдельно интересны attention residuals. Это уже не столько про ускорение, сколько про улучшение передачи информации между слоями. Residual-связи соединяются между слоями, а их вклад определяется через attention score. По отчёту, это немного, но стабильно улучшает validation loss и downstream performance, ценой примерно +4% к обучению и +2% к инференсу.
Ещё один необычный момент — в Kimi K3 вообще нет RoPE. Модель полностью использует NoPE, то есть обходится без positional embeddings. Для frontier-модели это довольно редкий подход.
Ну и K3 теперь нативно мультимодальная.
В целом архитектура выглядит сложной, но почти все изменения хорошо укладываются в одну идею: масштабировать модель до безумных размеров, не превращая инференс в полный кошмар.
По сути Moonshot взяли архитектурные идеи из Kimi Linear и масштабировали их с 48B до 2.8T параметров. Сейчас K3 — крупнейшая open-weight модель.
Из нового появился LatentMoE — подход, где большие linear layers дополнительно сжимают через down-projection. Общий вектор здесь понятный: сделать такую гигантскую модель дешевле и эффективнее на инференсе.
Поэтому обычные компоненты постепенно заменяются более оптимизированными версиями: MoE → LatentMoE, стандартный attention → multi-head latent attention и Kimi Delta Attention.
Отдельно интересны attention residuals. Это уже не столько про ускорение, сколько про улучшение передачи информации между слоями. Residual-связи соединяются между слоями, а их вклад определяется через attention score. По отчёту, это немного, но стабильно улучшает validation loss и downstream performance, ценой примерно +4% к обучению и +2% к инференсу.
Ещё один необычный момент — в Kimi K3 вообще нет RoPE. Модель полностью использует NoPE, то есть обходится без positional embeddings. Для frontier-модели это довольно редкий подход.
Ну и K3 теперь нативно мультимодальная.
В целом архитектура выглядит сложной, но почти все изменения хорошо укладываются в одну идею: масштабировать модель до безумных размеров, не превращая инференс в полный кошмар.
Новое исследование Meta и CMU про agentic context management для long-horizon задач.
Стоит сохранить.
Продакшен-агенты накапливают всё больше контекста с каждым шагом. Обычно проблему решают через сжатие по порогу токенов, отбрасывая остальное. Из-за этого компрессия может сработать в момент, который вообще не связан с текущей задачей агента.
В ACM агенту дают отдельные инструменты для управления контекстом. Он сам решает, когда что-то сжать, переносит отброшенные детали во внешнее хранилище памяти и позже запрашивает их обратно, если они снова понадобятся. По сути, информация переезжает из краткосрочного контекста в долгосрочную память.
Авторы также построили post-training pipeline на качественных демонстрациях управления контекстом. Это дало 27% относительного прироста на BrowseComp-Plus и позволило приблизиться к open-source моделям, которые примерно в 40 раз крупнее.
Лучшее управление контекстом снижает пиковое потребление токенов, позволяет агенту дольше исследовать задачу до упора в контекстное окно и делает результаты стабильнее между независимыми запусками одной и той же задачи.
Код, данные и чекпоинты опубликованы.
Paper: https://arxiv.org/abs/2607.23809
Стоит сохранить.
Продакшен-агенты накапливают всё больше контекста с каждым шагом. Обычно проблему решают через сжатие по порогу токенов, отбрасывая остальное. Из-за этого компрессия может сработать в момент, который вообще не связан с текущей задачей агента.
В ACM агенту дают отдельные инструменты для управления контекстом. Он сам решает, когда что-то сжать, переносит отброшенные детали во внешнее хранилище памяти и позже запрашивает их обратно, если они снова понадобятся. По сути, информация переезжает из краткосрочного контекста в долгосрочную память.
Авторы также построили post-training pipeline на качественных демонстрациях управления контекстом. Это дало 27% относительного прироста на BrowseComp-Plus и позволило приблизиться к open-source моделям, которые примерно в 40 раз крупнее.
Лучшее управление контекстом снижает пиковое потребление токенов, позволяет агенту дольше исследовать задачу до упора в контекстное окно и делает результаты стабильнее между независимыми запусками одной и той же задачи.
Код, данные и чекпоинты опубликованы.
Paper: https://arxiv.org/abs/2607.23809
Kimi вместе с kvcache-ai открыли исходный код AgentENV.
AgentENV — это распределённая система для масштабного запуска агентных окружений. Её компоненты используются для agentic RL-тренировки Kimi K3 и поддерживают быстрые snapshot, resume и fork для параллельных агентных воркфлоу в большом масштабе.
AgentENV — это распределённая система для масштабного запуска агентных окружений. Её компоненты используются для agentic RL-тренировки Kimi K3 и поддерживают быстрые snapshot, resume и fork для параллельных агентных воркфлоу в большом масштабе.
GitHub
GitHub - kvcache-ai/AgentENV: AgentENV (AENV) is a distributed platform for running agent environments at scale.
AgentENV (AENV) is a distributed platform for running agent environments at scale. - kvcache-ai/AgentENV