Локальные языковые модели против облачных API: сравнение задержки и стоимости

Команда, которая выбирает архитектуру диалогового ассистента — будь то служба поддержки с многотысячной очередью или внутренний инструмент для команды разработки, — обычно открывает два терминала, измеряет «время ответа» локальной LLM и облачного API и сравнивает две цифры. Это первая системная ошибка, потому что задержка ответа языковой модели раскладывается минимум на четыре независимые составляющие, и под нагрузкой они ведут себя по-разному. Проверить такое сравнение задержки и стоимости честно нельзя без разделения метрик, фиксации контекста и многослойной раскладки тарифа по типам токенов. Следовательно, универсального вывода «локально быстрее облака» или наоборот не существует: корректный ответ возможен только при одинаковом тестовом контуре и согласованной метрике.

Что скрывается за «средней задержкой»

Актуальная документация инференс-движка vLLM описывает метрику time_to_first_token_ms как время от планирования запроса до появления первого выходного токена. TTFT отвечает за субъективное ощущение «отклика» у пользователя — именно через этот интервал чат-бот начинает писать первый фрагмент текста. Вместе с тем отдельно выделяется queue_time_ms: время, которое запрос провёл в очереди до того, как планировщик вообще взял его в работу.

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

Третья переменная — mean_itl_ms, средняя межтокенная задержка при декодировании; в терминологии бенчмарков MLCommons её обозначают как TPOT, time per output token. Наконец, сквозная скорость tokens_per_second в vLLM учитывает prefill-фазу и охватывает весь путь от планирования до последнего токена, а не только декодирование. Два ответа с одинаковым общим временем могут ощущаться пользователем совершенно по-разному: один мгновенно начинает печатать и медленно генерирует, другой долго висит в тишине, а затем выдаёт текст рывком. Именно поэтому сравнивать только «полное время ответа» — значит заранее получать невоспроизводимый результат.

Корректное сравнение локальной модели и облачного API требует четырёх разделённых метрик — TTFT, queue_time, ITL и общей длительности. Без этого любой вывод «X быстрее Y» воспроизводится только на бумаге.

Где заканчиваются бенчмарки и начинается реальный продукт

В серверном сценарии тестов MLPerf Inference для моделей Llama2-70B и Mixtral-8x7B зафиксированы ограничения TTFT 2000 мс и TPOT 200 мс. Эти значения — не пользовательская норма для произвольного чат-бота, а параметры конкретного бенчмарка с заданной моделью, нагрузочным профилем и критериями качества. Переносить их на свой продукт без проверки нагрузочного профиля, типа модели и сценария использования нельзя. Нет общего стандарта, который предписывал бы единый SLA по TTFT или TPOT для всех пользовательских чат-ботов, поэтому любое «соответствие MLPerf» в маркетинговых материалах нужно читать с оговоркой о сценарии.

В практическом тесте, помимо самих метрик, необходимо зафиксировать:

• идентичный промпт, температуру и целевую длину ответа;
• длину входного контекста: она влияет и на prefill-фазу, и на тариф;
• уровень параллелизма — одиночные запросы и реальный профиль нагрузки, а не только удобный тест «один пользователь»;
• режим квантования модели на локальной стороне;
• регион облачного API и сетевой маршрут до него;
• правила ретраев, таймаутов и стриминга ответа.

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

Тарифы облачных API: четыре измерения одной цены

Вторая системная ошибка — сравнивать облачные тарифы только по «цене за входной токен». Современная страница цен OpenAI API для модели gpt-5.6-luna в стандартном режиме короткого контекста указывает четыре независимых ставки: 0,20 USD за 1 млн входных токенов, 0,02 USD за 1 млн кэшированных входных токенов, 0,25 USD за 1 млн токенов записи в кэш и 1,20 USD за 1 млн выходных токенов. На этой же странице при длинном контексте указаны 0,40 USD за 1 млн входных токенов и 1,80 USD за 1 млн выходных токенов — иными словами, при большом объёме контекста стоимость растёт не линейно, а с заметным переломом.

Такая структура означает, что простой расчёт «средний запрос стоит X» теряет смысл. Запросы с повторяющимися системными инструкциями, попадающими в кэш, обходятся в десять раз дешевле по входу; запросы с длинной историей диалога переключаются на повышенный тариф; длинные ответы ассистента тарифицируются по отдельной, более высокой ставке. В сумме доля выходных токенов в платеже за API обычно оказывается выше, чем предполагает менеджер, рассчитывавший только по входу.

Здесь важно не перепутать «длину промпта» с платным объёмом входа. В реальном ассистенте один и тот же системный промпт, политика безопасности, справочная база и история разговора могут занимать большую часть контекста. Если эти части стабильно повторяются, кэширование меняет экономику радикальнее, чем попытка выжать несколько процентов из средней длины пользовательского вопроса. Если же каждый запрос уникален и тащит за собой новую длинную историю, расчёт нужно строить уже по полной входной цене.

Batch-режим и его место в экономике

Документация Anthropic указывает, что Batch API обрабатывает запросы асинхронно и даёт скидку 50% и на входные, и на выходные токены. Это полезный инструмент для пакетной обработки: суммаризации тысяч диалогов, классификации тикетов, генерации черновиков, где интерактивный отклик не нужен. Однако сравнивать стоимость Batch API с интерактивным локальным ответом по задержке некорректно — асинхронный режим принципиально не конкурирует с диалоговым UX.

С другой стороны, разумная экономическая стратегия выглядит менее эффектно, но работает лучше: интерактивные запросы обслуживаются там, где важна задержка, а пакетные — там, где важна скидка. Один продукт вполне может использовать оба канала. Например, оператор видит ответ ассистента в реальном времени, а ночная обработка накопившихся обращений уходит в Batch API. Сводить эти режимы к одной «цене токена» — значит сравнивать разные продукты внутри одного счёта.

Экономика локального развёртывания

Для локального запуска оплачивается не число токенов, а вычислительная мощность по времени выбранной схемы. AWS, к примеру, указывает для Capacity Blocks цену p6-b200.48xlarge в US East (Ohio) 98,84 USD за инстанс-час, или 12,355 USD на каждый из восьми ускорителей B200 в этом инстансе. Это тариф конкретного региона, конкретного типа инстанса и конкретной схемы резервирования, и использовать его как «цену локальной LLM» нельзя.

Для собственного сервера в офисе стоимость амортизации GPU, электроэнергии и охлаждения считается иначе, а арендованный инстанс On-Demand тарифицируется посекундно с минимальным периодом 60 секунд. AWS также указывает, что Savings Plans и Spot Instances могут снизить затраты относительно On-Demand. Следовательно, выбор схемы покупки меняет итоговую цифру не косметически, а принципиально.

В практическом расчёте, помимо GPU-часа, нужно учитывать:

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

Открытые веса модели означают отсутствие лицензии за токен, но не означают «бесплатно». При пересчёте на один запрос стоимость GPU-часа делится на фактическое количество успешно обработанных запросов в час. При малой нагрузке локальная экономика часто проигрывает облаку именно из-за простоя: ускоритель потребляет деньги, когда пользователи молчат. При высокой и стабильной нагрузке, исчисляемой десятками миллионов токенов в сутки, фиксированная стоимость инстанса становится предсказуемее тарифицируемого API, и точка безубыточности смещается в пользу локального варианта.

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

Что меняется с квантованием и длиной контекста

Локальный запуск редко использует fp16-веса открытой модели: на практике применяются кванты вроде Q4, Q5 или Q8, что снижает требования к памяти GPU и позволяет запускать более крупные модели на меньшем железе. Поэтому при сравнении с облачным API важно фиксировать именно тот квант, который планируется к развёртыванию. Разница в качестве между Q4 и Q8 может быть заметной в задачах с длинной цепочкой рассуждений, и это меняет пользовательский опыт, а не только скорость.

Длина контекста дополнительно нагружает KV-кэш и увеличивает prefill-фазу. Один и тот же сервер при коротком запросе способен начать генерацию заметно быстрее, чем при длинной истории диалога или крупном пакете документов: модели требуется обработать больше входных токенов до появления первого выходного. Поэтому сравнивать TTFT на коротком тестовом промпте и затем обещать тот же отклик в RAG-сценарии с объёмным контекстом — плохая инженерная привычка.

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

Когда локально, когда в облаке, когда гибрид

Сравнение не сводится к бинарному выбору: в зрелых продуктах архитектура чаще всего гибридная, и понимание границ каждой части важнее идеологического «только своё» или «только API». Ниже — компактная карта решений, основанная на логике метрик и тарифов, а не на маркетинговых лозунгах.

Гибридный подход особенно полезен там, где система живёт не в одном режиме. Базовый трафик с повторяемыми запросами можно держать на локальном инстансе, чтобы контролировать данные, модель и предсказуемую загрузку. Пиковые обращения, редкие сложные задачи или новые функции — отправлять в API, не закупая инфраструктуру под максимальную нагрузку. Отдельный маршрут нужен и для пакетных задач: им не требуется конкурировать с пользовательским чатом за GPU и за низкий TTFT.

Гибридная архитектура обычно выигрывает у чистого локального и чисто облачного варианта именно там, где нагрузка и чувствительность данных меняются со временем.

Практические шаги проверки

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

1. Выбрать одну-две production-модели и прогнать их на одинаковом наборе промптов разной длины. В выборке должны быть короткие вопросы, типичные рабочие диалоги и длинные контексты, которые действительно встретятся в продукте.

2. Замерить TTFT, queue_time, ITL и общую длительность раздельно при нескольких уровнях параллелизма. Одиночный запрос нужен как базовая линия, но решение обычно определяет поведение под одновременной нагрузкой.

3. Смотреть не только на среднее значение. Пользователь сталкивается не со средним TTFT по красивому графику, а с длинным хвостом: теми запросами, которые попали в очередь, получили большой контекст или оказались в моменте фоновой нагрузки.

4. Посчитать стоимость облака с учётом доли кэшированных входов, длинного контекста и выходных токенов, а не только «цены за вход». Для пакетных операций стоит строить отдельную модель, не смешивая их с интерактивным каналом.

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

6. Принять решение по целевой метрике — например, по допустимому p95 TTFT при заданном числе одновременных пользователей — и сравнивать варианты уже по ней. Так разговор о «быстрее» перестаёт быть вкусовым спором.

Итог

Универсального ответа на вопрос «локально или API» нет, и попытки его получить почти всегда заканчиваются подменой метрик. Корректное сравнение требует раздельно измерять TTFT, queue_time, ITL и полную длительность. Очередь важна для пользовательского опыта не меньше скорости самой модели, но её нельзя маскировать под TTFT: иначе становится невозможно понять, лечить ли инференс, планировщик или ёмкость сервиса.

Стоимость тоже не сводится к одной цене за миллион токенов. Облачный счёт зависит от кэширования, длины контекста, объёма генерации и режима обработки. Локальный — от загрузки GPU, квантования, инфраструктурной схемы, запаса под пики и стоимости сопровождения. На малом или рваном трафике API часто покупает команде не только вычисления, но и право не держать простаивающий сервер. На стабильном потоке локальный контур может дать предсказуемость, контроль и более понятную себестоимость.

Практический вывод здесь не романтический: не нужно выбирать сторону. Нужно проверить сравнение задержки и стоимости на собственных запросах, собственной очереди и собственной структуре токенов. Тогда облако останется удобным инструментом для быстрого запуска, экспериментов и пиков, а локальные модели — рабочим вариантом для устойчивого трафика и чувствительных данных. И решение будет опираться не на лозунг «локально дешевле» или «API удобнее», а на цифры, которые команда сможет повторить через неделю и объяснить через квартал.