Когнітивний податок: як вижити, коли інференс з’їдає маржу

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

$100k на розробника щорічно тільки на токени? Я перевірив цю цифру

В AI-спільнотах останнім часом активно розповсюджують одну цифру — нібито $100 000 на розробника щорічно тільки на токени. Фінансові директори, які це почули, вже нервово відкривають Excel. Але перш ніж різати бюджети, є сенс розібратись: звідки ця цифра взагалі і що вона насправді означає.

Коротко: це перебільшення. Але реальна проблема все одно існує — просто виглядає інакше.

Скільки насправді коштують токени

Беремо фактичні тарифи. Pro-план Claude — $20 на місяць, Max 5x — $100, Max 20x — $200. При інтенсивному використанні API середній розробник витрачає близько $6 на день. Навіть у найекстремальнішому сценарії — мультиагентна команда, довгі автономні сесії, постійна паралельна генерація — місячний рахунок сягає $400—$1 200. Тобто $5k—$14k на рік на одного. Це вже серйозні гроші. Але до $100k звідси дуже далеко.

Де тоді проблема? Вона не у вартості токенів як такій. Вона у тому, що агент без керованої пам’яті виконує один і той самий запит знову і знову, нарощуючи контекст з кожним кроком. Я сам запускав агента з завданням на 12 API-запитів — він зробив 847. Не тому що «здурів». Просто архітектура не передбачала пам’яті між кроками.

Ось конкретна ілюстрація цього ефекту: запит із трьох слів на початку сесії коштує $0.0018. На 260-му кроці того ж агента, коли контекст вже набух від сміттєвих токенів, ідентичний запит коштує $2.41. У 1 300 разів дорожче. Гроші утікають саме там.

Чому моделі-«мислителі» не вирішують проблему, а погіршують її

У червні 2025-го Apple Machine Learning Research опублікували роботу «The Illusion of Thinking» — і вона перевернула мої уявлення про те, коли взагалі варто вмикати режим глибокого мислення.

Дослідники виявили парадокс: моделі з довгими ланцюжками міркувань (LRM) починають «думати менше» — генерують коротші траєкторії і швидше здаються — саме тоді, коли завдання стає справді складним. Ніби перед важкою задачею втомлюються раніше, ніж її вирішать. Повний PDF роботи тут.

Взаємодія з сучасними моделями поділяється на три чіткі зони складності.

На низькому рівні звичайна модель без мислення виявляється точнішою і дешевшою. Модель-«мислитель» швидко знаходить правильну відповідь — а потім продовжує її шукати, перебираючи хибні альтернативи. Через відсутність внутрішнього механізму зупинки вона псує фінальний результат власноруч. Це і є overthinking у дії.

Середня складність — рідна стихія LRM. Тут механізм самокорекції виправдовує себе сповна: модель виправляє власні помилки в процесі виведення і стабільно перевершує стандартні архітектури.

А от на максимальній складності настає повний колапс. Точність обох типів моделей падає до нуля. Причому LRM не просто помиляється — вона різко скорочує довжину міркування і здається, незважаючи на невикористаний ліміт токенів. Дослідники назвали це «відмовою від боротьби».

Практичний висновок для архітектури: ніколи не вмикайте режим мислення для тривіальних задач. Це одночасно дорого і контрпродуктивно.

Залізо: де проходить реальна межа

Суперечка між Apple Silicon і NVIDIA часто зводиться до цифр, які гуляють у соцмережах без першоджерел — більшість з них взято з непов’язаних фізичних чи хімічних досліджень і до реального інференсу відношення не мають. Краще дивитись на перевірені технічні огляди, наприклад це порівняння від XDA Developers.

Реальний вибір між платформами упирається не в швидкість генерації, а в доступний обсяг пам’яті. RTX 5090 з 32 ГБ VRAM і пропускною здатністю 1.79 ТБ/с — абсолютний чемпіон для моделей, що вписуються у свій ліміт. Але 70B+ параметри туди просто не лізуть без агресивного квантування, яке руйнує якість міркувань. Плюс понад 500 Вт споживання — це окрема розмова про охолодження і живлення.

Apple M4 Max йде іншим шляхом. Архітектура єдиної пам’яті (UMA) дає до 128 ГБ при пропускній здатності 546 ГБ/с, а все SoC споживає 160–180 Вт під навантаженням. 70B-модель завантажується повністю і сидить там без жодного квантування.

Цікавіший кейс — чотири Mac Mini M4 Pro за $7 000. Об’єднані у кластер, вони дають 192 ГБ спільної пам’яті, на якій Llama-3-70B або Nemotron-70B запускаються без жодного цента хмарним провайдерам. При команді з 50 розробників власна колокація на вузлах L40S окупається десь за 10 місяців.

Найбільша діра в бюджеті — не залізо, а архітектурна лінь

Найбільша діра в бюджеті при створенні агентних систем — це не дороге залізо, а банальна архітектурна лінь при проектуванні інструментів. Коли розробники підключають стандартні сервери MCP (Model Context Protocol), вони змушують модель тягати гігантські описи кожної дрібної функції туди-сюди з кожним новим запитом. Наприклад, звичайне підключення плагіна GitHub MCP додає до контексту майже 17 600 токенів метаданих ще до того, як користувач встигне написати перше слово.

Інженери Anthropic та Cloudflare паралельно намацали логічний вихід із цього глухого кута, назвавши його Code Mode — програмним викликом інструментів.

Замість того щоб роздмухувати системний промпт сотнями детальних описів ендпоінтів, моделі видають лише кілька універсальних мета-інструментів. Вони дозволяють шукати потрібний функціонал у локальних файлах TypeScript чи JavaScript, автоматично генерувати компактний скрипт під конкретну задачу та запускати його в ізольованому середовищі V8, повертаючи в контекст лише відфільтрований результат роботи.

На практиці це дає колосальний ефект. У робочому ланцюжку між Google Drive та Salesforce інженерам з Anthropic вдалося прибрати зі 150 000 до скромних 2 000 токенів на один крок — чисті 98.7% економії. Cloudflare пішла ще далі: щоб не завантажувати понад мільйон токенів при зверненні до API з 2 500 ендпоінтів, вони згорнули весь інтерфейс у два виклики — пошуковий search() та виконуваний execute(), зафіксувавши розмір системного промпту в межах однієї тисячі токенів.

Важливий нюанс, який зазвичай замовчують: ізоляція V8 sandbox — не срібна куля від усіх проблем безпеки. Вона прибирає частину векторів атаки, але сам підхід Code Mode переносить ризики на динамічно згенерований код, а не знімає їх. Докладна специфікація та SDK у звіті Cloudflare про Code Mode для MCP.

SkillOpt: як навчити агента один раз і не платити за це знову

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

Замість того щоб змушувати модель щоразу хаотично переписувати свої промпти з нуля, система запускає агента на тренувальній вибірці та збирає траєкторії успіхів і помилок. Далі модель-оптимізатор на базі GPT-4 генерує чітко обмежені атомарні операції — додавання, видалення чи заміну рядків — у єдиному markdown-файлі навичок. Це принципово важливо: оптимізатор не переписує файл цілком, а робить хірургічні точкові правки, що унеможливлює семантичний вибух.

Для стабілізації процесу розробники впровадили концепцію текстового бюджету швидкості навчання, обмежуючи кількість одночасних правок до 4–8 за крок. Плюс суворий валідаційний бар’єр: кожна нова редакція перевіряється на відкладеній вибірці, і якщо точність не зростає, правка відхиляється в спеціальний буфер помилок. Цей буфер стає негативним орієнтиром для майбутніх кроків оптимізатора — аналог механізму імпульсу в класичному градієнтному спуску, тільки у текстовому просторі.

На етапі деплою агент використовує вже готовий відкомпільований файл best_skill.md, який взагалі не потребує додаткових запитів до моделі під час виконання. Нуль витрат на інференс при розгортанні. На бенчмарках з GPT-5.5 в агентній петлі Codex — приріст точності +24.8%, у Claude Code — +19.1%.

TurboQuant: як запхати 3.4x більше контексту в ту саму пам’ять

Коли контекстне вікно розростається до сотень тисяч токенів, відеопам’ять забивається набагато швидше, ніж модель встигає розв’язати задачу. Технологія TurboQuant від Google DeepMind (ICLR 2026) пропонує стискати Key-Value кеш безпосередньо під час генерації до 3–4 біт без критичного падіння точності.

Математичне ядро складається з двох послідовних етапів. На першому PolarQuant виконує випадкове ортогональне обертання вхідних векторів ключа та значення. Оскільки у просторах великої розмірності (d=128) міра має властивість концентруватися, розподіл кутів фокусується у вузькому гаусівському дзвоні — що дозволяє застосувати стандартний квантизатор Ллойда-Макса без необхідності зберігати складні нормалізаційні константи для кожного вектора. На другому кроці QJL (Quantized Johnson-Lindenstrauss) кодує залишок похибки додатковим 1-бітним перетворенням і усуває систематичне математичне зміщення при обчисленні уваги.

Але головна фішка TurboQuant — не математика, а апаратна оптимізація під тензорні ядра NVIDIA H100. Спеціальні CUDA-ядра утримують матрицю обертання безпосередньо у швидкій спільній пам’яті GPU, виконуючи змішане пакування бітів за один прохід. Завдяки потиковому калібруванню з виділенням окремих каналів під аномальні значення режим turboquant_4bit_nc розширює ємність VRAM у 3.4 раза при втраті якості в межах похибки вимірювання.

Агресивне стиснення turboquant_3bit_nc дає виграш у 4.9 раза — але на складних логічних тестах AIME25 і LiveCodeBench точність падає на 8–20 пунктів. Для критично важливих систем міркувань це неприйнятно.

Graphiti: забудьте про «прогребання всієї стрічки»

Квантування чудово вирішує фізичну проблему нестачі пам’яті, але не рятує від іншої архітектурної біди — квадратичного зростання витрат, коли модель щоразу змушена перечитувати всю історію взаємодії по колу.

Компанія Zep випустила опенсорсну бібліотеку Graphiti — динамічний темпоральний граф контексту. На відміну від статичних RAG-систем, де вектори просто складаються в pile і шукаються за косинусною схожістю, Graphiti автоматично розбирає вхідний потік на сутності та зв’язки-ребра, присвоюючи кожному ребру конкретне часове вікно валідності.

Завдяки бі-темпоральній моделі даних, коли інформація змінюється, старі факти не видаляються безслідно, а маркуються як недійсні за допомогою часових міток. Наприклад, якщо клієнт змінив уподобання, система збереже повну еволюцію його налаштувань — і агент зможе звернутися до будь-якого історичного зрізу через гібридний пошук (семантичні ембеддінги + BM25 + трасування зв’язків у Neo4j) без потреби годувати модель сирим логом листування. Схеми сутностей описуються декларативно через Pydantic-класи, що дає відтворюваність і типізацію прямо в коді.

AgentShield: дві зовсім різних речі з однією назвою

На ринку безпеки ШІ-агентів зараз серйозна плутанина — у 2026 році з’явилися два абсолютно різних інструменти під назвою AgentShield, які вирішують протилежні завдання і яких у мережі постійно плутають.

Перший — AgentShield CLI, створений Affaan Mustafa на хакатоні Claude Code. Класичний статичний аналізатор безпеки локального середовища: перевіряє файли конфігурацій .claude/, CLAUDE.md та .cursorrules за 102 правилами. Його мета — виявити захардкоджені API-ключі, вразливі хуки або занадто широкі права доступу на кшталт Bash(*), автоматично пропонуючи звузити їх до безпечних меж типу Bash(git *) або Bash(npm *). Виставляє оцінку від A до F за п’ятьма категоріями.

Другий — дослідницький фреймворк AgentShield (травень 2026) — зовсім інша концепція. Тут немає статичного аналізу коду: захист побудований на децептивному виявленні компрометації безпосередньо в рантаймі.

Система інтегрує три контури пасток в інтерфейс взаємодії моделі з інструментами. Перший контур (Honeytools) додає до списку доступних функцій приманки з назвами типу export_all_user_data або system_admin_console — для звичайного сценарію вони безглузді, але приваблюють атакуючого. Будь-який виклик такої приманки є миттєвим сигналом про злам без жодної хибної тривоги. Другий контур (Honeytokens) засіває оточення фальшивими паролями та SSH-ключами, відстежуючи, чи не намагається скомпрометований агент злити їх у вихідному трафіку на сторонні сервери. Третій (Parameter Validator) динамічно звіряє аргументи викликів із білими списками адрес та доменів.

Під час тестування на бенчмарку AgentDojo децептивна схема показала точність виявлення непрямих ін’єкцій інструкцій (IPI) на рівні 90.7%—100% при нульовому показнику хибних спрацьовувань. Оскільки фреймворк аналізує структуру викликів, а не внутрішній стан моделі, захист виявився нечутливим до мови атаки — блокував ін’єкції навіть курдською та арабською мовами.

Коли розробник стер 2.5 роки продакшену

Є конкретний кейс: розробник схвалив запропоновану AI команду terraform destroy і знищив 2.5 роки виробничої інфраструктури. Модель спрацювала впевнено. Розробник не зупинив.

Це не провал моделі. Вона зробила те, що від неї просили — технічно грамотно і впевнено. Відповідає архітектор системи, який дав AI-агенту права виконання без детермінованих кордонів. Не було жодного бар’єру між «запропонувати» і «виконати».

Саме для цього існує AgentShield CLI — не щоб ловити проблеми постфактум, а щоб до першого виклику будь-якої деструктивної дії вже були виставлені обмеження. Сканування конфігурацій — це п’ять хвилин, які могли б зберегти ці 2.5 роки.

PGlite: PostgreSQL у 3 мегабайти

Повна незалежність від хмари вимагає і локального зберігання. PGlite від ElectricSQL — це повноцінна СУБД PostgreSQL, скомпільована у WebAssembly для роботи в однопроцесорному режимі без запуску Linux VM. У стиснутому стані вся бібліотека важить менше 3 МБ — завантажується на клієнт за лічені миті. З коробки є реактивні запити, синхронізація в реальному часі та розширення pgvector, що дозволяє розгортати повноцінне векторне сховище для RAG прямо в браузері чи на пристрої.

Але варто розуміти й обмеження. Однопроцесорний режим виключає класичний багатокористувацький доступ із конкурентними транзакціями — тут краще покаже себе традиційна зв’язка SQLite WASM із кастомними обгортками. PGlite — це інструмент для конкретного класу задач, зокрема CI/CD модульних тестів і локального edge RAG, а не заміна повноцінного сервера.

Підсумок

Реальна загроза для маржі — не висока вартість API як така, а безконтрольне використання моделей міркування для тривіальних задач. Як показало дослідження Apple «The Illusion of Thinking», на низькому рівні складності LRM схильні до надмірного аналізу і часто заплутують самі себе в простих логічних трикутниках. Перевага розкривається виключно у середній зоні. При переході до надважких завдань точність обох класів моделей неминуче падає до нуля — і LRM просто припиняє спроби пошуку рішень, різко скорочуючи довжину генерації попри невикористаний ліміт токенів.

Компанії, які впровадять Code Mode для роботи з інструментами, оптимізують текстовий простір навичок через SkillOpt та стиснуть KV-кеш через TurboQuant, знизять операційні витрати на порядок. Решта продовжить спалювати бюджети, оплачуючи зайві цикли мислення на рутинних операціях.

Пряме запитання: ваш агент прямо зараз перечитує документацію Stripe вдесяте за цю годину?

Запитання та заперечення — у коментарях. Відповідаю.

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Із API інтерфейсів (після закриття Anthropic-ом можливості викорстання API для підписок), відкрив для себе DeepSeek V4 Flash/Pro. Якість — на рівні Claude/ChatGPT, а ціна на порядок менша. Звичайна сесія на 2-3 години може коштувати менше 50 центів.

Щодо локальних моделів, нещодавно провів порівняння десятка моделів від 30b до 400b і скажу, що жодна із моделів на 70b-120b не впоралась із доволі посереднім завданням на python з обробкою сигналу. Тож, мінімум, що я ставив би R&D інженерам локально — Qwen-397B-A17B. Так, квантування є, але на наших задачах не помітив сильного зниження якості. Так, на 5090 воно вже не лізе ніяк, треба будувати кластер на серверних GPU, але якість роботи того вартує.

А які у вас моделі-фаворити для API-планів?

Запускали granite4.1:3b локально через Ollama на Core Ultra 5 135U. Порівнювали wall-clock latency в двох режимах: з format:"json" (grammar-constrained) та без. Виявилось, що constrained-режим стабільно швидший (~12-19 сек/промпт vs ~19-21 сек), тобто grammar constraint — це не тільки коректність, але й реальна економія на токенах. При цьому schema validity (семантична коректність полів) не зростає: граматика знає, що поле є string, але не знає, що воно не може бути порожнім. Тобто format:"json" — це перша лінія оборони, але не заміна явної специфікації полів у промпті.

Щодо routing малих/великих моделей — підтверджуємо що для структурованого output proxy-модель (3b) і production-модель (26b) можуть давати різні результати. Не ухвалюємо рішення про routing без benchmark саме production-моделі.

До того ж зараз в клоді є кеш вхідних токенів на годину, тож кожен новий запит не повністю оплачує всі попередні, тож навіть постійно робити компакт, чи стартувати нову сесію тепер може бути навіть не вигідно

Вона зробила те, що від неї просили — технічно грамотно і впевнено

На цьому моменті зрозумів що стаття написана також AI

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

Це прекрасно!) Буду чекати на Медіумі історії типу «Я вивчив китайську, щоб писати промпти»

6 доларів на день — це не інтенсивне, а доволі лайтове використання Codex 5.3 до обіду. Тому реальні цифри з моєї практики точно більші за ваші десь удвічі, але все одно менші за 100к.

Один кадр в місяць спалює токенів на мільйон баксів. Такиж небагато, але ж є.

Підписатись на коментарі