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

Железо для инференса: когда одной GPU уже недостаточно

Параллелизация между GPU: pipeline, tensor и sequence parallelism

Если модель не помещается на одну GPU, ее приходится параллелить между несколькими GPU.
Для распределения нагрузки при инференсе крупных моделей применяются три основные техники:

• Pipeline Parallelism (PP) — вертикальное разделение модели по слоям. Первый GPU обрабатывает начальные слои нейросети, затем передает промежуточный результат на второй GPU, который считает следующие слои, и так далее. Это позволяет запускать модели, не помещающиеся в память одной карты, но требует точной балансировки, чтобы ускорители не простаивали в ожидании данных от соседей (проблема "pipeline bubble").

• Tensor Parallelism (TP) — горизонтальное разделение вычислений внутри одного слоя. Вместо того чтобы один GPU считал огромную матрицу целиком, операция "нарезается" на части: каждый ускоритель параллельно вычисляет свой блок, после чего они мгновенно синхронизируют результаты. Поскольку обмен данными происходит постоянно и внутри одного шага, именно здесь возникает критическая потребность в сверхбыстрой шине — без NVLink эта техника упирается в ограничения пропускной способности PCIe.

• Sequence Parallelism (SP) — разделение на уровне входных данных, где "режется" сама размерность последовательности. Разные GPU параллельно обрабатывают разные фрагменты длинного пользовательского запроса или документа. Эта техника стала стандартом де-факто для моделей с гигантским контекстным окном (сотни тысяч токенов), так как она защищает память отдельного GPU от переполнения кэшем внимания (KV-cache).

Основные способы распределить модель между GPU. Pipeline parallelism делит слои, tensor parallelism делит матричные операции, sequence parallelism распределяет обработку по длине последовательности.

В реальных системах техники часто комбинируют. Но как только появляется параллелизация между GPU, становится важен канал обмена данными.

NVLink против PCI Express: почему меж-GPU обмен становится узким местом

Для обмена между GPU есть два принципиальных варианта: PCI Express и NVLink.
NVLink — это высокоскоростная шина прямого соединения между GPU внутри сервера.По сравнению с PCI Express (PCIe), NVLink обеспечивает значительно более высокую пропускную способность и меньшую задержку передачи данных.

Рост пропускной способности NVLink в поколениях NVIDIA GPU. Чем больше модель зависит от обмена между видеокартами, тем важнее скорость меж-GPU соединения.

Поколения NVIDIA GPU различаются не только производительностью, но и NVLink-поддержкой.

Важная практическая оговорка: потребительские RTX-карты не поддерживают NVLink в том смысле, который нужен для production-запуска больших моделей. Их можно рассматривать, если модель помещается в одну GPU. Если модель нужно разносить на несколько GPU, NVLink становится критичным.

Бенчмарки GPU: когда новое поколение не спасает без NVLink

Хороший пример этой проблемы — бенчмарк CloudRift, сравнивающий RTX Pro 6000 с датацентровыми GPU. Смысл сравнения сводится к простому правилу: производительность самой карты имеет значение лишь до тех пор, пока модель помещается в один GPU. Как только требуется 4 или 8 карт, отсутствие NVLink превращает соединение по PCIe в бутылочное горлышко.
Источник: https://www.cloudrift.ai/blog/benchmarking-rtx6000-vs-datacenter-gpus

Инференс модели, помещающейся в одну GPU. В таком режиме новая одиночная карта может конкурировать с датацентровыми решениями по скорости.

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

Производительность при распределении модели на восемь GPU. В многокарточном режиме пропускная способность шины и NVLink заметно влияют на итоговый throughput.

Стоимость токена в конфигурации на восемь GPU. Чем больше обмена между картами, тем быстрее PCIe становится экономическим ограничением, а не только техническим.

Крупная модель, занимающая все восемь GPU. При такой загрузке различия в HBM-памяти, NVLink и межкарточном обмене особенно сильно отражаются на throughput.

Стоимость токена для крупной модели на восьми GPU. Датацентровые конфигурации с быстрой связью между картами могут быть дешевле в пересчете на миллион токенов.

Вывод из этих графиков: если модель помещается в память одного ускорителя, целесообразно использовать серверную конфигурацию с одним производительным GPU. Если модель не влезает и требует распределения по нескольким устройствам, нужно переходить на решения с шиной NVLink. Чем больше GPU участвует в инференсе, тем сильнее разница в пропускной способности между NVLink и PCIe.

Фреймворки инференса: как runtime влияет на throughput и latency

Оптимизации на уровне фреймворков: batching, PagedAttention и FlashAttention

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

Batching: как загрузить GPU и не заставить короткие запросы ждать длинные

Базовая оптимизация — batching. Она позволяет нагрузить простаивающую GPU и повысить пропускную способность.
У LLM есть нюансы:

• веса модели общие и загружаются один раз;
• KV cache свой для каждого запроса в пакете;
• классический статический batching демонстрирует низкую эффективность, так как при разном количестве генерируемых токенов короткие запросы уходят в простой, дожидаясь окончания самого длительного вычисления.
  Поэтому современные inference-фреймворки используют dynamic batching (или continuous batching): новые запросы добавляются в batch, а завершенные убираются на лету.

PagedAttention: как уменьшить фрагментацию KV cache

PagedAttention оптимизирует память KV cache. Вместо выделения непрерывного блока памяти под максимальную длину последовательности память разбивается на небольшие страницы. Они выделяются по мере необходимости. Это уменьшает фрагментацию и позволяет обслуживать больше параллельных запросов.

FlashAttention: как ускорить attention за счет работы с SRAM

FlashAttention оптимизирует вычисление attention на уровне GPU. Обычная реализация создает большие промежуточные матрицы n × n, которые не помещаются в быструю SRAM и уходят в более медленную HBM. FlashAttention переписывает алгоритм так, чтобы считать attention блоками и держать данные в SRAM.

Софт для инференса LLM: Ollama, TGI, vLLM и TensorRT-LLM

Сравним несколько популярных вариантов запуска.

Базовый ориентир для сравнения: 13B-модель на одной A100 GPU. Цифры выше стоит читать как ориентир для сравнения классов решений, а не как универсальный рейтинг: конкретные значения зависят от модели, GPU, длины контекста, batch-а и настроек сервера.
Практический смысл такой:

• Ollama хороша для локального запуска и экспериментов, но не для production-нагрузки.
• Хотя TGI имеет нужные оптимизации, он уступил лидерство на рынке: сейчас проект находится в режиме базовой поддержки, о чем авторы прямо пишут в документации.
• vLLM стал де-факто стандартом production-инференса: активно развивается, поддерживает OpenAI-compatible API и основные оптимизации.
• TensorRT-LLM может дать максимальную производительность на NVIDIA, но требует компиляции и сильнее привязан к конкретному железу.

Triton Inference Server

Отдельно стоит NVIDIA Triton Inference Server. Это не только LLM-фреймворк, а универсальная платформа инференса.
Triton поддерживает разные backend-ы:

• TensorRT;
• TensorRT-LLM;
• PyTorch;
• TensorFlow;
• ONNX Runtime;
• OpenVINO;
• Python;
• vLLM.
  Он позволяет держать несколько моделей на одном сервере, управлять жизненным циклом моделей, предоставлять API, отдавать метрики и подключать разные frontend-ы, включая OpenAI-совместимый.

Архитектура Triton Inference Server. Data Plane принимает inference-запросы, Control Plane управляет моделями, а backend-ы выполняют конкретные runtime-реализации.

API Triton для управления моделями и inference-запросами. Такие endpoints позволяют автоматизировать загрузку моделей, генерацию и streaming-ответы.

Backend-слой Triton соединяет единый серверный API с разными движками инференса. Это позволяет запускать разные модели через общий production-интерфейс.
Но у Triton есть минусы. Во-первых, он добавляет overhead. Если запустить vLLM напрямую и vLLM внутри Triton, вариант с Triton будет медленнее. Во-вторых, новые версии backend-ов и поддержка новых моделей доходят до Triton с задержкой. Если свежая модель уже работает в новой версии vLLM, в Triton ее может еще не быть.

Управление нагрузкой: почему throughput без latency ничего не гарантирует

Что влияет на время ответа LLM

Время ответа LLM зависит от четырех факторов:

• используемой модели;
• количества токенов в запросе;
• количества сгенерированных токенов;
• общей нагрузки на систему.

Из чего складывается время ответа LLM. На общую задержку влияют сеть, очередь, prefill входного контекста и последовательная генерация выходных токенов.
Для LLM особенно важны выходные токены. Prefill можно параллелить, но decoding идет последовательно, токен за токеном. Поэтому именно генерация часто определяет пользовательскую задержку.

Пропускная способность и RPS: больше параллельности не всегда лучше для пользователя

Согласно результатам бенчмарка производительности Artificial Analysis для модели DeepSeek, с ростом параллельных запросов общая пропускная способность растет. Но это не значит, что пользовательский опыт становится лучше.

Throughput растет вместе с параллельностью только до насыщения системы. После этого запросы начинают ждать в очереди, а пользовательская задержка увеличивается.
Если принять длину ответа за 1000 токенов, можно оценить, сколько времени будет ждать один пользователь при разной параллельности и какой RPS получится при такой длине ответа.

На первый взгляд, с ростом параллельности RPS растет. Но одновременно падает скорость генерации для отдельного запроса, а значит растет пользовательская задержка. Система может выдавать больше токенов суммарно, но конкретный пользователь ждет дольше.
Поэтому нельзя ориентироваться только на throughput. Нужно смотреть latency.

Метрики задержки: TTFT, ITL, TPOT и TTLT

Основные метрики задержки:

• TTFT, Time to First Token — время до первого токена;
• «ITL (Inter-token Latency) / TPOT (Time Per Output Token) — задержка между токенами, или время на генерацию одного выходного токена. В профильной литературе могут встречаться обе аббревиатуры, но фактически они обозначают одну и ту же метрику;
• TTTLT (Total Time to Last Token) / End-to-End Request Latency — полное время до генерации последнего токена, которое фактически отражает итоговую задержку всего запроса для пользователя.

Метрики задержки LLM-запроса. TTFT отвечает за время до первого токена, ITL/TPOT описывает скорость генерации, TTLT показывает время до полного ответа.
Смотреть нужно не только среднее и не только медиану. В production важны p90, p95, p99.
Для правильного чтения графиков важно понимать разницу в перцентилях. Медиана (p50) показывает время, быстрее которого обрабатывается 50% запросов, но вторая половина может быть значительно медленнее. Поэтому для оценки реального пользовательского опыта критичны метрики p90, p95 и p99. Например, p99 означает, что 99% всех запросов уложились в это время, и позволяет отследить тот самый худший 1% «хвостовых» задержек, который сильнее всего портит впечатление от продукта.

TPOT при разной параллельности. Рост concurrency увеличивает задержку между токенами, поэтому максимальный throughput не всегда совместим с комфортной скоростью ответа.

TTFT и TTLT под нагрузкой. Чем выше параллельность, тем дольше запрос может ждать первого токена и тем позже пользователь получает полный ответ.
При росте числа параллельных запросов TTFT и TTLT растут. Для чата это критично: если первый токен приходит через 10 секунд, пользователь воспринимает систему как медленную, даже если суммарный throughput высокий.

TPS и маленькие модели: самый быстрый способ улучшить latency и экономику

Еще одна важная метрика — TPS, tokens per second. Она показывает, сколько токенов модель генерирует в секунду.

Скорость генерации у моделей разного размера. Если меньшая или дистиллированная модель решает задачу, она часто дает кратный выигрыш по latency и стоимости.
Здесь хорошо видно, почему стоит начинать с маленьких моделей. Дистиллированная или меньшая модель может работать в десятки раз быстрее большой reasoning-модели. Практический ориентир: разница может быть порядка 30 раз.
Если маленькой модели хватает для задачи, это самый сильный способ улучшить latency и экономику. И только если качества не хватает, стоит переходить к большой модели и платить за нее вычислениями, памятью и эксплуатацией.

Где брать метрики: Prometheus, Grafana и готовые dashboard-ы vLLM

Практический плюс: современные production-фреймворки уже отдают метрики из коробки.
Например, vLLM публикует метрики в формате Prometheus.

Пример метрик vLLM в формате Prometheus. Фреймворк отдает данные по запросам, токенам, очередям и задержкам для мониторинга.
Дальше схема стандартная: Prometheus забирает метрики, Grafana показывает dashboard-ы.

Пример scrape-задачи Prometheus для vLLM. Конфигурация указывает endpoint метрик и интервал, с которым мониторинг забирает новые значения.
У vLLM есть готовые dashboard-ы для Grafana:
Один dashboard показывает query statistics: API, время запросов, время ответов. Второй — performance statistics: TTFT, ITL, TTLT, TPS, входящие и выходящие токены, percentile-метрики

_Готовые Grafana dashboard-ы для vLLM. Их можно использовать как стартовую точку для мониторинга query statistics и performance statistics.
_

Performance dashboard vLLM в Grafana. На панели видны percentile-метрики, throughput и скорость обработки входных и выходных токенов.

Связь задержки и throughput на Grafana dashboard. Такие графики помогают увидеть, где рост нагрузки начинает ухудшать пользовательскую скорость ответа.
Вывод по управлению нагрузкой:

• сначала пробовать маленькие модели;
• обязательно делать нагрузочные замеры;
• использовать метрики из vLLM, Triton и других фреймворков;
• искать баланс между задержкой и пропускной способностью;
• смотреть не только throughput, но и p90/p99 latency.

Экономика эксплуатации LLM: когда self-hosted дороже API

Стоимость эксплуатации большой LLM: что хранится во VRAM

Отдельный вопрос: сколько стоит self-hosted-инференс большой модели.

Для оценки порядка возьмем большую MoE-модель уровня DeepSeek V3/R1 в 4-битной квантизации. Это хороший пример сценария, где веса, активные эксперты и KV cache вместе быстро превращаются в инфраструктурную задачу. Во VRAM будут храниться несколько крупных компонентов.

Это грубая оценка, но она хорошо показывает порядок величин. Большая модель требует не «одну хорошую видеокарту», а полноценный серверный контур.
Для комфортного запуска потребуется около 600 ГБ VRAM — например, сервер на базе 8 ускорителей NVIDIA H100, — а также много CPU-ядер, большой объем RAM, Docker, NVIDIA Container Runtime и вся эксплуатационная инфраструктура.

Стоимость серверов и сравнение с API

Для оценки порядка затрат полезно посмотреть на стоимость серверов у разных поставщиков и

Почасовая аренда виртуальной машины с 8 GPU NVIDIA H100 NVLink: около 6832 рублей в час. Если пересчитать в непрерывную работу в течение 30 дней, это уже около 4,9 млн рублей в месяц без учета эксплуатационного запаса и сопутствующей инфраструктуры.

Пример месячной аренды конфигурации с 8 Tesla H100: 2 322 432 рубля за 30 дней, или 53,76 рубля в минуту. Даже в более компактной конфигурации порядок затрат все равно измеряется миллионами рублей в месяц.
Разброс между этими примерами важен сам по себе: цена зависит от провайдера, формата аренды и конфигурации, но полноценный контур на восемь мощных GPU в любом случае быстро выходит на миллионы рублей в месяц.
в разных моделях аренды. Даже если конфигурации отличаются по поколению GPU, CPU, RAM и типу размещения, сами числа быстро показывают масштаб задачи.

Пример стоимости выделенного сервера с 8 GPU NVIDIA H200: около 2,9 млн рублей в месяц. Более мощные модели GPU и серверный контур меняют конкретные цифры, но не общий вывод о масштабе расходов.
Эти затраты полезно сравнить с API-доступом к той же модели.
По результатам бенчмарка при максимальной нагрузке, concurrency около 100:

• input throughput: около 2400 токенов/сек, или около 6,2 млрд токенов в месяц;
• output throughput: около 620 токенов/сек, или около 1,6 млрд токенов в месяц.
  Оценка стоимости через API:
  Input: 6200 * $0.28 = $1736
  Output: 1600 * $0.42 = $672
  Итого: ~$2400, или около 190 000 рублей в месяц
  Даже если не спорить о конкретных тарифах, порядок важен: при заметной нагрузке API может стоить сотни тысяч рублей в месяц, а self-hosted-контур для большой модели — уже миллионы.
  И это еще оптимистичное сравнение. Железо нельзя держать на 100% загрузки постоянно: начнут расти очереди и задержки. Нужен запас, мониторинг, MLOps, обновления, дежурства и люди, которые будут поддерживать систему. Если нужен SLA уровня внешнего API, стоимость эксплуатации растет еще сильнее.

Главный экономический вывод: API выгоднее, если нет жестких ограничений

Если нет жестких требований по SLA, информационной безопасности, приватности данных или необходимости дообучать модель, API во многих сценариях оказывается дешевле собственной инфраструктуры по полной стоимости владения.
Self-hosted нужен, когда:

• нельзя отправлять данные внешнему поставщику;
• есть жесткие требования ИБ;
• нужен полный контроль над моделью и окружением;
• нужна донастройка или дообучение;
• есть стабильная высокая нагрузка, которая оправдывает инфраструктуру;
• команда готова эксплуатировать модель как production-сервис.
  Во всех остальных случаях начинать лучше с API и маленьких моделей. Если маленькая модель решает задачу — отлично. Если нет, тогда уже нужно смотреть в сторону больших моделей, но считать экономику заранее.

Итоговый чек-лист: как запускать LLM в production без лишних затрат

Перед запуском LLM в production стоит пройти по этому списку.

1. Определить задачу и требуемое качество.
2. Проверить маленькие модели.
3. Сравнить модели не только по benchmark-ам, но и по архитектуре attention, KV cache, MoE/Dense и квантизации.
4. Рассчитать ожидаемую длину контекста и число параллельных запросов.
5. Оценить VRAM: веса, KV cache, буферы, overhead фреймворка.
6. Выбрать фреймворк: vLLM, TGI, TensorRT-LLM, Triton или другой вариант.
7. Проверить, нужна ли параллелизация между GPU.
8. При необходимости измерить пропускную способность NVLink и скорость обмена данными между GPU.
9. Провести нагрузочные тесты.
10. Развернуть мониторинг (Prometheus + Grafana) для отслеживания TTFT, ITL/TPOT, TTLT, TPS и percentile-метрик.
11. Настроить Prometheus и Grafana.
12. Представить результаты сравнения TCO для self-hosted и API: затраты на железо, резерв мощностей, эксплуатацию, ФОТ команды и обеспечение SLA.
    Производительность инференса LLM — это не один параметр. Это система компромиссов между качеством модели, архитектурой, памятью, железом, фреймворком, задержкой, throughput и деньгами. Если смотреть только на количество параметров или только на цену GPU, легко получить технически красивую, но экономически бессмысленную систему.