Модели OpenAI взломали сайт Hugging Face с открытым ИИ, чтобы украсть ответы и сжульничать в бенчмарке 🤡
OpenAI рассказала о необычном инциденте во время внутреннего тестирования моделей на кибербезопасность. GPT-5.6 Sol и ещё одна неанонсированная модель, предположительно GPT-6, пытались получить максимальный результат в ExploitGym и в процессе вышли за пределы изолированной среды.
Для теста моделям заранее ослабили защитные ограничения и отключили продакшен-классификаторы. В итоге они нашли zero-day в прокси реестра пакетов OpenAI, повысили свои права, переместились по внутренней инфраструктуре и добрались до машины с доступом в интернет.
Дальше модели предположили, что ответы для ExploitGym могут находиться на Hugging Face. С помощью украденных учётных данных и zero-day уязвимостей - они получили удалённый доступ к серверам Hugging Face и добрались до закрытой информации в продакшен-базе данных.
В OpenAI назвали произошедшее беспрецедентным киберинцидентом.
OpenAI рассказала о необычном инциденте во время внутреннего тестирования моделей на кибербезопасность. GPT-5.6 Sol и ещё одна неанонсированная модель, предположительно GPT-6, пытались получить максимальный результат в ExploitGym и в процессе вышли за пределы изолированной среды.
Для теста моделям заранее ослабили защитные ограничения и отключили продакшен-классификаторы. В итоге они нашли zero-day в прокси реестра пакетов OpenAI, повысили свои права, переместились по внутренней инфраструктуре и добрались до машины с доступом в интернет.
Дальше модели предположили, что ответы для ExploitGym могут находиться на Hugging Face. С помощью украденных учётных данных и zero-day уязвимостей - они получили удалённый доступ к серверам Hugging Face и добрались до закрытой информации в продакшен-базе данных.
В OpenAI назвали произошедшее беспрецедентным киберинцидентом.
Please open Telegram to view this post
VIEW IN TELEGRAM
NVIDIA Blackwell Ultra установила мировой рекорд по производительности при предобучении DeepSeek-V3 с 671 млрд параметров, достигнув 1 648 TFLOPS на один GPU.
Это примерно втрое выше ранее достигнутой производительности предыдущего поколения. Результат стал возможен благодаря глубокой совместной оптимизации аппаратной и программной частей, а также постоянному улучшению ПО в популярных фреймворках, включая Megatron-Core, TorchTitan и JAX.
Это примерно втрое выше ранее достигнутой производительности предыдущего поколения. Результат стал возможен благодаря глубокой совместной оптимизации аппаратной и программной частей, а также постоянному улучшению ПО в популярных фреймворках, включая Megatron-Core, TorchTitan и JAX.
Методы квантования LLM, которые я бы изучил, если бы мне нужно было запустить модель 70B на одной GPU:
(сохраните в закладки)
Модель 70B в FP16 требует около 140 ГБ только под веса.
В 4-битном формате этот объём уменьшается до 35 ГБ, что уже помещается на одну видеокарту.
Но простое округление значений не работает для больших моделей. Примерно 0,1% скрытых размерностей содержат значения, которые могут быть до 20 раз больше, чем остальные значения в тензоре, и они ломают квантовочную сетку для всех остальных параметров.
Каждый из этих 5 методов решает проблему выбросов на разном этапе:
1. RTN (Round-To-Nearest)
Игнорирует проблему.
Каждый вес просто округляется до ближайшего уровня квантования без использования калибровочных данных.
Самый дешёвый вариант, но самый слабый при низкой разрядности.
2. GPTQ
Исправляет последствия округления.
Квантует слой за слоем, столбец за столбцом, и после каждого шага корректирует оставшиеся веса, чтобы компенсировать возникшую ошибку, прежде чем перейти дальше.
3. AWQ (Activation-aware Weight Quantization)
Защищает важные веса до округления.
Находит примерно 1% каналов весов, которые оказывают наибольшее влияние, и масштабирует их так, чтобы они лучше переживали квантование.
При этом итоговая модель всё равно полностью работает в обычном INT4.
4. LLM.int8()
Изолирует выбросы во время инференса.
Размерности с выбросами выполняются в FP16, а остальные 99,9% параметров работают в INT8. Затем результаты объединяются.
5. QAT (Quantization-Aware Training)
Решает проблему ещё во время обучения.
Модель дообучается с учётом квантования: округление встроено в каждый forward pass, поэтому модель заранее адаптируется к возникающим потерям до фактического применения квантования.
Все пять методов создают один и тот же результат — модель, работающую с меньшей точностью представления по сравнению с исходной обученной версией.
Разница только в том, на каком этапе решается проблема выбросов.
Визуализация ниже хорошо суммирует эти подходы.
Есть отличная статья с подробным исследованием методов квантования LLM:
https://arxiv.org/abs/2411.02530
(сохраните в закладки)
Модель 70B в FP16 требует около 140 ГБ только под веса.
В 4-битном формате этот объём уменьшается до 35 ГБ, что уже помещается на одну видеокарту.
Но простое округление значений не работает для больших моделей. Примерно 0,1% скрытых размерностей содержат значения, которые могут быть до 20 раз больше, чем остальные значения в тензоре, и они ломают квантовочную сетку для всех остальных параметров.
Каждый из этих 5 методов решает проблему выбросов на разном этапе:
1. RTN (Round-To-Nearest)
Игнорирует проблему.
Каждый вес просто округляется до ближайшего уровня квантования без использования калибровочных данных.
Самый дешёвый вариант, но самый слабый при низкой разрядности.
2. GPTQ
Исправляет последствия округления.
Квантует слой за слоем, столбец за столбцом, и после каждого шага корректирует оставшиеся веса, чтобы компенсировать возникшую ошибку, прежде чем перейти дальше.
3. AWQ (Activation-aware Weight Quantization)
Защищает важные веса до округления.
Находит примерно 1% каналов весов, которые оказывают наибольшее влияние, и масштабирует их так, чтобы они лучше переживали квантование.
При этом итоговая модель всё равно полностью работает в обычном INT4.
4. LLM.int8()
Изолирует выбросы во время инференса.
Размерности с выбросами выполняются в FP16, а остальные 99,9% параметров работают в INT8. Затем результаты объединяются.
5. QAT (Quantization-Aware Training)
Решает проблему ещё во время обучения.
Модель дообучается с учётом квантования: округление встроено в каждый forward pass, поэтому модель заранее адаптируется к возникающим потерям до фактического применения квантования.
Все пять методов создают один и тот же результат — модель, работающую с меньшей точностью представления по сравнению с исходной обученной версией.
Разница только в том, на каком этапе решается проблема выбросов.
Визуализация ниже хорошо суммирует эти подходы.
Есть отличная статья с подробным исследованием методов квантования LLM:
https://arxiv.org/abs/2411.02530
This media is not supported in your browser
VIEW IN TELEGRAM
Kimi снова это сделали!
В Kimi K3 они разработали новый подход к работе с residual connections (остаточными связями) в Transformer-архитектурах — механизмом, который практически не менялся со времён ResNet в 2015 году.
В стандартном Transformer каждый слой добавляет свой выход обратно к входу с фиксированным весом 1.
То есть каждый слой получает одинаковую важность независимо от того, что именно нужно конкретному токену.
При глубине в 40, 60, 80+ слоёв скрытое состояние превращается в сумму всех предыдущих представлений с одинаковыми весами.
Более глубоким слоям приходится создавать всё более крупные выходные значения, чтобы хоть как-то влиять на итоговое представление. При масштабировании моделей это делает обучение менее стабильным.
Attention Residuals решают эту проблему, заменяя фиксированное сложение на softmax attention по глубине сети.
Теперь каждый слой сам учится определять, сколько информации брать из каждого предыдущего слоя — в зависимости от входа. Благодаря этому разные токены могут извлекать разные представления из разных слоёв, ориентируясь на то, что действительно полезно.
Идея повторяет то, что оригинальный Transformer сделал с последовательностями.
RNN сжимали всю предыдущую информацию о токенах в одно состояние, которое передавалось по времени. Transformer заменил это механизмом attention. Attention Residuals применяют ту же идею, но уже к глубине модели.
Когда Kimi впервые проверили этот подход на своей модели Kimi Linear 48B в марте, Block AttnRes показал такую же производительность, как базовая модель, обученная с в 1,25 раза большим количеством вычислений, при этом добавив менее 2% задержки на инференсе.
Kimi K3 стала первой моделью, где этот подход применяется в масштабе фронтирной модели: 2,8 трлн параметров, вместе с Kimi Delta Attention, который обеспечивает до 6,3× более быстрое декодирование при работе с контекстом размером в миллион токенов.
API уже доступен, а веса модели будут опубликованы 27 июля.
В Kimi K3 они разработали новый подход к работе с residual connections (остаточными связями) в Transformer-архитектурах — механизмом, который практически не менялся со времён ResNet в 2015 году.
В стандартном Transformer каждый слой добавляет свой выход обратно к входу с фиксированным весом 1.
То есть каждый слой получает одинаковую важность независимо от того, что именно нужно конкретному токену.
При глубине в 40, 60, 80+ слоёв скрытое состояние превращается в сумму всех предыдущих представлений с одинаковыми весами.
Более глубоким слоям приходится создавать всё более крупные выходные значения, чтобы хоть как-то влиять на итоговое представление. При масштабировании моделей это делает обучение менее стабильным.
Attention Residuals решают эту проблему, заменяя фиксированное сложение на softmax attention по глубине сети.
Теперь каждый слой сам учится определять, сколько информации брать из каждого предыдущего слоя — в зависимости от входа. Благодаря этому разные токены могут извлекать разные представления из разных слоёв, ориентируясь на то, что действительно полезно.
Идея повторяет то, что оригинальный Transformer сделал с последовательностями.
RNN сжимали всю предыдущую информацию о токенах в одно состояние, которое передавалось по времени. Transformer заменил это механизмом attention. Attention Residuals применяют ту же идею, но уже к глубине модели.
Когда Kimi впервые проверили этот подход на своей модели Kimi Linear 48B в марте, Block AttnRes показал такую же производительность, как базовая модель, обученная с в 1,25 раза большим количеством вычислений, при этом добавив менее 2% задержки на инференсе.
Kimi K3 стала первой моделью, где этот подход применяется в масштабе фронтирной модели: 2,8 трлн параметров, вместе с Kimi Delta Attention, который обеспечивает до 6,3× более быстрое декодирование при работе с контекстом размером в миллион токенов.
API уже доступен, а веса модели будут опубликованы 27 июля.
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