Google представила программный комплекс TorchTPU с открытым исходным кодом, предназначенный для запуска ИИ-моделей с использованием фреймворка PyTorch на ускорителях TPU. Проект призван упростить использование ускорителей Google в обучении и инференсе ИИ; поддерживаются популярные программные средства — создавать отдельную программную среду для TPU не требуется.

Разработанный совместно с командой PyTorch в Meta✴ инструментарий TorchTPU позволяет запускать существующие проекты в PyTorch с минимальными изменениями кода, используя привычный API. Поддерживаются отладка в обычном режиме PyTorch и механизмы распределенных вычислений. Google заручилась поддержкой Hugging Face, благодаря чему представленные на ИИ-платформе открытые модели могут запускаться нативно через TorchTPU — поддерживаются библиотеки Transformers v5 и Diffusers.

Источник изображения: youtube.com/@googlecloudtech

Программный модуль vLLM для TorchTPU поддерживает одновременную обработку множества запросов, квантизацию и распределение вычислений между чипами TPU; стандартные средства управления вычислениями и обработки запросов сохранены. Для TPU адаптирован инструмент SGLang — он позволяет ускорять сложные многоэтапные задачи, в том числе выполняемые ИИ-агентами; поддерживаются повторные обращения к KV-кешу и повторяющиеся префиксы запросов, за счёт чего одни и те же вычисления могут не выполняться заново. Версия SGLang-TorchTPU сохранила механизмы выполнения задач, распределения запросов и API. Средства обмена данными с HiCache помогают сократить задержку и оптимизировать вывод при сложной многоэтапной генерации.

Совместно с Red Hat, IBM и сообществом разработчиков выпущен роутер llm-d 1.0 — он направляет запросы к экземплярам модели, где уже сохранен контекст, а также разделяет обработку входного запроса и генерацию ответа по вычислительным ресурсам, что позволяет использовать их эффективнее. В Google Kubernetes Engine этот инструмент поддерживает запуск моделей как на GPU, так и на TPU. Google интегрировала TorchTPU с TorchTitan — инструментом распределённого обучения крупных моделей; поддерживаются, в частности, Llama 3, Qwen 3 и FLUX.1. Поддержка появилась в VeRL — одном из наиболее популярных фреймворков для обучения с подкреплением, позволяющий улучшать модели в математических задачах, написании кода и многоэтапных агентских задачах.

Заявлено о поддержке TorchTPU в Ray — инструмент для распределения вычислительных задач позволяет объединить обработку данных, обучение, и инференс в рабочий процесс с использованием центральных и графических процессоров, а также TPU. В экосистему PyTorch вошла библиотека LiteRT, предназначенная для запуска моделей на пользовательских устройствах. Google также представила предварительную версию TPU agent suite — при помощи плагинов этот набор инструментов помогает автоматизировать первоначальную настройку, диагностику и оптимизацию моделей в PyTorch.

Поддержку PyTorch на своих ускорителях реализовали также Amazon, Intel и Meta✴.

Российский разработчик решений для видеоконференцсвязи «Труконф» представил новую серверную архитектуру TrueConf Cluster.

Решение предназначено для построения отказоустойчивых систем унифицированных коммуникаций в государственных структурах, банках и промышленных предприятиях. Архитектура TrueConf Cluster позволяет объединять несколько серверов в единый логический кластер с автоматическим перераспределением нагрузки и мгновенным переключением на резервные узлы при сбоях. По данным разработчика, система обеспечивает непрерывность сеансов связи: при выходе из строя одного из узлов активные конференции не прерываются, а пользователи незаметно для себя переводятся на работающие мощности.

В основу архитектуры TrueConf Cluster положена фирменная технология компании «Труконф»: каждый участник взаимодействует только со «своим» узлом кластера, а медиаданные передаются напрямую между задействованными узлами — такой подход обеспечивает равномерную нагрузку на сеть.

Источник изображения: «Труконф» / trueconf.ru

Кластер может быть развёрнут в контуре заказчика или его доверенного подрядчика — в том числе в изолированных сетях. Настройка узлов TrueConf Cluster и конфигурирование системы осуществляется через единый портал с мониторингом нагрузки и активности в реальном времени, а также централизованным управлением правами групп пользователей и администраторов.

TrueConf Cluster поддерживает взаимодействие со сложными LDAP-лесами, настройку многофакторной авторизации и механизма единого входа, а также интеграцию со сторонними средствами защиты цифровых угроз. Благодаря возможностям масштабирования продукт может использоваться в организациях любого размера, будь то ведомственные предприятия, территориально распределённые или международные компании с широкой географией офисов.

ICANN начала тестировать схемы аутентификации, которые позволят правоохранительным органам направлять срочные запросы на получение закрытой информации WHOIS, сообщает The Register. Механизм предназначен для особых случаев: чтобы предотвратить угрозу жизни людей или критически важной инфраструктуре, а также пресечь случаи жестокого обращения с детьми.

Регистраторы доменных имён собирают информацию о своих клиентах. Ранее эти данные были общедоступными в системе WHOIS; сейчас доступна услуга по подмене контактных данных клиентов, чтобы обеспечить конфиденциальность. В последние годы, в частности, с принятием в ЕС «Общего регламента по защите данных» (GDPR), регистраторы обязаны скрывать сведения в WHOIS. Из-за этого у правоохранительных органов возникают трудности — они не могут связаться с владельцев домена, если, например, ресурс по соответствующему адресу используется для размещения вредоносного ПО или управления им, а также для проведения фишинговых атак.

Источник изображения: icann.org

Основаниями для срочного запроса данных WHOIS могут быть «прямая угроза жизни, серьёзного телесного вреда, угроза критической инфраструктуре или эксплуатация детей». Организация сформировала для этих целей «Группу по механизмам аутентификации для правоохранительных органов». В ходе ежегодной конференции ICANN на индонезийском Бали представители группы рассказали о достигнутом прогрессе. Её работа носит преимущественно технический характер. Когда будет выработан механизм для подачи запросов, отвечающие за формирование политики другие группы ICANN определят нормы его допустимого использования и сопутствующие вопросы.

На данный момент предпочтительный подход ICANN предусматривает использование протокола SAML (Security Assertion Markup Language). Прошедшие процедуру аутентификации сотрудники правоохранительных органов смогут входить в систему RDRS (Registration Data Request Service) и подавать заявки на получение доступа к непубличной информации WHOIS. Этот механизм уже тестируется совместно с ФБР и Интерполом; не исключаются и другие способы аутентификации, которые откроют доступ к RDRS и другим ведомствам. Задача рабочей группы — создать спецификацию, которую смогут применять эти организации.

ICANN будет направлять поступившие по каналам RDRS запросы соответствующим регистраторам, через которых приобретались домены. У регистратора будут 24 часа, чтобы рассмотреть заявку, или в сложных случаях до 72 часов. Если регистратор сочтёт, что запрос не соответствует критериям срочности, он будет вправе его отклонить. Чтобы не допустить перегрузки системы, ICANN планирует обязать правоохранительные органы назначать сотрудников, уполномоченных подавать такие запросы. Для контроля за наличием полномочий будет использоваться специальный токен, передаваемый в процессе аутентификации по протоколу SAML.

Обсуждается также аспект защиты личности сотрудников правоохранительных органов, которые направляют запросы через RDRS — если в запросах на получение данных WHOIS будут фигурировать адреса электронной почты сотрудников, они могут стать объектами преследования. Ранее Number Resource Organization, координирующая работу региональных регистраторов (RIR), объявила о намерении пересмотреть критерии формирования новых RIR — инициатива призвана пресечь злоупотребления и нарушения в глобальной системе IP-адресации.

Компания Marvell Technology анонсировала ретаймер Alaska E 3.2T и чип Alaska A 1.6T AEC DSP второго поколения для высокопроизводительных ИИ-инфраструктур. Изделия призваны решить проблему затухания сигналов и роста энергопотребления при построении сетей со сверхвысокими скоростями передачи данных.

Ретаймер Alaska E 3.2T обеспечивает общую пропускную способность до 3,2 Тбит/с. Конфигурация включает 16 линий 224G PAM4 SerDes. Реализована поддержка протоколов Ethernet, UALink и ESUN. Говорится об ультранизкой задержке и об архитектуре, оптимизированной для ИИ-платформ высокой плотности. Ретаймер позволяет гибко размещать вычислительные узлы без потери качества сигнала.

Источник изображения: Marvell

В свою очередь, решение Alaska A 1.6T AEC DSP — это специализированный цифровой сигнальный процессор для активных электрических кабелей (AEC). Его конфигурация предусматривает использование восьми линий 224G PAM4, а пропускная способность составляет 1,6 Тбит/с. Изделие производится по 3-нм технологии в корпусе с размерами 12 × 14 мм. Заявленное энергопотребление — 12,8 Вт. Решение даёт возможность передавать сигнал 1,6 Тбит/с по медным кабелям на расстояние более 6 м, что вдвое превышает показатель чипов первого поколения. Упомянуты протоколы Ethernet, UALink и ESUN.

У обеих новинок компенсация вносимых потерь превышает 45 дБ. Реализован полный набор диагностических возможностей. Пробные поставки Alaska E 3.2T и Alaska A 1.6T AEC DSP уже начались. 

Amazon анонсировала TorchNeuron — инструментарий с открытым исходным кодом, позволяющий запускать рабочие нагрузки PyTorch на ИИ-ускорителях AWS Trainium. До настоящего момента запуск на чипах Trainium самого популярного в отрасли фреймворка PyTorch для разработки систем искусственного интеллекта требовал значительного объёма ручной работы — затраты на разработку увеличивались, создавался барьер для пользователей.

TorchNeuron позволяет запускать проекты PyTorch на чипах Trainium, не внося масштабных изменений в код. Разработчикам, подчеркнули в Amazon, достаточно лишь задать параметр, какой именно чип следует использовать для выполнения задач. Поддерживаются Trainium2 и Trainium3 — две новейшие модели в линейке этих ускорителей; они подходят как для обучения, так и для инференса моделей.

Более мощный из двух ускоритель Trainium3 оснащён восемью вычислительными ядрами, каждое из которых состоит из четырёх модулей, оптимизированных для определённых типов вычислений, необходимых ИИ-моделям при обработке данных. Объём встроенной памяти составляет 144 Гбайт. На сервере могут работать до 144 ускорителей Trainium3 — одна такая система способна выполнять до 362 квадриллионов операций в секунду при работе с данными в формате MXFP8, который широко применяется в моделях ИИ.

Источник изображения: aboutamazon.com

Для серии Trainium был разработан собственный язык программирования NKI; благодаря наличию специального компилятора этот язык позволяет производить низкоуровневую оптимизацию моделей, за счёт чего снижается потребление аппаратных ресурсов и повышается скорость работы ИИ.

В состав TorchNeuron входит набор готовых операторов NKI — программных компонентов, которые можно использовать при создании ИИ-моделей. Одни из них упрощают реализацию архитектуры Mixture-of-Experts, другие помогают сократить объём памяти, который занимают нейросети. Ускоряется выполнение и сопутствующих задач, например, квантования. TorchNeuron поддерживает не только PyTorch, но и другие открытые инструменты, которые разработчики часто используют в связке с этим фреймворком. Среди них поддерживается TorchTitan — популярный механизм для обучения ИИ-моделей. Он автоматизирует часть задач, связанных с распределением процессов между ускорителями; метод полностью сегментированного параллелизма данных разделяет не только обучаемую модель, но также состояния оптимизатора и градиенты. Оптимизатор — программа совершенствующая способности модели; градиенты — данные, которые играют в этом процессе важную роль. В состав TorchNeuron вошли функции, позволяющие дополнительно оптимизировать рабочий процесс обучения с использованием ускорителей Trainium.

Ранее о поддержке PyTorch на своих ускорителях заявили Intel, Meta✴ и корейский стартап HyperAccel.

Причиной отключения ряда онлайн-сервисов для клиентов в Западной Европе стал «инцидент с электроснабжением», сообщили в Google Cloud. К настоящему моменту работоспособность облачных сервисов полностью восстановлена.

Системы вышли из строя 20 октября в 09:08 мск — возникли неполадки в зоне доступности europe-west-2-b, одной из трёх в лондонском регионе. Полностью работу всех сервисов удалось восстановить в 17:03 мск. Среди затронутых сервисов оказались BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, Google App Engine, Google Cloud NetApp Volumes, Google Kubernetes Engine и Managed Service for Apache Kafka.

Источник изображения: Ameer Basheer / unsplash.com

В результате крупномасштабного сбоя возникли неполадки в работе ресурсов Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Cloudflare, Screwfix и Revolut. Причиной проблемы стал «инцидент с электроснабжением». В общей сложности из строя вышли 38 сервисов, подсчитал давший ресурсу The Register комментарий эксперт. Сбой подчеркнул, насколько сильно современные облачные экосистемы зависят друг от друга: при возникновении проблемы в одном из ключевых облачных регионов по каскаду возникают отказы в работе приложений, API, баз данных, систем аутентификации, платёжных платформ, аналитики и сторонних SaaS-продуктов.

Чтобы обеспечить устойчивость сервисов, требуется проектировать архитектуру с учётом подобных региональных сбоев. Ресурсы следует развёртывать в нескольких регионах, обеспечивать возможность переносить рабочие нагрузки и предусматривать процедуры восстановления после аварий, добавил эксперт. Платформа Google Cloud время от времени сталкивается с масштабными сбоями, которые выводят из строя многочисленные сервисы. В июне сервисы Google Cloud в Индии около недели работали с перебоями из-за произошедшего в одном из ЦОД в Дели пожара. В июле был зафиксирован 15-часовой сбой сервиса в Нидерландах по вине проблем питания и охлаждения в ЦОД. А в сентябре регион us-central1-b на несколько часов прекратил работу из-за человеческого фактора.

Провайдер «Софтлайн Облако» (ГК Softline) и компания Oxygen, специализирующаяся на дата-центрах уровня Tier III, объявили о запуске совместного мультиоблачного решения. Новый сервис предназначен для размещения IT-систем с автоматическим резервированием на независимой инфраструктурной площадке.

Решение было разработано в ответ на острый дефицит мощностей в Московском регионе. По оценке NF Group, в 2026 году будет введена лишь треть из заявленных 199 МВт новых мощностей дата-центров. В условиях, когда строительство собственной резервной площадки становится долгим и дорогостоящим, компании переносят отказоустойчивость в облако.

Источник изображения: oxygen.cloud

Технически решение строится на двух полностью изолированных платформах. Основной может выступать инфраструктура любой из компаний, вторая — служит резервной. Данные и виртуальные машины реплицируются между облаками, которые не связаны ни общей инфраструктурой, ни управлением. В штатном режиме заказчик оплачивает в основном хранение реплик, а вычислительные ресурсы разворачиваются автоматически только в момент переключения. Параметры восстановления (RTO/RPO) фиксируются в SLA, а переключение регулярно тестируется совместными командами инженеров.

«Резерв в том же облаке защищает от сбоя оборудования, но не от рисков самого провайдера. Независимое облако и проверенное на практике переключение делают отказоустойчивость реальной», — пояснили в компании «Софтлайн Облако».

Управление по электроэнергии Израиля установило предельную мощность новых дата-центров в стране на уровне 200 МВт. Новые правила вводятся из-за роста числа ЦОД, требующих подключения к электросетям, сообщает Datacenter Dynamics.

Новые правила должны предотвратить подачу спекулятивных заявок, «перегружающих» процесс подключения к сети. Теперь застройщики, занимающиеся проектами ЦОД, должны будут предоставить гарантии в размере 2 млн шекелей (NIS) ($643 300) на каждый мегаватт запрошенной мощности. Кроме того, правила предусматривают создание механизмов резервного энергоснабжения, позволяющих отключать дата-центры от электросети в периоды пикового спроса на электроэнергию.

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

Управление намерено не только ограничить максимальную мощность ЦОД, но и дополнительно распределить 1 ГВт мощности между крупными дата-центрами. В результате общая законтрактованная мощность сектора ЦОД превысит 3 ГВт. В случае успешной реализации плана к 2030 году на ЦОД будет приходиться 20 % общего потребления электроэнергии в стране.

Источник изображения: Adam Jang/unsplash.com

Израиль уже столкнулся с беспрецедентным спросом на электричество со стороны сектора ЦОД. Национальный электрооператор NOGA сообщил, что проекты ЦОД в совокупности нуждаются в 27 ГВт электричества. Это заставило в июле ввести временный мораторий на рассмотрение новых запросов на подключение дата-центров к электросетям.

Ожидается, что он продлится до начала декабря и коснётся всех ЦОД от 8 МВт. В этот период Управление по электроэнергии, Министерство энергетики страны и NOGA закончат совместный обзор состояния дел в этой сфере и предложат новую политику распределения электроэнергии между ЦОД и прочими секторами экономики.

Представители властей заявляли, что стремительный рост числа заявок на подключение связан с израильским законопроектом о планировании и строительстве (Planning and Building Bill (Amendment No. 168), ещё не принят окончательно), присваивающим дата-центрам статус объектов национальной инфраструктуры для того, чтобы убрать препятствия для их планирования и строительства.

Рынку ЦОД в Израиле предрекают быстрый рост. По оценкам Mordor Intelligence, $963,99 млрд будут инвестированы в соответствующий сектор к 2031 году. Недавно Crusoe объявила, что она инвестирует в дата-центры страны около $10 млрд в следующие 10–15 лет, используя «арендную» модель.

Компания Microsoft отказалась от участия в проекте, предусматривавшего аренду вычислительных мощностей в флагманском дата-центре компании Nscale, поддерживаемой NVIDIA. Такое решение было принято после того, как вероятные сроки подключения ЦОД к электроснабжению сдвинули на 2030-е годы — это стало наглядной демонстрацией того, что британские амбиции в сфере ИИ могут столкнуться с серьёзными препятствиями, сообщает Reuters.

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

В компании подчёркивают, что отказ от сделки касается конкретной площадки в Лоутоне (Loughton) графства Эссекс. Именно там Nscale не смогла обеспечить своевременное подключение — представители оператора местных электросетей сообщили, что рассчитывают подавать энергию к ЦОД не раньше 2030-х гг. В самой Nscale также утверждают, что эта проблема с электросетевой инфраструктурой Лондона и прилегающих районов не повлияет на другие контракты.

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

Источник изображения: Nomadic Julien/unsplash.com

Проект впервые анонсировали в ходе визита в Великобританию президента США Дональда Трампа (Donald Trump) в сентябре 2025 года, Предполагалось, что он продемонстрирует желание страны стать одним из мировых лидеров в ИИ-индустрии. Тем не менее, Великобритания столкнулась с дефицитом электричества для ЦОД из-за нехватки доступных энергетических мощностей. Из-за очередей на подключение сроки реализации проектов ЦОД могут быть отложены на срок до 13 лет.

В 2025 году партнёры заявляли, что ЦОД в Лоутоне должен заработать в начале следующего года, 23 040 ускорителей NVIDIA GB300 должны были обеспечить 50 МВт вычислительных ИИ-мощностей в помощь сервисам Microsoft Azure в Соединённом Королевстве.

В сентябре Nscale подала заявку на IPO в США. Предполагалось, что в числе крупнейших клиентов будут Anthropic и Microsoft.

Nscale обеспечивает клиентам ИИ-инфраструктуру, включая вычислительные мощности, электроснабжение и собственно ЦОД, а также ПО для обучения и эксплуатации ИИ-моделей.

С момента основания Nscale активно развивалась. За 2,5 года стоимость заключённых ей контрактов выросла с $100 млн до более $103 млрд. В число прямых конкурентов входят CoreWeave, Nebius, Crusoe и Lambda.

Не все проекты удаётся реализовать одинаково успешно. Недавно сообщалось, что сдача ЦОД Nscale в норвежском Глом-фьорде отложена на полгода из-за пожара, утечек в системе охлаждения и более серьёзных проблем, включая ограничения со стороны местных властей.

Только 51,8 % из 10 104 ИИ-ускорителей, выделенных бизнесу, предприятиям и другим организациям, в рамках государственных проектов Южной Кореи, активно использовались по состоянию на сентябрь 2026 года, сообщает TelecomPaper.

По статистике Национального агентства по продвижению IT-индустрии (NIPA) Южной Кореи, используются лишь 5234 из 10 104 ускорителей, предоставленных при участии государства. Информация была раскрыта в ходе парламентского аудита государственных органов одним из депутатов страны, обратившим внимание на неэффективное расходование средств.

Согласно статистике по секторам, в крупных компаниях уровень использования ускорителей наиболее высок и составляет 80,6 %. В научно-исследовательских структурах он значительно ниже — 61,2 %.

Хуже всего показатели у малого бизнеса и университетов. На малых и средних предприятиях уровень использования составляет 56,5 %, в стартапах — 46,1 %, а в университетах — 42,1 %.

Источник изображения: Mathew Schwartz/unsplash.com

Более того, как минимум в 15 отдельных проектах, в том числе в 10 промышленных, академических и исследовательских проектах, а также в пяти инициативах в сфере ИИ, используется менее 20 % выделенных ускорителей.

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

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

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

При этом в Южной Корее довольно решительно настроены на развитие ИИ-отрасли. Например, в июне сообщалось, что страна инвестирует почти $3 трлн в полупроводники и ИИ. В том же месяце было объявлено, что NVIDIA поможет SK hynix, Naver, Doosan, SK Telecom и LG расширить ИИ-инфраструктуру Южной Кореи.