SemiAnalysis выделила в работе ИИ-агентов отдельный тип нагрузки на серверы

Когда ИИ-агент продолжает долгую сессию, серверы работают не так, как при новом запросе или генерации ответа, пишут аналитики SemiAnalysis в большом разборе того, как дата-центры обслуживают языковые модели.

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

Повод: Тандж Беннетт (Tanj Bennett), Брайан Шан и основатель SemiAnalysis Дилан Пател разобрали, как модели со смесью экспертов¹ раскладываются по ускорителям, стойкам и хранилищам. Они выделили отдельный режим, в котором к длинной сохранённой истории добавляется новая порция — реплика пользователя или ответ инструмента, — и назвали его мидфиллом.

Как это работает: мидфилл находится между двумя привычными режимами: префиллом, когда модель читает новый запрос с нуля, и генерацией ответа по одному токену.

• К контексту в полмиллиона токенов может добавиться всего несколько сотен или тысяч новых.
• На каждый прочитанный байт здесь может приходиться в сотни раз больше вычислений, чем при генерации одного токена.
• Зато сохранённого состояния, KV-кэша², модель читает в десятки раз больше, чем при префилле с тем же числом новых токенов.
• Поэтому авторы советуют держать для мидфилла отдельный пул серверов: оборудование то же, но модель разложена по ускорителям иначе.

Интрига: в сессиях с моделями Anthropic, по собственным данным SemiAnalysis, история регулярно сжимается у практического предела: около 250 тыс. токенов у Claude Opus 4.8 и 1 млн у Fable. На тех же графиках видны короткие выбросы, которые авторы прозвали «сталактитами» и связывают с закрытыми особенностями моделей Anthropic.

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

Общая картина: главный вывод авторов об оборудовании — скорость памяти ценнее её объёма. Быстрая память ускорителей (HBM) в несколько раз дороже обычной DDR, и её не хватает. Держать в ней стоит только то, что модель обрабатывает прямо сейчас, а законченный ход сразу отправлять в память процессоров и общее хранилище.

В цифрах: авторы прикинули, сколько быстрой памяти нужно одной ступени конвейера — группе ускорителей, которая держит часть слоёв модели:

• Два миллиона токенов живого контекста у модели со сжатым вниманием займут около 140 ГБ.
• Двойная буферизация, при которой одни данные подгружаются, пока другие в работе, поднимает эту цифру до 280 ГБ.
• С весами модели, рабочими буферами и запасом выходит 400–500 ГБ — этот ориентир авторы предлагают для систем 2027 года.

Расклад: авторы смоделировали работу Kimi K3 на системах Nvidia B200, B300 и GB200, где в стойке от 16 до 64 видеокарт:

• В большинстве оптимальных конфигураций модели хватает меньше 80 ГБ быстрой памяти на видеокарту, даже с буферами для передачи контекста.
• Префилл на всех трёх системах идёт почти одинаково: его сдерживают вычисления, а они у поколения Blackwell³ общие.
• В мидфилле GB200 быстрее всех выдаёт первый токен, а B300 догоняет её там, где важнее общая пропускная способность.
• Больше всего энергии на запрос уходит на генерацию: на ответ в 1 000 токенов нужно около 1 000 проходов через модель.

Но: всё это прогноз по модели нагрузки и оборудования, а не замеры на реальных серверах.

Что говорят: «Данные, которые лежат в памяти без дела, — это расход, а данные, которые движутся на обработку, — выручка», — пишут Беннетт, Шан и Пател.

Похожий приём SemiAnalysis уже показала 18 сентября: после переноса части DeepSeek V4.1-Flash из видеопамяти в оперативную память одной копии модели хватило двух ускорителей B300 вместо четырёх.