AI Factory: почему нейросети превращают дата-центр в фабрику токенов

Еще недавно дата-центр воспринимался как большое помещение, где круглосуточно работают сайты, базы данных, корпоративные приложения и облачные сервисы. Сегодня внутри тех же зданий появляется инфраструктура другого типа. Мощные GPU-кластеры загружают модели в память, принимают тысячи запросов и непрерывно генерируют новые токены. Снаружи это может выглядеть как очередной этап развития серверов. На практике меняется сама логика вычислений. Сервер теперь не просто хранит данные или выполняет заранее определенный код. Он производит результат работы нейросети: текст, программный код, изображения, рекомендации, прогнозы и действия AI-агентов. Именно поэтому все чаще используется термин AI Factory, или «фабрика искусственного интеллекта». Главной единицей ее производительности становится не количество процессоров и даже не число GPU, а объем полезных токенов, которые инфраструктура способна выпустить за секунду, за доллар и за ватт потребленной энергии.

От дата-центра к вычислительной фабрике

Традиционный дата-центр обслуживает множество разных задач. На одном сервере работает интернет-магазин, на другом находится база данных, третий выполняет резервное копирование, четвертый раздает видеоконтент. Разумеется, все эти системы тоже создают нагрузку. Однако большинство классических приложений обрабатывает сравнительно короткие и предсказуемые операции. Пользователь открыл страницу, приложение выполнило несколько SQL-запросов, сервер сформировал ответ и освободил ресурсы. Генеративный искусственный интеллект работает иначе. Когда пользователь задает вопрос языковой модели, сервер не извлекает готовый ответ из базы данных. Модель последовательно вычисляет вероятность следующего токена, добавляет его к контексту, снова выполняет вычисления и повторяет этот цикл до завершения ответа. Чем длиннее ответ, тем больше таких циклов необходимо выполнить. Представим обычный чат с AI-ассистентом. Пользователь отправляет запрос, модель анализирует историю переписки, документы из корпоративной базы знаний и системный промпт. Затем она начинает выдавать ответ по одному небольшому фрагменту. В это время GPU продолжает работать, память занята контекстом, а сервер удерживает активную сессию. Один запрос может быть незаметен. Но если одновременно работают тысячи пользователей, AI-сервис превращается в постоянно действующую производственную линию. NVIDIA описывает AI Factory как инфраструктуру, специально спроектированную для производства «интеллекта» в форме токенов. В такой системе энергия, вычислительные ускорители, сеть, хранилища, модели и приложения рассматриваются не отдельно, а как части единого конвейера. Метафора фабрики здесь довольно точна. У обычного предприятия есть сырье, оборудование, логистика и готовая продукция. У AI Factory: сырьем становятся запросы, документы и данные; производственным оборудованием служат GPU-кластеры; конвейером выступает inference-платформа; продукцией становятся токены, ответы и действия моделей; себестоимость измеряется расходами на генерацию полезного результата.

Что именно производит фабрика токенов

Токен представляет собой небольшой фрагмент информации, который обрабатывает модель. В языковых системах это может быть слово, часть слова, знак препинания, число или элемент программного кода. Пользователь обычно не замечает токены. Он видит готовое предложение, изображение или ответ AI-агента. Но для инфраструктуры каждый токен означает очередной вычислительный шаг. Допустим, корпоративный помощник получил вопрос: Какие риски есть в договоре с новым поставщиком? Перед генерацией ответа система может загрузить договор, инструкции юридического отдела и историю предыдущих обсуждений. Входной контекст займет десятки тысяч токенов. Затем модель сформирует еще несколько тысяч токенов с анализом документа.

За одним простым интерфейсом скрывается длинная цепочка операций

Текст преобразуется в токены. Входной контекст передается модели. GPU обрабатывает промпт. Модель начинает последовательно генерировать ответ. Результат передается пользователю. Метрики и логи сохраняются для мониторинга. Если в компании работают сотни сотрудников, а помощник используется ежедневно, число токенов быстро вырастает до миллионов или миллиардов. Еще больше нагрузки создают AI-агенты. Они не ограничиваются одним ответом. Агент может обратиться к модели, выполнить поиск, вызвать API, проверить результат и снова обратиться к модели. Одна пользовательская команда запускает целую серию inference-запросов. Поэтому рост AI-сервисов определяется не только количеством пользователей. Важны глубина рассуждений, длина контекста, число подключенных инструментов и количество внутренних шагов агента.

Обучение модели и inference: два разных типа нагрузки

Разговор об AI-инфраструктуре долгое время был сосредоточен вокруг обучения моделей. Именно обучение требовало огромных GPU-кластеров и занимало недели или месяцы. Однако модель обучают ограниченное количество раз, а используют постоянно.

Обучение похоже на строительство завода

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

Inference похож на работу завода

После запуска модели начинается эксплуатация. Запросы поступают круглосуточно, их объем меняется, а пользователи ждут ответ прямо сейчас. Утром корпоративным помощником могут пользоваться десять сотрудников, после обеда уже тысяча. После выхода нового продукта нагрузка увеличивается в несколько раз. Ночью запускается пакетная обработка документов, а утром те же GPU должны обслуживать интерактивный чат.

Inference становится отдельным инфраструктурным классом, потому что одновременно требует

• низкой задержки ответа

• высокой совокупной производительности

• устойчивости к пиковым нагрузкам

• эффективного использования GPU

• изоляции разных клиентов

• предсказуемой стоимости генерации.

NVIDIA прямо связывает дальнейшее расширение AI-инфраструктуры с переходом от экспериментов и обучения к постоянно работающим системам inference, которые производят токены в промышленном масштабе. Для бизнеса это важный сдвиг. Купить или арендовать мощный GPU недостаточно. Необходимо превратить его вычислительную мощность в стабильный сервис с понятными SLA и экономикой.

Почему производительность GPU нельзя оценивать одной цифрой

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

Latency: сколько пользователь ждет ответа

Latency показывает задержку между запросом и результатом. Но в генеративном AI одной общей цифры уже недостаточно.

Time to First Token

Time to First Token, или TTFT, показывает, сколько времени проходит до появления первого токена ответа. Для пользователя это момент, когда интерфейс перестает «думать» и начинает выводить текст. Если первый токен появляется быстро, сервис кажется отзывчивым, даже если полный ответ генерируется еще несколько секунд. Если пользователь долго смотрит на пустой экран, система воспринимается как медленная. TTFT особенно важен для: чат-ботов; голосовых ассистентов; помощников программиста; поисковых систем с генеративным ответом; AI-интерфейсов клиентской поддержки.

Inter-Token Latency

Inter-Token Latency, или ITL, измеряет задержку между последующими токенами. Представьте, что первый фрагмент ответа появился быстро, но дальше текст выводится рывками. Формально сервис уже ответил, однако пользоваться им неприятно. Для голосового ассистента нестабильная межтокенная задержка еще заметнее. Речь начинает прерываться, появляются паузы, а диалог теряет естественный ритм. В инструментах NVIDIA для тестирования LLM отдельно измеряются TTFT, межтокенная задержка, общая длительность запроса, скорость генерации токенов и количество обработанных запросов. Это показывает, насколько многомерной стала оценка inference-систем.

Throughput: сколько токенов проходит через конвейер

Throughput показывает совокупную пропускную способность системы. Для языковых моделей его часто измеряют в токенах в секунду. Пусть один пользователь получает 60 токенов в секунду. Это выглядит быстро. Но что произойдет, если к сервису одновременно подключатся 500 пользователей? Возможны два сценария. В первом каждый новый запрос замедляет остальные. Скорость ответа падает, очередь растет, пользователи начинают получать ошибки. Во втором инфраструктура группирует запросы, распределяет их между GPU и продолжает обслуживать систему в рамках SLA. Именно второй сценарий нужен промышленному AI-сервису. Высокая скорость генерации одного запроса еще не означает высокую производительность всей платформы. Нередко максимальная индивидуальная скорость достигается при почти пустом GPU. С экономической точки зрения это не всегда выгодно.

Фабрике токенов приходится искать баланс

• слишком маленький батч оставляет GPU недогруженным

• слишком большой батч повышает throughput, но увеличивает задержку

• высокая конкуренция за память ограничивает число активных запросов

• длинные контексты вытесняют короткие запросы

• неравномерный трафик создает очереди и простои.

Поэтому производительность AI Factory нельзя описать фразой «этот сервер генерирует N токенов в секунду». Всегда нужно уточнять модель, длину входа и выхода, число одновременных запросов и допустимую задержку.

Goodput: полезная производительность вместо красивого рекорда

Допустим, платформа обрабатывает 1 000 запросов в секунду. Звучит впечатляюще. Но если половина запросов получает первый токен слишком поздно, а часть ответов не укладывается в SLA, реальная ценность значительно ниже. Для этого используется метрика goodput. Она учитывает только запросы, которые были выполнены в рамках установленных ограничений по времени и качеству обслуживания.

Например, сервис может считать полезными только ответы, где

• первый токен появился не позднее заданного порога

• межтокенная задержка осталась стабильной

• запрос завершился без ошибки

• пользователь получил ответ в пределах общего SLA.

В документации NVIDIA goodput определяется как число завершенных запросов, которые соответствуют заданным целевым показателям сервиса. Для владельца AI-платформы это намного честнее, чем пиковый throughput. Фабрика должна производить не просто много токенов, а много токенов с приемлемой скоростью и предсказуемым качеством сервиса.

Utilization: почему дорогой GPU не должен простаивать

GPU-сервер может стоить дорого, но его наличие само по себе не приносит пользы. Экономика появляется только тогда, когда ускоритель занят полезной работой. Проблема в том, что inference-нагрузка редко бывает ровной. У сервиса есть утренние и вечерние пики. Корпоративные системы активнее используются в рабочее время. Публичные приложения получают всплески после рекламных кампаний или выхода новой функции. Если инфраструктуру построить под максимальную нагрузку, значительная часть GPU будет простаивать в обычные часы. Если ориентироваться на среднюю нагрузку, сервис не выдержит пик. Получается знакомая ситуация. В ресторане нужно иметь достаточно столиков для пятничного вечера, но в понедельник днем половина зала пустует. Только в случае с AI каждый свободный «столик» может стоить десятки тысяч долларов. Высокий utilization означает, что доступные вычислительные ресурсы действительно используются для обработки запросов. Но и здесь нельзя просто стремиться к 100%. GPU, загруженный до предела, может потерять запас для внезапного увеличения трафика. Очередь начинает расти, latency ухудшается, а запросы перестают укладываться в SLA. Задача оператора AI Factory заключается не в том, чтобы постоянно видеть цифру 100% в мониторинге. Нужно поддерживать максимально высокую полезную загрузку, сохраняя резерв для пиков и требуемую скорость ответа.

Две фазы inference: почему один запрос ведет себя как две разные задачи

Генерацию ответа языковой моделью можно условно разделить на две фазы: prefill и decode.

Prefill: модель читает запрос

На этапе prefill модель обрабатывает входной контекст. Это может быть короткий вопрос, длинный документ, история диалога или содержимое нескольких страниц из базы знаний. Чем больше входных токенов, тем больше работы нужно выполнить до появления первого ответа. Именно prefill заметно влияет на Time to First Token.

Decode: модель пишет ответ

После обработки контекста начинается decode. Модель генерирует выходные токены последовательно. Каждый новый токен зависит от уже созданной последовательности. У prefill и decode разные вычислительные характеристики. Prefill хорошо распараллеливается и активнее использует вычислительные блоки GPU. Decode выполняется последовательно и предъявляет другие требования к памяти и пропускной способности. NVIDIA рассматривает раздельное обслуживание этих фаз как один из способов масштабирования inference. В такой архитектуре одни группы GPU обрабатывают входные запросы, а другие отвечают за последовательную генерацию. Это позволяет независимо масштабировать разные части конвейера и точнее распределять ресурсы. Для небольшого проекта такое разделение может быть избыточным. Но на уровне крупных AI-сервисов это уже напоминает настоящее производство, где разные операции выполняются на специализированных участках.

KV-кеш: невидимый потребитель памяти

После обработки входного контекста модель сохраняет промежуточные данные, необходимые для генерации следующих токенов. Их называют KV-кешем. Он помогает не пересчитывать всю последовательность заново при каждом следующем токене. Благодаря этому генерация ускоряется. Однако кеш занимает видеопамять. Чем длиннее контекст и чем больше одновременно активных пользователей, тем больше памяти требуется. Представим AI-ассистента, который работает с длинными договорами. Каждый пользователь загрузил документ на десятки страниц и попросил провести анализ. Сама модель уже занимает значительную часть VRAM. Дополнительно для каждой активной сессии создается KV-кеш. В какой-то момент ограничением становится не вычислительная мощность GPU, а доступная память. Это объясняет, почему две системы с одинаковыми ускорителями могут обслуживать разное количество пользователей. Одна эффективно управляет кешем, объединяет запросы и повторно использует общие префиксы. Другая расходует память фрагментарно и быстро упирается в лимит. Современные inference-движки используют paged KV cache, квантизацию кеша, его повторное использование и перенос между уровнями памяти. Все это позволяет увеличить число параллельных запросов и снизить стоимость генерации. Получается любопытный эффект. Иногда обновление программного стека дает больше пользы, чем установка дополнительного GPU.

Multi-tenant GPU: один ускоритель, несколько клиентов

Не каждому приложению требуется целый GPU. Небольшая модель классификации, сервис распознавания изображений или корпоративный чат могут использовать только часть его возможностей. Если выделять каждому клиенту отдельный ускоритель, оборудование будет простаивать. Поэтому AI Factory часто работает по multi-tenant-модели, когда один физический GPU обслуживает несколько независимых задач.

На практике возможны разные варианты

• несколько моделей работают на одном ускорителе

• один экземпляр модели обслуживает разных клиентов

• GPU разделяется на изолированные аппаратные экземпляры

• ресурсы динамически распределяются через оркестратор

• небольшие запросы объединяются в общие батчи.

Технология NVIDIA MIG позволяет разделять поддерживаемые GPU на несколько изолированных экземпляров с выделенными вычислительными и memory-ресурсами. Это помогает одновременно запускать несколько workloads и получать более предсказуемое поведение каждого из них. Однако multi-tenancy добавляет сложности. Нужно исключить ситуацию, когда один клиент отправляет длинные запросы и ухудшает latency всех остальных. Требуются лимиты, приоритеты, контроль памяти, очереди и изоляция данных. Иными словами, разделить GPU технически проще, чем справедливо распределить его производительность.

Хорошая multi-tenant-платформа должна учитывать

• размер модели

• длину контекста

• число выходных токенов

• приоритет клиента

• требования к latency

• доступный объем VRAM

• текущую загрузку каждого ускорителя.

Для этого уже недостаточно простого балансировщика HTTP-запросов. Нужен планировщик, который понимает особенности LLM.

Почему batching повышает эффективность, но может раздражать пользователей

GPU особенно эффективен, когда выполняет крупные параллельные операции. Поэтому inference-сервер старается объединить несколько пользовательских запросов в батч. Это похоже на автобус. Везти одного пассажира на большом автобусе невыгодно. Лучше дождаться нескольких человек и отправить их вместе. Но если слишком долго ждать заполнения салона, первый пассажир начнет нервничать. С batching происходит то же самое. Большие батчи обычно повышают throughput и помогают лучше использовать GPU. Однако ожидание формирования батча увеличивает latency. Кроме того, запросы имеют разную длину. Один пользователь попросил коротко перевести предложение, другой отправил документ на 50 страниц. Современные inference-системы применяют continuous batching, или динамическое пакетирование. Новый запрос может добавляться в обработку по мере освобождения ресурсов, не дожидаясь завершения всего предыдущего батча. Также используются in-flight batching, paged attention, управление KV-кешем и специальные алгоритмы планирования. TensorRT-LLM, например, включает оптимизации для производственного inference, ориентированные одновременно на высокую пропускную способность и низкую задержку. Для пользователя все это невидимо. Он просто замечает, быстро или медленно отвечает сервис. Но именно внутри планировщика решается, будет ли работа GPU экономически оправданной.

Стоимость токена как главный экономический показатель

Цена GPU-сервера важна, но сама по себе она почти ничего не говорит об экономике AI-продукта. Дешевый сервер может оказаться дорогим, если модель работает медленно, ускоритель простаивает, а сервис обслуживает мало пользователей. Более дорогая конфигурация, наоборот, может генерировать значительно больше токенов и снижать стоимость каждой операции. Поэтому инфраструктуру все чаще оценивают через стоимость миллиона токенов. Упрощенную формулу можно представить так: Стоимость миллиона токенов = общие расходы на inference / количество полезных токенов × 1 000 000

В общие расходы входят

• аренда или амортизация GPU

• электроэнергия

• охлаждение

• процессоры и оперативная память

• сеть и хранилища

• лицензии и программное обеспечение

• резервирование

• работа инженеров

• потери от простоя оборудования.

Количество сгенерированных токенов тоже нельзя брать без оговорок. Если ответы не уложились в SLA или завершились ошибкой, формально токены были произведены, но бизнес не получил полноценного результата. Поэтому правильнее считать стоимость полезных токенов или запросов, соответствующих требованиям сервиса. NVIDIA продвигает cost per token как интегральную метрику, которая учитывает производительность оборудования, программные оптимизации и реальную загрузку инфраструктуры. Компания также связывает эффективность AI Factory с количеством токенов, генерируемых на доллар и ватт при заданных требованиях к latency. Разумеется, это не единственный показатель. Качество модели, безопасность и точность ответов важнее слепой экономии. Но после выбора подходящей модели стоимость токена становится удобным способом сравнить варианты ее размещения.

Простой пример экономики inference

Предположим, компания запускает AI-помощника для клиентской поддержки. За месяц система генерирует 2 миллиарда выходных токенов. Полная стоимость инфраструктуры, включая GPU, резервирование и обслуживание, составляет 20 000 долларов. Условная стоимость миллиона выходных токенов: 20 000 / 2 000 000 000 × 1 000 000 = 10 долларов После оптимизации batching, квантизации и управления KV-кешем та же инфраструктура начинает генерировать 3 миллиарда токенов без ухудшения SLA. Тогда стоимость миллиона токенов снижается: 20 000 / 3 000 000 000 × 1 000 000 ≈ 6,67 доллара Компания не купила новые GPU и не снизила качество модели. Она просто повысила эффективность конвейера. Теперь представим обратную ситуацию. Из-за пиковых нагрузок часть запросов не укладывается в SLA. Формально система выдала 3 миллиарда токенов, но только 2,4 миллиарда можно считать полезными. Экономику придется считать уже по этой цифре. Так становится видно, почему показатели utilization, throughput и latency нельзя анализировать отдельно. Они сходятся в одной точке: в стоимости полезного результата.

Токены на ватт: энергия становится частью производительности

Для крупного AI-кластера энергопотребление является не второстепенным расходом, а одним из основных ограничений. Дата-центр может иметь деньги на новые GPU, но не иметь свободной электрической мощности для их подключения. Кроме самих ускорителей, энергию потребляют CPU, память, сеть, системы хранения и охлаждение.

Поэтому в разговоре об AI Factory появляются показатели

• токены на ватт

• токены на киловатт-час

• токены на мегаватт

стоимость токена при заданном энергетическом лимите. Раньше дата-центр мог оцениваться по числу стоек или общей мощности оборудования. Теперь важно, какой объем AI-вычислений производится внутри доступного энергетического бюджета. NVIDIA использует показатель token cost per megawatt и рассматривает совместное проектирование вычислений, сети, охлаждения и программного обеспечения как способ увеличить выпуск токенов при фиксированной мощности объекта. Это еще одна причина, почему AI Factory нельзя свести к покупке ускорителей. Даже самый производительный GPU будет ограничен, если сеть не успевает передавать данные, охлаждение не справляется с плотностью стоек, а inference-движок использует ресурсы неэффективно.

Из каких слоев состоит AI Factory

Полноценная фабрика токенов состоит не только из GPU. Условно ее можно разделить на несколько уровней.

Энергия и охлаждение

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

Вычислительные узлы

Это GPU, CPU, оперативная и видеопамять. Конфигурация зависит от размера модели, длины контекста и требуемого throughput. Модель может помещаться на одном ускорителе или распределяться между несколькими GPU и серверами.

Высокоскоростная сеть

Если модель работает на нескольких узлах, данные должны быстро перемещаться между ускорителями. Сетевая задержка начинает напрямую влиять на скорость генерации. Особенно важна сеть при tensor parallelism, pipeline parallelism, передаче KV-кеша и распределенном serving.

Хранилище

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

Inference-платформа

Она принимает запросы, управляет очередями, формирует батчи, распределяет нагрузку и следит за памятью. Именно здесь физическая мощность GPU превращается в токены.

Модели и приложения

Верхний слой включает сами LLM, embedding-модели, reranker, системы компьютерного зрения, AI-агентов и пользовательские приложения. Даже идеальная инфраструктура не исправит неэффективную архитектуру приложения. Если агент делает двадцать обращений к большой модели там, где достаточно трех, фабрика будет производить дорогие лишние токены.

Почему AI Factory должна работать 24/7

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

Поэтому операторы стремятся распределять разные типы workloads по времени

• днем обслуживать интерактивные запросы

• ночью запускать пакетную обработку

• в свободные окна выполнять fine-tuning

• использовать резервные ресурсы для фоновых задач

• перемещать workloads между регионами с учетом спроса.

Например, корпоративный AI-помощник активнее используется в рабочие часы. Ночью тот же кластер может обрабатывать архив документов, создавать embeddings или генерировать отчеты. Это уже напоминает расписание производственной линии. Оборудование не должно простаивать, но разные операции имеют разный приоритет. Интерактивный запрос пользователя нельзя задержать ради фоновой классификации документов. Поэтому планировщик должен уметь прерывать, переносить или ограничивать менее важные задачи. В обычном сервере подобную проблему часто решают лимитами CPU и RAM. В GPU-кластере дополнительно приходится учитывать VRAM, размер KV-кеша, топологию ускорителей и стоимость переноса модели.

Почему модель нельзя просто «запустить на сервере»

На этапе прототипа все действительно выглядит просто. Инженер арендует GPU, устанавливает inference-сервер, загружает модель и открывает API. Пока запросов мало, система работает хорошо.

Проблемы появляются позже

• несколько длинных промптов занимают всю память

• одновременные пользователи увеличивают задержку

• после сбоя модель долго загружается

• обновление версии требует остановки сервиса

• отдельный клиент создает аномальную нагрузку

• стоимость генерации растет быстрее выручки

• резервный сервер простаивает большую часть времени.

То, что работало как демонстрация, не всегда готово к production.

AI Factory начинается там, где появляются

• измеримые SLA

• автоматическое масштабирование

• резервирование

• планирование GPU

• мониторинг токенов и задержек

• контроль себестоимости

• изоляция пользователей

безопасное обновление моделей. Именно поэтому inference постепенно превращается в самостоятельную инженерную дисциплину, похожую на смесь SRE, распределенных систем и управления производительностью HPC.

Какие метрики стоит собирать в production

Обычного мониторинга температуры GPU и процента загрузки недостаточно.

Для реального AI-сервиса желательно видеть несколько групп показателей.

Пользовательские метрики

Time to First Token; Inter-Token Latency; полное время ответа; процент ошибок; число запросов, соответствующих SLA.

Производственные метрики

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

Метрики GPU

utilization; занятая VRAM; пропускная способность памяти; энергопотребление; температура; число ошибок оборудования.

Экономические метрики

стоимость миллиона входных токенов; стоимость миллиона выходных токенов; стоимость успешного запроса; токены на ватт; токены на GPU-час; доля времени полезной загрузки. Публичные benchmark-тесты помогают сравнивать платформы, но production-нагрузку все равно нужно измерять отдельно. MLCommons развивает MLPerf Inference как воспроизводимый набор тестов для разных моделей и сценариев, однако реальные запросы конкретного приложения могут заметно отличаться от стандартизированного профиля. Лучший benchmark для корпоративного сервиса строится на его собственных данных: реальной длине промптов, типичных ответах, фактической конкуренции и целевых SLA.

Где чаще всего теряются деньги

Первая очевидная статья расходов, простаивающие GPU. Но она далеко не единственная.

Слишком большая модель

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

Неограниченный контекст

В каждый запрос передается вся история диалога или десятки документов. Большая часть информации не влияет на ответ, но оплачивается на этапе prefill и занимает KV-кеш.

Отсутствие batching

Каждый запрос обрабатывается отдельно. Пользователь получает хорошую скорость, но общая пропускная способность GPU остается низкой.

Неправильный autoscaling

Новые экземпляры запускаются слишком поздно, потому что система ориентируется только на загрузку GPU. Между тем очередь уже растет, а TTFT ухудшается. Для LLM полезнее учитывать число активных последовательностей, заполнение KV-кеша и скорость поступления токенов.

Избыточные шаги AI-агента

Агент многократно обращается к модели, повторно анализирует те же данные и генерирует длинные внутренние рассуждения. Каждый шаг выглядит недорогим, но в масштабе продукта превращается в миллионы дополнительных токенов.

Погоня за максимальным utilization

Инфраструктура работает почти без запаса. Небольшой всплеск трафика создает очередь, и пользовательские запросы перестают соответствовать SLA. В итоге GPU загружены отлично, а продукт работает плохо.

Покупать кластер или арендовать GPU-серверы

Термин AI Factory звучит масштабно, но строить собственный дата-центр требуется далеко не каждой компании. Для большинства проектов разумный путь начинается с аренды GPU-серверов. Такой вариант позволяет: запустить пилот без крупных капитальных затрат; протестировать несколько моделей; измерить реальный профиль нагрузки; подобрать объем VRAM; сравнить стоимость разных GPU; масштабироваться по мере роста продукта. Собственная инфраструктура становится оправданной, когда нагрузка достаточно велика и предсказуема, а оборудование можно стабильно загружать в течение длительного времени.

Перед покупкой кластера стоит ответить на несколько вопросов

• Сколько входных и выходных токенов генерируется в месяц?

• Как меняется нагрузка по часам и дням недели?

• Какие требования установлены к TTFT и ITL?

• Какой запас мощности нужен для пиков?

• Какая часть GPU будет простаивать?

• Потребуется ли резервный кластер?

• Есть ли команда для поддержки inference-платформы?

• Насколько быстро меняются используемые модели?

Последний вопрос особенно важен. Индустрия развивается быстро. Модель, под которую закупалось оборудование, через год может уступить более компактному решению или потребовать другой объем памяти. Аренда снижает этот риск. Компания получает вычислительную мощность как ресурс и может менять конфигурацию без перестройки собственного дата-центра.

Как подготовить проект к промышленному inference

Начинать лучше не с выбора самого дорогого GPU, а с измерения нагрузки.

Опишите пользовательский сценарий

Чат, генерация кода, обработка документов и AI-агент создают разные профили запросов. Нужно понимать среднюю длину входа, длину ответа и число одновременных пользователей.

Зафиксируйте SLA

Определите допустимый Time to First Token, скорость последующей генерации и максимальное время полного ответа. Без этого невозможно решить, какая конфигурация действительно подходит.

Проведите benchmark на собственных данных

Синтетический тест полезен для первичного сравнения. Но финальное решение лучше принимать после нагрузки реальными промптами.

Измеряйте не только пиковую скорость

Проверьте систему при разном числе параллельных запросов. Посмотрите, где throughput перестает расти, а latency резко ухудшается. Именно эта точка часто показывает реальную емкость сервиса.

Считайте полную стоимость

Сравнивайте не только цену GPU-часа. Учитывайте количество полезных токенов, резервирование и эксплуатационные расходы.

Оставляйте пространство для изменений

Модели, inference-движки и методы квантизации меняются быстро. Архитектура должна позволять обновлять их без полной перестройки платформы.

AI Factory не отменяет обычный дата-центр

Несмотря на громкий термин, AI Factory не заменяет классическую инфраструктуру.

Нейросетевому сервису все равно нужны

• API-шлюзы

• базы данных

• объектное хранилище

• системы авторизации

• очереди сообщений

• журналирование

• мониторинг

• резервное копирование.

GPU-кластер становится новым вычислительным ядром, но вокруг него продолжает работать привычная серверная среда. Более того, чем активнее используется AI, тем больше нагрузки возникает у соседних систем. RAG требует хранения и поиска embeddings. AI-агенты обращаются к базам данных и API. Мультимодальные модели загружают изображения, аудио и видео. Поэтому современный AI-дата-центр представляет собой не ряд одинаковых GPU-стоек, а сложную комбинацию ускорителей, CPU-серверов, хранилищ и высокоскоростных сетей.

Что изменится дальше

Сегодня большинство пользователей воспринимает нейросеть как отдельное приложение: открыл чат, задал вопрос, получил ответ. Следующий этап гораздо менее заметен. AI будет встроен в редакторы, CRM, поисковые системы, игры, службы поддержки, средства разработки и промышленное оборудование. Каждое такое действие создаст inference-запрос. Один человек сможет незаметно генерировать тысячи токенов в день, просто работая с обычными приложениями. AI-агенты добавят к этому внутренние обращения к моделям, проверку результатов и вызов внешних инструментов. В результате спрос на вычисления будет определяться не только числом людей, но и числом автоматизированных процессов, работающих от их имени. Дата-центр в этой модели действительно начинает напоминать фабрику. В него поступают запросы и данные, внутри работает сложный вычислительный конвейер, а на выходе появляются токены, решения и действия. Главным конкурентным преимуществом становится не просто наличие GPU. Важно, насколько эффективно инфраструктура превращает электричество и вычислительное время в полезный результат.

Вывод

AI Factory не является новым названием обычного дата-центра. Это другой способ смотреть на нейросетевую инфраструктуру. Раньше серверы в основном хранили информацию, выполняли приложения и отвечали на относительно короткие запросы. Теперь GPU-кластеры работают как круглосуточные производственные линии. Они принимают контекст, запускают модели и непрерывно выпускают токены. Из-за этого меняются и критерии эффективности. На первый план выходят latency, throughput, goodput, utilization, объем KV-кеша и стоимость миллиона полезных токенов. Для бизнеса главный вывод довольно практичен. Запуск модели является только началом. Чтобы AI-сервис оказался быстрым, устойчивым и экономически оправданным, нужно проектировать весь inference-конвейер: от GPU и сети до batching, мониторинга и распределения нагрузки. Начать можно без строительства собственного мегаваттного кластера. Аренда GPU-сервера позволяет протестировать модель, измерить реальные показатели и постепенно перейти от экспериментального запуска к собственной фабрике токенов. Когда нагрузка измерена, SLA определены, а стоимость каждого ответа понятна, AI-инфраструктура перестает быть дорогим экспериментом и становится управляемым производственным инструментом.