
OpenAI Batch или Claude Batches: ист попуст, двојно различен лимит

За евалуации, класификација и масовна обработка, двата API нудат ист процентуален попуст, но не и ист капацитет по пакет. Водичот за OpenAI Batch API наведува попуст од 50%, обработка во рок до 24 часа и најмногу 50.000 барања во пакет со влезна датотека до 200 MB. Услугата користи посебен капацитет за ограничувањата на брзината, што е важно кога синхроните барања веќе го оптоваруваат тимскиот лимит.
Водичот за Anthropic Message Batches наведува ист попуст од 50%, но најмногу 100.000 барања или 256 MB во пакет; обработката може да трае до 24 часа, а повеќето пакети завршуваат за помалку од еден час. За голем број кратки барања, Claude затоа може да бара помалку пакети. Тоа не значи автоматски пониска сметка: цената на избраниот модел, големината на влезот и начинот на кој ќе се обработат прекините остануваат дел од изборот.
Колку пакети бараат 40.000, 80.000 и 150.000 барања?
Оваа пресметка е условна: секое барање е доволно мало за ограничувањето во мегабајти да не се достигне прво. Тогаш бројот на пакети произлегува директно од максималниот број барања што секој API го прима во еден пакет:
- За 40.000 барања се потребни еден OpenAI пакет и еден Anthropic пакет.
- За 80.000 барања се потребни два OpenAI пакета, на пример со 50.000 и 30.000 барања, или еден Anthropic пакет.
- За 150.000 барања се потребни три OpenAI пакета со по 50.000 барања или два Anthropic пакета со 100.000 и 50.000 барања.
Тоа се минимални броеви според бројот на барања, а не гаранција дека сите пакети ќе влезат во обработка истовремено. Кај OpenAI големината се однесува на влезната датотека, додека кај Anthropic на пакетот; ова се различно опишани ограничувања и не треба да се сведат само на споредба на мегабајти. Долги промптови или обемна содржина можат да бараат повеќе пакети и кога бројот на барања е под таванот.
Постои и капацитет над нивото на поединечниот пакет. OpenAI ограничува колку промпт-токени за одреден модел може да чекаат во Batch, а Anthropic применува ограничувања на барањата што чекаат обработка. Затоа правилно поделениот товар може да бара постепено поднесување. За планирање одделете три прашања: колку пакети се потребни според бројот на барања, дали нивната содржина собира во дозволената големина и колкав товар може да чека кај провајдерот.
Попустот се применува на различна основна цена
Истиот процент на намалување не ја изедначува цената на два различни модели. За споредлив товар прво проценете ги влезните и излезните токени, применете ја цената на конкретниот модел, па пресметајте го попустот за пакетна обработка. Ако една варијанта создава подолги одговори или користи поинаков модел, процентот сам по себе кажува малку за конечната сметка. Во таа пресметка влегува и вкупниот трошок за API обработка.
Рокот за завршување исто така не е исто што и ветување за одредена брзина. Anthropic наведува дека повеќето пакети завршуваат брзо, но тоа е типично однесување, не гаранција за конкретен товар. Кај двата API недовршените барања можат да истечат по дозволениот прозорец; завршените резултати треба да се преземат, а преостанатите барања да се разгледаат одделно. За ноќна евалуација е поважен исходот на секое барање отколку само статусот на пакетот.
Резултатите имаат различен рок за преземање
Резултатите зачувајте ги во сопствено складиште кога ќе станат достапни. Споредбата на IntuitionLabs ја издвојува разликата: OpenAI автоматски ја брише излезната датотека 30 дена по завршувањето на пакетот, додека резултатите од Anthropic се достапни 29 дена од неговото создавање. Почетниот момент на тие рокови е различен, па задачата за преземање треба да се врзе за состојбата на секој пакет, а не за заеднички календарски рок.
Не потпирајте се на редоследот на редовите. OpenAI ги става успешните одговори во излезна датотека, а грешките во посебна датотека; Anthropic враќа исход за секое барање, меѓу кои succeeded, errored, canceled и expired. Во двата случаи custom_id го поврзува резултатот со изворното барање. При увозот зачувајте ги идентификаторот на пакетот, custom_id и исходот: така делумно завршен пакет не се меша со целосно неуспешна задача.
Локалната евиденција го решава ризикот од повторно поднесување
Custom_id помага да се препознае резултат, но сам по себе не е клуч што спречува повторно создавање пакет. Ако повикот за поднесување успее кај провајдерот, а потврдата се изгуби поради мрежен прекин, автоматското повторување може да создаде уште еден пакет со исти барања. Завршените барања во двата пакета тогаш може повторно да се обработат и да создадат дополнителен трошок. Ова е ризик од неутврден исход на поднесувањето, а не тврдење дека секој прекин предизвикува двојна наплата.
Неутрален образец за двата API почнува со стабилен клуч за секое логичко барање. Клучот може да се изведе од идентификаторот на изворниот запис, верзијата на неговата содржина, моделот и верзијата на промптот. Зачувајте манифест со тие клучеви, провајдерот и состојбата на поднесувањето пред мрежниот повик. Во локалната база спречете две истовремени операции да го преземат истиот манифест; кога ќе пристигне потврда, запишете го идентификаторот на пакетот и означете го како поднесен.
Ако потврдата не пристигне, состојбата е „непозната“, не „неуспешна“. Прегледајте ги пакетите кај провајдерот и достапните времиња и метаподатоци пред ново поднесување. Ако од нив не може сигурно да се утврди дали првиот повик создал пакет, задржете го случајот за разрешување наместо слепо да го повторите целиот товар. Без клуч за идемпотентност на самото создавање пакет, локалната евиденција може да спречи вообичаени дупликати, но не може сама да докаже дека повик со изгубена потврда се извршил точно еднаш.
По преземањето, запишете успешен резултат само еднаш за стабилниот клуч, а неуспешните исходи чувајте ги одделно. Нов пакет составете од барањата за кои нема успешен одговор и за кои причината дозволува повторување; погрешни параметри најпрво треба да се поправат. Така разликата во капацитетот останува јасна при изборот, а повторното преземање или обработка на резултатите не ја менува тивко состојбата на задачата.
Прочитајте и:
Поврзани статии


Claude API враќа 429: retry не помага ако го погодите погрешниот лимит

Claude Code или Codex CLI: ист резултат не значи ист трошок

Anthropic ја намали AI-дестилацијата до 99% — доказот е внатрешен

Prompt caching во OpenAI или Claude: динамичната содржина ја јаде заштедата

OpenAI или Claude cache: динамичните алатки можат да ја зголемат латентноста
Претплатете се на нашиот билтен
Добивајте ги најновите вести за Web3, AI и крипто директно во вашето сандаче.