Ваш GPU наполовину порожній: як Kog Inference Engine розкриває приховану ціну кожного AI-агента

Рахунок, який ніхто не закладав у бюджет

Довгий час логіка була проста: якщо AI-агенти працюють повільно або дорого — купуй більше GPU. Залізо вирішує все, питання лише в кількості. Потім у травні 2026 року паризький стартап Kog опублікував технічне демо, яке потрапило на першу сторінку Hacker News — і тихо зруйнувало цю логіку. Їхній Kog Inference Engine (KIE) показав до 30x швидший LLM-інференс на тих самих стандартних дата-центрових GPU, які вже є у підприємств, — без жодної зміни в залізі.

Але справжня цінність цього — не в бенчмарках. Вона в тому, що це говорить про гроші, які ви витрачаєте прямо зараз. Розрив між тим, на що здатні ваші GPU, і тим, що ваш inference-стек із них реально видавлює, — це не похибка округлення. Це структурна втрата, яка множиться з кожним новим AI-агентом. Варто розібратися, наскільки глибокий цей розрив і які важелі його закривають, — до того як ви приймете наступне інфраструктурне рішення.

Чому AI-інференс став найшвидше зростаючою статтею витрат

Для більшості компаній, що вийшли за межі пілотів, AI-інференс — процес, під час якого навчена модель отримує запит і генерує відповідь — непомітно перетворився на головну й найменш передбачувану частину витрат на AI. Навчання моделі відбувається один раз. Інференс — щоразу, коли користувач, процес або агент надсилає запит. У масштабі ця різниця вирішує все.

Коренева проблема — утилізація. Без цілеспрямованої оптимізації виробничі inference-навантаження зазвичай завантажують GPU на 5–20%, тоді як бізнес платить за 100% виділеної потужності. Залізо переважно простоює між запитами, але лічильник не зупиняється. Для компаній, що запускають агентні сценарії — де AI генерує код, виконує його, аналізує результати, переглядає підхід і повторює цикл — простої ще довші: кожен крок створює паузу, поки система обробляє проміжні результати.

Саме цю неефективність і атакує Kog. Компанію заснував у 2023 році Ґаель Делало — інженер École Polytechnique, чий бекграунд охоплює фізику твердого тіла та офензивну кібербезпеку (зокрема чотири фінали DEFCON capture-the-flag). Команда з Парижа налічує одинадцять осіб: десять інженерів і дослідників, п'ятеро з яких мають PhD. Підхід Делало до оптимізації GPU прямо виростає з його безпекового досвіду: розібрати систему до асемблера й бінарного коду, а потім перепрограмувати її під цілі, для яких вона не проектувалась.

Результат — програмний шар, який переосмислює планування, батчинг і виконання inference-навантажень на рівні фізичних обмежень заліза: стандартних дата-центрових GPU на кшталт AMD MI300X і Nvidia H200, які вже є у підприємств. Після виходу демо на Hacker News CEO Kog повідомив про 200 реальних бізнес-лідів. Ринковий сигнал був однозначним: проблема реальна, масштабна й дорога.

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

Три шари оптимізації, які працюють вже сьогодні — без нового заліза

Не потрібно чекати, поки KIE стане загальнодоступним. Стек оптимізації має кілька рівнів, і найефективніші кроки доступні прямо зараз.

Шар 1: Виправте архітектуру навантажень — до того як торкатися інфраструктури

Найпотужніша зміна, яку більшість компаній може зробити, не стосується GPU взагалі. Йдеться про те, яка модель обробляє яке завдання.

Модель класу GPT-4 коштує приблизно в 10–20 разів більше за токен, ніж модель на 7 мільярдів параметрів — за публічними цінами API станом на середину 2026 року. У добре спроектованому пайплайні 70–80% підзавдань — класифікація намірів, перевірки безпеки, прості підтвердження, форматування — можуть обробляти менші моделі. Сукупна вартість одного звернення падає на 80–95% порівняно з маршрутизацією всього через одну фронтирну модель.

Це не теоретична оптимізація. Саме такий підхід дозволив одному споживчому AI-застосунку масштабуватися до мільйона користувачів за 19 днів, не розоривши компанію на inference-рахунках, — через реструктуризацію того, як стек обробляє кожну розмову, а не через перехід на гіршу модель чи скорочення функцій.

Практична реалізація: побудуйте routing-шар (інструменти на кшталт LiteLLM або LangChain справляються з цим добре), який класифікує кожен запит за складністю й направляє його до найдешевшої моделі, здатної надійно з ним впоратися. Виклики фронтирних моделей залиште для справді неоднозначних, критичних або високоцінних завдань. Плоска архітектура, де кожен запит іде до найпотужнішої моделі, — це гроші, викинуті на вітер.

Шар 2: Квантизація та батчинг — два важелі, які більшість команд недовикористовує

На рівні рантайму дві техніки стабільно дають вимірюваний результат при низькому ризику впровадження.

Квантизація зменшує числову точність ваг моделі, скорочуючи споживання пам'яті й підвищуючи пропускну здатність. FP8-квантизація на GPU класу H100 — нативно підтримується у vLLM — дає приріст пропускної здатності в 1,3–2x порівняно з FP16 при втраті якості менше 2% на instruction-tuned моделях. Для стандартних задач розмовного AI, підсумовування та генерації коду ця різниця в якості непомітна у виробництві. На новішому залізі B200 FP4 через TensorRT-LLM додає ще 1,5–2x поверх FP8.

Адаптивний батчинг вирішує проблему утилізації напряму. Фіксовані розміри батчів ламаються: вони роздувають затримку при низькому трафіку й марнують ефективність при високому. Адаптивний батчинг підлаштовується динамічно залежно від глибини черги, цільових затримок і характеристик моделі — коли трафік зростає, батчі збільшуються; коли спадає — зменшуються, зберігаючи чутливість. Це один із ключових механізмів, який KIE оптимізує на рівні заліза, але він також налаштовується у стандартних inference-серверах на кшталт vLLM і Triton вже сьогодні.

Сукупний ефект цих технік задокументований у виробничих розгортаннях. NVIDIA повідомляла, що Screenshop від Snap досяг приблизно 3x приросту пропускної здатності та орієнтовного скорочення витрат на 66% завдяки TensorRT, а Amdocs скоротив кількість токенів у препроцесингу до 60% і в інференсі до 40%, одночасно знизивши затримку запитів приблизно на 80%.

Шар 3: Кешування промптів і дисципліна контексту

У багатоходових розмовах і агентних сценаріях кожне нове повідомлення знову подає в модель повну історію розмови. Контекстні вікна роздуваються. Кількість токенів накопичується. Це один із найшвидших способів, яким AI-бюджет виходить з-під контролю.

Кешування промптів — збереження й повторне використання обчисленого стану повторюваного контексту — скорочує витрати на 50–90% для навантажень зі значним повторюваним контекстом: системні промпти, посилання на документи, спільні інструкції для багатьох запитів. Більшість великих API-провайдерів вже підтримують якусь форму кешування промптів; зусилля на впровадження невеликі відносно економії.

Дисципліна контексту — це доповнювальна практика: аудит того, що реально потрібно у вікні контексту, а що потрапляє туди за замовчуванням або за звичкою. Довгі системні промпти, багатослівні chain-of-thought виводи й нестиснені історії розмов підвищують кількість токенів без пропорційного приросту якості. Агресивне скорочення — з вимірюванням впливу на якість — часто є найшвидшою доступною оптимізацією.

Вибір інфраструктури підсилює все вищезазначене. Виділені GPU можуть коштувати $5 за GPU-годину проти $11 у великих хмарних провайдерів при еквівалентних характеристиках — різниця, яка суттєво накопичується при високій утилізації. Стек оптимізації — це не одне рішення, а послідовність рішень, кожне з яких має власний потенціал економії.

Що підхід Kog змінює для бізнесів, що масштабують AI-агентів

Специфічний внесок Kog знаходиться на шарі нижче того, що адресують більшість інструментів оптимізації. Замість роботи в межах існуючих inference-фреймворків KIE переосмислює планування й виконання навантажень на рівні фізики GPU-заліза — те, що Делало описує як занурення глибше за апаратно-незалежні програмні підходи, ближче до роботи дослідницьких лабораторій на кшталт Hazy Research зі Стенфорду.

Практичне значення для агентних сценаріїв — суттєве. Поточні inference-фреймворки обробляють агентні сценарії як складні одиничні запити. Але це не так. Агент, який генерує код, запускає його, чекає результатів і повторює цикл, створює принципово інший патерн утилізації, ніж простий обмін запит-відповідь. Підхід Kog передбачає прогнозування моментів цих пауз і пакування кількох агентних сценаріїв на один GPU — перемикання між завданнями, щоб процесори постійно отримували роботу. Це той самий принцип, який сучасні операційні системи використовують для багатозадачності, застосований до специфічних патернів AI-інференсу.

Для бізнесів, що розгортають AI-агентів у масштабі — у закупівлях, комплаєнсі, клієнтських операціях або розробницьких сценаріях — це важливо, бо структура витрат агентного AI якісно відрізняється від простих API-викликів. Простої між кроками агента — це місце, де накопичуються втрати, і саме тут програмна оптимізація має найбільший простір для маневру. Якщо вас цікавить, як витрати на AI-агентів вписуються в ширший ROI-фреймворк, розрахунок точки окупності AI-агента проти найму нового співробітника дає структуровану відправну точку.

Kog зараз проводить програму Design Partner для команд, що будують coding-агентів, системи генерації застосунків або інші агентні сценарії, де швидкість ітерацій вже є конкурентним вузьким місцем. Для бізнесів у цій категорії раннє залучення до оптимізації на рівні інфраструктури — через Kog або через runtime-техніки, описані вище — варто пріоритизувати зараз, поки використання не масштабувалося далі й структура витрат не закостеніла. А якщо вас цікавить, як агентна інфраструктура тримається під реальним виробничим навантаженням, стаття про стійкість AI-агентної інфраструктури охоплює вимір надійності, який оптимізація витрат сама по собі не вирішує.

Керівники, які роблять це правильно — які можуть прийти на раду директорів і показати, що вартість одного вирішеного тікета падає, поки пропускна здатність агентів зростає, — це ті, чиї AI-інвестиції читаються як операційний важіль, а не як експериментальні витрати. Це не м'яка перевага. Це різниця між бюджетом, який захищають, і бюджетом, який ставлять під сумнів щокварталу.

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

---

FAQ

Що таке AI-інференс і чому він такий дорогий? AI-інференс — це процес, під час якого навчена модель отримує вхідні дані — промпт, документ, запит — і генерує відповідь. На відміну від навчання моделі, яке відбувається один раз, інференс запускається безперервно щоразу, коли користувач або автоматизований сценарій надсилає запит. У масштабі сукупні обчислення на GPU роблять інференс найбільшою й найшвидше зростаючою складовою витрат на AI-інфраструктуру для більшості виробничих розгортань.

Чим підхід Kog відрізняється від стандартних інструментів оптимізації на кшталт vLLM або TensorRT? Стандартні інструменти на кшталт vLLM і TensorRT оптимізують у межах існуючих inference-фреймворків — покращуючи батчинг, квантизацію та управління пам'яттю на програмному рівні. Kog Inference Engine занурюється глибше: переосмислює планування й виконання навантажень на рівні фізики GPU-заліза, включно з низькорівневою інженерією під конкретну архітектуру кожного GPU (наприклад, AMD MI300X). Зворотний бік — ця глибина вимагає тижнів або місяців інженерної роботи на кожну модель GPU, що обмежує кількість чіпів, які команда з одинадцяти осіб може підтримувати.

Яка найшвидша оптимізація для малого бізнесу без виділеної ML-інфраструктури? Кешування промптів і маршрутизація моделей дають найшвидший результат при найнижчій складності впровадження. Направлення 70–80% рутинних підзавдань до менших, дешевших моделей — при збереженні викликів фронтирних моделей для справді складних завдань — може скоротити сукупні витрати на інференс на 80–95% у добре структурованих пайплайнах. Кешування промптів на повторюваному контексті (системні промпти, спільні інструкції) додає ще 50–90% скорочення для цих конкретних категорій токенів.

З якого масштабу варто інвестувати інженерний час в оптимізацію інференсу? Нижче приблизно 10 000 щоденних активних користувачів або еквівалентного обсягу агентних запитів загальні витрати на AI-інфраструктуру зазвичай достатньо низькі, щоб інженерний час на глибоку оптимізацію коштував більше, ніж генерована економія. Вище цього порогу — або коли агентні сценарії працюють безперервно, а не на вимогу — економіка рішуче схиляється на користь інвестицій в оптимізацію.

Чи безпечно використовувати квантизацію у виробництві? Чи не погіршиться якість виводу? Для більшості виробничих задач — розмовного AI, підсумовування, генерації коду, класифікації — FP8-квантизація дає менше 2% втрати якості порівняно з FP16, і ця різниця зазвичай непомітна кінцевим користувачам. Ризик вищий для задач, що вимагають точних числових міркувань або дуже специфічного фактологічного відтворення. Стандартна практика — бенчмаркувати квантизовані моделі на вашому конкретному розподілі завдань перед розгортанням у виробництво, а не припускати, що вплив на якість або незначний, або суттєвий, без вимірювання.

Які метрики реально показують, що оптимізація інференсу працює? Витрати на токени й утилізація GPU — це вхідні дані, а не результати. Метрики, що мають значення: вартість одного вирішеного тікета, вартість одного завершеного агентного сценарію та людино-еквівалентна погодинна ставка — порівняння того, що ваші AI-агенти коштують за одиницю роботи, з людською працею, яку вони замінюють або доповнюють. Саме ці цифри перекладають інфраструктурні рішення на мову бізнесу — і саме вони будуть значущими для ради директорів або інвесторів. Детальніше про те, як вимірювати ROI від AI, — у матеріалі про те, чому бюджети на ШІ скорочують через провал вимірювання, а не технології.

---

Розрив між тим, на що здатна ваша поточна GPU-інфраструктура, і тим, що ваш inference-стек із неї реально видавлює, — для більшості бізнесів, що запускають AI-агентів у виробництві, він і більший, і більш усувний, ніж здається. Робота Kog робить цей розрив видимим на рівні заліза. Техніки оптимізації, описані вище, роблять його усувним на рівні архітектури — вже сьогодні, без очікування нового заліза чи нових інфраструктурних партнерств.

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