Ценообразуването на API на DeepSeek в пиковите часове прави маршрутизирането на модела проблем с планирането

Ценообразуването на V4 API на DeepSeek се премести от прост въпрос за избор на модел към въпрос за време.

Официалната страница за ценообразуване на API на компанията вече изброява DeepSeek V4 Flash и DeepSeek V4 Pro с големи контекстни прозорци от 1 милион токена, базови URL адреси във формат OpenAI и формат Anthropic и отделни категории за таксуване за въвеждане с попадение в кеша, въвеждане и извеждане с пропуск в кеша токени. Доклади, събрани от Techmeme на 13 август, казват, че DeepSeek повишава цените на моделите V4 и въвежда динамично таксуване в пиков/ненатоварен период, като новото ценообразуване влиза в сила в 16:00 UTC на 16 август 2026 г.

Това прави промяната повече от рутинна актуализация на ценовата таблица. За екипи, работещи с агенти с голямо извличане, асистенти за кодиране с дълъг контекст, задания за партиден анализ или ориентирани към клиента AI продукти, цената на заявка за DeepSeek може вече да зависи не само от избрания модел, но и кога е изпратена заявката и каква част от подканата може да бъде обслужена от кеша.

Какво се промени в таксуването на DeepSeek V4

Текущата документация на API на DeepSeek представя V4 Flash и V4 Pro като налични чрез API формати в стил OpenAI и Anthropic. Това има значение, тъй като много разработчици вече насочват 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.Достъпът в антропен формат създава същия проблем от другата посока: по-лесната интеграция не премахва необходимостта от разбиране на категориите за фактуриране на доставчика.

Разработчиците, поддържащи калкулатори за ценообразуване, табла за управление на дистрибутори или вътрешни инструменти за връщане на плащания, трябва бързо да актуализират предположенията. Ако ценовата таблица в даден продукт все още третира DeepSeek V4 като единична плоска цена за токен, тя може да подценява или надценява реалното използване. Това може да изкриви маржовете на клиентите, бюджетите на екипа и решенията за избор на модел.

Екипите за доставки и финанси също трябва да обърнат внимание. Динамичното ценообразуване на API прави месечното прогнозиране по-трудно. Работно натоварване, което е било достъпно при тестване, може да се държи различно в производството, ако потребителският трафик се концентрира в пиковите прозорци. Същият риск важи за демонстрациите, оценките и сравнителните показатели на агентите: сравнението на модели, изпълнявано по едно и също време на деня, може да не представя икономиката на непрекъснатото изпълнение на един и същ работен процес.

Какво трябва да направят екипите сега

Непосредствената стъпка е да се отдели техническата миграция от финансовото валидиране. Може да не е необходима промяна на кода, ако приложенията вече извикват DeepSeek V4 Flash или V4 Pro чрез поддържани API формати. Но предположенията за таксуване, предупрежденията и таблата за управление се нуждаят от преглед.

Инженерните екипи трябва да идентифицират кои работни натоварвания на DeepSeek са интерактивни и кои могат да бъдат отложени. Пакетното обобщаване, обогатяването, прилежащо към вграждане, анализът на хранилището, генерирането на синтетични данни и пакетите за оценка са кандидати за планиране извън пиковите натоварвания, ако изискванията на продукта го позволяват. Агентните рамки трябва да регистрират не само броя на токените и идентификационните номера на модела, но и времето за заявка, поведението на попадение в кеша и изходния обем.

Екипите трябва също така да проверят отново стратегията за бързо кеширане. Ако контекстните блокове за многократна употреба все още са по-евтини от некеширания вход, кеширането остава ценно. Ако ценообразуването на кеширане се е повишило значително за конкретен модел и времеви прозорец, може да си струва да съкратите системните подкани, да разделите работните потоци или да сравните друг доставчик за повтарящи се задачи с дълъг контекст.

Това, което остава несигурно, е точното въздействие върху цената на живо за всяко работно натоварване. Официалната документация на DeepSeek потвърждава форматите на модела, контекстния прозорец и категориите за таксуване, видими в страницата с цените, докато вторичните доклади описват пиковото/неактивното активиране на 16 август и увеличенията на цените. Точната делта на разходите зависи от текущата маса на живо, времето за изпращане на заявките, поведението на кеша и дължината на изхода.

По-широкият урок е по-малко несигурен. Ценообразуването на LLM започва да функционира. Изборът на модел, времето на заявката, дизайнът на кеша и бюджетната политика вече са свързани. За разработчиците и бизнеса контролът на разходите за AI API вече не е просто упражнение с електронни таблици след внедряване; това е част от начина, по който производствените AI системи трябва да бъдат маршрутизирани.