Материалы по тегу: ии
|
22.10.2026 [18:24], Руслан Авдеев
Квартальная прибыль Nokia превысила ожидания — немалую часть роста обеспечили облачные и ИИ-клиентыФинский производитель телекоммуникационного оборудования Nokia отчитался о квартальных финансовых показателях. В III квартале прибыль оказалась выше ожидаемой, хотя прогноз на год сохранился без изменений, сообщает Reuters. Сопоставимая операционная прибыль (comparable operating profit) в III квартале выросла до €605 млн ($680,20 млн) по сравнению с €448 млн годом ранее. Показатель оказался выше среднего прогноза экспертов, ожидавших приблизительно €453 млн. Сопоставимая чистая выручка (comparable net sales) выросла на 10 %, до €5,15 млрд, превысив консенсус-прогноз экспертов, составлявший €5,05 млрд. Всё большее значение приобретает спрос со стороны клиентов, связанных с облачным и ИИ-сегментами. Консолидированная выручка в этом направлении выросла год к году на 123 %, а объём новых заказов — на 118 %, составив €1,5 млрд.
Источник изображения: Nokia По словам главы Nokia Джастина Хотарда (Justin Hotard), ожидается, что совокупный бизнес компании в сфере оптических и IP-сетей в 2027 году вырастет на 25–30 %. В отчёте подчёркивается, что возможности Nokia позволяют удовлетворять растущие потребности, связанные с ИИ-инфраструктурой. Компания инвестирует в направления, для которых способна предложить уникальные решения и разрабатывать технологии совместно с гиперскейлерами. Так, партнёрство с Google на фоне инвестиций последней в Финляндии в размере €13 млрд демонстрирует, как оптические и IP-сети обеспечивают работу критически важной инфраструктуры связи. Сети, изначально проектируемые для ИИ, выходят за пределы виртуальной среды в «физический мир». Платформа AI-RAN была специально разработана для обеспечения необходимой производительности в этом сегменте. Совместно с T-Mobile и NVIDIA компания завершила первый в мире вызов с применением AI-RAN в действующей сети оператора связи. По словам Хотарда, в целом темпы роста ускоряются, эффект операционного рычага становится всё заметнее, а долгосрочная уверенность в ценности компании для акционеров укрепляется. С начала года акции Nokia выросли в цене на 48 %.
22.10.2026 [17:42], Павел Котов
В Google Cloud появятся новейшие ИИ-модели OpenAIOpenAI объявила о планах сделать свои новейшие большие языковые модели доступными в Google Cloud. Они появятся в сервисе Model Garden, который открывает доступ к более чем 200 нейросетям от самой Google, её партнёров, а также к открытым проектам. В каталоге представлены не только большие языковые модели, но и более компактные специализированные решения, предназначенные для конкретных задач, например, для перевода текстов, сообщает SiliconANGLE. Первой моделью, которую OpenAI разместит в Google Cloud, станет флагманская GPT-6 Astra. Этот алгоритм использовался в проектах, которые помогли сделать ряд математических открытий; модель также показала наилучший результат в бенчмарке ExploitBench, который оценивает способности нейросетей обнаруживать уязвимости в области кибербезопасности и эксплуатировать их. В Astra предусмотрены защитные механизмы, адаптированные для корпоративного применения — эта модель, заявил разработчик, демонстрирует меньше «нежелательных результатов» по сравнению с другими, прошедшими внутреннее тестирование компании.
Источник изображения: cloud.google.com Клиенты Google Cloud также получат доступ к моделям GPT-6.1 Sol и GPT-6 Luna — облегчённым версиям Astra, которые OpenAI представила в конце сентября. Качество генерации у них несколько ниже, но работа обходится существенно дешевле: Sol в пять, а Luna — в сто раз меньше, чем Astra. Облачные провайдеры часто предлагают скидки корпоративным клиентам, готовым взять на себя долгосрочные обязательства по расходам, — клиенты Google Cloud смогут воспользоваться этой схемой, отметили в OpenAI. Модели Astra, Sol и Luna появятся в сервисе Google Model Garden в ближайшие недели. Далее компании планируют интегрировать их в панель инфраструктурных служб Confidential Compute. Серверные CPU, в том числе используемые Google, поддерживают функцию безопасности TEE (Trusted Execution Environment). Она предполагает шифрование части памяти на хосте таким образом, что доступ к ней остаётся только у конкретной рабочей нагрузки — в службах Confidential Compute эта функция используется. OpenAI также планирует сделать свои модели доступными в продуктах самой Google, в том числе в сервисе помощника по написанию кода Antigravity и в ИИ-агенте Gemini Agent. Разработчик ChatGPT намерен построить в Огайо (США) крупнейший ИИ ЦОД — гарантии по проекту в размере $250 млрд готова предоставить NVIDIA. Совместно с Broadcom компания OpenAI разработала собственный ИИ-ускоритель Jalapeño для инференса, участие в разработке нового чипа примет Samsung.
22.10.2026 [17:32], Андрей Крупин
Релиз «Кибер Бэкап» 19: интеграция с VMmanager, RuPost, Zabbix, расширенная поддержка PostgreSQL и многое другоеКомпания «Киберпротект» сообщила о выпуске новой версии программного комплекса «Кибер Бэкап» 19, предназначенного для резервного копирования IT-систем любой сложности. В обновлённом релизе продукта существенно расширены возможности защиты данных в СУБД на основе PostgreSQL. К существующим механизмам резервного копирования добавлены новые технологии, ускоряющие работу с данными и расширяющие сценарии восстановления. Важным изменением стала интеграция с библиотекой libpgprobackup (результат совместной работы с Postgres Professional). Теперь администраторы могут выбирать между ней и фирменным многопоточным механизмом файлового бэкапа. Добавлена поддержка инструмента walsummary (сводка изменений WAL-журналов), что ускоряет инкрементные бэкапы и восстановление на нужный момент времени. Также реализована поддержка кластеров высокой доступности Patroni и отечественной СУБД Jatoba с многопоточным резервированием для сокращения окна бэкапа.
Источник изображений: «Киберпротект» / cyberprotect.ru Существенное развитие получили инструменты защиты виртуальных сред. Появилась нативная поддержка отечественной платформы управления виртуальной инфраструктурой VMmanager. Резервное копирование теперь выполняется на уровне гипервизора без установки агентов в гостевые ОС. Также реализована миграция V2V. Сетевой трафик при работе с VMware снижен более чем в 2,5 раза, а для остальных платформ (кроме Hyper-V) — более чем в 10 раз благодаря новому алгоритму сжатия. ![]() Доработкам подверглась защита корпоративной почты. «Кибер Бэкап» 19-й версии реализована глубокая интеграция с отечественной почтовой системой RuPost: поддерживается полное и инкрементное копирование ящиков, писем и календарей с возможностью восстановления на Linux-серверы. Также значительно улучшена масштабируемость для среды VK WorkSpace — теперь один сервер управления поддерживает до 85 000 почтовых ящиков. ![]() В числе прочего был полностью обновлён движок уведомлений, рассчитанный на высокие нагрузки в инфраструктурах с десятками тысяч защищаемых объектов. Появилась возможность отправлять служебные оповещения в мессенджер «Макс». Для централизованного мониторинга реализована передача метрик и логов в Zabbix (в комплекте поставляется готовый шаблон контрольной панели). Для защиты от вирусов-вымогателей добавлена интеграция с решением AMT InfoDiode — благодаря технологии однонаправленной передачи данных оно позволяет на физическом уровне изолировать резервные копии от основной сети, полностью исключая возможность их изменения или удаления даже в случае компрометации контура. ![]() Отдельное внимание разработчиками было уделено изменениям в лицензировании продукта: текстовые лицензионные ключи заменены на лицензионные файлы, защищённые цифровой подписью «Киберпротекта». Лицензионные файлы активируются путём привязки лицензий к инсталляции сервера управления, что исключает возможность их использования на других инсталляциях. Кроме того, с релизом «Кибер Бэкап» 19 были исправлены ошибки и недоработки в коде программного решения. С полным списком изменений и улучшений можно ознакомиться в разделе «Что нового» прилагаемой к продукту документации. Система резервного копирования и восстановления данных «Кибер Бэкап» зарегистрирована в реестре российского ПО Минцифры России и может использоваться организациями для реализации стратегии технологической независимости от импортных решений.
22.10.2026 [17:25], Павел Котов
Nebius привлекла $3,5 млрд от Citi на развитие сети ЦОДОблачный провайдер Nebius объявил о получении кредитной линии в размере $3,5 млрд от банка Citi. Средства будут направлены на дальнейшее развитие ЦОД и закупку GPU — компания стремится нарастить свои вычислительные мощности максимально быстро. Это сообщение появилось на фоне недавнего массового падения акций компаний, связанных с инфраструктурой для ИИ, напоминает Reuters. Инцидент был спровоцирован резко подешевевшими облигациями CoreWeave — конкурента Nebius. CoreWeave, как и Nebius, относят к числу ведущих представителей сегмента неооблачных провайдеров, которые специализируются на создании ЦОД для нужд ИИ. Срок погашения новой кредитной линии составляет 364 дня, а процентная ставка установлена на уровне 2,75 % от уровня базовой SOFR.
Источник изображения: Nebius Финансирование обеспечит гибкость в выборе сроков и структуры привлечения капитала для обеспечения роста в 2027 году и в дальнейшем, отметили в компании. Другими источниками финансирования выступают предоплата от клиентов и операционный денежный поток. У Nebius есть и другие возможности для привлечения средств, в том числе получение кредитов под обеспечение будущими поступлениями по долгосрочным контрактам с заказчиками, у которых высокий кредитный рейтинг, отметил операционный директор Nebius Офир Наве (Ophir Nave). Общая сумма таких контрактов составляет $40 млрд, среди заказчиков значатся Microsoft и Meta✴. Nebius выступает приоритетным облачным провайдером у Palantir. Оператор ЦОД выпустил облигации на $5 млрд для расширения парка дата-центров и ИИ-ускорителей. Компания активно расширяется в Европе, строя и арендуя ЦОД в Эстонии, Финляндии и Великобритании.
22.10.2026 [17:05], Владимир Мироненко
GitHub перевела 99,99999 % репозиториев в облако AzureGitHub объявила о переносе 99,99999 % репозиториев в Azure. «За последний год, на фоне экспоненциального роста трафика Git, 99,99999 % репозиториев GitHub стали размещаться одновременно в двух местах: в наших собственных дата-центрах и в Azure. Оставшиеся репозитории — одни из самых активно используемых на платформе, и их переносу мешает лишь один фактор: задержка в 25 мс при обмене данными (round trip)», — сообщила компания. Компания объяснила сроки и формат перехода «агентным сдвигом» (agentic shift): стремительным ростом трафика, жёсткими ограничениями по энергопотреблению в её дата-центрах и прилегающих регионах, а также физическими трудностями в цепочках поставок. Рост трафика, генерируемого программными агентами, повысил нагрузку на критически важные сервисы (уровень Tier 0), обеспечивающие основные операции с репозиториями. Учитывая масштаб системы и её критическую важность для сообщества, GitHub тщательно выстроила последовательность действий, решив сначала перенести данные, сервисы и все сопутствующие зависимости, а затем, после их перемещения, развивать архитектуру. Первая копия репозитория была размещена в регионе Azure Central US в августе 2025 года. На данный момент у большинства репозиториев две из пяти реплик находятся в Azure, и на долю этой платформы приходится около половины всего трафика Git. На протяжении большей части этого периода Azure брала на себя растущую нагрузку, в то время как собственные дата-центры GitHub сохраняли стабильные показатели. При этом GitHub опиралась на два принципа: минимизацию координации и отделение хранилища от вычислительных ресурсов. В GitHub описывают эту работу как «мост» между текущей архитектурой (системой Spokes) и следующей моделью хранения данных. Для большинства репозиториев GitHub создаёт пять реплик, распределнных по разным регионам и зонам доступности. Сервис Spokes использует механизм предпочтительной маршрутизации, направляя каждый запрос к реплике, находящейся в том же регионе и зоне доступности, что и источник запроса. По мере переноса реплик в Azure доля трафика, обслуживаемого этой платформой, увеличивается — до тех пор, пока не будет перемещена последняя реплика, после чего старый регион полностью перестает получать запросы. В текущей архитектуре репозиторий, размещённый более чем в одном регионе, имеет более низкий предел пропускной способности для операций записи. Для их подтверждения системе Spokes требуется большинство реплик, при этом кворум ожидает ответа от каждой исправной реплики вплоть до истечения времени ожидания (тайм-аута). Задержка при записи определяется самой медленной из исправных реплик. Поскольку на время выполнения записи накладывается блокировка всего репозитория, эта задержка также ограничивает максимальную пропускную способность репозитория. Если одна из реплик оказывается в целевом регионе Azure — на расстоянии около 1600 км от дата-центров GitHub, — каждый цикл обмена данными по сети (round trip) занимает примерно 25 мс, а для выполнения записи требуется несколько таких циклов. Если репозиторий уже работает на пределе своей пропускной способности, он не сможет «поглотить» эти дополнительные временные затраты при каждой записи, в результате чего очередь операций push начнёт расти. Здесь вступает в силу принцип минимизации координации. В данном случае это означает: не стоит сериализовать (выполнять строго последовательно) те операции, которые в этом не нуждаются. В связи с этим меняется область действия кворума: теперь он распространяется не на весь репозиторий целиком, а на отдельные ссылки. Запись с привязкой к конкретной ссылке (ref) сохраняет порядок операций, требуемый Git. Git предполагает наличие опредёленной последовательности событий для каждой ссылки (ветки или тега): как только сервер принимает новое значение, клиент видит либо это значение, либо более позднее. Между независимыми ссылками требования к согласованности отсутствуют. При сериализации на уровне отдельных ссылок (per-reference serialization) ожидание репозитория, то есть его временная блокировка, требуется только в тех случаях, когда операции записи затрагивают одну и ту же общую ссылку. На практике большинство операций записи в репозиторий направлено на разные ссылки. Когда агенты и разработчики работают с разными ветками, их операции больше не блокируют друг друга. Хотя каждая операция записи по-прежнему подвержена задержкам, связанным с передачей данных между регионами, операции с разными ссылками могут выполняться параллельно. Такой подход устраняет необходимость в единой очереди для всего репозитория, сохраняя при этом гарантии согласованности, на которые полагаются клиенты Git. По данным внутреннего тестирования было зафиксировано, что при записи в разные ссылки пропускная способность возрастает в 3–4 раза, а задержки при этом снижаются. В большинстве репозиториев соотношение операций чтения к записи составляет от 100:1 до 1000:1. В текущей архитектуре реплик GitHub чтение и запись выполняются на одних и тех же вычислительных ресурсах, из-за чего они конкурируют за память и процессорное время, что исключает возможность их независимого масштабирования. Новая архитектура предусматривает разделение мощностей для чтения и записи, благодаря чему для каждой задачи можно задать собственную конфигурацию. На первом этапе объектное хранилище включается в состав кворума в качестве «виртуальной реплики записи» (virtual write replica) — временного узла, который передаёт входящие данные записи в Azure Blob Storage, но не обслуживает запросы на чтение. Spokes включает этот узел в кворум и отправляет подтверждение записи клиенту после того, как данные будут надёжно сохранены в объектном хранилище. Виртуальная реплика записи также объединяет транзакции, затрагивающие независимые ссылки, в единый пакет сетевых операций ввода-вывода при обращении к объектному хранилищу. Благодаря этому для активно используемого репозитория вместо отдельного сетевого запроса на каждую операцию записи выполняется лишь один запрос для целого ряда одновременных операций. На текущем этапе виртуальная реплика записи также отвечает за процесс уплотнения данных (compaction), а реплики чтения (read replicas) получают уже уплотнённое состояние. Использование виртуальных реплик записи позволяет по мере необходимости масштабировать систему, создавая любое количество виртуальных реплик чтения. Каждая такая реплика наполняет свой кеш данными из Azure Blob Storage и начинает обслуживать запросы на чтение, не становясь участником кворума. Единственным достоверным источником данных выступает объектное хранилище, с которым реплика в фоновом режиме согласовывает своё локальное состояние. Поскольку синхронизация проходит в фоновом режиме, реплики подходят не для всех типов рабочих нагрузок, связанных с чтением. Для поддержки любых видов операций чтения процесс синхронизации должен быть переведён в синхронный режим (in-line): реплика должна запрашивать только те данные и состояния, которые изменились с момента её последней синхронизации. Компания отметила, что, несмотря на эти изменения, кворум по-прежнему остаётся ограничивающим фактором для дальнейшего роста. GitHub утверждает, что Spokes обрабатывает более 100 млрд операций в день, и предупреждает, что его протокол фиксации изменений (commit protocol) не сможет обеспечить работу сервиса с миллиарда репозиториев до следующего миллиарда. Сегодня Spokes представляет собой интеллектуальный уровень маршрутизации и балансировки нагрузки, единый API, через который внутренние сервисы получают доступ к данным репозиториев, а также набор фоновых процессов — так называемых «чистильщиков» (sweepers), — которые управляют размещением репозиториев, их восстановлением и перераспределением между узлами хранения. Компания отметила, что после реализации этих шагов следующим ограничивающим фактором станет пропускная способность операций записи. Каждая операция записи по-прежнему зависит от реплик, каждая из которых хранит полную копию репозитория, хотя лишь малая часть данных, записываемых в репозиторий, требует строгого упорядочивания. Объекты Git неизменяемы и идентифицируются по своему содержимому, поэтому их можно сохранять без необходимости достижения консенсуса между узлами. Остаётся лишь небольшой объём данных, и самая сложная задача — упорядочить их максимально быстро, не создавая при этом «узкого места» в другом звене системы. Как ожидается, подробности о финальной версии архитектуры платформы компания сообщит на GitHub Universe.
22.10.2026 [15:10], Руслан Авдеев
Amazon отозвала заявку на строительство кампуса ЦОД в Вирджинии из-за противодействия со стороны властей округа ЛаудонAmazon отказалась от планов строительства кампуса ЦОД в округе Лаудон (Loudoun) в регионе Северная Вирджиния (штат Вирджиния) — сердце мировой индустрии ЦОД. Компания согласилась отозвать заявку на строительство дата-центров на территории одного из кампусов Университета Джорджа Вашингтона (George Washington University Science and Technology Campus) в Эшберне (Ashburn), сообщает Datacenter Dynamics. В социальных сетях представитель наблюдательного совета округа сообщил, что местные власти провели ряд встреч с сотрудниками компании, в результате которых было заключено новое соглашение — Project Potomac Promise. В совете подчеркнули, что основной целью было не допустить строительства на землях университета ЦОД или инфраструктуры, способной обеспечить их работу. При этом Amazon отказывается от судебных разбирательств и попыток отстаивать право на возведение дата-центров на этом участке. В марте Amazon Data Services приобрела у университета (GWU) участок площадью около 49,4 га за $427 млн в рамках сделки с обратной арендой сроком на пять лет. Это давало компании время оформить необходимые разрешения на строительство, а университету — подготовиться к «переезду» с проданной территории. Amazon рассчитывала построить кампус из четырёх зданий ЦОД общей площадью 74 320 м2 — так называемый Bridgefield Tech Center. Но проект столкнулся с противодействием местных жителей, студентов и даже совета округа. Согласно новому соглашению, Amazon передаст округу Лаудон участок площадью около 10 га стоимостью $65 млн. В совете сочли его «идеально подходящим» для строительства нового общественного центра искусств и спортивного комплекса.
Источник изображения: Joshua Hummell/unsplash.com Кроме того, компания согласилась изменить зонирование оставшейся земли, предусмотрев возможность её «смешанного» использования и строительства жилья. Дополнительно в жилищный фонд округа будет перечислено $5 млн. В ответ представители местных властей поблагодарили компанию за «готовность встречаться и вести диалог». По словам вице-президента Amazon по развитию мощностей ЦОД Джоша Вайсмана (Josh Weissman), компания взаимодействует с округом Лаудон в сфере строительства уже 20 лет. На территории округа работают более 3,4 тыс. её сотрудников, поэтому предложение университета о покупке участка не осталось без ответа. Тем не менее в Amazon понимают серьёзные опасения местного сообщества относительно строительства ЦОД на этой территории, поэтому к предложению местных властей отнеслись «со всей ответственностью». Ранее сотрудники администрации округа сообщили наблюдательному совету, что Amazon потребуется дополнительное разрешение местных властей перед началом строительства любых ЦОД на принадлежащем компании участке. Подчёркивалось, что действующее решение о зонировании не допускает эксплуатацию ЦОД в качестве основного вида использования купленной земли. По словам Вайсмана, в компании иначе оценивают «юридический потенциал» участка. Тем не менее Amazon предпочла не ввязываться в судебные разбирательства, решив вместо этого заключить соглашение о реализации инициативы Project Potomac Promise. Учитывая близость округа Лаудон к корпоративным офисам компании и объектам её розничного бизнеса, Amazon признала необходимость расширения строительства доступного жилья на своём участке на фоне быстрого развития округа. Северная Вирджиния является крупнейшим в мире центром размещения ЦОД. В регионе работают сотни соответствующих объектов, совокупная мощность которых измеряется гигаваттами. Значительная часть этих мощностей сосредоточена именно в округе Лаудон, где Amazon также арендует немало объектов.
Источник изображения: Matthew Lancaster/unsplash.com Тем не менее в последние годы власти округа стали всё активнее выступать против новых проектов строительства дата-центров. В частности, они исключили ЦОД из перечня объектов, строительство которых разрешено без дополнительных согласований. Также изучается возможность отозвать право на строительство у владельцев участков, для которых по прежним правилам сохранялся упрощённый режим согласования. Кроме того, рассматриваются моратории на строительство новых ЦОД как на уровне штата, так и на уровне округа. Примечательно, что ещё в феврале 2025 года AWS сообщала о намерении строить ЦОД в «каждом округе» от Северной Вирджинии до Ричмонда. Тем не менее, Вирджиния становится всё менее комфортной для строителей ЦОД. В июле появилась информация, что совет округа Принс-Уильям (Prince William) остановил реализацию проекта строительства крупного ЦОД Dulles South Innovation Center на площади 785 га, а в целом в округе было ограничено разрешение на строительство дата-центров «по умолчанию», без специальной процедуры одобрения. В июле также сообщалось, что округ Лаудон рассматривает мораторий на новые ЦОД, а в сентябре губернатор штата Эбигейл Спанбергер (Abigail Spanberger) подписала указ, ужесточающий правила строительства и эксплуатации ЦОД в Вирджинии. Ещё в 2022 году сообщалось, что на рынке ЦОД в Северной Вирджинии наметился катастрофический недостаток электроэнергии. Уже тогда т.н. «Аллея дата-центров» обгоняла по ёмкости сверхкрупных дата-центров и Европу, и Китай. Наконец, в конце июня произошло знаковое событие: Вирджиния первой в истории одобрила налог на электричество для ЦОД, даже включая то, что операторы будут генерировать сами.
22.10.2026 [15:07], Павел Котов
Red Hat и NVIDIA расширили партнёрство для обеспечения безопасности ИИ-агентовRed Hat объявила о расширении сотрудничества с NVIDIA. Цель партнёрства — обеспечить клиентам безопасность ИИ-агентов, контроль доступа к ИИ-моделям и развёртывание рабочих нагрузок на инфраструктуре Vera Rubin, пишет SiliconANGLE. В центре внимания — решение Red Hat AI Factory with NVIDIA, которое объединяет средства управления средой выполнения агентов, ПО для инференса моделей и аппаратную поддержку в гибридных облачных средах. Red Hat работает над интеграцией эталонной архитектуры NVIDIA OpenShell в свои ИИ-платформы как встроенной функциональности. Предложенный подход к безопасности направлен на устранение двух основных рисков: выхода ИИ-агентов за пределы установленных для них границ, а также их компрометации злоумышленниками — например, посредством внедрения вредоносных запросов или атак на цепочку поставок. Компании стремятся вынести механизмы контроля безопасности за пределы ИИ-агентов, а в ряде случаев и за пределы ОС на хосте. OpenShell выступает в качестве песочницы — изолированной среды выполнения для ИИ-агентов. На более низком уровне работает система безопасности NVIDIA Sentry на базе DPU BlueField; для мониторинга рабочих нагрузок используется ПО DOCA Argus на отдельном устройстве. Argus анализирует определённые структуры памяти хоста, определяя, какие процессы запущены, с какими файлами производится работа, и какие используются сетевые соединения. При обнаружении угрозы система безопасности может инициировать применение политик BlueField, которые изолируют скомпрометированную рабочую нагрузку.
Источник изображения: NVIDIA Эта архитектура опирается на реализованную в Red Hat OpenShift 4.22 поддержку платформы BlueField-3. Она позволяет отделить рабочие нагрузки ИИ на CPU серверов от сетевых функций и сервисов безопасности, работающих на Arm-процессорах модулей BlueField. Таким образом, если злоумышленник скомпрометирует хост, элементы управления инфраструктурой останутся защищёнными. Sentry может изолировать скомпрометированный ИИ-агент за считанные миллисекунды. Перенос функций мониторинга и управления сетью на DPU снижает нагрузку на основные процессоры сервера, высвобождая ресурсы для выполнения ИИ-задач. Партнёрство также связано с вопросами инфраструктуры моделей, необходимых агентам для принятия решения и выполнения действий. Эталонный проект включает средства контроля доступа в рамках схемы «модель как услуга» (Model-as-a-Service) и ИИ-шлюз с технологиями инференса, такими как vLLM, llm-d, NVIDIA Dynamo и микросервисы NVIDIA NIM. Основанное на NVIDIA Inference Hub решение поддерживает самостоятельный выбор моделей пользователями, возможности задавать политики доступа, ограничивать частоту запросов и разграничивать возможности по подписке. Функции управления доступом и выполнения моделей разделены — это даёт клиентам возможность контролировать квоты, распределять затраты и поддерживать производительность в гибридных средах. Компании объявили о совместной поддержке моделей NVIDIA Nemotron, в том числе Nemotron 3.5 Super VL, в среде инференса и обслуживания vLLM. В Red Hat отметили механизмы квантования и спекулятивного декодирования, позволяющие снижать задержку при запуске моделей без потери точности. Версия Red Hat Enterprise Linux for NVIDIA теперь поддерживает процессоры Vera и готова к работе с платформой Vera Rubin. Партнёры стремятся обеспечить совместимость ОС и платформы к моменту выхода нового оборудования. В RHEL for NVIDIA 26.03 для поддержки новой платформы внесены изменения в набор базовых пакетов; при этом сохранены стандартное пользовательское окружение и средства безопасности, включая Security-Enhanced Linux. Когда поддержка оборудования будет включена в основное ядро Linux, клиенты смогут перейти на стандартную версию RHEL без переустановки системы. Сценарии использования, эталонные решения и функции работы с агентами доступны у партнёров, в том числе Cisco, Dell и Lenovo; продолжается работа по нативной интеграции OpenShell. Ранее процессор NVIDIA Vera продемонстрировал превосходство над чипами Intel и AMD. Компания передала в OCP спецификации стоек Vera Rubin и вычислительных узлов в рамках открытой архитектуры MGХ. В инфраструктуре Google Cloud инстансы на базе Vera Rubin NVL72 заработают в ноябре.
22.10.2026 [12:36], Владимир Мироненко
IBM увеличила прогноз по выручке от ПО — акции выросли на 4 %IBM опубликовала финансовые результаты за III квартал 2026 года, завершившийся 30 сентября. Финансовый директор IBM Джеймс Кавано (James Kavanaugh) сообщил, что задержки в заключении сделок в сфере ПО — фактор, обеспокоивший инвесторов в прошлом квартале, — начали преодолеваться. В связи с этим компания повысила прогноз по выручке от ПО. Результаты по этому сегменту за прошедший квартал также превзошли ожидания аналитиков, отметило агентство Reuters. Выручка IBM в III квартале увеличилась на 4,7 %, до $17,10 млрд, превысив средний прогноз аналитиков в размере $16,82 млрд, опрошенных LSEG (по данным CNBC). Скорректированная прибыль на акцию (Non-GAAP) составила $2,95 при прогнозе $2,86. Чистая прибыль (GAAP) составила $2,19 млрд или $2,30 на акцию, превысив показатели аналогичного периода годом ранее, — $1,74 млрд и $1,84 на акцию соответственно. Выручка от ПО увеличилась на 8 % до $7,80 млрд, превысив консенсус-прогноз аналитиков, опрошенных StreetAccount ($7,66 млрд). Гибридные облачные решения (Hybrid Cloud, включая Red Hat) принесли больше выручки на 11 %. Выручка подразделения по автоматизации упала на 3 %, выручка подразделения по обработке данных и ИИ выросла на 19 %, выручка от обработки транзакций — на 9 %. По словам Кавано, около 25 % выручки в сегменте обработки транзакций обеспечили сделки, перенесенные со II квартала, а «остальные 75 % — это полностью новый бизнес». Кавано заявил агентству Reuters, что теперь IBM ожидает роста годовой выручки от продажи ПО на уровне 7–8 % (ранее прогнозировался рост в диапазоне 6–8 %). На фоне этих новостей акции IBM выросли примерно на 4 % на расширенных торгах. Выручка от консалтинга осталась на прежнем уровне, составив $5,3 млрд. Выручка инфраструктурного подразделения (IBM Infrastructure), занимающегося продажей серверов, СХД, коммутаторов и системного ПО, составила $3,7 млрд (рост — 4 %). При этом выручка от продаж аппаратного обеспечения мейнфреймов z упала на 20 %. Что касается прогноза, то компания по-прежнему ожидает, что по итогам года рост выручки составит от 4 до 5 %.
22.10.2026 [00:36], Владимир Мироненко
Google Cloud и NVIDIA запустят в ноябре инстансы на базе Vera Rubin NVL72Google Cloud и NVIDIA объявили, что в следующем месяце в Европе станут общедоступны инстансы Google Cloud A5X на базе систем NVIDIA Vera Rubin NVL72. Они предоставят клиентам комплексную платформу для обучения моделей, инференса и масштабного обучения с подкреплением. A5X используют системы NVIDIA Vera Rubin NVL72, сетевые адаптеры NVIDIA ConnectX-9 SuperNIC, сеть Virgo Network и передовую технологию жидкостного охлаждения четвертого поколения от Google Cloud. Сообщается, что Google Cloud планирует расширить инфраструктуру на базе архитектуры Vera Rubin, доведя количество ускорителей Rubin до 960 тыс. единиц, размещённых на различных площадках. Обучение с подкреплением требует непрерывного цикла: накопления опыта, оценки результатов и обновления моделей. Для этого необходима инфраструктура, способная поддерживать весь процесс в больших масштабах. A5X интегрирует архитектуру Vera Rubin в систему Google Cloud AI Hypercomputer, объединяя вычислительные мощности, сетевые ресурсы и системы хранения данных для поддержки обучения на основе опыта. По мере развёртывания агентских систем компаниям необходимо обеспечивать защиту проприетарных моделей и конфиденциальных данных, лежащих в основе этих систем, даже при использовании инфраструктуры сторонней организации. Google Cloud станет одним из первых облачных провайдеров, предлагающих NVIDIA Confidential Computing в масштабе стойки на bare-metal-инстансах, таких как A4X Max на базе NVIDIA GB300 NVL72. Кроме того, Google Cloud делает конфиденциальные вычисления (Confidential Computing) общедоступными на виртуальных машинах G4 на базе ускорителей NVIDIA RTX PRO 6000 Blackwell Server Edition, предлагая гибкую платформу для конфиденциального инференса и тонкой настройки. Клиенты, включая Vertebrae, Polaris Cloud и Confidential Core AI, используют ВМ Confidential G4 для обеспечения конфиденциальности разговоров, проверяемой работы агентов и корпоративного ИИ, управляемого в рамках заданных политик. Google Cloud и NVIDIA также изучают возможности комплекса технологий NVIDIA DSX MaxLPS для инфраструктуры на базе Vera Rubin, чтобы оптимизировать производительность на ватт и расширить возможности в рамках доступного бюджета электропитания ЦОД.
22.10.2026 [00:19], Павел Котов
DeepSeek открыла исходный код DeepInfer — фреймворка для инференса своего ИИКитайская ИИ-лаборатория DeepSeek открыла исходный код DeepInfer — фреймворка для инференса, на базе которого работают собственные сервисы компании, сообщает SiliconANGLE. Ключевой задачей продукта разработчик называет обеспечение работы с большой пользовательской базой при сохранении приемлемой стоимости. Один кластер, по заявлению DeepSeek, обрабатывает 155 трлн токенов в сутки, а доход при использовании тарифов в периоды низкой нагрузки составляет $38 в час на один GPU. На данный момент DeepInfer поддерживает только модель DeepSeek-V4.1-Flash — по умолчанию загружается версия 1017, вышедшая в минувшие выходные. Фреймворк совместим с GPU NVIDIA на архитектуре Blackwell (SM100) и ускорителями Huawei Ascend 950; поддержка архитектуры NVIDIA Hopper и более старых поколений не предусмотрена. В DeepInfer есть две функции, гарантирующие получение идентичных результатов при повторном запуске с одинаковыми исходными данными. Они работают только на ускорителях NVIDIA. Быстродействие DeepInfer DeepSeek проверяла только на ускорителях NVIDIA, поэтому приведённые результаты бенчмарков получены исключительно в ходе собственных испытаний компании.
Источник изображения: DeepSeek В DeepInfer предусмотрены два способа ускорения работы модели. Спекулятивное декодирование с помощью системы DSpark предполагает генерацию сразу пяти токенов вспомогательной моделью; модуль оценки уверенности прогнозирует, какие из них будут приняты основной моделью. Вычислительные ресурсы для проверки затрачиваются только на наиболее вероятные варианты, благодаря чему количество проверяемых «черновых» токенов на каждом шаге сокращается на 30 %. В реальных рабочих нагрузках это обеспечивает прирост производительности на 4–7 %. Второй механизм почти вдвое сокращает объём вычислений при первичной обработке запроса: через слои декодера модели повторно пропускаются только последние 128 токенов, а не весь запрос целиком. Код для управления KV-кэшем и балансировки нагрузки DeepSeek пока не опубликовала, пояснив, что эти компоненты тесно связаны с внутренней инфраструктурой компании. DeepInfer преимущественно ориентирован на разделение нагрузки между первичной обработкой запросов и генерацией ответов, но реализовывать этот механизм пользователям придётся самостоятельно. В качестве минимальной эффективной конфигурации указываются 128 GPU: по 64 для первичной обработки запросов и генерации ответов. Фреймворк DeepInfer доступен на GitHub под лицензией Apache 2.0. В комплект входит библиотека deepseek-recipe, которая преобразует запросы в последовательности токенов, используя ту же логику, что и официальный API DeepSeek. В этом же репозитории будет размещаться код для инференса и будущих моделей. Поддержка платформы Ascend в DeepInfer появилась вслед за релизом от 30 сентября, в рамках которого DeepSeek при содействии Huawei обеспечила поддержку TileLang — китайского аналога NVIDIA CUDA. Во Внутренней Монголии ИИ-лаборатория намерена построить кампус ИИ ЦОД мощностью 1 ГВт и развернуть там не менее 160 000 ускорителей Huawei Ascend 950DT. Ранее стало известно, что DeepSeek занимается разработкой и собственного ИИ-ускорителя для инференса, чтобы снизить свою зависимость как от NVIDIA, так и от Huawei. |
|



