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

Шесть сервисов, где можно бесплатно получить доступ к Claude, GPT и другим топовым ИИ-моделям без привязки банковской карты. Проверил стартовые кредиты, реальные лимиты, доступные модели и ограничения: от $20 до $100 стартовых кредитов, а в отдельных сервисах — до сотен тысяч токенов и кредитов

В августе в Раздане открылась AI-фабрика Firebird: 6144 ускорителя NVIDIA B200 на 15 МВт, стройка заняла чуть больше полугода. Вторая, Eleveight, работает с июня — 512 B300 в селе Гагарин у Севана. Канал доставки чипов — легальный, американский: меморандум с Трампом, экспортные лицензии, инвестиции CoreWeave. Но главный вопрос — не «как построили», а «для кого»: на своём сайте Firebird обещает открыть 90% мощностей американским компаниям региона. Внутри — разбор обеих фабрик, история канала от VivaTech до визита Вэнса и расчёт, на кого в итоге работают армянские вычисления. Энергетический фундамент и его пределы — во второй статье.

Сейчас очень много обсуждают модель Jev от Typesafe, я решил выложить модель в своем CMF формате для личного использования (License:apache-2.0) которая давно работает на шлюзе

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

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

В Cortiq 0.8.0 один и тот же файл работает на CPU, Apple Metal и Vulkan. На RTX PRO 4000 Blackwell полный локальный путь занял 1,10–1,24 мс.

Ниже — как устроен этот механизм, что получилось в сравнении с Jev и Laya и как запустить модель или добавить свою задачу.

VK Cloud перевела материал о том, как NVIDIA FLARE помогает участникам проекта федеративного обучения работать вместе, даже если у них разные инфраструктуры. Рассказываем, зачем платформе двухуровневая архитектура и как каждая организация сохраняет контроль над своими данными и вычислительными ресурсами. 

Я считаю, что у каждого человека должен быть свой кубернетес, и твёрдо и непоколебимо иду к этой цели. Уже есть кубернетес для татар и кубернетес для любителей эксельки. А сегодня я представляю три новых Кубернетеса, и каждый со своим характером и особенностями.

Сколько вычислительной мощности реально у России, Казахстана и Беларуси — и что из этого доступно CTO прямо сейчас. Прайсы: аренда H100 от 342 ₽/час, серая карта от 2,65 млн ₽; порог, когда выгоднее купить, чем платить за API. Господдержка: 243-ФЗ уже в силе, пакет 71,7 млрд ₽ обсуждается, платный ЦКП — от 208 ₽/час. Казахстан строит ИИ-хаб с NVIDIA; у Беларуси — профицит атомной энергетики и тариф 0,69 ₽/кВт·ч. Шесть выводов с цифрами и первоисточниками.

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

А если чуть отдохнуть?

Пора вспомнить, что до них тоже существовало машинное обучение — и оно вполне умело решать полезные задачи.

Берём телеметрию виртуальных машин, час истории нагрузки и пытаемся предсказать перегрузку за 30 минут до того, как её увидит обычный мониторинг.

Используем классику: временные ряды, численные методы, LSTM и проверка на реальных данных.

И да — это еще работает.

Как раньше: женщины были женщинами, мужчины — мужчинами, колбаса была настоящей, мороженое — вкусным, а каждый юноша писал сам свое ядро линукс.

Команда VK Cloud перевела статью, описывающую три сценария сбоя, которые отличают наличие резервных копий от возможности восстановления, а также рекомендации, следующие из каждого сценария. Каждый сценарий воспроизводим на ноутбуке из указанного выше репозитория стенда, и каждый показанный вывод терминала является реальным выводом терминала, полученным на стенде. 

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

Конкретные инструменты упоминаются там, где они нужны для описания сценария: Velero и CSI snapshot APIs. Они приведены как эталонные реализации, чтобы сделать сценарии более предметными. Описанные отказы и рекомендации применимы к любому инструменту, который выполняет ту же роль.

10 июня 2026 года CISA выпустила директиву BOD 26-04 Prioritizing Security Updates Based on Risk. Новый документ отменяет BOD 19-02 и BOD 22-01 — директиву, которая с 2021 года задавала для федеральных агентств США единые календарные сроки устранения уязвимостей из каталога Known Exploited Vulnerabilities, KEV. Вместо плоского дедлайна новая модель предлагает определять срок по риску конкретного актива.

Для приоритизации CISA учитывает четыре обстоятельства: доступен ли актив публично, есть ли уязвимость в KEV, можно ли автоматизировать её эксплуатацию и к какому техническому эффекту приводит атака. Таблица сроков, как указывает сама CISA, построена с опорой на SSVC. В наиболее срочном случае уязвимость нужно устранить в течение трёх дней и провести первичный forensic triage; в наименее срочном исправление допускается при очередном плановом обновлении системы.

Наиболее неудобный объект для такого подхода — AI-платформа. В её разных слоях слово «устранить» означает принципиально разные действия. В веб-API это может быть обычный патч; в цепочке ML-зависимостей — мажорное обновление фреймворка; в GPU-рантайме — обновление драйвера или прошивки с окном простоя; в инференс-движке — ожидание решения от мейнтейнера либо замена компонента. Для весов модели патча в привычном смысле может не быть вовсе.

Поэтому одинаковый CVSS не означает одинаковый приоритет, срок и способ обработки. В этой статье восемь публичных CVE из типового AI-стека проходят через дерево решений: для каждой записи разберём доступность актива, признаки эксплуатации, автоматизируемость атаки, технический эффект и реальный путь к устранению. Также покажем, как получить пороги для принятия решений из опубликованных данных FIRST.

Материал рассчитан на AppSec- и DevSecOps-инженеров, которые ведут бэклог уязвимостей платформы, и на тимлидов, у которых релиз зависит от открытых security-тикетов. Руководителям ИБ будет полезен отдельный раздел о требованиях ФСТЭК. Подход применим и к обычной инфраструктуре без GPU и моделей: в таком случае меняется набор активов, но не логика приоритизации.

Показано, как из классического вычисления интеграла Гаусса-Пуассона получается еще одна аппроксимирующая формула для этого интеграла

TL;DR. Мы выкатили Татарнетес — национальную обёртку над Kubernetes, где команды, сообщения, ошибки и даже перерывы на чай с чак-чаком и т.п. на татарском. Рядом — TatarOS Linux (обёртка над Talos, которая поднимает кластер с Татарнетесом) и Татарнетес UI (панель на фоне татарского келәма). Всё под собственной лицензией Tatarch 2.0.

Под капотом i18n на чистом bash 3.2 без единой зависимости, три системы письма (кириллица, яңалиф, гарәп язуы), детерминированный чайный график (кластер рандомно останавливается на попить чай с молоком и бабушкиными кыстыбыями) и первый черновик татарской IT-терминологии Kubernetes. А ещё мы прогнали всё на реальном кластере CozyStack — с живыми kubectl/talosctl, RBAC, метриками и одним пойманным багом.

Репозитории tatar-ncf: tatarnetes · tataros · tatarnetes-ui. Лицензия — Tatarch 2.0.

Проект посвящается Саше, Роме, Максу и Рамилю из одного замечательного кубер-чатика.

Лето на площадке в Марфино выдалось насыщенным. Собрали в одном выпуске всё, что произошло за эти месяцы, — и рассказываем, как продвинулась стройка.

Я архитектор и до сих пор отхожу от VMware: Kubernetes дался мне не сразу. Как выяснилось, я не один такой. С этим сталкиваются разработчики в нашей команде, которым нужно быстро освоить Kubernetes для повседневной работы. С этим же сталкиваются ИТ-специалисты широкого профиля у заказчиков: они десятилетиями эксплуатировали vSphere, а теперь уходят от него, потому что всё больше ПО поставляется в контейнерах.

Люди приходят к одному вопросу: с чего действительно начать изучение Kubernetes?

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

Такие материалы редко помогают освоить ключевые концепции Kubernetes и собрать мысленную модель, на которую затем можно накладывать более глубокие знания.

Команда VK Cloud перевела статью о том, как начать изучать Kubernetes без попыток сразу охватить всю экосистему: сначала разобраться в базовых принципах работы кластера, а затем переходить к специализированным инструментам и сценариям эксплуатации. Все схемы взяты из оригинала статьи по ссылке.

Kubernetes дал платформенным командам единообразный способ развёртывать, масштабировать и эксплуатировать контейнеризированные приложения. Теперь многим из них приходится поддерживать и ИИ-нагрузки.

Переход уже начался. По данным CNCF 2025 Annual Cloud Native Survey, 66% организаций, которые размещают генеративные ИИ-модели, используют Kubernetes для части или всех инференс-нагрузок. Однако ежедневно развёртывают ИИ-модели лишь 7% организаций. Этот разрыв показывает разницу между запуском ИИ-нагрузок в Kubernetes и платформой, которая готова непрерывно эксплуатировать ИИ в production.

Проблема заметна и внутри платформенных команд. Исследование 2025 State of AI in Platform Engineering2 показало, что 35% таких команд всё ещё не оркестрируют ИИ-нагрузки. Это говорит о разрыве между внедрением ИИ и зрелостью операционных платформ, необходимых для его масштабной поддержки.

ИИ не требует от платформенных команд отказываться от Cloud Native-практик. Kubernetes, GitOps, observability, автоматизация и самообслуживание по-прежнему составляют ценный фундамент. Однако ИИ предъявляет дополнительные требования к вычислительным ресурсам, планированию, доставке моделей и эксплуатации.

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

Крупные дата-центры требуют все больше электричества, а системы охлаждения — еще и воды. Строить ЦОД можно далеко не везде: требуются свободные мощности в энергосети, быстрые каналы связи. А ведь еще нужно покупать/арендовать землю, на которой строятся объекты. Это крайне дорого. Поэтому некоторые компании начали всерьез обсуждать перенос части вычислений в космос. Почему и зачем? 

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

Привет, Хабр! Значю, что вам на это плевать и вы не хотите это читать, но я все равно продолжу это писать:) В общем, Sheet-Native Computing Foundation продолжает цвести и пахнуть и у нас даже есть сторонние контрибьюторы. А чего добились вы?

Итак, вот что теперь можно сделать в таблице: запушить в неё настоящий OCI-образ контейнера и вытянуть его обратно. Не ссылку на образ, не метаданные о нём — сами слои, хранящиеся как base64 по ячейкам, с адресацией по sha256, собирающиеся байт-в-байт на выходе. У SheetHub — нашего форжа в стиле GitLab, который работает на Google-таблице — появился реестр контейнеров, и он целиком живёт в ячейках.

Этот пост — про то, как это всё устроено.

«Просто арендую сервер помощнее». Так я думал, когда пет-проект внезапно оброс людьми.

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

Я изучил, как похожие проблемы решают крупные компании, и применил эти принципы на практике.

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

Есть проверенный закон вселенной: если у чего-то есть экран и хоть немного памяти, рано или поздно на этом запустят DOOM. Запускали на осциллографах, на тесте на беременность, на кофемашине и на тракторе. Мы в Sheet-Native Computing Foundation тоже решили побыть в этом уже достаточно запылившемся тренде и запустить DOOM в контейнере, упакованном в ячейки электронной таблицы. То есть образ контейнера с игрой физически лежит в ячейках, оттуда собирается обратно в Docker-образ, проверяется по sha256 и запускается.

В первой статье я рассказывал про Sheeternetes — оркестратор контейнеров, у которого весь control plane (Deployments, Nodes, Pods, Events) живёт внутри Google Таблицы или Excel, а на другом конце крутятся настоящие Docker-контейнеры. Там же мельком был упомянут наш формат образов — SICF (Sheet-Native Image Container Format). Эта статья как раз про него: как он устроен, как всё это воспроизвести у себя, как оно работает на bare metal (то есть в эксельке, а не гугл-таблице) без интернета и какие неожиданно интересные находки вылезли, когда мы начали пихать всё это дело в ячейки Google Sheets.

Спойлер: DOOM — настоящий (Chocolate Doom плюс свободный Freedoom, всё в Linux-контейнере, играется в браузере с клавиатуры).

В одном чате по куберу меня спросили единственное, что реально важно, когда ты собрал оркестратор контейнеров внутри таблицы: а сколько оно вообще тянет? Сколько подов, пока не ляжет. Какой образ влезает в ячейки. Сколько кластеров держит одна машина. И — раз уж мы фонд с серьёзным лицом — как это смотрится рядом с настоящими: Kubernetes, Docker Swarm, Nomad.

Поэтому мы провели честное нагрузочное тестирование. Четыре измерения, два бэкенда (.xlsx на диске и живая Google-таблица), синтетика на ноутбуке и реальные Docker-образы на облачной виртуалке. А потом поставили цифры рядом со взрослыми оркестраторами.

Короткая версия: по каждой оси, которая имеет значение, мы проигрываем на 3–5 порядков. По осям, которые значения не имеют, — выигрываем вчистую. И один наш давний «факт» оказался неверным — бенчмарк нас поправил. Поехали.

Медиана зарплаты DevOps-инженера в 2026 году держится в районе от 220 000 до 250 000 ₽, но разброс внутри одного грейда огромный: у Senior вилка идёт от 300 000 до 850 000 ₽.

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

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