DeepSeek V4.1-Flash-1017 представили поздно вечером в субботу 17 октября: компания выпустила серию сообщений в X и технический отчёт на Hugging Face. Разработчик называет релиз незначительным обновлением предыдущей V4.1-Flash и обещает три вещи: рост результатов в бенчмарках, более быстрое выполнение задач и более короткий вывод. Сообщение о релизе перечисляет эти пункты без методики замера.
Короткий ответ на главный вопрос: измеримой публичной цифры экономии токенов у V4.1 Flash нет. Единственный подтверждённый замер в доступных материалах, это Humanity's Last Exam, где новая версия набрала 36,8-42,6 балла против 36,8-39,1 у V4.1-Flash. HLE проверяет качество решений на тысячах задач по математике, естественным и гуманитарным наукам. Расход токенов он не измеряет вообще.
Отсюда практический вывод: модель можно пробовать, но решение о переходе стоит принимать по собственным замерам, а не по формулировке «более короткие выходные данные».
Что такое DeepSeek V4.1 Flash и что разработчик заявил об экономии токенов
V4.1-Flash-1017 это номер сборки поверх прошлой V4.1-Flash, а не новая архитектура. Модель уже доступна в веб-версии, в приложении DeepSeek и на платформе для разработчиков, то есть проверить её можно без локальной установки.
Официальные заявления vs подтверждённые цифры
Три тезиса из релиза стоит разделить по степени проверяемости.
- Выше результаты в бенчмарках. Частично подтверждено: на HLE верхняя граница диапазона выросла с 39,1 до 42,6 балла.
- Быстрее выполнение задач. Заявление без опубликованной методики: непонятно, о какой латентности речь, при каком контексте и каком уровне thinking effort проводились замеры.
- Более короткий вывод. Тоже заявление. Ни распределения длины ответов, ни набора задач, ни базовой линии в открытом виде нет.
| Модель | HLE, баллы | Как читать |
|---|---|---|
| V4.1-Flash-1017 | 36,8-42,6 | Верхняя граница выше, нижняя совпадает с прошлой версией |
| V4.1-Flash | 36,8-39,1 | Базовая линия для сравнения |
Диапазоны пересекаются, и это важнее верхней цифры. На нижней границе версии неразличимы. Чем объясняется разброс, в материалах не раскрыто, поэтому корректно сравнивать только одинаковые режимы, а какие именно настройки дали какие баллы, из публикации не ясно.
Почему «экономия токенов» самый спорный пункт релиза
Расход токенов зависит от задачи, формулировки промпта, длины контекста, уровня thinking effort и того, как модель строит цепочку рассуждений. Без фиксации этих параметров формулировка «короче на N процентов» не значит ничего: её можно получить почти для любой пары моделей, подобрав удобный набор задач.
Дефицит данных хорошо виден в обсуждении на r/LocalLLaMA. Автор поста искал публикации о токен-эффективности V4.1 Flash и нашёл ровно одну, где экономия подаётся как главный аргумент, а сам бенчмарк он называет бессмысленным. Обсуждение токен-эффективности V4.1 Flash иллюстрирует не отсутствие экономии, а отсутствие нормального способа её измерить.
Почему маркетинговые замеры экономии токенов ненадёжны
Замер токен-эффективности ломается на деталях, которые почти никогда не попадают в красивый график. Проверить чужой бенчмарк можно по нескольким признакам.
Типичные ошибки в замерах токен-эффективности
- Не описан набор задач: непонятно, что решали, сколько задач было и насколько они похожи на ваши.
- Не зафиксирован thinking effort. Длина CoT на разных уровнях различается сильнее, чем между версиями модели.
- Не указана версия: V4.1-Flash и V4.1-Flash-1017 легко перепутать, а сравнение идёт именно между ними.
- Токены рассуждений смешаны с токенами финального ответа, хотя платятся они одинаково, а означают разное.
- Нет базовой линии: экономия «относительно чего» остаётся загадкой.
- Нет повторяемости: один прогон на генеративной модели ничего не доказывает.
- Неудачные прогоны выброшены из выборки, хотя именно они дают основную стоимость.
Условный пример арифметики. Если на high effort длина CoT сократилась на 20 процентов, а на max effort не изменилась, то при доле high в половину запросов средняя экономия по парку составит 10 процентов. В релизе такая цифра превратилась бы в «до 20 процентов короче». Разница между этими двумя формулировками и есть суть проблемы.
Чем независимые бенчмарки отличаются от вендорских
Вендорский замер отвечает на вопрос «что мы хотим показать», независимый, на вопрос «что воспроизводится у третьей стороны». Площадки вроде AA дают именно второй тип данных, но их работа не гарантирована: автор поста прямо пишет, что не уверен, будет ли AA ретестировать эту модель, хотя и надеется на это. Надежда на независимый ретест пока остаётся надеждой, а не фактом.
HLE тоже внешний бенчмарк, но он про качество ответов. Ни один из доступных публичных замеров не отвечает на вопрос «сколько токенов уходит на одно успешно решённое действие».
Какие метрики оценки LLM действительно важны для токен-эффективности
Сравнение по расходу токенов имеет смысл только при фиксированном наборе задач и одинаковом thinking effort. Дальше нужен набор метрик, каждая из которых ловит свой тип расхода.
| Метрика | Что показывает | Как считать |
|---|---|---|
| Входные токены | Стоимость контекста: системный промпт, история диалога, вставки из RAG | Из ответа API, поле usage |
| Выходные токены всего | Полная стоимость генерации | Сумма по всем шагам задачи |
| Токены CoT | Сколько уходит на размышления до содержательного ответа | Отдельным полем, если провайдер его отдаёт; иначе оценка по разметке блоков |
| Число шагов/ходов до решения | Накладные расходы в агентных сценариях и tool calling | Счётчик итераций на задачу |
| Доля решений с первой попытки | Стабильность и предсказуемость | Успех с первой итерации / все задачи |
| Токены на успешно решённую задачу | Главная экономическая величина | Все токены задачи, включая провалы, делить на число успехов |
| Стоимость за решённую задачу | Сравнение моделей в деньгах при текущем прайсе | Токены умножить на тариф входа и выхода, сложить |
Токены на задачу vs токены на успешное решение
Схематичный пример. Модель A выдаёт компактную цепочку рассуждений, но чаще переспрашивает и делает три шага вместо одного. Модель B пишет длиннее, зато решает с первой попытки. По средней длине ответа A выглядит дешевле, по стоимости за решённую задачу B может оказаться впереди, потому что вы не платите за две неудачные итерации.
Именно поэтому цифру «на N процентов короче вывод» стоит сразу пересчитывать в токены на успех. Как считаются деньги на конкретных тарифах, мы разбирали в материале про DeepSeek V4 Flash и цену в $0.09 за миллион входных токенов: там видно, что при низких тарифах экономия длины ответа влияет на счёт меньше, чем число повторных попыток.
Как учитывать длину CoT и thinking effort
Thinking effort это отдельный параметр, и его нужно фиксировать при любом сравнении, ровно как версию модели и температуру. Наблюдения по V4.1 Flash показывают, что уровень effort меняет картину радикально: на максимальном режиме длина CoT остаётся прежней, на high сокращается. Усреднять такие замеры в одно число нельзя, иначе вы получите показатель, которого нет ни на одной реальной настройке.
Что показывают предварительные тесты DeepSeek V4.1 Flash на Reddit
Автор поста прогнал свой классический набор тестов, по его собственным словам, не весь. Результаты стоит читать как ранний сигнал, а не как доказательство.
Max vs high effort: где реально сокращается CoT
Два наблюдения из предварительных тестов на Reddit:
- На максимальном thinking effort разницы в длине CoT относительно прошлой версии нет.
- На high effort цепочка рассуждений заметно короче, но ненамного.
- Независимо от уровня качество CoT выше, меньше «воды», и до решения задачи уходит меньше ходов.
Практический смысл простой: если ваш продакшен работает на max effort, экономии по длине рассуждений ждать не стоит. Выигрыш там идёт за счёт меньшего числа шагов, а это уже другая метрика и другой расчёт стоимости. Если рабочий режим high, сокращение CoT есть, но измерять его надо в своих задачах.
Почему сравнение с GLM 5.3 Flash важно
Автор поста отмечает, что предыдущая V4.1-Flash была настолько слабой, что GLM 5.3 Flash оказывалась для него лучшим выбором. Это субъективный личный опыт, а не контролируемое сравнение, но контекст он задаёт: текущий положительный сигнал означает улучшение относительно слабой базы, а не автоматическую победу над конкурентами. Базовую линию всё равно нужно строить самому, ориентируясь на критерии из разбора GLM 5.3 Flash и MiMo 2.6 Flash для реальной разработки.
Стоит ли пробовать DeepSeek V4.1 Flash: кому подходит и с какими оговорками
Взвешенный ответ выглядит так: попробовать имеет смысл, но с собственными замерами и без расчёта на готовый бенчмарк токен-эффективности.
Кому имеет смысл тестировать модель сейчас
- Командам, которые платят за токены и считают стоимость за решённую задачу: меньше шагов до решения напрямую снижает счёт.
- Тем, у кого high effort рабочий режим: именно здесь предварительные тесты видят сокращение CoT.
- Агентным пайплайнам, где цена ошибки измеряется лишними итерациями, а не длиной одного ответа.
- Тем, кто готов потратить пару дней на прогон своих 20-30 задач: без этого любой вывод останется чужим.
Кому лучше подождать независимых данных
- Если для решения нужен воспроизводимый публичный бенчмарк токен-эффективности. Его пока нет, а ретест AA не подтверждён.
- Если критична стабильность на max effort: там длина CoT не изменилась, а выигрыш держится на качестве рассуждений и числе шагов.
- Если планируется локальный запуск: технические ограничения по квантизации и таблицам (ниже) придётся обходить руками.
Отсутствие независимого ретеста это неопределённость, а не приговор модели. Просто она означает, что риск ошибки выбора лежит на вас, и снижать его придётся собственной методикой.
Как самостоятельно провести корректный тест токен-эффективности
Методика занимает меньше дня и даёт цифры, которым можно верить больше, чем релизным графикам.
Минимальный набор метрик и как их логировать
- Зафиксируйте набор из 10-30 реальных задач своего домена, с эталонными ответами и понятным критерием успеха.
- Зафиксируйте версию модели (V4.1-Flash-1017) и thinking effort. Меняете effort, меняете прогон целиком.
- Логируйте токены входа, выхода и CoT отдельными полями.
- Считайте число шагов или ходов до решения по каждой задаче.
- Фиксируйте успех и неуспех, а затем делите все потраченные токены на число успехов.
- Прогоните базовую линию: предыдущую V4.1-Flash, GLM 5.3 Flash или модель, которая стоит у вас сейчас.
- Повторите прогон минимум дважды, чтобы увидеть разброс.
Схема лога, которую достаточно вести в CSV:
model,version,thinking_effort,task_id,tokens_in,tokens_out,tokens_cot,steps,result,latency_ms
v4.1-flash-1017,1017,high,T-014,1820,940,610,1,ok,8420
v4.1-flash,1014,high,T-014,1820,1180,830,2,fail,15310
Из этих двух строк уже видно, как считается экономика: вторая модель потратила больше токенов и не решила задачу с первой попытки, поэтому её стоимость за успех выше, даже если сравнивать только длину вывода.
Как не обмануть себя при сравнении
- Не меняйте промпты между моделями, иначе вы сравниваете формулировки, а не модели.
- Не сравнивайте high effort с max effort: это разные режимы с разным качеством и ценой.
- Не выбрасывайте неудачные прогоны, они и есть основная статья расходов в продакшене.
- Не усредняйте по разнородным задачам без разбивки: код, аналитика и тексты дают разную длину CoT.
Предварительные тесты автора поста были неполными, и для ранней оценки это нормально. Для решения о миграции такой выборки мало: нужна базовая линия и повторяемость. Пример более дисциплинированного подхода есть в разборе теста локальных и облачных моделей на 500+ заданиях по кодингу и pandas.
Технические нюансы: квантизация и локальный запуск V4.1-Flash-1017
Для тех, кто планирует запускать модель у себя, доступны не только облачные эндпоинты.
Что даёт EXL3 2.9 bpw и чем это грозит качеству
Опубликована EXL3-квантизация 2.9 bpw версии V4.1-Flash-1017. По данным авторов релиза, на отложенном тексте перплексия растёт на 1,8 процента на коде и на 0,4 процента на прозе относительно неквантованной модели. Деградация небольшая, но для кода она в четыре с лишним раза заметнее, чем для прозы, и проверять её стоит на своих задачах, а не переносить выводы с чужого held-out набора. Замер относится к конкретному квантованному релизу и к двум непубличным наборам текста, к токен-эффективности исходной модели он отношения не имеет.
Engram-таблицы и совместимость с exllamav3
Две таблицы Engram в релизе 1017 новые, и шарды из более старого релиза переиспользовать нельзя. Второе ограничение: в upstream exllamav3 пока нет класса модели DeepseekV41, поэтому напрямую загрузить этот чекпоинт он не может. Обе вещи всплывают уже на этапе планирования локального деплоя, а не после него. Если вы ускоряете MoE-инференс своими патчами, полезны замеры из материала про оптимизацию MoE-инференса в llama.cpp на RTX 4080, где видно, какие патчи дают прирост, а какие ломают воспроизводимость.
Что в итоге: как принимать решение по DeepSeek V4.1 Flash
Соберите факты в одну картину. Официально подтверждён только прирост на HLE: 36,8-42,6 против 36,8-39,1, причём диапазоны пересекаются. Публичного надёжного бенчмарка токен-эффективности нет, единственная найденная публикация на эту тему опирается на замер, который автор обсуждения называет бессмысленным, а ретест AA не подтверждён.
Предварительные тесты дают осторожный положительный сигнал: качество CoT выше, меньше «воды», меньше шагов до решения; на high effort CoT заметно короче, на max effort длина не меняется. Предыдущая версия при этом уступала GLM 5.3 Flash, так что планка для сравнения низкая.
Дальше два пути. Первый: взять 20-30 своих задач, зафиксировать версию и thinking effort, прогнать V4.1-Flash-1017 против текущей модели и посчитать токены на успешно решённую задачу. Второй: подождать независимых данных, если вам нужна цифра, которую можно показать без собственных логов. Локальный запуск добавляет третий пункт: новые Engram-таблицы и отсутствие класса DeepseekV41 в exllamav3 придётся учитывать заранее.