Китайская METASTONE представила TokenFleet для эффективной маршрутизации GPU-задач

Китайская компания «Шиши кэцзи» (METASTONE), работающая под брендом независимого оператора полного стека вычислительных мощностей, представила на конференции CCF по высокопроизводительным вычислениям 2026 года новую систему планирования распределённых задач TokenFleet. Разработка обещает заметно повысить эффективность уже развёрнутых GPU-кластеров за счёт более грамотной маршрутизации запросов, согласования мощностей между дата-центрами и управления смешанными нагрузками. Иными словами, речь идёт о попытке выжать больше полезной работы из того железа, которое уже стоит в стойках, не докупая новые ускорители.

Проблема, которую решает TokenFleet, знакома любому, кто эксплуатирует инференс-сервисы. Внутри GPU-кластера очереди запросов и простаивающие ресурсы нередко возникают одновременно. Модели уже развёрнуты, но кластеру приходится обслуживать сразу несколько бизнес-задач: несколько моделей делят одни и те же мощности, у разных арендаторов свои требования к уровню сервиса. Короткие диалоги ждут мгновенного отклика, обработка длинных документов требует больше вычислений и видеопамяти, а офлайн-пакетные задания имеют дедлайны. Если сервисы разнесены по нескольким дата-центрам, приходится думать ещё и о том, как согласовать их ёмкости. Простое разделение потоков приводит к тому, что часть экземпляров обрастает очередями, тогда как мощности в других местах простаивают. Длинные запросы и пакетные задачи давно конкурируют с интерактивными, а тайм-ауты, отмены и повторные вычисления съедают ресурсы, так и не превращаясь в качественно оказанную услугу.

Авторы проекта предлагают смотреть на инференс-сервис как на своеобразную фабрику по производству токенов: GPU — это станки, инференс-экземпляры — рабочие места, а запросы бизнеса — заказы. TokenFleet как раз и отвечает за то, чтобы заказы правильно соотносились с производственными мощностями. Одна и та же группа оборудования при разных задачах и разных схемах распределения даёт разное время ожидания и разный объём выполненной работы, отвечающей требованиям. Ключевая метрика, на которую ориентируется система, — это полезная выдача токенов, то есть объём успешно выполненных и соответствующих заявленному уровню сервиса результатов. Оптимизация идёт при условии, что качество модели, требования к сервису и бюджет вычислений остаются неизменными, а цель — повысить полезный выход токенов и снизить стоимость единицы такой полезной продукции.

За тремя ключевыми технологиями стоят вполне конкретные задачи. Модуль TokenPilot выбирает экземпляр внутри одного пула моделей, FleetMind отвечает за согласование мощностей между дата-центрами, а SLOMax занимается допуском смешанных нагрузок, управлением очередями и распределением ёмкости. Вопросы о том, кому отдать запрос, когда поставить задачу в очередь и как согласовать мощности разных площадок, в итоге сводятся к одному показателю — объёму успешно выполненных и соответствующих требованиям токенов.

TokenPilot при выборе экземпляра одновременно оценивает выгоду от кэша и цену ожидания в очереди. Короткий вопрос-ответ и длинный документ могут требовать совершенно разных вычислений и видеопамяти, даже если формально считаются одним запросом, поэтому распределять нагрузку только по количеству запросов неэффективно. Кэш добавляет ещё один слой компромисса: запрос с одинаковым длинным префиксом, отправленный на экземпляр, сохранивший соответствующий KV-кэш, может переиспользовать ранее посчитанное и сократить предварительную обработку входа. Но у экземпляра с высоким попаданием в кэш может быть длинная очередь, и сэкономленное на вычислениях время уйдёт на ожидание. TokenPilot взвешивает оба фактора, оценивает объём работы по размеру входа, бюджету выхода и переиспользуемому префиксу, а затем оценивает кандидатов с учётом очереди, токенов в обработке, давления на KV-кэш и прогнозируемой задержки. По данным настройки модели GLM5.3, которые приводит «Шиши кэцзи», на протестированном кластере ускорителей и при соответствующей нагрузке маршрутизация с прогнозом задержки снизила P95 задержки первого токена на 32,4 процента, а P50 — на 71,3 процента. Показатель P50 отражает медианный уровень, P95 — ожидание хвостовых запросов, и эти цифры говорят об улучшении отклика в конкретных условиях, тогда как экономический эффект ещё нужно оценивать вместе с пропускной способностью и загрузкой ресурсов.

FleetMind добавляет к картине ещё один уровень — суждение о доступной ёмкости между площадками. Наличие свободных GPU вовсе не гарантирует, что площадка сразу примет заказ: важно, развёрнута ли целевая модель, совпадает ли версия, готов ли сервисный эндпоинт и сколько времени займёт передача по сети. FleetMind собирает сведения о доступности моделей, реальной ёмкости и состоянии сети в разных дата-центрах, сначала выбирает площадку исполнения, а уже затем локальный движок принимает решение о конкретном экземпляре. Когда горячая площадка начинает обрастать очередью, система проверяет, есть ли в других местах готовые эндпоинты той же версии модели и остаток мощности, и решает, можно ли принять туда новые запросы, допускающие межрегиональное исполнение. При этом сначала должны выполняться ограничения по правам доступа и территориальному размещению данных, а уже потом сравниваются задержка возврата, очередь, вычисления, кэш и передача. Согласование работает на разных временных горизонтах: в коротком цикле меняется маршрут новых запросов, в длинном — расположение копий модели и точек прогрева, с резервированием ёмкости, учётом пределов нагрузки и автоматическим откатом, чтобы сокращать рассогласование мощностей.

SLOMax отвечает за то, чтобы разные по требованиям запросы не мешали друг другу. Интерактивному диалогу важны задержка первого токена и скорость генерации, задачам с длинным контекстом — обработка входа и ёмкость KV-кэша, офлайн-пакетам — дедлайны и пропускная способность. В одной очереди они начинают конкурировать за ресурсы, а длинная предварительная обработка, давление на KV-кэш и пакетные нагрузки могут вытеснять интерактивные запросы. SLOMax определяет объём работы по длине входа, бюджету выхода, типу задачи и целям арендатора, а затем организует допуск по уровням, очереди по пулам и согласование ёмкости, защищая интерактивную часть и ограничивая взаимное влияние длинных и коротких запросов. Чтобы измерять эффект, TokenFleet берёт за цель полезную пропускную способность — объём выходных токенов успешно завершённых и соответствующих оговорённым требованиям запросов за тестовый период, делённый на его длительность, причём для разных категорий задач пороги определяются отдельно. Система возвращает в планировщик данные о полезной пропускной способности, отказах, отменах и повторах и постоянно подстраивает допуск и пропорции ёмкости. В расчётном примере для GLM5.3, который приводит компания, после внедрения согласованного управления потоком общая пропускная способность выросла примерно на 1,5 процента, полезная пропускная способность — примерно на 29,4 процента, а доля соответствующих требованиям результатов поднялась с примерно 67 до примерно 86 процентов. Это именно расчётная оценка, и реальный эффект ещё предстоит проверять на конкретных нагрузках и порогах сервиса.

Сама «Шиши кэцзи» описывает себя как независимого оператора полного стека вычислительных мощностей, не привязанного к конкретному производителю больших моделей и предлагающего заказчикам комплексную поставку — от оборудования и сетевой инфраструктуры до планирования, оптимизации и эксплуатации. Компания опирается на опыт, полученный в национальных вычислительных центрах, заявляет об уровне SLA выше 99,95 процента, управляет более чем 20 тысячами петафлопс вычислительных ресурсов и эксплуатирует более десяти суперкомпьютерных интеллектуальных центров, два из которых относятся к национальному уровню, а её команда имеет на счету три премии Гордона Белла. Если раньше выпущенный компанией движок Meta-Infer повышал эффективность отдельного инференс-экземпляра, то TokenFleet переносит акцент на планирование уровня кластера: на то, как распределяется каждый запрос и как используется каждая единица ёмкости. Именно от этого, по замыслу разработчиков, зависит, станет ли инференс на отечественных мощностях дешевле и доступнее для большего числа бизнес-задач.