Вы запускаете локальную модель для кода, видите в характеристиках видеокарты огромные числа TFLOPS и ожидаете мгновенных ответов. Но агент долго думает перед первым токеном, генерация периодически замирает, а при длинном контексте процесс внезапно упирается в память. Именно здесь полезен репозиторий AI Performance Engineering от Wafer. На 26 августа 2026 года список выстроен от одного запроса и одной GPU до ядер, движков инференса и распределённых систем. Это не рейтинг видеокарт для игр и не курс, который нужно пройти от корки до корки. Для вайб-кодера это карта местности: она помогает понять, что измерять, где искать узкое место и какой стек выбирать под реальную работу с кодом.

Почему игровой бенчмарк почти ничего не говорит об инференсе

Частота кадров в игре зависит от рендеринга, драйвера, процессора и конкретного движка. Инференс трансформера устроен иначе. В фазе prefill модель обрабатывает промпт и контекст большими матричными операциями. В фазе decode она последовательно выдаёт токены и часто ограничена скоростью чтения весов из памяти. Поэтому две карты с похожей игровой производительностью могут заметно различаться при запуске одной LLM.

Пиковые TFLOPS тоже не дают готового ответа. Цифра зависит от точности вычислений, поддержки tensor cores и возможности конкретного движка использовать нужные ядра. Важны объём VRAM, пропускная способность памяти, формат весов, длина контекста, размер KV-кэша и накладные расходы рантайма. Репозиторий предлагает опираться на измеренное поведение железа, а не только на теоретический пик или occupancy.

Четыре метрики, которые нужны вайб-кодеру

1. Время до первого токена

TTFT, или time to first token, показывает, сколько вы ждёте до начала ответа. Для агента, которому передали дерево проекта, несколько файлов и подробное задание, это критическая метрика. Она включает обработку входного контекста, планирование запроса и подготовку к декодированию. Разницу между TTFT и скоростью дальнейшей генерации мы подробно разбирали в материале о времени до первого токена.

2. Время на выходной токен

TPOT описывает задержку между токенами после старта ответа. Пользователю удобнее перевести её в tokens/s, но при сравнении важно не смешивать среднюю и медианную скорость. Для интерактивного дополнения кода важна ровная подача, а для длинной автономной генерации файла важнее итоговое время выполнения.

3. Goodput вместо красивого throughput

Throughput отвечает на вопрос, сколько токенов или запросов система обработала в сумме. Goodput учитывает только запросы, уложившиеся в заданные ограничения по задержке. На личной рабочей станции это различие кажется академическим, пока параллельно не запускаются агент, IDE-помощник и индексатор. Система может показывать высокий общий поток, но регулярно задерживать интерактивные ответы. В проверенном списке Wafer для этих понятий указан Etalon, а для воспроизводимых сценариев нагрузки приведены MLPerf Inference и endpoint-бенчмарки.

4. Память и запас под контекст

Проверяйте не только размер файла модели. В VRAM размещаются веса, KV-кэш, служебные буферы и иногда графы выполнения. Чем длиннее контекст и больше одновременных запросов, тем заметнее KV-кэш. Если модель едва помещается, движок может выгрузить часть данных в RAM, после чего скорость перестаёт отражать возможности GPU. Практический пример конфигурации потребительской карты есть в статье про локальную Qwen на RTX 3090.

Как провести честный тест своей задачи

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

  1. Зафиксируйте окружение. Запишите модель, ревизию, тип квантования, движок, его версию, драйвер, GPU, объём VRAM и параметры запуска.
  2. Прогрейте систему. Первый запуск может включать загрузку весов, компиляцию ядер и построение графов. Отделяйте холодный старт от тёплых запросов.
  3. Выравняйте входы. Сравнивайте варианты на одинаковых промптах, длине контекста, лимите вывода и настройках сэмплирования.
  4. Снимайте распределение. Одного среднего мало. Запишите медиану, p95, худший результат, TTFT, TPOT, tokens/s и пиковую VRAM.
  5. Проверяйте качество. Быстрый неверный патч бесполезен. Запускайте тесты, линтер и проверку сборки, а затем считайте долю успешно выполненных заданий.
  6. Повторите при конкуренции. Проверьте один запрос и два или четыре параллельных запроса, если так работает ваш агентный процесс.

Для простого стенда достаточно клиента, который отправляет запросы в OpenAI-совместимый endpoint и сохраняет временные отметки. TTFT считается от отправки запроса до первого фрагмента ответа, полное время до закрытия потока. Потребление памяти можно снимать средствами производителя GPU, а системную временную шкалу на NVIDIA удобно исследовать через Nsight Systems. Если нужно понять, почему конкретное ядро медленно, список ведёт к Nsight Compute, roofline-анализу и Compute Sanitizer.

Как выбрать движок инференса, а не любимый логотип

В актуальном репозитории среди основных production-реализаций названы vLLM, SGLang и TensorRT-LLM. Это не означает, что один из них всегда лучший. Выбор зависит от модели, железа и характера нагрузки.

Смотрите также на поддержку квантования. GPTQ, AWQ и SmoothQuant решают разные задачи, а одинаковая надпись «4 bit» не гарантирует одинаковую скорость или качество. Проверьте, есть ли оптимизированное ядро именно для выбранного формата. Иначе компактные веса сэкономят память, но преобразования на лету съедят часть выигрыша.

Что подсказывает структура списка Wafer

Сильная сторона подборки в последовательности уровней. Раздел GPU fundamentals объясняет потоки, warps, блоки и иерархию памяти. Kernel optimization показывает, почему размещение данных и число обращений к памяти иногда важнее количества операций. В разделах про attention собраны FlashAttention от первой версии до FlashAttention-4 и FlashInfer. Затем идут Triton, CUTLASS, CuTe, CUDA Tile и аналоги для AMD, JAX и AWS.

Для пользователя кодового агента наиболее прикладной слой начинается с inference engines. Там находятся continuous batching, PagedAttention, chunked prefill, KV-кэш, квантование и speculative decoding. Если один большой запрос портит задержку остальных, изучайте chunked prefill и планировщик. Если память заканчивается при длинных сессиях, смотрите KV-кэш, GQA и квантование кэша. Если decode медленный, тестируйте speculative decoding, но обязательно проверяйте долю принятых токенов draft-модели.

Распределённые разделы нужны не каждому. Tensor parallelism, NCCL, disaggregation prefill и decode, маршрутизация и Kubernetes становятся актуальны, когда одна GPU уже не вмещает модель или требуется обслуживать команду. Для одного разработчика преждевременный кластер чаще добавляет сетевые задержки и обслуживание. Иногда выгоднее использовать быстрый внешний endpoint, как в примере с быстрым инференсом Cerebras, и сравнить его полную задержку с локальным вариантом.

Практическая матрица выбора

Сведите кандидатов в таблицу или JSON, где строка означает связку GPU + модель + квантование + движок. Для каждой связки сохраните следующие поля:

После этого задайте пороги. Например: первый токен не дольше двух секунд для короткого запроса, не меньше 25 tokens/s при генерации, успешная сборка в 70 процентах тестовых задач, запас VRAM не меньше 15 процентов. Побеждает не максимальная цифра в одном столбце, а самый дешёвый и стабильный вариант, который проходит ваши пороги.

Типичные ошибки при сравнении

Минимальный план на один вечер

Выберите одну модель для кода и два доступных движка. Подготовьте десять обезличенных задач, запустите по пять повторов после прогрева и соберите TTFT, полное время, tokens/s, VRAM и результат тестов. Затем повторите длинную задачу с двумя параллельными запросами. Такой эксперимент даст больше пользы, чем десятки таблиц с абстрактными пиковыми показателями.

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

Вывод

GPU performance engineering для вайб-кодера начинается не с написания CUDA-ядер. Сначала вы формулируете рабочую нагрузку, измеряете TTFT, TPOT, goodput, память и качество результата, затем сравниваете связки железа, модели, квантования и движка. Подборка Wafer полезна как проверенный навигатор по первичным статьям, официальной документации и реальным реализациям. На 26 августа 2026 года в ней отдельно отмечена быстро меняющаяся frontier-секция, проверенная авторами 23 августа 2026 года, включая AI-generated kernels и watchlist будущего железа. Используйте этот список как справочник для следующего измерения, а не как обещание готовой победы. Ваш лучший стек определяется кодом, контекстом, бюджетом и допустимой задержкой.