ЦОДы на вечной мерзлоте

Я снова с ноутом.
Будет два поста содержательных

За вчера:
1) Залит ноут
2) Сломан наушник
3) Забанен клод

LLM разбойник на месте

Почему

https://arxiv.org/abs/2603.01875

Завтра напишу почему


P.s. FSDP2 мне не очень нравится и все его производные

Астра и сол — лучший релиз closed source. Последний раз ощущения такие же были после 3.5->4o

Больше не разбойник.

(Всего лишь попросил меня нанять)

Я все еще настаиваю на том, что использовать БЯМ в своей повседневной жизни скорее увеличивает производительность труда, чем отупляет.
Да, порой хочется полениться и понадеяться на чудо, что все получится с двух строчного промпта и reasoning effort: max.

Тем не менее, пример для персонализированного обучения собственной мясной нейросети намного круче. Можно не бояться и спрашивать тупые вопросы, уходить в дебри и просить рисовать картинки в голове. По факту личный 3b1b

Кмк, очень интересно и можно настроить под себя в инфре pi. Тем не менее, скиллы верификации и гейтвеи качества (ссылки на реальные статьи и учебники) — мастхев

https://youtu.be/kzcI5F4tGiU?si=5a6bB9r0RSMgUepp

Нишевые экономические релизы

Ждут опенсорс беррилм

На выхах пост

Учим небольшую 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

Пост из отложки. [Часть 2]

И что дальше? Как приложить?

Как мне когда-то говорили: "Чтобы представить 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 становится интересен не как ускоритель одной проверки, а как способ сделать такой уровень наблюдаемости экономически возможным.

Не только проверять то, что мы уже знаем как ошибку.

А замечать, когда данные перестали быть похожими на самих себя.

Пост из отложки. [Часть 1]

Как сделать 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 — позволить себе гораздо больше паранойи относительно собственных данных.

Самая умная национальная модель РФ - 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.
И там:
[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?

Сегодня пост не про LLM. Но вот вам похихикать

С братиком (https://t.me/max_saprykin05) в цоде

Я не позавтракал