DeepSeek се премести от обикновен въпрос за избор на модел към въпрос за време.
Официалната страница за ценообразуване API на компанията вече изброява DeepSeek V4 Flash и DeepSeek V4 Pro с големи контекстни прозорци от 1 милион токена, OpenAI-формат и Anthropic-формат основни URL адреси и отделни категории за таксуване за кеширане input, cache-miss input и output tokens. Докладите, обобщени от Techmeme на 13 август, гласят, че DeepSeek повишава цените на моделите V4 и въвежда динамично таксуване в пиков/ненатоварен период, като новото ценообразуване влиза в сила в 16:00 UTC на 16 август 2026 г.
Това прави промяната повече от рутинна актуализация на ценовата таблица. За екипи, работещи с интензивни агенти за извличане, асистенти за кодиране с дълъг контекст, задания за пакетен анализ или насочени към клиента AI продукти, цената на DeepSeek заявка вече може да зависи не само от избрания модел, но и кога е изпратена заявката и каква част от подканата може да бъде обслужена от кеша.
Какво се промени в DeepSeek V4 текущата API документация на billing
DeepSeek представя V4 Flash и V4 Pro като налични както в OpenAI-style, така и в Anthropic-style API формати. Това има значение, тъй като много разработчици вече маршрутизират DeepSeek заедно с други доставчици чрез слоеве за съвместимост, вместо да пишат специфичен за доставчика код на приложение.
Забележителната структура на таксуване е разделянето на входа при попадение в кеша, входа и изхода при пропуск в кеша. На практика това означава, че повтарящите се префикси на подкана, системни инструкции, схеми на инструменти или дълги контекстни блокове за многократна употреба могат да имат различен разходен профил от новоподадения текст на подкана. Това вече беше важна част от DeepSeek историята на разходите за V4-Pro. Новият пиков/извън пиков слой добавя друга променлива: едно и също работно натоварване може да има различна цена в зависимост от това кога се изпълнява.
Вторичното отчитане сочи значително увеличение на цените за моделите V4 и динамичен график, започващ на 16 август. Някои изчисления на общността твърдят, че много големи процентни увеличения за специфични случаи с тежък кеш, особено когато цените за попадения в кеша се променят рязко. Тези цифри трябва да се третират предпазливо, докато не бъдат проверени спрямо активни фактури или текущата таблица за фактуриране на DeepSeek. Посоката на движение обаче е достатъчно ясна: API потребителите вече не могат да оценяват DeepSeek V4 само по възможностите на основния модел и номиналните ставки за токен.
Защо пиковите и извънпиковите цени са от значение
Пиковите/непиковите цени са често срещани на инфраструктурните пазари, но все още е сравнително нов модел за масовите LLM API. Създава стимули, които са познати на екипите за облак и данни: преместете гъвкавата работа извън скъпите прозорци, запазете първокласно време за заявки, обърнати към потребителите, и накарайте пакетните задания да изчакват, когато забавянето не е критично.
За приложения с изкуствен интелект това има няколко практически ефекта. Ботът за поддръжка в реално време обикновено не може да забави отговора на клиента до по-евтин прозорец. Нощен анализ на кодова база, тръбопровод за обогатяване на документи или оценка често могат. Системите на агентите се намират някъде по средата: някои извиквания на инструменти са интерактивни, докато други могат да бъдат поставени на опашка, повторен опит или планирани.
Това променя проблема с маршрутизирането. Шлюзът, който избира между модели въз основа на качество, латентност и цена на токена, сега трябва да вземе предвид времето. Ако DeepSeek V4 Pro е рентабилен извън пиковите часове, но е скъп през пиковите часове, приложението може да предпочете друг модел през деня и да се върне към DeepSeek по-късно. Ако V4 Flash остане привлекателен за бързи задачи, но икономиката на кеша се влоши за дълги споделени префикси, самата подкана архитектура може да се нуждае от преглед.
За екипи, които използват AI API шлюз, най-полезната функция може да не е превключване на друг модел. Може да е политика: незабавно изпращане на интерактивни заявки, поставяне на неспешни задачи в опашка, предупреждаване, когато заявка навлиза в прозорец с по-високи разходи, или прилагане на бюджети на ниво екип, преди да започне пакетно изпълнение.Това е пряко свързано с инфраструктурата в стил Model Gate, тъй като унифицираното таксуване, анализите на използването и контролите за маршрутизиране стават по-ценни, когато цените на доставчиците са динамични, а не статични.
Кой е най-изложен
Най-голямото въздействие вероятно ще падне върху разработчиците с голям обем и фирмите с предвидими натоварвания. Потребителски продукти за чат, платформи за кодиращи агенти, инструменти за проучване, услуги за почистване на данни и вътрешни екипи за автоматизация могат да изпращат голям брой подобни заявки. Тези системи често се възползват от бързото кеширане, но също така са чувствителни към малки промени на токен, умножени в милиони или милиарди токени.
Екипите, използващи DeepSeek до OpenAI-съвместими интерфейси, не трябва да приемат, че съвместимостта ги предпазва от промени в таксуването. Заявката може да изглежда позната, но фактурата все още следва специфичните за модела правила за ценообразуване на DeepSeek. Anthropic-форматният достъп създава същия проблем от другата посока: по-лесната интеграция не премахва необходимостта от разбиране на категориите за фактуриране на доставчика.
Разработчиците, поддържащи калкулатори за ценообразуване, табла за управление на дистрибутори или вътрешни инструменти за връщане на плащания, трябва бързо да актуализират предположенията. Ако таблицата с цените в даден продукт все още третира DeepSeek V4 като единична фиксирана цена за токен, това може да подценява или надценява реалното използване. Това може да изкриви маржовете на клиентите, бюджетите на екипа и решенията за избор на модел.
Екипите за доставки и финанси също трябва да обърнат внимание. Динамичното API ценообразуване прави месечното прогнозиране по-трудно. Работно натоварване, което е било достъпно при тестване, може да се държи различно в производството, ако потребителският трафик се концентрира в пиковите прозорци. Същият риск важи за демонстрациите, оценките и сравнителните показатели на агентите: сравняването на модели, изпълнявано по едно и също време на деня, може да не представя икономиката на непрекъснатото изпълнение на един и същ работен процес.
Какво трябва да направят екипите сега
Непосредствената стъпка е да се отдели техническата миграция от финансовото валидиране. Може да не е необходима промяна на кода, ако приложенията вече извикват DeepSeek V4 Flash или V4 Pro чрез поддържани API формати. Но предположенията за таксуване, сигналите и таблата за управление се нуждаят от преглед.
Инженерните екипи трябва да идентифицират кои DeepSeek натоварвания са интерактивни и кои са отложени. Пакетното обобщаване, обогатяването, прилежащо към вграждане, анализът на хранилището, генерирането на синтетични данни и пакетите за оценка са кандидати за планиране извън пиковите натоварвания, ако изискванията на продукта го позволяват. Агентните рамки трябва да регистрират не само броя на токените и идентификационните номера на модела, но и времето на заявката, поведението на попаденията в кеша и изходящия обем.
Екипите трябва също така да проверят отново стратегията за бързо кеширане. Ако контекстните блокове за многократна употреба все още са по-евтини от некеширания вход, кеширането остава ценно. Ако ценообразуването на кеширане се е повишило значително за конкретен модел и времеви прозорец, може да си струва да съкратите системните подкани, да разделите работните потоци или да сравните друг доставчик за повтарящи се задачи с дълъг контекст.
Това, което остава несигурно, е точното въздействие върху цената на живо за всяко работно натоварване. Официалната документация на DeepSeek потвърждава форматите на модела, контекстния прозорец и категориите за таксуване, видими в страницата с ценообразуването, докато вторичните отчети описват пиковото/неактивното активиране на 16 август и увеличенията на цените. Точната делта на разходите зависи от текущата таблица на живо, времето за изпращане на заявките, поведението на кеша и дължината на изхода.
По-широкият урок е по-малко несигурен. Ценообразуването на LLM започва да функционира. Изборът на модел, времето на заявката, дизайнът на кеша и бюджетната политика вече са свързани. За разработчиците и бизнеса AI API контролът на разходите вече не е просто упражнение с електронни таблици след внедряване; това е част от начина, по който производствените AI системи трябва да бъдат маршрутизирани.