DeepSeek-V4-Flash-0731: почему Low расходует больше токенов, чем High

Low расходует больше токенов, чем High: что показали измерения

TL;DR: В выбранных измерениях Low генерировал больше токенов, чем High, поэтому мог увеличивать стоимость токенов и API-вызова. Наблюдение повторилось на локальном UD-Q2_K_XL и через официальный API DeepSeek, но зависит от промптов, версии и тестовой среды. Для выбора режима смотрите на фактический token usage: none — для прямых ответов, High — для большинства задач с рассуждениями, Max — для сложного анализа, а Low проверяйте отдельно.

Тестирование модели DeepSeek-V4-Flash-0731 выявило парадокс: режим усилий рассуждений Low генерировал на 25–100% больше выходных токенов, чем режим High. Это противоречит интуитивной логике: обычно более высокий уровень усилий подразумевает более длинные цепочки рассуждений и, следовательно, больший объём токенов. Здесь картина обратная.

Измерения проводились на локальном кванте UD-Q2_K_XL и через официальный API DeepSeek. В обеих средах на выбранных промптах паттерн сохранялся. На простых запросах разница достигала 25%, на сложных аналитических задачах разрыв расширялся до 100% и выше. Low не просто «размышляет» — он делает это многословно, часто дублируя логические шаги или добавляя избыточные пояснения. High, напротив, выдаёт более сжатый, структурированный результат. Если такой паттерн сохраняется на рабочих запросах, он напрямую влияет на расчёт стоимости инференса: выбор «низкого» режима может неожиданно увеличить счёт за API.

Практический вывод: ориентироваться на названия режимов нельзя. Нужно измерять реальное потребление токенов на своих задачах. В этой статье разберём методику тестирования, сравним поведение четырёх режимов (none, low, high, max), покажем баг в OpenRouter, который ломает управление усилиями, и дадим рекомендации по оптимизации затрат.

Методика тестирования: как измеряли token usage и стоимость токенов

Для проверки гипотезы о нестандартном расходе токенов использовались две среды: локальный квант модели и удалённые API. Такое сравнение снижает вероятность того, что наблюдение связано только с одной платформой, но не исключает влияния кванта, версии сервера и конкретных промптов.

Локальный квант UD-Q2_K_XL: особенности и ограничения

Квант UD-Q2_K_XL — это сильно сжатая версия модели, оптимизированная для запуска на потребительском оборудовании. Квантование снижает точность весов, что может влиять на генерацию: модель иногда становится более «болтливой» или, наоборот, теряет связность. Этот квант выбран, чтобы проверить, сохраняется ли парадокс токенизации в условиях ограниченных ресурсов. На выбранных промптах паттерн Low > High проявился и здесь, хотя абсолютные цифры токенов отличались от API. Это важная оговорка — на других квантах (Q4_K_M, Q6_K) пропорции могут сдвигаться.

Официальный API DeepSeek и OpenRouter: как передаётся reasoning_effort

Официальный API DeepSeek использовался как контрольная среда. Одинаковые промпты отправлялись с параметром reasoning_effort, установленным в none, low, high и max. В описанных измерениях API DeepSeek воспроизводил данный парадокс. OpenRouter, позиционируемый как универсальный прокси-сервис, повёл себя иначе. На части запросов режимы усилий игнорировались, и модель отвечала так, будто параметр не задан. Это может указывать на баг в проксировании вызовов, который мы отдельно разберём ниже.

reasoning_effort: что означают none, low, high, max

DeepSeek-V4-Flash-0731 поддерживает четыре уровня усилий, управляющих глубиной внутренних рассуждений перед финальным ответом. Параметр reasoning_effort передаётся в API и меняет поведение модели принципиально, а не просто обрезает длину вывода.

• None: модель не генерирует цепочку рассуждений. Ответ формируется напрямую, как в стандартных чат-моделях. Обычно это минимальная задержка и минимальное потребление токенов.
• Low: минимальные рассуждения. Модель делает короткие логические шаги, но по задумке должна оставаться лаконичной. На практике именно здесь обнаружен парадокс многословности.
• High: стандартный уровень. Модель строит развёрнутую цепочку мыслей, но контролирует её объём, стремясь к чёткости и структуре.
• Max: максимальные усилия. Модель исследует множество альтернативных путей решения, проверяет гипотезы, ищет краевые случаи. Обычно это наиболее затратный по токенам режим, который может быть полезен для глубокого анализа.

Ожидаемая логика такова: количество токенов растёт от none к max. Реальность для DeepSeek-V4-Flash-0731 в приведённых измерениях иная: Low обгоняет High, а иногда приближается к Max. Рабочая гипотеза состоит в том, что «минимальные усилия» интерпретируются не как жёсткое сокращение рассуждений, а как более свободный и менее структурированный стиль вывода.

Парадокс Low vs High: token usage, структура ответа и стоимость

Сравнение ответов модели в режимах Low и High на одних и тех же промптах выявило системную разницу в структуре вывода. Low склонен к повторению уже сказанного, переформулированию одной мысли разными словами и включению в ответ фрагментов, которые в High отбрасываются как избыточные. High действует как редактор: он оставляет основную логическую линию, убирает повторы и выдаёт плотный, информативный текст.

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

Low vs High: краткое сравнение

Пример 1: простая задача — где Low проигрывает в эффективности

Промпт: «Объясни разницу между списком и кортежем в Python». В режиме High модель выдала ответ из 4 пунктов, использовав 120 токенов. Чётко, с примерами кода, без воды. В режиме Low ответ занял 180 токенов. Модель добавила вводную фразу «Давайте разберёмся, это важный вопрос», дублировала объяснение про изменяемость в двух абзацах и привела пример, который повторял уже сказанное словами. В этом примере заметного роста качества не было, а расход токенов увеличился на 50%.

Пример 2: сложное рассуждение — неожиданная многословность Low

Промпт: «Проанализируй, как изменение ставки рефинансирования влияет на венчурные инвестиции, и предложи стратегию для стартапа в такой ситуации». В этом сравнении High построил трёхшаговую цепочку: макроэкономический эффект, влияние на оценку рисков, практические рекомендации. Результат занял 450 токенов и содержал структурированный вывод. Low сгенерировал 920 токенов. Он включил пространные рассуждения о каждом шаге, возвращался к уже сделанным выводам, перепроверял их и добавлял оговорки. Ответ стал более «человечным», но потерял в чёткости. Для принятия решений такая многословность вредна: ключевые инсайты тонут в объёме текста.

Баг OpenRouter: почему reasoning_effort может не работать

OpenRouter выступает посредником между пользователем и множеством AI-провайдеров. В описанных проверках параметр reasoning_effort не всегда передавался модели. В части вызовов модель отвечала одинаково при установке low, high и max. Количество токенов и содержание ответа совпадали, что похоже на игнорирование параметра. Баг проявлялся нестабильно: иногда режимы работали корректно, иногда нет. Поэтому OpenRouter не стоит использовать как единственную среду для точного тестирования и production-использования модели с управлением усилиями без предварительной валидации.

Риск для разработчика очевиден: вы настраиваете режим High для экономии, а OpenRouter может передать вызов без параметра, и модель будет работать в режиме по умолчанию. В результате появляются неожиданный объём токенов и некорректные метрики. Подобные проблемы при сравнении моделей через разные scaffolding-решения показывают, что разница в проксировании способна исказить результаты сильнее, чем архитектурные особенности модели.

Как проверить, что режим усилий работает правильно

1. Отправьте тестовый промпт с известным ожидаемым поведением. Например, запрос на решение математической задачи, где важна цепочка рассуждений.
2. Выполните четыре вызова с параметрами reasoning_effort='none', reasoning_effort='low', reasoning_effort='high' и reasoning_effort='max'.
3. Сравните количество выходных токенов и структуру ответа, а также token usage, если эти данные возвращаются в ответе API. При none ожидается прямой ответ без рассуждений, при high — более выраженные логические шаги, при max — обычно более детальный анализ.
4. Если ответы для high и max идентичны или не отличаются от none, режимы усилий, вероятно, не работают. Для контрольной проверки используйте официальный API DeepSeek.

Практические рекомендации: какой reasoning_effort выбрать для оптимизации затрат

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

В этих измерениях High оказался оптимальным для большинства проверенных сценариев: он давал высокое качество ответа при меньшем количестве токенов, чем Low. Max может быть оправдан для сложных исследовательских задач, где глубина анализа критична, а стоимость вторична. None подходит для простых чат-ботов и классификации, где рассуждения не нужны. Low в текущей версии модели не стоит считать экономичным режимом: он проигрывал High и по стоимости, и по качеству на выбранных промптах.

Короткие правила выбора:

• none — прямые ответы, извлечение данных, перевод и классификация, когда рассуждения не нужны.
• low — не выбирать по названию; сначала проверить token usage и качество на собственных промптах.
• high — базовый выбор для логического вывода, генерации кода и структурированного анализа.
• max — сложные исследовательские задачи, где дополнительные токены оправданы требуемой глубиной.

Сценарий 1: быстрые ответы без рассуждений — режим none

Используйте none, когда задача требует прямого ответа без анализа. Примеры: извлечение именованных сущностей из текста, перевод, ответы на фактологические вопросы («Сколько ГБ в терабайте?»). В сводных измерениях экономия токенов по сравнению с High составляла около 60%. Модель не тратит ресурсы на внутренние монологи, что обычно ускоряет ответ и снижает затраты.

Сценарий 2: баланс цены и глубины — почему High часто лучше Low

Для задач, требующих логического вывода, генерации кода или структурированного анализа, High даёт лучший результат за меньшие деньги в приведённых измерениях. Модель в этом режиме дисциплинированна: она строит цепочку рассуждений, но отбрасывает лишнее. Low, вопреки названию, ведёт себя как «разговорчивый коллега» — он может дать правильный ответ, но вы потратите время на чтение и деньги на лишние токены. Прямое сравнение DeepSeek V4 Flash с Qwen 3.6 27B показывает, что в кодинге и агентных сценариях чёткость вывода критична, и High её обеспечивает.

Выводы и дальнейшие шаги

Главный инсайт: режим Low в DeepSeek-V4-Flash-0731 не является «низким» по потреблению токенов. В приведённых измерениях он генерировал на 25–100% больше токенов, чем High, из-за менее строгого контроля над структурой рассуждений. Это парадокс, который нужно учитывать при расчёте стоимости API.

Рекомендации:

• Всегда тестируйте модель на своих данных и промптах, не полагайтесь на названия режимов. Фиксируйте token usage и качество ответа.
• Используйте официальный API DeepSeek для точных измерений — OpenRouter может искажать поведение из-за бага с пробросом параметров.
• High — практическая отправная точка для большинства задач. Он даёт структурированный ответ за меньшее количество токенов, чем Low, в описанных измерениях.
• Low не считайте экономичным по умолчанию: проверяйте его отдельно, если многословность допустима для конкретного сценария.
• Max включайте только для глубокого исследовательского анализа, когда стоимость не критична.

Данные актуальны на момент тестирования (июль-август 2026). Модель может обновиться, а баг в OpenRouter — исправиться, поэтому значения следует перепроверять после обновлений. Если вы уже экспериментировали с режимами усилий на своих задачах, ваши цифры помогут сообществу точнее оценить модель.

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