Forwarded from БЕЗРАБОТНЫЙ NEWS
Самая умная национальная модель РФ - GLM 4.7
Помните BerryLM-XL от Wildberries, которая в «независимом» MERA превзошла GPT?
Какие-то совершенно случайные совпадения
BerryLM-XL:
— 358 млрд параметров
— MoE
— FP8
— контекст ~202K
— reasoning
— генерация до ~120K токенов
GLM-4.7 от китайской Z.ai:
— 358 млрд параметров
— MoE
— FP8
— 202 752 токена контекста
— reasoning
— до 128K генерации
Ну ладно, характеристики могли случайно совпасть.
Но MERA ещё и выложила chat template BerryLM.
И там:
Плюс тот же формат tool calls:
То есть практически тот же самый отпечаток GLM-4.7.
Но нет-нет, конечно.
Wildberries просто независимо создал с нуля модель ровно на 358 млрд параметров, с тем же контекстом, той же архитектурой, теми же специальными токенами и тем же форматом вызова инструментов.
Кстати, БигТех: WB, Сбер, Мтс: вы там когда обгоняли GPT, 17.04.2026, забыли "права" сайт обновить: сейчас не 2025. Может еще рейтинг обновите до gpt-5.5 или сразу 5.6?
Помните BerryLM-XL от Wildberries, которая в «независимом» MERA превзошла GPT?
Какие-то совершенно случайные совпадения
BerryLM-XL:
— 358 млрд параметров
— MoE
— FP8
— контекст ~202K
— reasoning
— генерация до ~120K токенов
GLM-4.7 от китайской Z.ai:
— 358 млрд параметров
— MoE
— FP8
— 202 752 токена контекста
— reasoning
— до 128K генерации
Ну ладно, характеристики могли случайно совпасть.
Но MERA ещё и выложила chat template BerryLM.
И там:
[gMASK]<sop><|system|><|user|><|assistant|><|observation|>Плюс тот же формат tool calls:
<tool_call><arg_key><arg_value>То есть практически тот же самый отпечаток GLM-4.7.
Wildberries просто независимо создал с нуля модель ровно на 358 млрд параметров, с тем же контекстом, той же архитектурой, теми же специальными токенами и тем же форматом вызова инструментов.
Кстати, БигТех: WB, Сбер, Мтс: вы там когда обгоняли GPT, 17.04.2026, забыли "права" сайт обновить: сейчас не 2025. Может еще рейтинг обновите до gpt-5.5 или сразу 5.6?
huggingface.co
Vtmpas/BerryLM · Hugging Face
We’re on a journey to advance and democratize artificial intelligence through open source and open science.
Пост из отложки. [Часть 1]
Как сделать ROI на GPU, если ты GPU-poor и LLM тебе не нужны
Когда говорят про данные, часто вспоминают «мусор на входе — мусор на выходе». А дальше обычно два сценария: либо «давайте прикрутим технологию покруче, и всё починится», либо игрушечный Data Quality из NOT NULL, UNIQUE и пары range checks.
В реальном enterprise всё может быть сложнее. Есть клики, SAP, CRM, MES, телеметрия, старые DWH, Excel и интеграции, которые пережили людей, их написавших. И самые неприятные проблемы не обязательно выглядят как
И вот здесь мне интересен GPU за пределами очевидного «давайте крутить LLM».
GPU — это прежде всего большой объём параллельного compute. И structured data умеет использовать его напрямую: [cuDF](https://docs.rapids.ai/api/cudf/stable/) делает на GPU привычные DataFrame operations, а [RAPIDS Accelerator for Apache Spark](https://docs.nvidia.com/spark-rapids/) переносит поддерживаемые Spark SQL и DataFrame workloads на GPU.
Для задач качества данных это важно не потому, что IS NULL внезапно нужно считать на видеокарте. Интереснее другое: дополнительный compute позволяет считать больше свойств данных и делать это чаще.
Можно постоянно пересчитывать codedistributions, quantiles, cardinality, missingness, correlations, categorical combinations и другие статистики — не только по таблице целиком, но и по
И тут compute довольно прямо превращается в business value. Он работает не только на один DQ job, а на весь поток:
Меньше времени на тяжёлую обработку, больше проверяемых гипотез, раньше замеченные проблемы и меньше мусора, который доезжает до аналитики и моделей.
На этом фоне идея прогонять сырые табличные данные через LLM выглядит не всегда оптимальной. Если задача сводится к groupby, статистике и anomaly detection; очистке и статистическому анадизу, разумнее сначала потратить GPU непосредственно на эти вычисления. А LLM оставить на последний километр — например, объяснить аналитику, почему уже найденная аномалия выглядит подозрительно.
Не «GPU вместо LLM», а более приземлённая идея: использовать дорогой compute там, где он максимально прямо превращается в полезный сигнал.
Возможно, одно из самых интересных применений GPU в enterprise — позволить себе гораздо больше паранойи относительно собственных данных.
Как сделать ROI на GPU, если ты GPU-poor и LLM тебе не нужны
Когда говорят про данные, часто вспоминают «мусор на входе — мусор на выходе». А дальше обычно два сценария: либо «давайте прикрутим технологию покруче, и всё починится», либо игрушечный Data Quality из NOT NULL, UNIQUE и пары range checks.
В реальном enterprise всё может быть сложнее. Есть клики, SAP, CRM, MES, телеметрия, старые DWH, Excel и интеграции, которые пережили людей, их написавших. И самые неприятные проблемы не обязательно выглядят как
age < 0. Данные могут оставаться формально валидными, но начать вести себя иначе: schema на месте, NULL'ов нет, объём тот же, pipeline зелёный — а после обновления firmware изменился смысл сигнала, съехал mapping или старый join начал соединять немного не то.И вот здесь мне интересен GPU за пределами очевидного «давайте крутить LLM».
GPU — это прежде всего большой объём параллельного compute. И structured data умеет использовать его напрямую: [cuDF](https://docs.rapids.ai/api/cudf/stable/) делает на GPU привычные DataFrame operations, а [RAPIDS Accelerator for Apache Spark](https://docs.nvidia.com/spark-rapids/) переносит поддерживаемые Spark SQL и DataFrame workloads на GPU.
Для задач качества данных это важно не потому, что IS NULL внезапно нужно считать на видеокарте. Интереснее другое: дополнительный compute позволяет считать больше свойств данных и делать это чаще.
Можно постоянно пересчитывать codedistributions, quantiles, cardinality, missingness, correlations, categorical combinations и другие статистики — не только по таблице целиком, но и по
plant × machine × product × shift × operating mode.И тут compute довольно прямо превращается в business value. Он работает не только на один DQ job, а на весь поток:
processing → profiling → DQ → feature engineering → MLМеньше времени на тяжёлую обработку, больше проверяемых гипотез, раньше замеченные проблемы и меньше мусора, который доезжает до аналитики и моделей.
На этом фоне идея прогонять сырые табличные данные через LLM выглядит не всегда оптимальной. Если задача сводится к groupby, статистике и anomaly detection; очистке и статистическому анадизу, разумнее сначала потратить GPU непосредственно на эти вычисления. А LLM оставить на последний километр — например, объяснить аналитику, почему уже найденная аномалия выглядит подозрительно.
Не «GPU вместо LLM», а более приземлённая идея: использовать дорогой compute там, где он максимально прямо превращается в полезный сигнал.
Возможно, одно из самых интересных применений GPU в enterprise — позволить себе гораздо больше паранойи относительно собственных данных.
Пост из отложки. [Часть 2]
И что дальше? Как приложить?
Классический Data Quality отвечает на вопрос: «как данные могут сломаться?» Мы заранее придумываем правила — schema, ranges, uniqueness, freshness, business constraints — и ждём их нарушения.
Но часть неприятных проблем устроена иначе. Данные проходят все проверки и при этом начинают вести себя не так, как раньше.
Допустим, температурный датчик на заводе продолжает стабильно присылать данные. Schema не изменилась, NULL'ов нет, значения в допустимом диапазоне, частота сообщений нормальная. Но исторически температура хорошо коррелировала с нагрузкой оборудования, а сегодня эта связь внезапно исчезла.
Причина может быть в firmware, mapping, единицах измерения, upstream join или изменении самого процесса. Формально данные валидны. Поведенчески — произошло что.-то странное.
Если compute достаточно много, можно попробовать строить Data Quality не только вокруг заранее известных failure modes, но и вокруг fingerprint нормального поведения данных.
Для каждой таблицы, партиции, машины, сенсора или завода можно отслеживать распределения, частоты, missingness patterns, correlations, сезонность и связи между признаками. А затем искать отклонения от собственной истории этой сущности.
Получается:
Здесь есть интересная аналогия с [NVIDIA Morpheus Digital Fingerprinting](https://docs.nvidia.com/morpheus/developer_guide/guides/5_digital_fingerprinting.html). Morpheus — cybersecurity framework, не Data Quality продукт. Но его подход похож: строится профиль нормального поведения пользователя, аккаунта, сервиса или машины, после чего новые события получают anomaly score.
Из этого паттерна для DQ мне нравятся три идеи:
• Не нужно заранее знать все способы поломки. Можно искать само изменение поведения.
• Baseline должен быть контекстным. Нормальное для одного завода, сенсора или типа оборудования может быть аномалией для другого.
• Detection и explanation можно разделить. Массовую обработку и anomaly scoring делать специализированными вычислениями, а LLM подключать уже после — для объяснения, triage и работы с человеком.
При большом числе источников и срезов быстро начинается combinatorial explosion. plant × machine × product × shift × supplier × operating mode превращает сотню ручных проверок в десятки тысяч потенциальных сигналов.
И вот здесь GPU становится интересен не как ускоритель одной проверки, а как способ сделать такой уровень наблюдаемости экономически возможным.
Не только проверять то, что мы уже знаем как ошибку.
А замечать, когда данные перестали быть похожими на самих себя.
И что дальше? Как приложить?
Как мне когда-то говорили: "Чтобы представить 5-мерное пространство, то закройте глаза и представьте трехмерное, а затем громко и уверенно скажите: "ПЯТЬ!""
Так и тут. Датчик температуры замените на любой статистически значимый показатель, который отслеживается
Классический Data Quality отвечает на вопрос: «как данные могут сломаться?» Мы заранее придумываем правила — schema, ranges, uniqueness, freshness, business constraints — и ждём их нарушения.
Но часть неприятных проблем устроена иначе. Данные проходят все проверки и при этом начинают вести себя не так, как раньше.
Допустим, температурный датчик на заводе продолжает стабильно присылать данные. Schema не изменилась, NULL'ов нет, значения в допустимом диапазоне, частота сообщений нормальная. Но исторически температура хорошо коррелировала с нагрузкой оборудования, а сегодня эта связь внезапно исчезла.
Причина может быть в firmware, mapping, единицах измерения, upstream join или изменении самого процесса. Формально данные валидны. Поведенчески — произошло что.-то странное.
Если compute достаточно много, можно попробовать строить Data Quality не только вокруг заранее известных failure modes, но и вокруг fingerprint нормального поведения данных.
Для каждой таблицы, партиции, машины, сенсора или завода можно отслеживать распределения, частоты, missingness patterns, correlations, сезонность и связи между признаками. А затем искать отклонения от собственной истории этой сущности.
Получается:
table / source / sensor → normal behavior → deviation → investigateЗдесь есть интересная аналогия с [NVIDIA Morpheus Digital Fingerprinting](https://docs.nvidia.com/morpheus/developer_guide/guides/5_digital_fingerprinting.html). Morpheus — cybersecurity framework, не Data Quality продукт. Но его подход похож: строится профиль нормального поведения пользователя, аккаунта, сервиса или машины, после чего новые события получают anomaly score.
Из этого паттерна для DQ мне нравятся три идеи:
• Не нужно заранее знать все способы поломки. Можно искать само изменение поведения.
• Baseline должен быть контекстным. Нормальное для одного завода, сенсора или типа оборудования может быть аномалией для другого.
• Detection и explanation можно разделить. Массовую обработку и anomaly scoring делать специализированными вычислениями, а LLM подключать уже после — для объяснения, triage и работы с человеком.
При большом числе источников и срезов быстро начинается combinatorial explosion. plant × machine × product × shift × supplier × operating mode превращает сотню ручных проверок в десятки тысяч потенциальных сигналов.
И вот здесь GPU становится интересен не как ускоритель одной проверки, а как способ сделать такой уровень наблюдаемости экономически возможным.
Не только проверять то, что мы уже знаем как ошибку.
А замечать, когда данные перестали быть похожими на самих себя.
Forwarded from RWB делает ML
Учим небольшую LLM с нуля: гибридное внимание, XSA, доменные бленды и загадки роста онлайн-бенчмарков
Команда обучения и инференса RWB обучила текстовую версию Qwen3.5-2B с нуля — без pretrained-весов. В статье разбираем весь путь: от сборки доменных датасетов и Megatron-LM до online-оценки и экспериментов с архитектурой👆
Хайлайты:
⏹️ обучили модель сначала на 1, затем на 11 трлн токенов
⏹️ протестировали XSA и получили −0,009 val loss и +1,6 п. п. на MMLU
⏹️ разобрались, почему MMLU в разных форматах показывает совершенно разную динамику
⏹️ проверили, как меняется качество при разных доменных блендах
⏹️ нашли слабое место модели — математику и reasoning
А ещё рассказали, как устроен наш pretrain-пайплайн и какие эксперименты планируем дальше.
➡️ Узнать больше
@rwb_delaet_ml
Команда обучения и инференса RWB обучила текстовую версию Qwen3.5-2B с нуля — без pretrained-весов. В статье разбираем весь путь: от сборки доменных датасетов и Megatron-LM до online-оценки и экспериментов с архитектурой
Хайлайты:
А ещё рассказали, как устроен наш pretrain-пайплайн и какие эксперименты планируем дальше.
@rwb_delaet_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
Я все еще настаиваю на том, что использовать БЯМ в своей повседневной жизни скорее увеличивает производительность труда, чем отупляет.
Да, порой хочется полениться и понадеяться на чудо, что все получится с двух строчного промпта и reasoning effort: max.
Тем не менее, пример для персонализированного обучения собственной мясной нейросети намного круче. Можно не бояться и спрашивать тупые вопросы, уходить в дебри и просить рисовать картинки в голове. По факту личный 3b1b
Кмк, очень интересно и можно настроить под себя в инфре pi. Тем не менее, скиллы верификации и гейтвеи качества (ссылки на реальные статьи и учебники) — мастхев
https://youtu.be/kzcI5F4tGiU?si=5a6bB9r0RSMgUepp
Да, порой хочется полениться и понадеяться на чудо, что все получится с двух строчного промпта и reasoning effort: max.
Тем не менее, пример для персонализированного обучения собственной мясной нейросети намного круче. Можно не бояться и спрашивать тупые вопросы, уходить в дебри и просить рисовать картинки в голове. По факту личный 3b1b
Кмк, очень интересно и можно настроить под себя в инфре pi. Тем не менее, скиллы верификации и гейтвеи качества (ссылки на реальные статьи и учебники) — мастхев
https://youtu.be/kzcI5F4tGiU?si=5a6bB9r0RSMgUepp
YouTube
How I Use AI to Learn Things
My current approach to learning with AI.
Repo: https://github.com/amosblomqvist/learn
0:00 Intro
0:25 How we're used to learning
0:55 One teaches many
1:42 One learns from many
3:08 One-to-one
4:22 The approach
5:13 The process
8:01 Demo
10:12 Probe
12:07…
Repo: https://github.com/amosblomqvist/learn
0:00 Intro
0:25 How we're used to learning
0:55 One teaches many
1:42 One learns from many
3:08 One-to-one
4:22 The approach
5:13 The process
8:01 Demo
10:12 Probe
12:07…
This media is not supported in your browser
VIEW IN TELEGRAM
Астра и сол — лучший релиз closed source. Последний раз ощущения такие же были после 3.5->4o
This media is not supported in your browser
VIEW IN TELEGRAM
https://arxiv.org/abs/2603.01875
Завтра напишу почему
P.s. FSDP2 мне не очень нравится и все его производные
Завтра напишу почему
P.s. FSDP2 мне не очень нравится и все его производные