Профиль нагрузки важнее названия модели

Одна и та же модель может уверенно обслуживать короткие чаты и собирать очередь на длинных документах. Название осталось прежним, а работа изменилась: сколько токенов нужно обработать на входе (prefill), сколько сгенерировать в ответе (decode) и какую часть вычислений можно пропустить благодаря KV-кэшу (KV cache).

Поэтому я бы начинал сравнение с профиля нагрузки (workload shape). Среднее число запросов в секунду (RPS) не показывает, насколько длинны вход и ответ, сколько запросов выполняется одновременно и приходят ли они ровным потоком или всплесками. До выбора модели, GPU и схемы обслуживания нужны эти распределения, требования к задержке, возможность пакетной обработки (batching) и фактическое повторное использование кэша. Для агента добавляются число шагов и стабильность префикса между ними.

Дальше можно воспроизвести записанный поток запросов (replay) или собрать синтетический профиль, который сохраняет его характеристики. На нём и сравнивать варианты. Название модели и характеристики ускорителя помогают выбрать кандидатов; измерение на целевой нагрузке показывает, кто справится с задачей.

Следующий вопрос — смогут ли разные запросы делить один пул. Его разбираю в статье «Ловушка гибридных резонеров». Границы ответственности за обслуживание моделей описаны в разделе Inference Plane.