Облачные вычисления *

Бизнес нацелился делать свой собственный AI. Все задают вопрос: «Какая модель мне нужна?» Но никто не задумывается, на каких мощностях модель будет работать. 

Мы тоже сначала не задумывались. Разработали корпоративного AI-агента, прокачали ИТ-команду, чтобы двигаться дальше — и споткнулись о «железный порог». Так родилась идея AI ready модуля. В статье рассказали, что это такое и почему AI начинается не с модели, а с инфраструктуры. 

2,5 км оптики — в земле, генплан на 24 МВт — утверждён. Май в Марфино был про связь и масштаб: показываем, как преобразилась площадка.

...или Протокол SPICE в современном графическом стеке, часть 3.

Мы продолжаем увлекательное путешествие по миру удалённого доступа. Это третья часть цикла про протокол доставки рабочего стола SPICE и то, как он вынужден работать в современных условиях.

Наша конечная цель - создать пилот стримингового агента для виртуальной машины на ОС Windows. В предыдущих двух частях рассматривали архитектуры самого протокола и графической подсистемы Windows, а сегодня мы готовим плацдарм в вопросах захвата экрана в Windows и сжатия видео средствами различных библиотек, фреймворков и API. С кодом и компактными пояснениями.

Приглашаю под кат всех любознательных - в особенности тех, кто сталкивается с Windows не только как пользователь; с решениями для удалённого доступа; с протоколом SPICE; с системами виртуализации и виртуальными машинами в принципе.

Я из Воркуты. Несколько лет изучаю возможность строительства здесь крупного вычислительного центра для ИИ-задач. Каждый раз, когда я рассказываю об этом, слышу одни и те же шесть возражений. Все они звучат убедительно. Ни одно не выдерживает проверки фактами.

S3-совместимые хранилища предоставляют бизнесу и ИТ-специалистам широкий набор инструментов для работы с данными. Это и практически бесконечная масштабируемость, позволяющая хранить петабайты информации без сложной настройки, и высокая надежность за счет автоматического резервирования, и гибкое управление доступом для разных команд и сервисов. Наряду с ними важной и полезной функцией является версионирование бакетов, которое позволяет хранить полную историю изменений каждого объекта и защищает от потери данных.

Но чтобы раскрыть весь потенциал этой функции и грамотно встроить ее в рабочие процессы, важно понимать, как она устроена. 

В этой статье разберем, что такое версионирование бакетов в S3, как оно меняет логику работы хранилища и как использовать его для решения реальных задач.

Привет, постоянные и не очень читатели!

Всего одна сделка (зато какая — на 61 000 000 000 $) неплохо так встряхнула мир виртуализации и IT в целом: Broadcom купила VMware, упразднила кучу SKU и ввела подписную модель лицензирования крупными пакетами (многие оплачивают то, что им и не нужно вовсе, так как пакетов меньше просто нет). Самое плохое, что ни партнёры, ни конечные клиенты не были готовы к такому повороту событий и сопутствующему ущербу, а потому до сих пор оправляются.

Вариантов, как все выкручиваются, много, а довольных новой моделью VMware by Broadcom — мало. Если у вас тоже наболело или вы просто зашли поглядеть на ещё один способ сложить (или нет?) все виртуалки в одну проприетарную корзину Huawei Cloud Stack, то эта серия статей для вас.

С ростом сложности рабочих нагрузок инференса больших языковых моделей (LLM) единый монолитный процесс обслуживания упирается в свои пределы. У префилла и декодирования принципиально разные профили вычислений, но традиционные развёртывания заставляют их работать на одном оборудовании. В итоге GPU недозагружены, а масштабирование — негибкое.

Дезагрегированный инференс решает эту проблему: разбивает конвейер на отдельные этапы — префилл, декодирование и маршрутизацию. Каждый этап работает как независимый сервис, который можно обеспечивать ресурсами и масштабировать на собственных условиях.

Команда VK Cloud перевела статью, в которой разбирается, как развернуть дезагрегированный инференс в Kubernetes. Здесь мы посмотрим на разные решения экосистемы, как они работают в кластере и что дают «из коробки».

Привет, Хабр!

Уже больше 10 лет я работаю с виртуализацией, и за это время успел в разной степени потрогать самые разные платформы. Естественно, до 2022 года это была в большей степени VMware, а параллельно с ней и разный опенсорс, в последние же годы руки добрались и до некоторых наших платформ. 

Вообще идея этой статьи у меня зародилась после первых волн санкций, но, видимо, тогда ее время еще не пришло — ничего было непонятно, но очень интересно.

Спустя 4 года российские платформы заметно подросли, обзавелись пользователями и вменяемыми кейсами. С другой стороны, сама по себе тема виртуализации успела обрасти определенным слоем маркетинга и разнообразными мифами.

Зачем я пишу эту статью?

Мне уже давно хочется разобраться, как сейчас обстоят дела с безопасностью виртуализации в разрезе наиболее используемых в РФ платформ — как отечественных, так и не очень. Наверное, в глубине души мне хочется как-то суммировать то, что я сам увидел и осмыслил за это время, и ответить на ряд вопросов — действительно ли так страшно оставаться на иностранных платформах, как об этом говорят, и как обстоят дела у российских вендоров.

Если эта статья кому-то поможет — буду очень рад.

В проектах с компьютерным зрением есть неприятная правда: почти все выглядит убедительно, пока не сталкивается с реальной площадкой. На слайдах обычно все просто: камера смотрит, модель распознает, система фиксирует событие. Но в жизни вместо эталонных датасетов появляются снег, дождь, блики, разные ракурсы, подвижные камеры, бюджетные ограничения и обычные промышленные условия, в которых надо получить результат.

Именно с такой задачей к команде разработчиков «Формат кода» пришел заказчик этого проекта. Причем сразу с несколькими сценариями, связанными с компьютерным зрением.

Облако Nubes в этой истории стало средой для тяжелой инженерной работы: хранения видеоданных, подготовки датасетов, предобработки, обучения моделей, оценки метрик и повторных циклов дообучения. Подробнее рассказали в статье. 

На майском HPC User Forum в Остине AMD рассказали о MI430X — ускорителе серии MI400, который позиционируется как инструмент для научных вычислений. Пока индустрия увлечена инференсом и считает токены в секунду на FP4, AMD напомнила, что CFD-код (Computational Fluid Dynamics) не интересует, насколько быстро чип умножает восьмибитные числа.

Привет, Хабр! Меня зовут Сергей Ковалёв, я менеджер выделенных серверов в Selectel. В этой статье мы мысленно «разберем» MI430X и обсудим, насколько новинка подходит для «ядерных расчетов» и машинного обучения. Подробности под катом!

Большие языковые модели требуют огромных объёмов памяти. Например, модель с 8 миллиардами параметров в формате FP16 занимает 24–27 ГБ памяти только для инференса (веса, кэш ключей-значений, буферы). Для полного обучения той же модели нужно уже 84–128 ГБ памяти. Даже с такими методами, как checkpointing активаций или offloading на CPU, требования остаются высокими, особенно для моделей с 70 миллиардами параметров.

Квантизация помогает снизить требования к памяти, уменьшая точность представления весов модели без значительной потери качества. В этой статье разберём основные форматы числовой точности, используемые в квантизации LLM, их особенности и ограничения. Также рассмотрим NF4 — ключевую инновацию из статьи про QLoRA, и разберём, зачем нужны такие методы, как блочная квантизация, двойная квантизация и квантизация по квантилям.

«Кто виноват и что делать?» — эти два вопроса, которые классики русской литературы адресовали обществу, сегодня как никогда актуальны для IT‑директоров и финансовых руководителей. Только «виноват» не конкретный человек, а не оптимально работающая инфраструктура, а ответ на вопрос «что делать?» — внедрять FinOps.

FinOps — это не технология, а организационная методика. Важная часть инструментария для FinOps это правильно построенная информационная система, которая собирает, хранит и дает анализировать данные о расходах и нагрузке. В этой статье мы разберем архитектурное ядро такой системы.

Довольно много компаний при работе в облаке выстраивают катастрофоустойчивость, ориентируясь на условные «лучшие практики»: составляют планы, предусматривают резервные площадки, настраивают репликацию. Вместе с тем во время реальных инцидентов многие сталкиваются с тем, что все предусмотренное не работает или работает не так, как ожидалось: восстановление занимает часы вместо минут, данные теряются в критическом для бизнеса объеме, а команды оказываются не готовы к действиям в условиях стресса.

Причина часто кроется в том, что меры обеспечения катастрофоустойчивости либо обеспечиваются формально («чтобы было»), либо проектируются без учета полного цикла рисков — от технических ограничений до организационной готовности.

В статье разберем, как проектировать решения, которые переживают не отдельные сбои, а крупные аварии.

Мы продолжаем увлекательное путешествие по миру удалённого доступа. В предыдущей части заглядывали под капот протокола доставки рабочего стола SPICE, а сейчас на операционный стол попала великая и ужасная ОС Windows - точнее, её графическая подсистема. Заглянем в её недры и окунёмся в её философию и историю развития. И заодно найдём интересные параллели в Linux.

Это вторая часть цикла про протокол SPICE и то, как он вынужден работать в современных условиях. Наша конечная цель - создать пилот стримингового агента для виртуальной машины на ОС Windows.

Приглашаю под кат всех, кто работает или сталкивается с системами виртуализации, с протоколом SPICE, с виртуальными машинами в принципе; кто интересуется такими темами как удалённый доступ и компьютерная графика; да и вообще всех любознательных!

Вы когда‑нибудь пользовались виртуальной машиной в Linux? Весьма вероятно, что это был QEMU/KVM + SPICE.

Виртуальные машины на spice://localhost:5900 работают достаточно бодро, тогда как подключение по сети может вызвать самые разные эмоции. Причиной тому является специфическая архитектура, которая идёт вразрез с современными диспетчерами среды рабочего стола. И вялая поддержка протокола open‑source сообществом.

Но нас, безбашенных русских инженеров, это нисколько не останавливает! Открываю цикл статей, где мы заглянем внутрь протокола SPICE и графической подсистемы Windows, чтобы провести увлекательный экскурс и разобраться в деталях. После чего создадим пилот нового решения — стриминговый агент для виртуальной машины на ОС Windows.

В первой части мы возьмёмся за сам протокол и увидим, почему SPICE ориентирован на Windows (да, я не шучу). В следующих частях пойдём разбираться в богатствах Windows и в возможностях для нас присосаться подключиться через системное API к потоку фреймов.

Приглашаю под кат всех, кто работает или сталкивается с системами виртуализации, с протоколом SPICE, с виртуальными машинами в принципе; кто интересуется такими темами как удалённый доступ и компьютерная графика; да и вообще всех любознательных.

iceberg и его философия metadata расскажем почему iceberg эффективно выполняет запросы и прост в управлении данными благодаря своей metadata

Контейнерный ЦОД в Марфино пережил первые реальные аварийные отключения, принял первых гостей и обзавёлся соседями — тремя дизельными электростанциями и двумя газопоршневыми установками. Рассказываем, как прошёл апрель.

Модель pay-as-you-go, которую предлагают в облаке, всегда была палкой о двух концах. С одной стороны, история вроде честнее некуда: платишь ровно за то, что заказал. Как в ресторане. Но, с другой, именно она практике нередко приводит к такому перерасходу, что поневоле начинаешь задумываться, а нужно ли нам вообще это облако?

На самом деле чудес не бывает, и я намеренно перевел pay-as-you-go как “платишь за то, что заказал”. Внимание: заказал, а не потребил. Потому что в этом и заключается первая проблема – нет, не облаков, – а тех, кто их использует. Компании регулярно выходят за рамки бюджетов, потому что платят за ресурсы, которыми де-факто не пользуются. Тут и забытые тестовые стенды, и старые проекты, которые продолжают генерировать счета, и простаивающие виртуальные машины с запасом по мощности, и чего только не. В результате до 30% облачного бюджета просто улетает впустую. А у некоторых и того больше. 

Плюс – усложнение архитектуры как таковой. Если раньше одно приложение работало на одном сервере, то теперь они состоят из десятков разных микросервисов, и каждому нужна своя база, свой кэш, своя очередь. А ведь еще есть тестовое окружение, staging, CI/CD и много других английских слов. И за все надо платить. Да, по отдельности вроде копейки. Но когда таких сервисов 100 или 200, сумма выходит приличная. Добавим сюда накладные расходы и получим еще минимум 15-25% к счету. А хотелось бы эти деньги оставить у себя в кармане. О том, как это сделать, сегодня и поговорим.

Когда обсуждают стоимость внедрения генеративного ИИ, разговор часто сводится к цене за токен или цене за арендуемый GPU. Это удобно — одно число. Но в реальном продакшене такая оценка почти всегда обманчива.

Стоимость GenAI-системы — это не только сколько стоит вызвать модель. Это инфраструктура, эксплуатация, безопасность, наблюдаемость, разработка, интеграции, поддержка пользователей и постоянные изменения вокруг моделей. Именно поэтому «мы поднимем open-source модель сами, будет дешевле» часто оказывается правдой только на первом слайде презентации.

Для ясности: я бывший инженер и учёный НАСА с докторской степенью в области космической электроники. Я также проработал в Google 10 лет в различных подразделениях компании, включая YouTube и тот отдел облачных технологий, который отвечал за развёртывание ИИ-ресурсов, поэтому я вполне компетентен высказать своё мнение по этому вопросу.

Краткая версия статьи: это абсолютно ужасная идея, которая действительно не имеет никакого смысла. Для этого есть множество причин, но все они сводятся к тому, что электроника, необходимая для работы центра обработки данных, особенно развёртывающего ИИ-ресурсы на основе графических процессоров (GPU) и тензорных процессоров (TPU), является полной противоположностью тому, что работает в космосе. Если вы раньше не работали конкретно в этой области, я бы предостёрег вас от поспешных выводов, потому что реальность обеспечения функционирования космического оборудования в космосе не всегда интуитивно очевидна.