Когато клиент ни попита колко ще струва един AI асистент, първата сметка почти винаги звучи успокоително. Цената на милион токени е публична, очакваният брой заявки е горе-долу известен, умножаваш едното по другото и получаваш число, което спокойно се побира в бюджета. Два месеца по-късно реалната сметка често е няколко пъти по-голяма. Не защото доставчикът е скъп, а защото повечето разходи идват от неща, които изобщо не участват в това умножение.
Пишем този текст от гледната точка на архитектурата. Въпросът, който ни интересува, не е кой модел е по-евтин на токен, а какво в дизайна на една функция решава дали тя ще струва двеста лева месечно или две хиляди при абсолютно същия брой потребители.
Токените, които плащате, не са токените, които виждате
Потребителят пише изречение от двайсет думи. Моделът получава четири хиляди токена. Разликата е контекстът: системната инструкция, описанията на инструментите, примерите, извлечените от базата документи, историята на разговора. И при всяка следваща реплика цялата тази маса тръгва наново.
Затова разговор от десет реплики не струва колкото десет отделни заявки. Струва чувствително повече, защото входът расте на всяка стъпка. Ако не сте сложили таван на дължината на историята, най-скъпите ви потребители ще бъдат точно най-активните — тези, които държат един разговор отворен цял работен ден.
Първото нещо, което включваме, е кеширане на промпта. Anthropic документира, че четенето от кеш се таксува на 0.1× цената на обикновения вход, докато записът в кеш струва 1.25× при петминутния кеш и 2× при едночасовия (официална документация). Сметката е проста: при петминутния кеш излизате на нула още след първото попадение, а всичко след него е спестени пари.
Уловката е в детайла. Кешът работи само когато началото на промпта е байт по байт идентично. Виждали сме внедрявания, в които някой е сложил текуща дата и час или името на потребителя в първия ред на системната инструкция. Технически всичко работи, кешът е включен, а попадения няма нито едно, защото префиксът се различава при всяка заявка. Затова държим всичко променливо максимално надолу в промпта и проверяваме реалния процент попадения в логовете, вместо да приемаме, че щом сме подали параметъра, ефектът е налице.
Повторните опити, които никой не брои
Второто място, където изтичат пари, е разликата между „заявки“ и „извиквания на модела“. Един неуспешен JSON, едно прекъсване по таймаут, една валидация, която не е минала — всяко от тези неща поражда още едно платено извикване. Потребителят вижда един отговор. Вие плащате три.
Правилото, което следваме, е скучно, но върши работа: логваме опити, не заявки. В момента, в който метриката се смени, обикновено излиза, че някъде между пет и петнайсет процента от разхода отива за повторения, а голяма част от тях идват от един-единствен зле описан инструмент, който моделът упорито извиква с грешни аргументи. Това е поправка за половин час, но само ако числото ви е пред очите.
При агентните функции същият проблем има по-остра форма. Цикъл, който няма твърд таван на броя стъпки, е финансов риск, а не архитектурно решение. Слагаме лимит на итерациите и лимит на общия разход за една задача, и предпочитаме функцията да се откаже честно и да предаде случая на човек, отколкото да опитва още четиринайсет пъти.
Заявките, които изобщо не е трябвало да стигат до модела
Най-евтиното извикване е онова, което не се е случило. Преди да оптимизираме промпти, гледаме колко от входящия поток въобще има нужда от езиков модел.
В една вътрешна система за обработка на заявки, по която работихме, близо една трета от съобщенията бяха повторения на вече отговорени въпроси или попадаха в няколко тесни категории, които се разпознават с обикновени правила. Кеш на ниво отговор и детерминистичен рутер изчистиха голяма част от обема, преди изобщо да се стигне до модела. Останалото разделихме на две: лек модел за класификация и извличане на полета, по-силен модел само там, където отговорът отива директно пред клиент.
За всичко, което не изисква отговор в реално време — нощни обобщения, масова класификация, обогатяване на записи — използваме пакетна обработка. OpenAI документира 50% отстъпка за Batch API срещу ангажимент за обработка в рамките на 24 часа (документация на Batch API). Ако бизнес процесът и без това работи на дневен цикъл, това е половин сметка срещу нула промяна в потребителското изживяване.
Какво слагаме, преди функцията да излезе в продукция
Контролът на разходите е инфраструктура, не намерение. Минималният набор, без който не пускаме AI функция навън, изглежда така:
- Цена на всяко извикване, записана заедно с идентификатора на заявката, потребителя и версията на промпта. Без това не можете да отговорите на въпроса „кой харчи“.
- Твърд месечен таван на ниво клиент или отдел, който спира, а не само алармира.
- Аларма по деветдесет и пети персентил на разхода за една заявка, не по средна стойност. Средното число крие точно случаите, които ви струват пари.
- Превключвател, с който функцията се изключва за минути без пускане на нова версия.
Това не е много работа — около два дни, ако се направи в началото, и неприятна седмица, ако се прави след първата изненадваща сметка.
Кога икономията е грешната цел
Има и обратна страна, която срещаме достатъчно често, за да си струва да се каже. Цената на токените е видимата част от разхода. Невидимата е човешкото време след това.
Илюстративен пример, за да е ясна сметката: ако по-евтин модел греши в 8% от случаите вместо в 3%, при десет хиляди документа месечно това са 500 допълнителни случая за ръчна проверка. При петнайсет минути на случай излизат около 125 човекочаса. Спестените пари по API са почти винаги по-малко от тази сума, а рискът от пропусната грешка не е включен никъде.
Затова не гледаме цена на токен, а цена на успешно завършена операция, включително човешкия преглед. В повечето проекти, които сме правили, оптимизацията с най-добра възвращаемост не беше смяна на модела, а стесняване на задачата: по-малко неща, които моделът трябва да реши сам, по-ясни граници и по-добри данни на входа. Това сваля и цената, и процента грешки едновременно, докато смяната на модела обикновено търгува едното срещу другото.
Ако тръгвате към първото си сериозно внедряване, най-полезното, което можете да направите през първата седмица, е да си осигурите видимост: разход по заявка, процент повторни опити, процент попадения в кеша. Тези три числа обясняват почти всяка изненадваща сметка, която сме виждали.