Inference Scaling: как reasoning модели сжигают ваши деньги и что с этим делать

Аномалия токенов: когда додумывать дороже, чем отвечать

Обычная LLM работала предсказуемо: prompt in — response out. Но вот пришли reasoning-модели (o1, DeepSeek R1, Qwen3 с включённым размышлением), и правила игры сломались. Теперь нейросеть не просто выдаёт ответ — она пишет внутренний монолог, перебирает гипотезы, прокручивает цепочки мыслей, которые пользователь никогда не увидит. Каждый такой внутренний токен — реальные деньги, которые списываются со счёта.

Звучит логично? А теперь представьте: вы арендуете GPU для инференса, платите за каждый миллион токенов, а половина из них ушла на «подумать» — причём впустую, если модель зациклилась или не может прийти к решению. Это и есть inference scaling — цена, которую платят за рассуждения.

И нет, проблема не в том, что модели тупые. Проблема в том, что мы пока не умеем дёшево заставлять их думать. Но умеем управлять этим процессом. Добро пожаловать в треугольник Cost-Quality-Latency — там, где каждый миллисекунда и каждый потраченный цент — компромисс.

Почему скрытые токены — проблема номер один

OpenAI называет их «chain of thought tokens», DeepSeek — «reasoning tokens», Anthropic — «hidden thinking». Разные названия — одна суть: модель тратит вычислительные ресурсы на внутреннюю рефлексию, которую вы, как разработчик, не контролируете ни по объёму, ни по содержанию. В контексте test-time compute эти токены — главный драйвер затрат, и вот почему.

• Непрозрачность: провайдеры не всегда выдают статистику по скрытым токенам. Вы видите только итоговую сумму в биллинге, но не понимаете, сколько ушло на «подумать».
• Бесконтрольность: модель может генерировать тысячи токенов пустого перебора, особенно если задача сложная или prompt некорректный.
• Эффект домино: длинный reasoning увеличивает latency, что убивает UX в real-time сценариях — чат-ботах, поддержке, ассистентах.

В статье об экономике LLM в 2026 уже считали: для некоторых провайдеров скрытые токены составляют до 75% общего потребления. Если не знать об этом — бюджет улетает в трубу.

Треугольник Cost–Quality–Latency: как не сломать баланс

Представьте равносторонний треугольник. В вершинах — стоимость, качество, задержка. Вы можете улучшить один параметр, только пожертвовав двумя другими. Reasoning-модели дают взрывной прирост качества на сложных задачах (логика, математика, планирование) — но ценой огромного роста стоимости и времени.

Задача DevOps — научиться этим треугольником жонглировать. Вот как это работает на практике:

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

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

Давайте разберём пошаговый план, как взять под контроль inference scaling на уровне production.

1Аудит текущих расходов

Прежде чем что-то менять — узнайте, сколько вы уже тратите на скрытые токены. Большинство провайдеров (OpenAI, Together, Fireworks) в логах отдают usage.completion_tokens_details с полем reasoning_tokens. Если нет — считайте косвенно: разница между completion_tokens и тем, что вернулось пользователю.

import openai

response = openai.chat.completions.create(
    model="o3-mini-2024-12-06",
    messages=[{"role": "user", "content": "Сложная логическая задача"}]
)
print(response.usage.completion_tokens_details.reasoning_tokens)
# -> 1534

Если число большое — у вас есть проблема. Если маленькое — возможно, модель почти не размышляет (но это не всегда хорошо для сложных задач).

2Внедрить маршрутизацию

Разделите входящие запросы на простые и сложные. Простые — пусть обрабатывает быстрая обычная модель (например, GPT-4o mini, Llama 3 8B). Сложные — отправляйте на reasoning-модель. Критерии разделения: длина запроса, наличие ключевых слов (логика, математика), метрики косинусной близости с эталонными сложными примерами.

В качестве решения можно использовать любой лёгкий классификатор. WizardLM Mix-GRM показывает, что синтез поверхностного и глубокого reasoning — ключ к сбалансированной оценке. Адаптируйте этот подход к маршрутизации.

def classify_request(prompt):
    # заглушка: используйте любую лёгкую ML-модель
    complexity_score = len(prompt.split()) + (1 if "докажите" in prompt else 0)
    return "complex" if complexity_score > 50 else "simple"

3Установить бюджет reasoning

Если ваша модель поддерживает reasoning_budget_tokens (как в llama.cpp для Qwen3 и других) — задавайте жёсткий лимит. Это не даст модели болтать бесконечно. Отличный пример — настройка flash-attention с лимитом рассуждений — модель думает не больше заданного числа токенов.

Бюджет можно адаптировать под задачу: простые — 512 токенов на размышления, средние — 2048, сложные — 4096+. Не забывайте мониторить, хватило ли лимита.

4Включить адаптивное снижение токенов

Техника DTR (Dynamic Token Reduction) — новая интересная штука. Идея: обрезать reasoning-цепочки на ходу, если модель явно зацикливается или повторяется. В упомянутой статье про DTR показано ускорение локальных моделей в 2 раза без потери качества. Суть: семплируем вероятность следующего токена — если модель долго топчется на месте, прерываем рассуждение и переходим к ответу.

В vLLM, llama.cpp это можно реализовать через кастомные sampling parameters. Пример для vLLM (псевдокод):

{
  "reasoning_parser": "dynamic_truncation",
  "max_reasoning_tokens": 1024,
  "truncation_signal": "repetition"
}

Настройте логику прерывания под свою модель. Тестируйте на бенчмарках — без экспериментов не обойтись.

5Анализировать и итерировать

Мониторинг — ваше всё. Собирайте метрики: latency, количество скрытых токенов, стоимость за запрос, качество (user feedback, Causal Inference для оценки — как раз статья про Causal Inference помогает отличить причину от корреляции).

Если видите, что модель часто превышает бюджет и срезает качество — увеличивайте лимит для сложных запросов. Если latency скачет — добавляйте ограничения по времени (тайм-аут).

В статье про 5 техник оптимизации vLLM есть отличные бенчмарки Qwen3-32B, которые показывают, как разные стратегии влияют на Cost-Quality-Latency. Возьмите их за основу для своих тестов.

Провалы и грабли: что делают 99% новичков

Ошибок много, но основные — одни и те же. Пробежимся по самым частым.

• Забыли про скрытые токены. Прочитали статью, но не внедрили мониторинг — и через месяц получили счёт в 3 раза больше ожидаемого. Реальная история.
• Отключили reasoning полностью. На всех запросах. Да, latency упало, но качество на сложных задачах рухнуло. Не делайте так, если ваш сервис отвечает на юридические вопросы или помогает с кодом.
• Поставили бюджет reasoning на 0. Некоторые модели (например, GLM-4.6V) без reasoning всё ещё дают ответ, но качество страдает. В заметке про GLM-4.6V показано, что просто отрубить reasoning — рабочий вариант, если вам нужно ускорение, но не везде.
• Думают, что маленькая модель — дешёвая. Ministral-3-14B-Reasoning бьёт гигантов по качеству, но если включить ей глубокий reasoning — она может генерировать в разы больше токенов, чем большая закрытая модель. Считайте не только цену за токен, но и количество.

И ещё один совет: не верьте догмам. Длиннее reasoning — не всегда лучше. DTR, бюджетные лимиты и маршрутизация — ваши друзья. Используйте их.

Технический гамбит: как Qwen 3.5 122B ломает стереотипы

Напоследок — пример из реального мира. Qwen 3.5 122B A10B — монстр, который при правильной настройке даёт insane качество за умеренные деньги. Но он же может сожрать бюджет, если не настроить UD Q2KXL и не ограничить reasoning. В разборе рекорда в UGI показано, как тонкая настройка квантизации и лимита токенов даёт выигрыш по всем трем осям треугольника.

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

Удачи в оптимизации. Если хотите поделиться своими граблями — пишите в комментариях (ну вы поняли, гипотетически).

Подписаться на канал