Google Cloud опубликовала бенчмарк, сравнивающий задачи классификации и генерации на TPU v6e в 15:36 UTC 4 сентября. Его главный вывод: "Для задач генерации с высокой долей декодирования модель Gemma 3 27B упирается в жесткий предел производительности после 64 одновременных пользователей, выходя на плато с 4,12x нормализованным множителем пропускной способности при 128 пользователях. В то же время модель 12B масштабируется до множителя 8,19x."

Оговорка ниже по тексту

"При экстремально высоких уровнях конкуренции (например, 128 пользователей) вы можете заметить математически аномальные всплески средней пропускной способности. … При жестких ограничениях ресурсов неправильно настроенные --max-num-seqs или --max-model-len могут привести к тихим пропускам запросов, тайм-аутам соединений на стороне клиента или OOM на рабочих узлах GKE. Когда такие неудачные запросы завершаются немедленно, они ложно укорачивают длительность сессии и искусственно завышают показатели пропускной способности. Точки данных для 128 пользователей в этих бенчмарках представляют абсолютный предел стабильности кластера и должны рассматриваться как потолок, а не как устойчивый производственный показатель."

Что говорят проверяемые строки

Таблица генерации для 16, 32, 64 и 128 пользователей показывает 1,00x / 1,98x / 2,96x / 8,19x для Gemma 3 12B и 1,05x / 1,97x / 4,00x / 4,12x для 27B. При 64 одновременных пользователях — в последней строке, от которой пост не отрекается, — более крупная модель быстрее, что противоположно заголовку. Вся история о "пределе производительности" — это сравнение двух чисел из строки, которую авторы сами дезавуируют.

Здесь нет абсолютного измерения

Каждая ячейка — это кратность по отношению к Gemma 3 12B при 16 пользователях, в таблице, где заголовок столбца гласит "Throughput (req/s)". Ни одной абсолютной величины запросов в секунду здесь нет и нет данных о стоимости — в посте, чей первый абзац посвящен unit economics. Конфигурация — пул узлов TPU v6e на одном хосте в топологии чипов 2x2 на GKE Autopilot, обслуживание через vLLM посредством tpu-inference, при max-model-len=128000, max-num-batched-tokens=8192, max-num-seqs=512.

Что не так с поданным выводом

Это будут цитировать как "TPU v6e дает 8x". Речь идет о нормализованной кратности, на одном узле, на одном стеке обслуживания, при уровне конкуренции, который издатель называет нестабильным и, возможно, искаженным из-за пропущенных запросов. Пост необычно откровенен — оговорка там прямо есть, без смягчений — и эта откровенность содержится в абзаце, который почти никто не дочитывает. Таблица классификации, где пики 6,04x-6,37x получены из той же строки для 128 пользователей, страдает от той же проблемы.