Токени, контекст і вартість

Зміст

Кожен запит до LLM — це рахунок за токени й гонка з лімітом контексту. Модель не бачить ваш текст як букви чи слова: вона ріже його на токени, і саме за токени ви платите, саме в токенах вимірюється, скільки модель здатна «тримати в голові» за один раз. Для QA це не бухгалтерія, а щоденні рішення: чому генератор автотестів «забув» половину специфікації, чому один і той самий українською дорожчий за англійський, чому після сотні кроків починає гальмувати й помилятися.

Зрозумієш механіку токенів і контексту — і навчишся свідомо керувати якістю, швидкістю та вартістю роботи з AI, а не покладатися на «якось воно порахується». Ця глава — місток між «Як працюють LLM» і практичним промптингом: без неї промпти пишуться наосліп.

Токен: одиниця, якою мислить модель

Токен (token) — це шматок тексту, яким оперує модель: частіше за все це не ціле слово й не окрема буква, а підслівний фрагмент (subword). Токенізатор (tokenizer) — алгоритм, що ріже текст на такі шматки; більшість сучасних моделей використовують різновид BPE (byte-pair encoding), який збирає найчастіші послідовності символів в окремі токени.

Груба, але робоча оцінка для англійського тексту: приблизно 4 символи на токен, або близько ¾ слова на токен (100 токенів ≈ 75 слів). Тобто коротке речення — це кілька десятків токенів.

Ключова пастка для нас: українська коштує дорожче. Токенізатори тренують переважно на англомовних даних, тож кирилиця ріжеться на дрібніші шматки — слово нерідко розпадається на кілька токенів. Той самий зміст українською може займати у 2–3 рази більше токенів, ніж англійською. Практичний наслідок: якщо женете великі обсяги (наприклад, генеруєте тест-кейси з україномовної специфікації), і токен-ліміт, і рахунок будуть відчутно більші, ніж підказує «на око».

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

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

Контекстне вікно: скільки модель бачить за раз

(context window) — це максимальна кількість токенів, яку модель здатна обробити за один запит. У нього має вміститися все: , уся історія діалогу, вкладені документи чи логи, поточне питання — і ще лишитися місце під відповідь, бо згенеровані токени теж рахуються у вікно.

Розміри дуже різні: від кількох тисяч токенів у старих чи маленьких моделей до 200 000 і навіть 1 000 000 у сучасних. Зазвичай є ще окремий ліміт на довжину відповіді (max output) — навіть із мільйонним вікном модель не видасть вам мільйон токенів тексту за раз.

Що критично зрозуміти QA: API моделі не має памʼяті між запитами — він stateless. «Чат» лише створює ілюзію памʼяті: клієнт щоразу надсилає всю історію повідомлень заново. Тому з кожним ходом діалогу вхід росте й рано чи пізно впирається у вікно. Коли контекст переповнюється, варіанти невеселі: помилка запиту, обрізання старих повідомлень або примусове стиснення історії — і модель справді «забуває» те, що ви їй казали двадцять реплік тому.

Чому довгий контекст ≠ кращі відповіді

Велике вікно спокушає: «закинемо туди все — і специфікацію, і код, і логи». Але місткість вікна й здатність моделі якісно цим користуватися — різні речі.

Добре задокументований ефект — «загублене посередині» (lost in the middle): моделі надійніше знаходять інформацію на початку та в кінці контексту, ніж усередині. Помістіть потрібний факт у середину довгого документа — і шанс, що модель його «не помітить», зростає. Є й ширше явище деградації: що більше зайвого в контексті, то дужче розпорошується увага, і на дуже довгих входах якість, стабільність і точність можуть просідати.

Для QA висновок прямий: не вивалюйте на модель усе підряд. Довгий контекст — це і дорожче, і повільніше, і не обовʼязково точніше. Краще подати релевантний зріз: потрібний фрагмент логу, а не весь файл; конкретний розділ вимог, а не весь Confluence. Це той самий принцип, що й у ручному тестуванні, — сфокусована перевірка бʼє «протестуй усе».

Скільки це коштує: input проти output

Оплата — за токени, зазвичай за мільйон (позначають MTok або /1M). Два тарифи рахуються окремо:

вхідні () токени — усе, що ви надіслали: промпт, історія, документи;
вихідні (output) токени — усе, що модель згенерувала.

Головне правило: вихідні токени коштують у кілька разів дорожче за вхідні — типово в 5–6 разів. Наприклад, для моделей рівня Opus станом на липень 2026 вхід — порядку кількох доларів за мільйон токенів, а вихід — кількох десятків (співвідношення 1:5); точні цифри залежать від моделі й регулярно змінюються, тож звіряйтеся з прайсом провайдера. Врахуйте й те, що токени «міркування» (reasoning), якщо модель їх генерує, теж ідуть у вихідні.

Звідси неочевидний наслідок — діалог дорожчає нелінійно. Оскільки історію щоразу пересилають повністю, десятий хід оплачує всі попередні девʼять як вхід:

// Кожен наступний виклик пересилає всю історію — вхід росте з кожним ходом
const messages = [{ role: "system", content: SPEC }]; // великий стабільний префікс
messages.push({ role: "user", content: "Згенеруй тест-кейси для логіну" });
messages.push({ role: "assistant", content: reply1 }); // відповідь теж лягає в історію
messages.push({ role: "user", content: "А тепер негативні сценарії" });
// другий запит оплачує SPEC + перше питання + першу відповідь ЗНОВУ

Довга агентна сесія з десятками кроків і великими логами в контексті може коштувати помітно більше, ніж здається з одного «дешевого» запиту.

Prompt caching: платити один раз за спільний префікс

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

Порядок цін у Anthropic станом на липень 2026: читання з кешу коштує близько 10% від звичайної ціни вхідного токена, а перший запис у кеш — трохи дорожче за звичайний вхід (1.25x за стандартного TTL). В інших провайдерів механіка й множники свої, тож звіряйтеся з документацією. Тобто вже з другого-третього повторення кеш окупається.

Критичний нюанс — це збіг за префіксом (prefix match): кеш працює, лише поки початок запиту побайтово однаковий. Одна змінена дужка, вставлена дата чи переставлений ключ у JSON на початку — і весь кеш після цієї точки анулюється. Тому стабільне (незмінний системний промпт, документ) кладуть на початок, а мінливе (поточне питання, timestamp) — у кінець. У кеша ще є час життя (TTL; у Anthropic за замовчуванням 5 хвилин), після якого префікс треба «прогріти» заново.

Це концептуально та сама ідея, що й HTTP-кеш (див. Кешування): зберегти вже пораховане, щоб не рахувати вдруге, з тим самим питанням валідності. Для QA це прямий важіль: якщо ви ганяєте сотню промптів проти однієї великої специфікації (генерація кейсів, ревʼю), спеки економить і час прогону, і бюджет.

Як економити контекст і гроші

Кілька практичних прийомів, що випливають з усього вище:

Подавайте зріз, а не все. Релевантний фрагмент логу чи вимог замість цілого файлу — дешевше і точніше.
Тримайте стабільне на початку, мінливе — в кінці, щоб працювало кешування.
Стискайте історію. У довгих діалогах підсумовуйте попереднє замість того, щоб тягнути кожну репліку дослівно; починайте нову сесію, коли тема змінилася.
Використовуйте вибірку замість «запхати весь корпус». Підхід, коли в контекст підтягують лише потрібні шматки з бази знань (), — окрема велика тема, але принцип той самий: менше нерелевантного в контексті.
Рахуйте перед відправкою. Для важливих чи масових прогонів прикидайте токени лічильником потрібної моделі, а не «на око».

Вибір моделі під задачу

Немає «найкращої» моделі — є доречна. Провайдери зазвичай мають лінійку: від маленьких швидких і дешевих (клас Haiku) до великих потужних і дорогих (клас Opus), з проміжними (клас Sonnet). Компроміс завжди між трьома осями: якість — швидкість — вартість.

Орієнтир:

прості, масові, чітко окреслені задачі (класифікація баг-репортів, витяг полів, коротке підсумовування) — маленька швидка модель; часто різниця в якості мізерна, а в ціні й латентності — кратна;
складне міркування, генерація й ревʼю коду, багатокрокові агентні задачі — велика модель;
проміжне — середня.

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

Енергія й CO₂: рахунок, який вам не виставляють

У кожного запиту є друга ціна, якої немає у вашому інвойсі, — енергія. ISTQB винесла її в окремий екзаменований підрозділ силабуса CT-GenAI (§3.3) з ціллю рівня K2: пояснити вплив характеристик задачі й ужитку моделі на (energy consumption of Generative AI). У силабусі цей підрозділ стоїть у главі про керування ризиками — поруч із приватністю й AI-регуляціями.

Механіка та сама, що з грошима. Навчання й робота LLM, за силабусом, «потребують інтенсивного використання великої кількості спеціалізованих обчислювальних ресурсів»; модель ви викликаєте як вебсервіс, тож її використання «збільшує навантаження на пристрої, мережі й дата-центри». Далі — залежність від обсягу: вплив на довкілля не варто недооцінювати, бо енергоспоживання різко зростає зі зростанням використання.

Чинників силабус називає дослівно два — складність задачі і потрібні обчислювальні ресурси; опис вправи додає третій кут, ужиток моделі (яку саме модель і як часто ви берете). Тобто ті самі важелі, що й у рахунку: що ви просите і чим.

Тепер найважливіше — про числа. Силабус їх не дає. Ані кіловат-годин на запит, ані грамів CO₂ на тисячу токенів. Єдина його кількісна опора — обережне порівняння: генерація одного зображення потужною AI-моделлю може спожити стільки ж енергії, скільки повна зарядка смартфона, тоді як генерація тексту витрачає лише невеликий відсоток заряду смартфона (силабус посилається тут на публікацію MIT Technology Review 2023 року). І в тому ж абзаці зізнається, що точні дані про вплив GenAI на довкілля здобути важко — хоча сам висновок про викиди називає очевидним: енергоємні операції сукупно дають значні викиди CO₂.

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

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

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

Типові помилки

Виглядає як «модель забула контекст» — а насправді історія вилізла за межі вікна й старі повідомлення обрізало. Не баг моделі, а переповнене вікно.
Виглядає як «токенів приблизно стільки ж» для англійської та української — а насправді той самий текст українською займає у 2–3 рази більше токенів. Оцінка за словами вводить в оману.
Виглядає як «великий контекст = точніше» — а насправді через lost in the middle факт у середині довгого документа модель може проігнорувати, і якість на довгому вході просідає.
Виглядає як «кеш не працює, хоча промпт майже той самий» — а насправді змінився початок префікса (дата, id, порядок ключів), і збіг за префіксом зламався.
Виглядає як «вартість = ціна одного запиту» — а насправді в діалозі історія пересилається щоразу, тож вартість росте з кожним ходом; вихідні токени ще й дорожчі за вхідні.
Виглядає як «візьмемо найпотужнішу модель, щоб напевно» — а насправді на простих масових задачах це зайві гроші й латентність без виграшу в якості.

Підсумок

Модель оперує токенами, не словами; українська й код коштують більше токенів, ніж здається, а різні моделі рахують токени по-різному.
Контекстне вікно — спільний бюджет на промпт, історію, документи й відповідь; API stateless, тож історію пересилають щоразу, і вона впирається у вікно.
Довгий контекст не гарантує кращих відповідей: працює lost in the middle і загальна деградація — подавайте релевантний зріз.
Платять за токени; вихідні дорожчі за вхідні в кілька разів, а діалог дорожчає нелінійно через повторне пересилання історії.
Prompt caching здешевлює спільний префікс, але тримається на побайтовому збігу початку; модель обирають під задачу за трикутником якість/швидкість/ціна.
Друга ціна того самого запиту — енергія: за CT-GenAI на неї впливають складність задачі й ужиток моделі, а єдина названа там практика — не робити зайвих звернень до моделі. Чисел силабус не наводить, тож і ви їх не вигадуйте.

Можливі питання

«Що таке токен і чому це важливо для роботи з LLM?» — інтервʼюер хоче почути, що модель оперує підслівними токенами, що від них залежать і ліміт контексту, і вартість, і що українська та код токенізуються дорожче.
«Що таке контекстне вікно і що станеться, якщо його перевищити?» — очікують згадку, що у вікно входить усе (промпт + історія + відповідь), що API stateless, і що при переповненні буде помилка, обрізання або стиснення, а не магічна памʼять.
«Чому не варто просто закидати в модель усі логи й вимоги?» — перевіряють розуміння деградації на довгому контексті (lost in the middle) і вартості; сильний кандидат говорить про подання релевантного зрізу.
«Чим відрізняється ціна input і output і як здешевити роботу з LLM?» — дивляться, чи знаєте, що output дорожчий, що діалог пересилає історію, і чи назвете prompt caching, стиснення контексту, вибір меншої моделі.
«Як обрати модель під задачу?» — хочуть побачити мислення в осях якість/швидкість/вартість, а не «беру найкращу»; плюс — приклад, де дешева модель доречна.
«Що ISTQB каже про енергоспоживання GenAI?» — очікують, що назвете окремий підрозділ CT-GenAI (§3.3), два чинники (складність задачі й потрібні обчислювальні ресурси) плюс ужиток моделі та практику «не робити зайвих звернень». Сильний кандидат окремо зауважить, що чисел силабус не дає й сам пише про брак точних даних.

Джерела

Токен: одиниця, якою мислить модель

ISTQB CT-GenAI Syllabus v1.1 — канонічне означення токенізації як розбиття тексту на менші одиниці, де токен буває завбільшки як символ, підслово або слово.
Google — Machine Learning Glossary — токен як атомарна одиниця, на якій модель навчається й робить передбачення; підслово складається з кореня, префікса або суфікса.
Claude Platform Docs — Context windows — чим рахувати замість «на око»: поле usage у відповіді й окреме API підрахунку токенів під конкретну модель.

Контекстне вікно: скільки модель бачить за раз

Claude Platform Docs — Context windows — що входить у вікно (системний промпт, кожне повідомлення, означення інструментів і сама відповідь), як накопичується історія, розміри на дату забору й окремий ліміт вихідних токенів; там же — стиснення на боці сервера й обрізання як поведінка чат-інтерфейсів.
ISTQB CT-GenAI Syllabus v1.1 — вендор-нейтральне означення вікна як обсягу попереднього тексту в токенах і ціна довгого вікна: більше токенів — вища вартість і латентність.

Чому довгий контекст ≠ кращі відповіді

N. F. Liu et al. — Lost in the Middle: How Language Models Use Long Contexts (arXiv:2307.03172) — першоджерело ефекту: продуктивність найвища, коли релевантне стоїть скраю, і суттєво падає, коли його треба дістати із середини — навіть у моделей, спеціально зроблених під довгий контекст.
Claude Platform Docs — Context windows — ширша форма явища під іменем context rot: зі зростанням кількості токенів деградують точність і повнота пригадування.
Claude Code Docs — Best practices for Claude Code — практичний бік: продуктивність падає в міру заповнення вікна, і модель починає «забувати» ранні інструкції.
Claude Platform Docs — Prompting best practices — слідство для компонування промпта: довгі документи кладуть угору, а сам запит — у кінець.

Скільки це коштує: input проти output

Claude Platform Docs — Prompt caching — прайс-таблиця на дату забору, з якої й береться відношення входу до виходу як 1:5.
Claude Platform Docs — Context windows — механіка нелінійності: попередні ходи зберігаються повністю, вхідна фаза кожного ходу містить усю історію, а токени міркування тарифікуються як вихідні.
ISTQB CT-GenAI Syllabus v1.1 — вендор-нейтральна рамка витрат і вправа на оцінку регулярних витрат із трьома множниками: кількість вхідних і вихідних токенів, вартість моделі, частота запитів.

Prompt caching: платити один раз за спільний префікс

Claude Platform Docs — Prompt caching — механіка цілком: кешується весь префікс у порядку tools → system → messages, множники запису й читання на дату забору, TTL за замовчуванням, кумулятивний хеш префікса й класична пастка з timestamp у останньому блоці.

Як економити контекст і гроші

Claude Platform Docs — Prompt caching — чому стабільне кладуть на початок: зміна будь-якого блока на або перед ним дає інший хеш і анулює кеш.
Claude Platform Docs — Context windows — основна стратегія для довгих агентних названа прямо: стиснення на боці сервера; і окреме API, яким рахують запит наперед.
Claude Code Docs — Best practices for Claude Code — практики керування контекстом: /clear між незвʼязаними задачами, автоматичне ущільнення історії, делегування дослідження в окремі вікна.
Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv:2005.11401) — першоджерело підходу «підтягнути лише потрібні шматки»: непараметрична памʼять через ретривер замість усього корпусу в контексті.

Вибір моделі під задачу

ISTQB CT-GenAI Syllabus v1.1 — вибір моделі як економічне рішення: враховують поточні витрати на використання, включно з ліцензійними платежами й операційними видатками.
Claude Platform Docs — Prompt engineering overview — пряма підстава під «є доречна, а не найкраща»: латентність і вартість часто дешевше поправити вибором іншої моделі, ніж промпт-інженерією.

Енергія й CO₂: рахунок, який вам не виставляють

ISTQB CT-GenAI Syllabus v1.1 — §3.3 як окремий екзаменований підрозділ із ціллю GenAI-3.3.1 (K2): два чинники впливу, накопичувальний ефект, єдина названа практика пом'якшення й пряме визнання, що точні дані здобути важко.
ISTQB — Certified Tester Specialist Level – Testing with Generative AI (CT-GenAI) Overview — сторінка сертифікації називає пʼять поіменно, і вплив на довкілля стоїть у цьому переліку нарівні з , упередженнями, безпекою й приватністю.

Що таке токен і чому модель не працює зі словами напряму?

Токен (token) — це найменша одиниця тексту, якою оперує модель: зазвичай не ціле слово й не окрема буква, а підслівний фрагмент (subword). Текст ріже на такі шматки токенізатор (tokenizer), найчастіше різновидом BPE (byte-pair encoding), який склеює найчастотніші послідовності символів в окремі токени. Слова моделі «незручні»: словник був би нескінченним і не покривав би одруки та нові слова, а окремі символи — надто дрібні, щоб нести сенс ефективно. Підслівний компроміс дає обмежений словник, який усе ж збирає часте слово в один токен, а рідкісне — з кількох. Для QA це не термінологія заради термінології: саме від токенів залежить і скільки модель вміщає за раз, і скільки коштує кожен запит.

Груба оцінка «100 токенів ≈ 75 слів» — коли вона підводить?

Це робоче правило для англійського тексту (приблизно 4 символи на токен), але для української воно систематично занижує число. Токенізатори тренують переважно на англомовних корпусах, тож кирилиця дробиться на дрібніші шматки — слово нерідко розпадається на кілька токенів. Той самий зміст українською може займати у 2–3 рази більше токенів, ніж англійською. Практично це б'є там, де женете обсяг: генерація тест-кейсів з україномовної специфікації і в ліміт вікна впреться раніше, і за рахунком вийде дорожчою, ніж підказує прикидка «на око» за словами. Тому для масових чи важливих прогонів число токенів рахують лічильником, а не множенням слів на коефіцієнт.

Чому код і JSON токенізуються не так, як здається?

Бо токенізатор бачить не «логіку», а символи, і структурні елементи коштують окремих токенів. Відступи, дужки, лапки, коми, довгі ідентифікатори — усе це окремі шматки, тож щільний на вигляд фрагмент може давати несподівано багато токенів. Мінімізований JSON чи лог на кілька екранів легко з'їдає тисячі токенів, хоч «корисної» інформації там мало. Для QA наслідок прямий: вкидати в контекст цілий сирий лог або весь дамп відповіді — це і роздутий рахунок, і швидше переповнення вікна. Дешевше й точніше подати зріз — потрібні рядки, а не весь файл.

Чому не можна рахувати токени для однієї моделі лічильником від іншої?

Бо різні моделі використовують різні токенізатори, і той самий рядок дає різну кількість токенів у різних провайдерів і навіть у різних поколінь однієї родини. Токенізатор — частина конкретної моделі, а не універсальний стандарт. Класична помилка — оцінювати токени умовного Claude бібліотекою, написаною під токенізатор GPT: число буде правдоподібним, але неправильним, і на межі вікна чи бюджету це підведе. Для точної цифри беруть офіційний токенізатор потрібного провайдера або підрахунку токенів саме тієї моделі, якою збираєтесь працювати.

Що таке контекстне вікно і що в нього входить?

(context window) — це стеля токенів, яку модель обробляє за один запит. Ключове: у цей бюджет входить усе одразу — , уся історія діалогу, вкладені документи чи логи, поточне питання, і ще має лишитися місце під відповідь, бо згенеровані токени теж рахуються у вікно. Розміри дуже різні: від кількох тисяч у старих чи маленьких моделей до 200 000 і навіть 1 000 000 у сучасних. Окремо зазвичай існує ліміт на довжину самої відповіді (max output), тож навіть мільйонне вікно не означає мільйон токенів тексту за раз. Для QA це бюджет, який треба свідомо розподіляти, а не сподіватися, що «якось поміститься».

Що означає «API моделі stateless» і як тоді працює «памʼять» чату?

Stateless означає, що між запитами модель не зберігає нічого: кожен самодостатній і не знає про попередні. «Памʼять» чату — ілюзія, яку створює клієнт: він щоразу надсилає всю історію повідомлень заново, і модель щоразу перечитує її з нуля. Звідси два наслідки. По-перше, з кожним ходом діалогу вхід росте, бо історія накопичується й пересилається повністю. По-друге, рано чи пізно ця історія впирається у вікно. Розуміти це важливо, щоб не дивуватися ні зростанню вартості довгої сесії, ні тому, що модель раптом «забула» сказане на початку.

Що станеться, коли розмова перевищить контекстне вікно?

Магічної памʼяті не буде — станеться одне з трьох, і всі варіанти неприємні. Або запит поверне помилку про перевищення ліміту, або клієнт/сервіс обріже старі повідомлення, щоб влізти у вікно, або історію примусово стиснуть у коротший переказ. У двох останніх випадках модель справді «забуває» те, що ви казали багато реплік тому — не тому, що вона «дурна», а тому, що цих токенів уже немає у вході. Для QA це діагностичний орієнтир: коли після сотні кроків «губить» початкову інструкцію, перший підозрюваний — переповнене вікно й обрізана історія, а не баг моделі.

Чому «закинути в модель усе підряд» — погана ідея навіть з великим вікном?

Бо місткість вікна і здатність якісно нею скористатися — різні речі. Велике вікно спокушає вкинути туди і специфікацію, і код, і всі логи, але довгий контекст одночасно дорожчий, повільніший і не обов'язково точніший. Що більше зайвого в контексті, то дужче розпорошується увага моделі, і на дуже довгих входах якість, стабільність та точність можуть просідати. Розумніше подати релевантний зріз: потрібний фрагмент логу замість цілого файлу, конкретний розділ вимог замість усього Confluence. Це той самий принцип, що й у ручному тестуванні: сфокусована перевірка б'є «протестуй геть усе».

Що таке ефект «загублене посередині» (lost in the middle)?

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

Чим різниться ціна input і output токенів?

Оплата йде окремо за два потоки: вхідні () токени — усе, що ви надіслали (, історія, документи), і вихідні (output) токени — усе, що модель згенерувала. Головне правило: вихідні коштують у кілька разів дорожче за вхідні, типово в 5–6 разів. Наприклад, для моделей класу Opus станом на липень 2026 вхід — це порядку кількох доларів за мільйон токенів, а вихід — кількох десятків, тобто співвідношення 1 до 5; точні числа залежать від моделі й регулярно змінюються, тож звіряйтеся з прайсом провайдера. Ще нюанс: токени «міркування» (reasoning), якщо модель їх генерує, теж рахуються як вихідні. Тому задачі з довгими відповідями плануйте бюджетувати за вихідним тарифом, а не за дешевшим вхідним.

Чому діалог з моделлю дорожчає нелінійно?

Бо історію пересилають повністю на кожному ході (API stateless), тож кожен наступний запит оплачує всі попередні як вхід. Десятий хід везе у вході і системний промпт, і всі дев'ять попередніх реплік разом із відповідями — і платить за них знову. Виходить, що вартість росте не рівномірно, а прискорено: чим довший діалог, тим більший вхід кожного нового кроку. Довга агентна сесія з десятками кроків і великими логами в контексті легко коштує помітно більше, ніж здається з ціни одного «дешевого» запиту. Тому в оцінці вартості дивляться на всю сесію, а не на окремий виклик, і стискають історію, коли вона розростається.

Що таке prompt caching і коли він окупається?

Prompt caching () зберігає вже оброблений початок запиту, щоб наступні запити з тим самим початком не рахували його заново. Це має сенс, коли багато запитів починаються з того самого великого шматка: незмінного системного промпта, великої специфікації, набору прикладів. Порядок цін у Anthropic станом на липень 2026: читання з кешу коштує близько 10% від звичайної ціни вхідного токена, а перший запис у кеш — трохи дорожче за звичайний вхід (1.25x); в інших провайдерів множники свої. Тобто вже з другого-третього повторення того самого префікса кеш окупається і грошима, і швидкістю. Для QA це прямий важіль: якщо ганяєте сотню промптів проти однієї великої спеки (генерація кейсів, ревʼю), цієї спеки економить і бюджет, і час прогону.

Чому кеш «ламається», хоча промпт майже той самий?

Бо кеш працює на збігу за префіксом (prefix match): він валідний рівно доти, доки початок запиту побайтово однаковий. Одна змінена дужка, вставлена дата, інший порядок ключів у JSON на початку — і кеш після цієї точки анулюється, запит рахується з нуля за повною ціною. «Майже той самий» тут не рахується: важлива буквальна тотожність початку. Ще є час життя кеша (TTL, часто кілька хвилин), після якого префікс треба «прогріти» заново. Тому симптом «кеш не працює, хоча промпт майже ідентичний» майже завжди означає, що на початку щось мінливе зламало збіг, або минув TTL.

Куди класти стабільне, а куди мінливе в промпті, і чому?

Стабільне — на початок, мінливе — у кінець. Оскільки кеш тримається на побайтовому збігу префікса, усе незмінне (системний промпт, велика специфікація, приклади) має стояти першим, щоб цей блок кешувався й перевикористовувався між запитами. А все, що змінюється від виклику до виклику (поточне питання, timestamp, id запуску), має йти після — інакше воно зсуне префікс і зламає збіг для всього, що далі. Це та сама ідея, що й у HTTP-кеші: зберегти вже пораховане й не рахувати вдруге. Практично для QA це означає структурувати промпт свідомо: не вставляти дату чи випадковий id на початку великого сталого блоку.

Автотести з LLM-генерацією подорожчали після переходу на україномовну специфікацію. Це баг білінгу?

Ні, це очікуваний ефект токенізації, а не помилка в рахунку. Той самий за змістом текст українською займає у 2–3 рази більше токенів, ніж англійською, бо кирилиця дробиться токенізатором на дрібніші шматки. Якщо специфікація, з якої генеруються кейси, переїхала з англійської на українську, вхідних токенів на кожен запит стало кратно більше — звідси й зростання рахунку, і швидше наближення до ліміту вікна. Перевірити просто: прогнати обидві версії спеки через токен-лічильник потрібної моделі й порівняти числа. Це аргумент подавати сталу частину промпта мовою, якою вона компактніша, або принаймні закладати цей коефіцієнт у бюджет.

Як обрати модель під задачу і чому «беру найпотужнішу» — не стратегія?

Немає «найкращої» моделі — є доречна, і вибір роблять у трикутнику якість / швидкість / вартість. Провайдери зазвичай мають лінійку: маленькі швидкі й дешеві (клас Haiku), великі потужні й дорогі (клас Opus), проміжні (клас Sonnet). Прості, масові, чітко окреслені задачі — класифікація баг-репортів, витяг полів, коротке підсумовування — часто без втрати якості тягне маленька модель, а різниця в ціні й латентності кратна. Складне міркування, генерація й ревʼю коду, багатокрокові агентні сценарії — робота для великої. Брати найпотужнішу «про запас» на тисячі дрібних викликів — це спалювати бюджет і час без виграшу в якості; зворотна крайність — тягнути найдешевшу туди, де вона систематично галюцинує. Розумний підхід у агентних системах — комбінувати: дешева модель на рутину, дорога на складні рішення.

Чи є в силабусах ISTQB щось про енергоспоживання AI — і що саме там сказано?

Так, і це не побічна ремарка: CT-GenAI має окремий екзаменований підрозділ §3.3 про енергоспоживання й вплив генеративного AI на довкілля, з ціллю рівня K2 (пояснити вплив характеристик задачі й ужитку моделі) і власною вправою на підрахунок енергії та викидів CO₂ для тестових задач. Причина, за силабусом: навчання й робота LLM потребують інтенсивного використання великої кількості спеціалізованих обчислювальних ресурсів, а сама модель — це вебсервіс, тож її використання збільшує навантаження на пристрої, мережі й дата-центри. Чинники названі дослівно два — складність задачі й потрібні обчислювальні ресурси; опис вправи додає ужиток моделі. Практика пом'якшення в силабусі одна — обмежувати зайві взаємодії з моделлю, тобто рівно те, чого вимагає й економія бюджету. Окремо варто знати межу: чисел силабус не наводить — ані кіловат-годин, ані грамів CO₂. Єдина його кількісна опора — обережне порівняння (генерація одного зображення потужною AI-моделлю може спожити стільки ж енергії, скільки повна зарядка смартфона, а генерація тексту витрачає лише невеликий відсоток заряду), і поруч із ним він сам пише, що точні дані про вплив GenAI на довкілля здобути важко.

Три робочі кейси, де токени й контекст перетворюються на конкретні рішення QA: прикидка вартості прогону генерації тест-кейсів (де ховаються гроші), розкладка під prompt caching у коді (що вмикає й що ламає кеш) і таблиця вибору моделі під типові задачі. Числа тут ілюстративні — точні тарифи звіряйте з прайсом провайдера, важлива механіка.

Кейс 1. Скільки коштує прогін генерації тест-кейсів

Задача: згенерувати тест-кейси проти специфікації розміром ~20 000 токенів, у діалозі з чотирьох ходів (згенеруй позитивні → додай негативні → покрий граничні → перепиши у форматі Gherkin). Спека українською, тож її розмір у токенах уже враховує «кириличний податок». Порахуймо вхід по ходах, памʼятаючи, що історію пересилають повністю щоразу.

Хід	Що у вході (input)	Вхідних токенів	Вихідних токенів
1	спека 20k + питання	~20 300	~2 000
2	спека + питання 1 + відповідь 1 + питання 2	~22 400	~2 000
3	усе попереднє + питання 3	~24 500	~2 000
4	усе попереднє + питання 4	~26 600	~2 500

Що тут видно і чому:

Вхід росте щоходу, хоча спека одна. Причина не в спеці, а в накопиченій історії: API stateless, тож кожен хід везе всі попередні репліки заново. До четвертого ходу спека фактично оплачена чотири рази.
Вихід дорожчий, ніж здається. Якщо вихідний токен коштує в ~5 разів більше за вхідний, то ~8 500 вихідних токенів за сесію можуть переважити частину «дешевого» входу. Довгі відповіді бюджетують за вихідним тарифом.
Українська спека — прихований множник. Та сама спека англійською зайняла б ~7–10k токенів замість 20k, тобто і вхід кожного ходу, і рахунок були б помітно меншими. Це аргумент тримати стабільну частину промпта компактною мовою.
Головний висновок: оцінюємо вартість усієї сесії, а не одного «дешевого» першого запиту. Довга сесія з логами в контексті дорожчає прискорено.

Груба прикидка перед масовим прогоном — без здогадок «на око»:

// Ілюстративні тарифи за 1M токенів; підставте актуальні з прайсу провайдера
const IN = 3;      // input, $/MTok
const OUT = 15;    // output, $/MTok (дорожчий у ~5x)

const inputTokens = 20_300 + 22_400 + 24_500 + 26_600; // сума входів по ходах
const outputTokens = 2_000 + 2_000 + 2_000 + 2_500;

const cost = (inputTokens * IN + outputTokens * OUT) / 1_000_000;
// приблизно (93 800 * 3 + 8 500 * 15) / 1e6 ≈ $0.41 за одну сесію
// помножте на 200 сценаріїв — і «копійчаний» запит стає відчутним бюджетом

Кейс 2. Розкладка промпта під prompt caching

Ганяємо сотню запитів проти однієї великої спеки (генеруємо кейси й робимо ревʼю). Спека незмінна, змінюється лише поточне питання — ідеальний випадок для префікса. Кеш працює на побайтовому збігу початку, тож усе стале кладемо першим, усе мінливе — останнім.

// ПРАВИЛЬНО: стабільний префікс на початку → кешується й перевикористовується
const messages = [
  { role: "system", content: SYSTEM_PROMPT }, // незмінний
  { role: "user", content: SPEC },            // велика незмінна спека (20k токенів)
  { role: "user", content: currentQuestion }, // єдине, що змінюється щозапиту
];
// перший запит: запис у кеш ~1.25x; далі читання префікса ~0.1x замість повної ціни

А тепер типова помилка, через яку кеш «мовчки не працює»:

// НЕПРАВИЛЬНО: мінливе значення заповзло на ПОЧАТОК префікса
const messages = [
  { role: "system", content: `Запуск від ${new Date().toISOString()}\n${SYSTEM_PROMPT}` },
  { role: "user", content: SPEC },
  { role: "user", content: currentQuestion },
];
// timestamp на самому початку зсуває префікс щозапиту → збіг ламається,
// спека рахується з нуля за повною ціною кожного разу

Що дивитися і чому:

Симптом «кеш не окупається, хоча промпт майже той самий». «Майже» тут не рахується: одна вставлена дата, id запуску чи переставлений ключ у JSON на початку — і весь префікс після цієї точки анулюється. Шукайте, що мінливе заповзло у голову промпта.
Порядок оплачується. Зі стабільним префіксом уже з другого-третього запиту кеш повертає вкладене: читання ~10% проти повної ціни вхідних токенів спеки. На сотні запитів це кратна економія бюджету й латентності.
Памʼятайте про TTL. Кеш живе обмежений час (часто кілька хвилин); якщо між запитами великі паузи, префікс доведеться «прогрівати» заново. Для щільного прогону це не проблема, для рідких викликів — так.
Це той самий принцип, що й HTTP-кеш: зберегти вже пораховане й не рахувати вдруге, з тим самим питанням валідності початку.

Кейс 3. Яку модель узяти під задачу

Спокуса взяти найпотужнішу модель «щоб напевно» коштує грошей і латентності там, де виграшу в якості немає. Розкладаємо типові QA-задачі по трикутнику якість / швидкість / вартість.

Задача	Профіль	Розумний вибір	Чому
Класифікація баг-репортів за компонентом	масова, чітка, проста	маленька (клас Haiku)	різниця в якості мізерна, а в ціні й латентності — кратна
Витяг полів з тексту тикета	масова, шаблонна	маленька	структурований витяг не потребує глибокого міркування
Коротке підсумовування логу падіння	обсяг, проста мета	маленька / середня	якщо не треба глибокого аналізу — дешевша впорається
Генерація складних тест-сценаріїв зі спеки	міркування, покриття	велика (клас Opus)	тут якість покриття прямо залежить від сили моделі
Ревʼю коду автотестів	міркування, точність	велика	дешева модель систематично пропускає логіку
Багатокрокова агентна сесія	планування, стійкість	комбінація	рутинні кроки — дешева, складні рішення — дорога

Що дивитися і чому:

Дві дзеркальні помилки. Найпотужніша модель на тисячі дрібних викликів спалює бюджет без виграшу; найдешевша на складному міркуванні систематично галюцинує чи не витягує логіку. Обидві однаково дорого коштують — просто по-різному.
В агентних системах комбінують. Дешева модель на рутину (парсинг, класифікація проміжних кроків), дорога — на вузлові рішення. Це не компроміс якості, а розподіл ресурсу під конкретний крок.
Рішення не вічне. Лінійки й ціни моделей регулярно змінюються, тож вибір варто переглядати, а числа звіряти з поточним прайсом, а не з памʼяті.

Токени й токенізація

Можу пояснити, що таке токен (підслівний фрагмент) і що модель ріже текст токенізатором, найчастіше різновидом BPE.
Знаю оцінку для англійської (≈4 символи або ≈¾ слова на токен) і що українська коштує у 2–3 рази більше токенів за той самий зміст, бо кирилиця дробиться дрібніше.
Розумію, чому код і JSON токенізуються неочевидно: відступи, дужки, лапки, довгі ідентифікатори — окремі токени.
Знаю, що різні моделі мають різні токенізатори, тож не рахую токени однієї моделі лічильником від іншої.

Контекстне вікно

Можу перелічити, що входить у вікно: , історія, документи, поточне питання і місце під відповідь (згенеровані токени теж займають вікно).
Знаю, що окремо існує ліміт на довжину відповіді (max output), не тотожний розміру вікна.
Можу пояснити, що API stateless: «памʼять» чату — це щоразове пересилання всієї історії клієнтом.
Знаю три сценарії переповнення вікна: помилка запиту, обрізання старих повідомлень, примусове стиснення історії.

Довгий контекст і деградація

Розумію, що місткість вікна і здатність якісно нею скористатися — різні речі: на довгих входах увага розпорошується, точність і стабільність просідають.
Можу пояснити ефект «загублене посередині» (lost in the middle): факт у середині довгого входу модель дістає гірше, ніж з країв.
Можу сформулювати практику: подавати релевантний зріз, а не «вивалити все підряд».

Вартість: input проти output

Знаю, що і output тарифікуються окремо (зазвичай за мільйон токенів) і вихідні дорожчі за вхідні в кілька разів (типово 5–6).
Розумію, що reasoning-токени рахуються як вихідні.
Можу пояснити, чому діалог дорожчає нелінійно: історію пересилають повністю щоходу, тож пізні кроки оплачують усі попередні.

Prompt caching

Розумію ідею кешувати спільний префікс і порядок цін (Anthropic, станом на 07.2026): читання з кешу ≈10% вхідної ціни, перший запис ≈1.25x, окупність з 2–3-го повторення.
Можу пояснити, що кеш тримається на побайтовому збігу префікса (prefix match): зміна дати, дужки чи порядку ключів на початку його ламає; є ще TTL (кілька хвилин), після якого префікс прогрівають заново.
Розумію правило розкладки: стабільне — на початок, мінливе — в кінець.

Економія й вибір моделі

Можу назвати прийоми економії: зріз замість усього файлу, стиснення історії, вибірка з бази знань (), підрахунок токенів перед відправкою.
Розумію трикутник вибору моделі (якість / швидкість / вартість) і розкладку по класах (Haiku / Sonnet / Opus): рутина на дешеву, складне міркування на дорогу.
Можу пояснити обидві крайні помилки: найпотужніша модель на масову дрібноту і найдешевша там, де вона систематично галюцинує.

Енергія й вплив на довкілля

Знаю, що — окремий екзаменований підрозділ CT-GenAI (§3.3, ціль рівня K2), а не побічна етична ремарка.
Можу назвати чинники, які називає силабус: складність задачі й потрібні обчислювальні ресурси, плюс ужиток моделі; і практику пом'якшення — обмежувати зайві взаємодії з моделлю.
Розумію, що ефект накопичувальний: окремий виклик здається незначним, значення має сукупність на мільйонах користувачів.
Пам'ятаю, що чисел (кВт·год, грамів CO₂) силабус не наводить і сам пише про брак точних даних — тож не переказую ефектних цифр без джерела й дати.

Знайшли помилку?