Крупнейший в Европе разработчик ПО SAP SE отчитался о рекордных финансовых результатах: квартальная выручка компании впервые превысила €10 млрд ($11,2 млрд). Кроме того, портфель облачных заказов вырос на 26 %, увеличился и прогноз годовой выручки, но прогноз операционной прибыли компания сохранила, сообщает Silicon Angle.

Немецкая компания сообщила о прибыли на акцию до вычета некоторых расходов, включая затраты на вознаграждение сотрудников акциями компании, в размере €1,89. Общая выручка составила €10,27 млрд. При этом эксперты прогнозировали прибыль в размере €1,83 на акцию и выручку в размере €10,10 млрд.

По данным SAP, выручка от облачных сервисов в III квартале увеличилась год к году на 25 %, до €6,67 млрд, а операционная прибыль по стандартам non-IFRS выросла на 18 %, до €3,03 млрд. Портфель облачных заказов год к году увеличился на 26 %, до €24,11 млрд. Это выше прогнозов экспертов, рассчитывавших на рост на 24–25 %. При этом компания сохраняет впервые представленный в июле прогноз операционной прибыли за год на уровне €11,8–12,2 млрд.

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

Как сообщил глава SAP Кристиан Кляйн (Christian Klein), результаты подтверждают успешность стратегии «автономного предприятия», впервые представленной в мае в ходе конференции Sapphire для клиентов. Одним из ключевых элементов стратегии является предложение автономного ИИ-агента Joule, предназначенного для повышения производительности и помощи в разработке программного обеспечения, способного использовать более 70 ИИ-моделей. Клиентам предлагается разговорный интерфейс, способный работать с приложениями SAP, а не «внутри» их.

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

По словам Кляйна, именно ИИ в минувшем квартале стал одним из факторов, способствовавших переходу клиентов в облако компании. Сотни клиентов оформили новые подписки, чтобы получить доступ к Joule.

В SAP отмечают, что для годовых финансовых результатов компании решающее значение будут иметь итоги IV квартала. При этом подчёркивается, что компания работает в неблагоприятной экономической обстановке: рост цен на нефть и процентных ставок в США оказывает всё более сильное давление на бизнес.

Вместе с тем отмечается, что рост облачного бизнеса в III квартале отчасти обеспечен возвращением к нормальной работе клиентов, ранее испытывавших значительные финансовые трудности. Это помогло SAP увеличить операционную рентабельность с 28,3 % во II квартале до 29,5 % в III квартале. Свободный денежный поток увеличился на 36 %, до €1,72 млрд.

Выручка SAP от подписок за 2026 финансовый год, как ожидается, приблизится к верхней границе прогнозного диапазона в €25,8–26,2 млрд. Другими словами, рост должен составить 23–25 %. В целом выручка с учётом сокращения бизнеса по продаже бессрочных лицензий должна достичь €36,3–36,8 млрд, увеличившись на 12–13 %.

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

OpenAI объявила о планах сделать свои новейшие большие языковые модели доступными в 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.

Компания «Киберпротект» сообщила о выпуске новой версии программного комплекса «Кибер Бэкап» 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 были исправлены ошибки и недоработки в коде программного решения. С полным списком изменений и улучшений можно ознакомиться в разделе «Что нового» прилагаемой к продукту документации.

Система резервного копирования и восстановления данных «Кибер Бэкап» зарегистрирована в реестре российского ПО Минцифры России и может использоваться организациями для реализации стратегии технологической независимости от импортных решений.

GitHub объявила о переносе 99,99999 % репозиториев в Azure. «За последний год, на фоне экспоненциального роста трафика Git, 99,99999 % репозиториев GitHub стали размещаться одновременно в двух местах: в наших собственных дата-центрах и в Azure. Оставшиеся репозитории — одни из самых активно используемых на платформе, и их переносу мешает лишь один фактор: задержка в 25 мс при обмене данными (round trip)», — сообщила компания.

Компания объяснила сроки и формат перехода «агентным сдвигом» (agentic shift): стремительным ростом трафика, жёсткими ограничениями по энергопотреблению в её дата-центрах и прилегающих регионах, а также физическими трудностями в цепочках поставок. Рост трафика, генерируемого программными агентами, повысил нагрузку на критически важные сервисы (уровень Tier 0), обеспечивающие основные операции с репозиториями.

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

Учитывая масштаб системы и её критическую важность для сообщества, 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.

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 заработают в ноябре.

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 на акцию соответственно.

Источник изображений: IBM

Выручка от ПО увеличилась на 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 %.

Китайская ИИ-лаборатория 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.

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

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.