Облачный эндпоинт модели не гарантирует стабильных весов. Пользователь /u/Jipok_ разобрал локальные логи своего кодинг-агента за 40 дней и обнаружил, что deepseek-v4.1-flash в середине октября 2026 года начала работать заметно хуже. 17 октября провайдер выпустил обновление -1017, а к 19 октября молча перезаписал эндпоинт новыми весами. Откатиться к прежней версии через облачный API нельзя: старых весов на стороне провайдера больше нет.
Что изменилось в -1017: провайдер убрал давнюю особенность, при которой модель периодически отвечала по-китайски, будучи на сто процентов уверенной, что пишет по-английски. Второе изменение - модель стала агрессивнее вызывать инструменты. По оценке автора логов, вместе с этими правками просело общее качество ответов.
Измеримые последствия по его же логам: нецензурные выражения втрое чаще, переключения моделей посреди сессии в 6,7 раза чаще. Это личный опыт одного пользователя, а не независимый замер, и методика разбора логов в посте не раскрыта. Дальше - что из этого кейса переносится на любую работу с облачными моделями.
Что произошло с deepseek-v4.1-flash: хронология тихой подмены
Кейс укладывается в три даты, и каждая меняет поведение агента без единой правки в клиентском коде.
- Середина октября 2026: по логам автора модель начинает отвечать заметно хуже прежнего.
- 17 октября: выходит обновление -1017, где исправлена утечка китайского языка и усилен вызов инструментов.
- 19 октября: провайдеры перезаписывают эндпоинт deepseek-v4.1-flash новыми весами.
Последовательность восстановлена по публикации /u/Jipok_. Сами логи и скрипт разбора автор не показывает, так что даты читатель принимает на веру: перепроверить их можно только собственной телеметрией.
Обновление -1017 от 17 октября: что чинили и что сломали
В -1017 провайдер закрыл две давние претензии к модели. Первая - случайные ответы на китайском: до апдейта модель периодически переходила на китайский, оставаясь уверенной, что говорит по-английски. Вторая - вялый вызов инструментов: после апдейта модель стала агрессивнее дёргать tool calls.
«In the -1017 update (released Oct 17) they fixed the Chinese leak and made it fire tool calls more aggressively - and somehow lobotomized the model in the process»
Формулировка про «лоботомию» - оценка автора логов, а не вывод из официальных заметок к релизу: описания изменений в источнике нет. Есть и более скучное объяснение. Агрессивные вызовы инструментов меняют структуру агентного цикла: больше шагов, больше промежуточных сообщений, больше шума в контексте. Пользователь видит ухудшение ответов, хотя часть эффекта создаёт обвязка вокруг модели. Разделить эти причины можно только прогоном одних и тех же задач на обеих версиях, а второй версии в облаке уже нет.
19 октября: эндпоинт тот же, веса другие
Идентификатор deepseek-v4.1-flash в запросе остался прежним. Тот же URL, та же схема биллинга, тот же формат ответа. Под капотом к 19 октября провайдеры отдавали новые веса. Пользователь узнаёт об этом из поведения модели, а не из письма на почту.
Откат через облачный API невозможен: вы не можете попросить у провайдера чекпойнт двухнедельной давности. Здесь и появляется главная асимметрия облачных моделей. Выбор модели у вас есть. Выбора версии модели нет.
Почему облачный эндпоинт - не гарантия стабильной модели
Алиас модели в API указывает на текущий деплой провайдера, а не на зафиксированный артефакт. Всё, что стоит между вашим запросом и весами, провайдер меняет по своему графику.
Алиас модели, снапшот и версия весов: в чём разница
Три сущности, которые легко перепутать:
- Алиас - строка в запросе, например deepseek-v4.1-flash. Указатель на «что сейчас работает под этим именем».
- Снапшот - датированная версия, если провайдер её публикует: суффикс с датой или отдельный идентификатор модели.
- Веса - конкретный чекпойнт с конкретным квантованием и настройками инференса.
Если провайдер отдаёт только алиас, воспроизводимость нулевая: завтрашний ответ на тот же запрос не обязан совпадать с сегодняшним. В мире открытых весов версия - это файл, который скачивают, хэшируют и хранят у себя. В облаке версия - обещание провайдера, и оно не всегда подкреплено SLA. Разные хостеры могут держать одну и ту же модель с разными весами и разными настройками, поэтому «deepseek-v4.1-flash у одного провайдера» и «у другого» - не обязательно одно и то же.
Что ещё меняется помимо весов
Прежде чем объявлять регрессию модели, стоит вычеркнуть источники дрейфа на стороне провайдера и на своей.
- Системный промпт, который провайдер подмешивает по умолчанию.
- Шаблон чата и форматирование tool calling.
- Параметры вызова инструментов: та самая агрессивность из -1017.
- Квантование и роутинг на разное железо под нагрузкой.
- Лимиты контекста, усечение истории, фильтры и модерация.
- Ваша сторона: версия агента, правки промптов, набор инструментов, температура, логика ретраев.
Практический порядок проверки простой: сначала фиксируем свою сторону и убеждаемся, что промпты и инструменты не менялись, потом смотрим на модель. Половина «деградаций» на этом шаге отменяется.
Как поймать регрессию по своим логам: методика телеметрии кодинг-агента
Автор кейса распарсил локальные логи сессий за 40 дней, чтобы найти день, когда модель «поглупела». Какие поля он брал и как считал, в источнике не сказано, поэтому ниже - рекомендуемая схема, а не реконструкция его методики.
Минимальный набор полей для логов сессий
Логировать нужно и успешные сессии, иначе сравнивать будет не с чем.
| Поле | Зачем нужно |
|---|---|
| timestamp (UTC) | Окна до и после 17 и 19 октября, привязка к датам апдейтов |
| model_id и endpoint | Что именно вызывалось, не сменился ли алиас |
| provider и регион | Разные хостеры и площадки дают разное поведение |
| agent_version | Исключить собственные изменения в агенте |
| prompt_hash | Поймать правку системного промпта и шаблона |
| temperature, top_p, max_tokens | Параметры сэмплинга влияют на стабильность сильнее, чем кажется |
| tool_calls_count и типы инструментов | Сравнить агрессивность вызовов до и после |
| retry_count, error_code | Отделить технические сбои от смысловых провалов |
| messages_count и длина сессии | Где именно сессия разваливалась |
| model_switch_flag | Смена модели посреди сессии, как в кейсе с ростом в 6,7 раза |
| outcome (успех, частично, провал) | Объективная оценка результата задачи |
Прокси-метрики фрустрации: что они говорят и чего не говорят
Две цифры из кейса - рост нецензурных выражений втрое и переключения моделей в 6,7 раза чаще - описывают поведение автора, а не качество модели. Это прокси-метрики фрустрации. Они дёшевы: не нужны эталонные наборы и разметка. И они чувствительны к посторонним факторам: дедлайны, сложность задач в конкретную неделю, настроение, привычка переключаться при первой заминке.
Сравнивать такие цифры между людьми бессмысленно, воспроизвести их нельзя. Держите их как вспомогательный сигнал рядом с объективными: доля закрытых задач, число ретраев на сессию, время до результата, доля сессий, брошенных до завершения.
Как отличить регрессию модели от своих изменений
- Зафиксируйте неизменность промптов, инструментов и версии агента на всём окне сравнения.
- Соберите регрессионный набор из 20-50 реальных задач с сохранёнными ответами прошлого периода.
- Прогоните набор на текущем эндпоинте дважды, чтобы отделить шум сэмплинга от системного сдвига.
- Проверьте, не сменился ли провайдер, регион или тариф между периодами.
Если промпты те же, инструменты те же, а поведение уехало синхронно с датой релиза, гипотеза о подмене весов становится основной. Как собирать такой набор с автоматическими проверками, разобрано в материале про Terminal Bench 4.0 и компактный evaluation-набор для кодинг-агентов.
Бенчмарки против личных логов: что говорят независимые замеры
Модель с меткой 1017 фигурирует в независимых замерах. По данным Artificial Analysis, в Coding Agent Index на Terminal-Bench 4.0 DeepSeek V4.1 Flash 1017 решила 31% задач. Для сравнения в тех же замерах: Mistral Large 4 - 41%, GLM-5.3 - 40%, Kimi K3 - 21%. В Intelligence Index v5 у Mistral Large 4 26 баллов, это лучший результат среди открытых моделей не из Китая, но на 6 баллов ниже DeepSeek V4.1 Flash 1017 и GLM-5.3.
Цифры не подтверждают и не опровергают кейс. Бенчмарк измеряет модель на стандартизированных задачах в контролируемых условиях. Кейс /u/Jipok_ описывает поведение в конкретном агенте на конкретных рабочих задачах с конкретным промптом. Совпадение метки 1017 в названии бенчмарк-версии и в апдейте не доказывает деградацию и не опровергает её.
Почему средний балл не отменяет просадку в узком сценарии
Агрегированный индекс усредняет по десяткам задач разного типа. Многошаговый агентный цикл с tool calling, длинным контекстом и жёстким системным промптом занимает в этом усреднении небольшую долю. Сдвиг в распределении ошибок - например, более агрессивные вызовы инструментов - может испортить именно агентный сценарий, почти не двинув средний балл. Поэтому личная телеметрия и бенчмарки отвечают на разные вопросы и не заменяют друг друга. Ограничения методик разобраны отдельно, в тексте о том, почему бенчмаркам AI-моделей пока нельзя доверять.
Ограничения кейса: чему здесь можно верить, а чему нет
Честная оценка достоверности важнее красивых цифр:
- Наблюдения о просадке, датах -1017 и замене весов к 19 октября - личный опыт одного пользователя /u/Jipok_, а не независимое измерение.
- Метрики «втрое» и «в 6,7 раза» описывают поведение автора, а не качество модели: это не бенчмарки.
- Не указано, какие именно провайдеры заменили эндпоинт и как велась телеметрия, поэтому методику нельзя воспроизвести по описанию.
- Тезис о невозможности отката относится к облачному API и ничего не говорит о способах зафиксировать версию другими путями.
Вывод: кейс полезен как демонстрация класса проблем и как повод завести свои логи. Доказательством конкретной деградации конкретной модели он не становится.
Если нужна фиксированная версия весов: варианты и их цена
Задачу «версия модели не должна меняться без моего ведома» решают несколькими способами, и у каждого есть цена.
Локальные веса: воспроизводимость против железа
Открытые веса дают то, чего не даёт облако: версия - это файл. Его можно скачать, посчитать хэш, хранить рядом с проектом и откатиться в любой момент. Тихих обновлений нет, данные не уходят наружу.
Плата тоже понятная. Нужно железо под конкретное квантование: объём VRAM зависит от размера модели и разрядности, и цифры для конкретной модели надо брать из её карточки, а не из чужих постов. Нужна инфраструктура: загрузка, сервинг, батчинг, мониторинг. Обновления безопасности и улучшения качества теперь ваша задача. Как выглядит борьба за скорость на локальном железе и какие компромиссы при этом всплывают, показывает эксперимент с ускорением MoE-инференса в llama.cpp на RTX 4080.
В материалах как кандидат с открытыми весами упомянута Mistral Large 4 (Le Chonk). Конкретных требований к VRAM и замеров скорости по ней в источнике нет, поэтому rating-таблицы из головы не составляем: проверяйте карточку модели и собственный прогон. Общую картину по открытым моделям и их отставанию от облачных флагманов разбирает материал о том, отстал ли DeepSeek от Qwen и GLM в 2026 году.
Пиннинг снапшота в облаке: что проверять в документации
Остаться в облаке и снизить риск можно, но только если провайдер даёт для этого инструменты. Чек-лист для чтения документации:
- Есть ли датированные снапшоты модели и как они называются в запросе.
- Что написано про deprecation-политику: за сколько дней предупреждают об отключении версии.
- Возвращает ли API в ответе поле с версией или идентификатором задеплоенного снапшота.
- Публикуется ли changelog с датами изменений.
Если провайдер отдаёт только алиас, считайте версию неконтролируемой и закладывайте регрессионные прогоны как обязательный шаг. Утверждать, что у конкретного провайдера снапшоты есть или их нет, по этому кейсу нельзя: таких данных в источнике нет.
Остальные варианты работают как дополнение. Контрактные гарантии и SLA помогают в корпоративных тарифах, но не спасают, если алиас не прибит к снапшоту. Кэширование ответов и собственный регрессионный набор страхуют при миграции. Гибридная схема удобна на практике: облако для черновой работы, локальные веса для критичных задач.
| Критерий | Облачный API | Локальные веса |
|---|---|---|
| Воспроизводимость версии | Зависит от провайдера, при одном алиасе нулевая | Полная: файл с хэшем |
| Контроль обновлений | На стороне провайдера | На вашей стороне |
| Стартовые затраты | Оплата по токенам | Железо под нужное квантование |
| Обслуживание | Чужое | Ваше: сервинг, мониторинг, обновления |
| Приватность данных | Зависит от политики провайдера | Данные не покидают контур |
Чек-лист: как защититься от тихой подмены моделей
- Логируйте в каждой сессии модель, эндпоинт, версию агента и хэш промпта. Без этого сравнивать периоды нечем.
- Держите регрессионный набор реальных задач и прогоняйте его при любом подозрении на просадку.
- Отслеживайте прокси-метрики фрустрации: ретраи, смены модели, брошенные сессии. Они дают ранний сигнал, но не заменяют проверяемых тестов.
- Проверьте, есть ли у провайдера датированные снапшоты, и пините их явно в коде, а не в голове.
- Держите fallback-модель и план миграции: смена эндпоинта не должна требовать переписывания агента.
- Для критичных задач посмотрите в сторону открытых весов и локального запуска, заранее оценив VRAM и стоимость обслуживания.
Стабильность модели в облаке - результат вашего мониторинга и архитектурных решений, а не свойство API. Один пост вроде разбора /u/Jipok_ стоит воспринимать как сигнал: проверьте свои логи за последние недели, пока подмена не всплыла в виде сорванного дедлайна.