Флагманська модель DeepSeek змінилася за одну ніч. Без жодних оголошень чи постів у блозі компанія замінила попередню збірку, яку використовувала більшість розробників, на офіційний реліз V4 Pro 0813, зберігши ту саму назву API-ендпоінту.

Ця заміна має значення, оскільки внутрішні ваги моделі — дані, що визначають, як вона інтерпретує промпти та форматує відповіді — змінилися. Будь-що, що покладається на певний стиль виводу, синтаксис виклику інструментів (tool-call) або поведінку при виконанні інструкцій, може зламатися в той самий момент, коли провайдер випускає нову версію за незмінним ендпоінтом.

Як DeepSeek перейшов на V4 Pro 0813

Публічний API DeepSeek тривалий час пропонував одну назву — наприклад, deepseek-v4-pro — як точку входу для своєї великої мовної моделі. Внутрішньо ця назва є лише покажчиком, який вендор може перенаправити в будь-який момент. У цьому випадку покажчик перемістився з попередньої збірки на офіційно випущену модель V4 Pro 0813.

V4 Pro 0813 приносить кілька ключових функцій, які, ймовірно, стали причиною переходу:

  • Перевага в ціні — вона коштує помітно менше, ніж конкуруючі пропозиції, такі як Claude.
  • Величезне контекстне вікно — модель може обробляти до 1 мільйона токенів в одному запиті, що є необхідним для багатьох розробників при роботі з довгими документами або розлогими історіями чатів.
  • Конкурентна продуктивність — бенчмарки показують лише невеликий розрив із найпотужнішими моделями у стандартних завданнях.
  • Майбутня зміна ціни — DeepSeek дав зрозуміти, що поточна ціна може зрости пізніше, що робить теперішній тариф привабливим для ранніх користувачів.

Жодна з цих змін не відображається в контракті API. Назва ендпоінту, формат запиту та схема відповіді залишаються ідентичними, тому клієнт, який просто викликає ендпоїнт, не бачить жодних ознак того, що базова модель була замінена.

Чому тихі оновлення є прихованим ризиком

Оновлення після навчання (post-training) можуть змінити три аспекти, які є найважливішими для робочих процесів (production pipelines):

  1. Дотримання інструкцій — незначні зміни в тому, як модель інтерпретує системні промпти, можуть призвести до інших варіантів завершення тексту, що порушує логіку подальшої обробки, яка очікує точних формулювань.
  2. Форматування викликів інструментів (tool-call) — багато агентів покладаються на сувору схему JSON для виклику зовнішніх інструментів. Нова версія моделі може додати, видалити або змінити порядок полів, що спричинить помилки парсингу.
  3. Стиль виводу — навіть вибір лапок, пробілів або порядку елементів списку може порушити перевірки на відповідність рядків, які деякі додатки використовують для валідації.

Коли провайдер тихо змінює модель, розробники не мають автоматизованого способу виявити це відхилення, доки помилка не проявиться в робочому середовищі. Вартість такої помилки — простої системи, розчарування користувачів або фінансові втрати — може значно перевищити зусилля, необхідні для фіксації версії моделі.

Практичні кроки для захисту вашого AI-стека

  • Використовуйте версію з датою в аліасі — Замість використання загального deepseek-v4-pro, оберіть назву, що включає дату релізу або хеш версії, наприклад, deepseek-v4-pro-2024-08-13. Залиште неспецифічний аліас лише для експериментів.
  • Підтримуйте «золотий» набір тестів — Сформуйте фіксовану колекцію репрезентативних промптів та очікуваних відповідей. Запускайте ці тести автоматично щоразу, коли змінюється ідентифікатор моделі. Будь-яке відхилення вкаже на регресію ще до того, як трафік буде перенаправлено.
  • Логуйте відбитки (fingerprints) моделі — Кожна відповідь API містить метадані, такі як версія моделі або хеш. Зберігайте це разом із запитом у ваших логах і налаштуйте сповіщення про будь-які неочікувані зміни.
  • Впровадьте шар маршрутизації — Абстрагуйте виклик моделі за допомогою внутрішнього сервісу, який вирішує, яку саме конкретну назву моделі використовувати. Цей шар може виконувати «канарейкове розгортання» (canary rollout): спрямовувати невеликий відсоток трафіку на нову версію, порівнювати результати із «золотим» набором і переходити на неї лише тоді, коли метрики відповідатимуть вашим порогам.
  • Розділяйте середовища продакшну та тестування — Тримайте аліас продакшну зафіксованим на відомій версії. У середовищі staging спрямовуйте аліас на останній реліз, щоб розробники могли бачити нову поведінку, не впливаючи на реальних користувачів.

Впровадження цих заходів перетворює тиху заміну моделі з події, що «ламає збірку», на контрольований експеримент. Накладні витрати на шар маршрутизації або набір золотих тестів є незначними порівняно з вартістю збою, спричиненого неочікуваним форматом виводу.

На що варто звернути увагу

DeepSeek натякнув на майбутнє підвищення цін, що може спонукати більше клієнтів зафіксувати поточні тарифи, закріпивши версію вже зараз. Слідкуйте за будь-якими офіційними повідомленнями — навіть найкоротшими — на предмет натяків на майбутні оновлення, і моніторте форуми спільнот, де інші розробники можуть ділитися першими ознаками відхилень (drift). Якщо провайдер зрештою опублікує список змін (changelog), інтегруйте його у свій робочий процес закріплення версій (version-pinning workflow), щоб ви могли вирішити, чи переходити на нову модель, чи залишатися на попередній.

Висновок: Незмінний ендпоінт не гарантує незмінності моделі. Ставтеся до назви моделі як до змінного вказівника (mutable pointer), а не як до контракту. Завдяки закріпленню версій, тестуванню на основі фіксованого «золотого набору» (golden set) та маршрутизації запитів через внутрішню абстракцію, ви перетворюєте приховані оновлення з прихованої загрози на керовану частину вашого життєвого циклу розробки.