Які обмеження ChatGPT?

 

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

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

 

 

 

Чому у ChatGPT взагалі є обмеження?

Якщо не заглиблюватися, то будь-які обмеження потрібні для захисту сервісу від зловживань, управління навантаженням і підтримки стабільної роботи для всіх його користувачів. Не став винятком і OpenAI, який прямо вказує, що навіть тарифи з практично необмеженим доступом все одно залишаються т.зв. subject to abuse guardrails, тобто підпорядковуються захисним обмеженням проти будь-яких зловживань.

Тільки уявіть, що кожен розробник на планеті почне вставляти в поле введення повні коди React-додатків, Kubernetes-кластери та дампи логів сотні разів на годину. Жодна інфраструктура такого не витримає і рано чи пізно зіткнеться з обмеженнями обчислювальних ресурсів.

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

 

 

 

 

Обмеження повідомлень: "Занадто багато запитів, спробуйте пізніше"

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

Наприклад, для безкоштовного тарифу OpenAI вказує обмежене використання GPT-5.5 у межах п'ятигодинного вікна.

Для Plus і Go в офіційній довідці вказано до 160 повідомлень з GPT-5.5 кожні 3 години, після чого чат може переключитися на mini-версію моделі до скидання ліміту. У платних тарифів ліміти, звичайно, вищі, але це все одно не означає повної відсутності обмежень.

Не завжди зрозуміло, де в даний конкретний момент можна подивитися фактичний ліміт повідомлень. Тому зазвичай користувач дізнається про нього вже в момент перевищення і часто це відбувається в найневідповідніший момент, наприклад після того, як ти вставив великий bash-скрипт, довгий лог або фрагмент конфігурації і натиснув Enter.

Якщо ви використовуєте OpenAI API, то ситуація трохи більш передбачувана. Там обмеження описуються через rate limits: запити на хвилину, запити на день, токени на хвилину, токени на день і зображення на хвилину. Ці ліміти залежать від організації, проєкту, моделі та вашого рівня доступу.

 

Як ці ліміти виглядають на практиці

Середовище використання	Тип ліміту	Що відбувається при перевищенні
ChatGPT web	Повідомлення за часовий інтервал	З’являється повідомлення про ліміт або вибрана модель тимчасово стає недоступною
ChatGPT tools	Окремі ліміти на файли, зображення, аналіз даних та інші інструменти	Інструмент тимчасово стає недоступним
OpenAI API	RPM, RPD, TPM, TPD, IPM	API повертає помилку ліміту, найчастіше 429
OpenAI API billing/usage	Обмеження бюджету та рівня доступу	Запити можуть бути відхилені до підвищення ліміту або зміни тарифу

Своїми словами можна сформулювати, що навіть якщо інтерфейс здається майже безлімітним, то обмеження є завжди. Просто в ChatGPT вони частіше сприймаються як "ліміт повідомлень", а в API - як формальні обмеження щодо запитів і токенів.

 

 

 

 

Розмір підказки

Жорсткий ліміт на підказки залежить від конкретної моделі та середовища використання. Зараз вже некоректно орієнтуватися на стару формулу "GPT-4 32K", тому що у сучасних моделей OpenAI контекстні вікна помітно відрізняються. В офіційній документації по API для окремих моделей вказані великі контекстні вікна і окремо максимальний розмір відповіді. Наприклад, в документації OpenAI API для GPT-5.4 вказано контекстне вікно 1M і максимальний вивід 128K токенів, тоді як для GPT-4.1 - контекст близько 1M токенів.

Але великий контекст не означає, що в один запит завжди розумно надсилати все підряд. Наприклад, поганою ідеєю буде вставити всю сторінку man Linux, повний nginx.conf, дамп journalctl, кілька YAML-маніфестів Kubernetes і очікувати ідеальної відповіді. Навіть якщо запит технічно вміщується в контекст, якість аналізу такого "салату" може сильно знижуватися через шум.

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

Конкретну модель потрібно вибирати за актуальною документацією OpenAI API, тому що імена моделей, розміри контексту та максимальний вивід з часом змінюються.

 

Як оцінити розмір запиту перед відправкою

Але є досить робочий варіант рішення - підрахувати токени перед відправкою. Для цього OpenAI рекомендує використовувати token counting API, оскільки локальні оцінки через tiktoken не завжди враховують зображення, файли, схеми інструментів та специфічну для моделі поведінку.

Наприклад, для простого тексту можна використовувати приблизну оцінку, коли 1 токен часто відповідає кільком символам тексту. Код, JSON, YAML та логи можуть витрачати токени менш передбачувано, а локальні оцінки, звичайно, корисні, але не завжди повністю збігаються з фактичним підрахунком API.

Тому приклад для Python з використанням інструменту tiktoken буде корисним для попередньої оцінки plain text:

import tiktoken

enc = tiktoken.get_encoding("cl100k_base")
text = "your input here"

tokens = len(enc.encode(text))
print(tokens)

 

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

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4",
    "input": [
      {
        "role": "user",
        "content": [
          { "type": "text", "text": "Here is my Docker Compose file..." }
        ]
      }
    ],
    "max_output_tokens": 0
  }'

 

У відповідь ви отримаєте блок usage, наприклад:

{
  "usage": {
    "input_tokens": 523,
    "output_tokens": 0,
    "total_tokens": 523
  }
}

Це і є фактичний підрахунок токенів з урахуванням моделі та структури запиту.

 

 

 

 

Витрата токенів

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

В API для моделей окремо вказується контекстне вікно та максимальний розмір output. Це важлива відмінність, оскільки навіть якщо модель підтримує великий контекст, це не означає, що вона завжди зможе згенерувати нескінченно довгу відповідь. Максимальний вивід, на жаль, теж обмежений.

Якщо ви використовуєте API, то обов'язково обмежуйте довжину відповіді параметрами виводу та заздалегідь проектуйте логіку обробки великих даних. Якщо ж ви використовуєте CLI-інструмент, то додайте розбиття великих запитів на частини, а також попереднє підсумовування та зберігання проміжних результатів.

Орієнтовна витрата токенів сильно залежить від типу даних. Наприклад, 100 рядків bash-коду зазвичай дають середнє навантаження на контекст. Файли Docker Compose також знаходяться в діапазоні від середньої до високої витрати, але тут все залежить від їх розміру та структури. Логи journalctl найчастіше створюють досить високу витрату токенів, особливо якщо містять довгі stack trace. YAML-файли Kubernetes також можуть давати як середнє, так і високе навантаження, залежно від кількості ресурсів та їх вкладеності. Окремо варто враховувати JSON-відповіді API, оскільки вони часто займають більше токенів, ніж здається візуально, через структуру та повторювані ключі. Звичайно, ці оцінки не є точними цифрами, оскільки їхнє основне завдання - допомогти зрозуміти, які типи даних найшвидше роздувають контекст.

 

 

 

 

Обмеження швидкості за IP, сеансом або ключем API

Якщо ви використовуєте будь-який інструмент на базі OpenAI API, то вам необхідно враховувати rate limits. В офіційній документації OpenAI API ліміти вимірюються через RPM - requests per minute, RPD - requests per day, TPM - tokens per minute, TPD - tokens per day та IPM - images per minute. Ліміт може бути досягнутий за будь-яким із цих параметрів, залежно від того, що закінчиться раніше.

Це означає, що можна натрапити на обмеження не тільки за кількістю запитів, але й за кількістю токенів. Наприклад, кілька дуже великих запитів можуть значно швидше вичерпати TPM, ніж сотні маленьких запитів.

Але не варто намагатися обійти обмеження зміною ключів, акаунтів або IP-адрес, оскільки це може порушувати умови використання. Крім того, веб-інтерфейс ChatGPT та OpenAI API мають різні обмеження і, наприклад, якщо ліміт спрацював у веб-версії ChatGPT, то це не обов'язково означає, що API-ключ теж обмежений, і навпаки.

 

Типові помилки при роботі з rate limit

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

• Агресивні повторні запити без затримки;
• Використання одного API-ключа для великої кількості користувачів;
• Відсутність черги завдань;
• Відсутність кешування повторюваних відповідей;
• Відправка великих логів без попередньої фільтрації;
• Повторна відправка одного й того ж запиту після помилки 429;

 

Навіть найпростіша ідея з використанням retry з поступовим збільшенням затримки вже може допомогти. Ну а в production-коді краще взагалі використовувати exponential backoff з jitter, щоб кілька процесів не повторювали запити одночасно.

 

 

 

 

 

Реальні приклади оптимізації запитів

Якщо ви досвідчений користувач або використовуєте ChatGPT як частину свого DevOps-інструменту, то краще відразу проектувати його роботу з урахуванням лімітів. Наприклад, при роботі з об'ємними логами не варто надсилати повний journalctl або весь лог додатка за добу. Спочатку спробуйте максимально звузити вибірку, наприклад так:

journalctl -u nginx --since "1 hour ago" --no-pager

Або так:

tail -n 200 /var/log/nginx/error.log

 

А якщо лог великий, тоді спочатку виділіть конкретно помилки:

grep -i "error" /var/log/nginx/error.log | tail -n 100

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

 

При роботі з кодом, звичайно, не варто вставляти весь проєкт, а замість цього краще надіслати:

• проблемний файл;
• текст помилки;
• команду, після якої з’явилася помилка;
• очікуване поведінку;
• фактичну поведінку.

Це загальне правило для будь-якого рефакторингу - завжди краще йти по частинах, виправляти один модуль, один сервіс, один контролер, один Dockerfile.

 

І таких прикладів можна наводити скільки завгодно, але всі ці приклади можна спробувати звести в невеликий звід загальних рекомендованих практик при роботі з ChatGPT, щоб не впиратися в ліміти або хоча б істотно підвищити продуктивність своєї роботи:

• Перевіряйте розмір запиту перед відправкою;
• Намагайтеся розбивати великі документи на логічні частини;
• Обов'язково кешуйте часто використовувані підказки та відповіді;
• Не надсилайте повну історію чату, якщо вона не потрібна - працюйте з короткими блоками;
• Після отримання помилки 429 обов'язково використовуйте затримку, а не робіть миттєве повторення;
• Видаляйте шум - старі логи, нерелевантні YAML-блоки, повторювані stack trace тощо;

 

 

 

 

 

Часті запитання (FAQ)

Чому ChatGPT обриває відповідь?

Зазвичай це пов'язано з лімітом виводу, лімітом контексту, поточними обмеженнями обраної моделі або особливостями інтерфейсу. В API для моделей окремо вказується максимальний output, тому довгі відповіді теж мають межу.

 

Що робити при помилці 429?

Помилка 429 зазвичай означає перевищення rate limit. Потрібно зменшити частоту запитів, скоротити розмір запитів, додати retry з backoff і перевірити ліміти проєкту або організації в OpenAI API.

 

Чи можна збільшити ліміти?

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

 

Скільки токенів вміщується в одне повідомлення?

Єдиної відповіді немає. Розмір контексту залежить від моделі та середовища використання. В API це потрібно перевіряти на актуальній сторінці моделей OpenAI, де вказані context window та max output.

 

Чому один і той самий запит іноді працює, а іноді ні?

Причина може бути в поточному ліміті, розмірі історії діалогу, обраній моделі, активності інструментів або rate limits. У ChatGPT та API обмеження працюють по-різному.

 

Чи можна надсилати в ChatGPT великі файли?

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

 

 

 

 

Висновок

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

Ставтеся до ChatGPT як до потужного інструменту з реальними лімітами, а не як до нескінченного оракула. Поважайте бюджет токенів, не надсилайте зайвий контекст, не спамте повторними запитами і не очікуйте, що модель за один раз розбере всю кодову базу, весь DevOps pipeline і всі логи за тиждень.

І навіть не думайте завантажувати в нього всю конфігурацію вашого Kubernetes-кластера без попередньої фільтрації - це не закінчиться нічим хорошим.

А якщо вам знадобиться VPS-сервер для свого проєкту або тестування роботи OpenAI API, тоді ви вже за адресою :)