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

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

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

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

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

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

Мы продолжаем увлекательное путешествие по миру удалённого доступа. В предыдущей части заглядывали под капот протокола доставки рабочего стола 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), является полной противоположностью тому, что работает в космосе. Если вы раньше не работали конкретно в этой области, я бы предостёрег вас от поспешных выводов, потому что реальность обеспечения функционирования космического оборудования в космосе не всегда интуитивно очевидна.

Разбираемся, как использовать встроенный механизм Google Colab для хостинга сервера без ngrok и cloudflared — и как достучаться до него через requests с помощью токена аутентификации.

Одна ошибка в выборе GPU может стоить двукратной переплаты за каждую задачу — каждый день, пока вы не смените карту. Десять моделей NVIDIA, пять архитектур, разброс памяти от 24 до 288 ГБ. Разбираем, какая карта для чего создана и где рубль работает эффективнее всего.

Мы десятилетиями строим IT-системы, но до сих пор не можем ответить на элементарный вопрос: кто за что платит? Теги есть, аллокация настроена, но в отчетах — хаос. Затраты разбросаны по разным системам (биллинг облака, CMDB, Excel-таблицы у финансистов), и все это приходится собирать вручную перед каждым советом директоров.

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

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

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

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

В предыдущей статье "Облако своими руками для расчета пространственных стержней методом конечных элементов на Node js, React js и Three js" представлен краткий обзор облачного SPA приложения ammonit3d по моделированию пространственных стержневых систем (ферм, балок, рамных и связевых конструкций, опор ЛЭП) методом конечных элементов с численно-аналитическим решением для каждого конечного элемента, в основе которого математическая модель Эйлера-Бернулли - механическая модель упругой балки или стержня длиной L с заданной изгибной жёсткостью EJ на которую действуют сосредоточенная сила F или момент M, а также распределённая сила q(x) или момент m(x) по длине стержня, продольная ось которого x1, вертикальная x2 проходит через начало стержня и x3 направлена на нас из точки пересечения x1, x2. Полагая сечения плоскими до и после изгиба при одноосном деформированном состоянии в рамках краевой задачи линейной теории упругости, уравнение упругой оси стержня можно представить в виде обыкновенного неоднородного дифференциального уравнения 4-го порядка:

Два крупнейших API-провайдера одновременно сменили риторику. Anthropic ввёл usage-based billing для агентных фреймворков — плата за токены вместо фиксированных подписок. Часть сторонних обёрток потеряла возможность работать через flat-rate тарифы. OpenAI параллельно ввёл гибкое корпоративное ценообразование для Enterprise, Business и EDU-планов — стоимость подписки теперь масштабируется с объёмом потребления, а не фиксируется на уровне seat.

Тренд последних двух лет («API дешевеет каждый квартал») не отменился, но получил важную оговорку. Цена за токен в прайсах действительно падала: за 2023–2025 годы стоимость миллиона токенов GPT-4-класса снижалась, но в 2026 году ключевой метрикой для бюджета становится не цена за токен, а стоимость решения задачи.

Привет, Хабр! На связи команда Рег.облака. 16 апреля мы провели свой Демо день — продуктовую конференцию для тех, кто строит IT-инфраструктуру и хочет делать это без лишних расходов. Два параллельных трека, панельная дискуссия про ИИ с «ВкусВиллом», банком «Синара», Raft и РБК, а вечером — нетворкинг с живой музыкой в Центре событий РБК. Для тех, кто пропустил, рассказываем, что обсуждали и к чему пришли.

Есть такая штука: чем больше компания тратит на инфраструктуру, тем меньше она понимает, куда уходят деньги. Казалось бы, парадокс. Но если посмотреть на то, как устроено управление ИТ-бюджетом в большинстве организаций, всё встаёт на свои места. Потому что считать научились, а управлять — пока нет. И проблема тут не в инструментах. Их-то как раз навалом. Проблема в том, что финансы, инженеры и бизнес до сих пор живут в параллельных реальностях и разговаривают на разных языках. А FinOps — это, по сути, попытка эти реальности склеить. Насколько успешная — вопрос открытый.

Вместе с Виталием Глушаковым мы решили разобрать, как это работает (или не работает, пусть будет сюрприз) на практике. Виталий имеет большой опыт управления и FinOps-трансформации отделов разработки и уже опубликовал свою часть на LinkedIn — «FinOps: 5 шагов к зрелости». Обязательно почитайте, там много интересного. А мы, со своей стороны, дополняем каждый тезис практическим контекстом, потому что между тем, как должно быть и как оно бывает на самом деле, иногда помещается целая пропасть.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

У AI-индустрии есть серьезная проблема: как развернуть вычислительную инфраструктуру раньше и быстрее (да еще и дешевле) конкурентов? Основной дефицитный ресурс сейчас — электричество, а не чипы или их компоненты, как вы могли предположить. Техногиганты думают, где поставить стойки, чем их охлаждать, но главное, где взять энергию, чтобы питать всю AI-систему.

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

Сегодня я расскажу вам о компании Crusoe —  которая крайне нестандартно превращает энергию в вычислительную мощность. Разберем их бизнес-модель и поймем, что такое вертикально интегрированная AI-инфраструктура.

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

| Если вам интересна тема AI-агентов и внедрения нейросетей, заглядывайте в мой Telegram-канал ДругОпенсурса. Там я публикую свежие новости и разборы инструментов в числе первых. |

В данной статье (а возможно цикле статей) речь пойдет о собственной разработке облачного SPA приложения по моделированию пространственных стержневых систем методом конечных элементов с численно-аналитическим решением для инженеров-проектировщиков в основе которого математическая модель Эйлера-Бернулли, вариационные принципы и итерационный метод сопряжённых градиентов применяемый для большеразмерных СЛАУ с разреженной матрицей жёсткости с одной стороны, и JavaScripts экосистема облака, выполненного в стеке Node js, Express js бэкенд части, и React js, MobX, Three js, glsl shaders фронтенд части с другой стороны. Отображение эпюр усилий в пространственных стержневых элементах реализовано на шейдерах vertexShader и fragmentShader. Это позволяет вычислять эпюры для каждого стержня на лету и выполнять отображение графиков (в общем случае полиномов 5 степени) в пространстве мгновенно.