Промисловий конвеєр повертає великі пакети паперу до тієї самої машини; на окремій короткій стрічці лежить лише один невеликий готовий пакет.

Як я за два тижні спалив $1 140 кредитів Amazon

Автор: Валерій Пожидаєв

Промисловий конвеєр повертає великі пакети паперу до тієї самої машини; на окремій короткій стрічці лежить лише один невеликий готовий пакет.
Редакційна ілюстрація до Reality Show / 01.

За два тижні я спалив $1 140 кредитів Amazon. На AWS у мене працював Гермес-продавець, якого я підключив до Claude Sonnet 4.6 від Anthropic через Amazon Bedrock. Це сервіс, через який агент отримував доступ до моделі. Обсяг обробленого тексту впливав на витрати.

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

Саме цю частину я не перевірив до підключення дорогого ресурсу. Розслідування показало, що проблема складалася з кількох речей, які зовні не були очевидними.

Що агент надсилав разом із повідомленням

Під час розбору 15 серпня в одній із робочих сесій знайшли 1 574 повідомлення. Її контекст оцінювали приблизно в 410 тисяч токенів, одиниць тексту, які обробляє модель.

У вікні Telegram можна бачити коротке нове повідомлення. Модель при цьому отримує ще й накопичену історію: попередні звернення, відповіді та матеріали роботи. Тому довжина останнього запитання мало говорить про обсяг наступного виклику. Сесія продовжує рости, і агент знову передає цю історію на обробку.

Коли виклики закінчувалися помилкою, Hermes робив повторні спроби з великим контекстом. У роботі вже був механізм, який міг багаторазово навантажувати модель. Для нього потрібно було перевірити межі: коли починати нову сесію, скільки спроб дозволяти та коли зупинятися.

Після початку нової сесії контекст скоротився приблизно в 75 разів. Проте помилка не зникла. Перевірка показала, що один маршрут доступу до Sonnet вичерпав денну квоту, а інший маршрут тієї самої моделі працював. Велика історія була реальною проблемою, але одним очищенням історії весь інцидент не пояснювався.

Чому зміна налаштувань не завжди змінювала роботу

Далі з’ясувалося, що загальні налаштування Hermes і налаштування живого Telegram-бота зберігалися окремо. Модель могли змінити в одному місці, а продавець продовжував читати інше.

Інструмент показував, що модель змінено. Однак цього було недостатньо, щоб знати, через яку модель проходить наступний запит. Потрібно було перевірити саме роботу бота після зміни. Резервний шлях на випадок відмови теж спочатку налаштували не там, звідки його мав брати продавець.

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

Що показали гроші

Фінансова перевірка теж не відразу дала відповідь. Перший файл із витратами охоплював лютий–липень і показував нулі. Шукали серпневі витрати, а дивилися на інший період.

Інший зріз показував невеликі суми після застосування кредитів. За ними було важко побачити, скільки ресурсу вже спожито. Кредити погашали нарахування, але самі виклики від цього не ставали безкоштовними: зменшувався доступний залишок.

Коли споживання відокремили від покриття кредитами й розклали за операціями, картина стала конкретною. У зрізі від 22 серпня на потокові виклики Sonnet 4.6 припало $987,45 із $1 017,40 споживання AWS. Близько 97%.

Це показало основну статтю витрат. Точного розподілу всієї суми між окремими агентами, сесіями та повторними спробами у знайдених даних немає. Тому приписувати кожен долар продавцеві або кожній помилці було б неточно.

У чому була моя помилка

Я підключив дорогий ресурс до системи, у якій ще не перевірив межі його використання. Розмір сесії, повторні спроби, фактична модель і обмеження витрат мали бути зрозумілі до такого підключення. Здатності агента відповідати й виконувати завдання для цього недостатньо.

Навіть рішення припинити використання Bedrock спочатку залишалося лише правилом. Можливість нових викликів зберігалася. 28 серпня їх заблокували на рівні прав Amazon і перевірили окремим запитом: доступ справді був закритий. Дані й робоче середовище при цьому зберегли.

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

0 0 голоси
Рейтинг статьи
Підписатися
Сповістити про
guest
0 комментариев
Найстаріші
Найновіше Найбільше голосів
0
Буду рада вашим думкам, прокоментуйте.x