Що таке LLM Latency Cost Calculator?
▾
Калькулятор вартості затримки LLM допомагає розробникам кількісно визначити приховану вартість часу відповіді в додатках ШІ шляхом моделювання часу до першого токена (TTFT), пропускної здатності токенів за секунду та загального часу відповіді для різних моделей і конфігурацій. Хоча більшість дискусій щодо витрат зосереджені на ціноутворенні токенів, затримка має свій власний економічний вплив: повільніші відповіді збільшують відмову користувачів, зменшують пропускну здатність і погіршують сприйману якість функцій на базі ШІ. Час затримки значно відрізняється залежно від моделі та постачальника. GPT-4o зазвичай забезпечує час до першого токена за 200–500 мілісекунд і генерує від 80 до 120 токенів за секунду. GPT-4o-mini працює швидше: від 100 до 300 мс TTFT і від 100 до 150 токенів за секунду. Claude Sonnet 4 варіюється від 300 до 700 мс TTFT із 70 до 100 маркерів на секунду. Ці відмінності означають, що відповідь із 500 токенів займає від 3 до 7 секунд залежно від вибору моделі, що безпосередньо впливає на взаємодію з користувачем і дизайн програми. Цей калькулятор моделює загальну вартість затримки, включно з прямими витратами на API, інфраструктурними витратами на утримання відкритих з’єднань, коефіцієнтами відключення користувачів, пов’язаними з часом відповіді, і наслідками пропускної здатності повільніших моделей, які потребують більшої кількості одночасних з’єднань для обслуговування того самого обсягу запитів. Для додатків у реальному часі, таких як чат-боти та пошук, оптимізація затримки може мати такий же вплив, як і оптимізація вартості токенів для загальної економіки системи.
DigiCalcs delivers precision-engineered tools for engineers and STEM professionals.
Формула
▾
Загальний час відповіді = час до першого токена + (вихідні токени / токени за секунду). Ефективна ціна за запит = вартість токена API + (Час відповіді / 3600) х вартість з’єднання з сервером за годину + ймовірність відключення х втрачений прибуток на користувача. Наприклад: 400 мс TTFT + 300 жетонів при 100 ток/с = 400 мс + 3000 мс = 3,4 секунди загальний час відповіді.Опис змінних
▾
| Символ | Ім'я | Одиниця | Опис |
|---|---|---|---|
| TTFT | Час до першого жетона | milliseconds | Затримка між надсиланням запиту API та отриманням першого маркера відповіді, яка представляє мінімальну очікувану затримку. |
| TPS | Токенів за секунду | tokens per second | Швидкість генерації після першого маркера, що визначає, як швидко виробляється повна відповідь, як правило, від 80 до 150 для стандартних моделей. |
| T_out | Підрахунок вихідних маркерів | tokens | Кількість токенів у відповіді моделі, помножена на швидкість генерації, визначає тривалість потокового передавання після TTFT. |
| D | Швидкість висадки | ratio per second of latency | Приблизний відсоток користувачів, які припиняють взаємодію за додаткову секунду часу відповіді, зазвичай становить від 5 до 15 відсотків за секунду понад 3-секундне порогове значення. |
| V_user | Вартість на втраченого користувача | USD | Приблизний втрачений дохід або цінність клієнта, коли користувач відмовляється від взаємодії ШІ через надмірну затримку. |
Як LLM Latency Cost Calculator
▾
- 1Виміряйте або оцініть час до першого токена (TTFT) для вибраної моделі та конфігурації. TTFT — це затримка між надсиланням запиту API та отриманням першого маркера відповіді. Це залежить від складності моделі, довжини підказки введення, завантаження сервера та географічної відстані до кінцевої точки API. GPT-4o TTFT коливається від 200 до 500 мс, тоді як моделі міркувань, такі як o1, можуть займати від 2 до 10 секунд для початкової фази мислення.
- 2Визначте швидкість генерації токенів за секунду для вашої моделі. Це швидкість, з якою модель створює вихідні маркери після надходження першого маркера. Стандартні моделі генерують від 80 до 150 токенів за секунду. Довші виходи займають пропорційно більше часу: відповідь із 500 токенів зі швидкістю 100 токенів на секунду займає 5 секунд після TTFT. Потокова передача відповіді користувачам зменшує очікувану затримку, показуючи маркери, коли вони надходять.
- 3Обчисліть загальний час відповіді для вашої типової довжини виводу. Для чат-бота з відповідями з 200 токенів на GPT-4o: TTFT (350 мс) + генерація (200 токенів / 100 ток/с = 2000 мс) = загалом 2,35 секунди. Для функції генерації вмісту з виведенням 1000 токенів: TTFT (350 мс) + генерація (10 000 мс) = 10,35 секунди. Ці проміжки часу визначають, чи буде функція чуйною чи повільною для користувачів.
- 4Змоделюйте вплив затримки на взаємодію з користувачем. Дослідження показують, що задоволеність користувачів значно падає після 3-секундного часу відповіді. Для чат-ботів відповіді протягом 5 секунд змушують від 20 до 30 відсотків користувачів припиняти розмову. Для функцій пошуку результати, які займають понад 2 секунди, мають на 10–15 відсотків нижчу залученість. Калькулятор призначає вартість цієї втраченої взаємодії в доларах на основі ваших коефіцієнтів конверсії та загальної цінності користувача.
- 5Розрахувати пропускну спроможність і її вартість. Сервер, який обробляє потокові відповіді, повинен утримувати з’єднання відкритими протягом повної тривалості відповіді. Якщо кожна відповідь займає 5 секунд, один серверний потік обробляє 12 запитів на хвилину. Перехід на швидшу модель, яка відповідає за 2 секунди, збільшує пропускну здатність до 30 запитів на хвилину, що вимагає на 60 відсотків менше ресурсів сервера для того самого трафіку. Ця економія інфраструктури може перевищувати різницю у вартості API між моделями.
- 6Порівняйте загальну вартість усіх варіантів моделі, включно з ціною токенів і витратами на затримку. Дешевша модель за токен, яка є повільнішою, насправді може коштувати дорожче з урахуванням інфраструктури, вилучення користувачів і обмежень пропускної здатності. Калькулятор виводить загальне економічне порівняння, яке включає вартість API, вартість сервера та прогнозований вплив затримки на дохід.
- 7Оптимізуйте затримку за допомогою змін конфігурації. Зменшення лімітів вихідних токенів за допомогою max_tokens, використання потокової передачі для покращення сприйняття сприйняття, впровадження швидкого кешування для зменшення TTFT і вибір географічно ближчих кінцевих точок API можуть зменшити затримку на 20-50 відсотків без зміни моделей. Калькулятор моделює вплив кожної оптимізації на витрати.
Розв'язані приклади
▾
Для чат-бота, націленого на 3-секундні відповіді, обидва GPT-4o та GPT-4o-mini відповідають порогу, тоді як Claude Sonnet 4 є межею. GPT-4o-mini на 28 відсотків швидший за GPT-4o та на 94 відсотки дешевший, що робить його оптимальним вибором для більшості додатків чат-ботів.
Кожна генерація 1000 токенів займає 10,4 секунди. Щоб обслуговувати 50 одночасних користувачів, вам потрібно приблизно 9 серверних потоків, які утримують з’єднання відкритими. При розмірі 5 доларів США на годину для серверної інфраструктури вартість пропускної здатності додає 0,0024 доларів США за запит до вартості токена API.
Після 200 мс для пошуку та 150 мс TTFT залишається 1450 мс для генерації маркера. При 130 жетонах на секунду максимальний вихід становить 188 жетонів. Якщо для функції потрібні довші відповіді, потрібно або збільшити бюджет затримки, або потрібна швидша модель або скорочений час отримання.
Практичне застосування
▾
Пошукові системи з генерацією відповідей на основі штучного інтелекту повинні надавати результати протягом 2-3 секунд, щоб відповідати очікуванням користувачів, встановленим традиційним пошуком. Пошукова платформа, яка використовує GPT-4o для синтезу відповідей, витрачає 500 мс на пошук і 2000 мс на генерацію LLM. При швидкості 100 токенів на секунду вони можуть генерувати приблизно 170 токенів (приблизно 130 слів) у межах бюджету затримки. Це обмеження визначає максимальну довжину відповіді та обумовлює вибір найшвидшої доступної моделі.
Служби перекладу в режимі реального часу повинні мінімізувати затримку для розмовного потоку. Функція прямого перекладу за допомогою GPT-4o-mini досягає 150 мс TTFT і 130 токенів на секунду, перекладаючи речення з 50 слів (приблизно 80 токенів) за 0,77 секунди. Ця субсекундна затримка забезпечує природний темп розмови. Замість цього використання GPT-4o додасть 200 мс TTFT і зменшить пропускну здатність, створюючи помітні паузи, які переривають потік розмови.
Платформи для трейдингу та фінансового аналізу використовують LLM для коментарів ринку в реальному часі та створення сповіщень. Затримка безпосередньо впливає на цінність інформації, що рухається на ринку. Фінансова платформа, яка використовує GPT-4o-mini для сповіщень про ринок із 100 токенами, забезпечує доставку менш ніж за 1 секунду, що відповідає вимогам щодо чутливої до часу фінансової інформації. Платформа направляє довші аналітичні фрагменти до GPT-4o у фоновому режимі, де затримка менш критична.
Голосові помічники та програми штучного інтелекту з підтримкою голосу мають жорсткі бюджети затримки, оскільки користувачі очікують миттєвої вербальної відповіді. Загальний конвеєр від мовлення до тексту (300–500 мс) до генерації LLM до перетворення тексту до мовлення (200–400 мс) має завершитися протягом 2–3 секунд. Це залишає лише 1–2 секунди для генерації LLM, що обмежує вибір моделі та тривалість відповіді. Багато голосових програм використовують GPT-4o-mini або Claude Haiku спеціально для швидшого TTFT.
Особливі випадки
▾
Для таких моделей міркування, як o1 і o3, TTFT включає розширене мислення
Для таких моделей міркування, як o1 і o3, TTFT включає розширену фазу мислення, яка може тривати від 2 до 30 секунд залежно від складності проблеми. Цей час на обдумування оплачується за ставкою вихідного маркера, але не відображається у потоковій відповіді. Запит, який створює 200 видимих токенів виводу, міг би споживати від 2000 до 5000 токенів мислення, створюючи як штраф за затримку, так і прихований множник витрат. Моделі міркування слід використовувати лише для завдань, де час на обдумування дає вимірно кращі результати.
Під час розгортання LLM за глобальним шлюзом CDN або API додані стрибки мережі
Під час розгортання LLM за глобальним шлюзом CDN або API додані мережеві переходи створюють від 10 до 50 мс додаткової затримки на запит. Незважаючи на те, що окремі витрати невеликі, ці накладні витрати виникають у додатках агентів, які здійснюють від 5 до 15 послідовних викликів LLM. Конвеєр агента з 10 послідовними викликами накопичує від 100 до 500 мс накладних витрат на шлюз. Для додатків агента, чутливих до затримки, мінімізуйте мережеві стрибки між оркеструвальником і кінцевою точкою API LLM.
Виклик функцій і використання інструментів додають затримку, оскільки модель має генерувати
Виклик функцій і використання інструментів додають затримку, оскільки модель має генерувати структурований вихід JSON (який є повільнішим, ніж природна мова), а потім чекати результату інструмента, перш ніж продовжити. Кожен зворотний виклик інструменту додає повний TTFT плюс час виконання інструменту. Агент, який здійснює 3 виклики інструментів, додає приблизно від 1 до 3 секунд затримки LLM плюс час відповіді зовнішнього інструменту. Розробляйте інтерфейси інструментів, щоб мінімізувати зворотні переходи шляхом групування кількох запитів в один виклик інструменту, де це можливо.
Контрольні показники затримки LLM (2025 середніх значень)
▾
| Модель | TTFT (медіана) | Жетони/секунда | Відповідь на 200 токенів | Відповідь 500 токенів |
|---|---|---|---|---|
| GPT-4o | 350 мс | 100 ток/с | 2,35 с | 5,35 с |
| GPT-4o-mini | 150 мс | 130 ток/с | 1,69с | 4.00с |
| Клод Сонет 4 | 500 мс | 80 ток/с | 3.00с | 6,75 с |
| Клод Хайку | 200 мс | 120 ток/с | 1,87с | 4,37с |
| Gemini 1.5 Flash | 200 мс | 140 ток/с | 1,63с | 3,77с |
| o1 (міркування) | 3000 мс | 50 ток/с | 7.00с | 13.00с |
| Лама 3 70B (H100) | 100 мс | 90 ток/с | 2,32с | 5,66с |
Часті запитання
▾
Який LLM має найнижчу затримку?
Серед основних комерційних моделей GPT-4o-mini стабільно забезпечує найнижчу затримку з 100–200 мс TTFT і 120–150 токенів на секунду. Клод Хайку такий же швидкий. Серед флагманських моделей GPT-4o трохи швидший за Claude Sonnet 4. Моделі міркувань, такі як o1, значно повільніші з TTFT від 2 до 10 секунд через внутрішнє мислення. Власні моделі на графічних процесорах H100 можуть досягати TTFT менше 100 мс, але вимагають значних інвестицій в інфраструктуру.
Як тривалість запиту впливає на затримку?
Довші підказки введення збільшують TTFT, оскільки модель повинна обробити всі вхідні маркери перед генерацією першого вихідного маркера. Обробка 1000 маркерів введення зазвичай додає від 100 до 300 мс порівняно з мінімальною підказкою. Обробка 10 000 вхідних токенів може додати від 500 до 1500 мс. Ось чому додатки RAG із великим отриманим контекстом мають вищу затримку, ніж проста взаємодія чат-бота. Кешування підказок (доступне від Anthropic) усуває час обробки для повторюваних префіксів підказок.
Чи слід використовувати потокове передавання для всіх викликів API?
Потокове передавання слід використовувати для будь-якої відповіді користувача, для створення якої потрібно більше 1 секунди. Для програмних викликів API, де вихід обробляється кодом, а не відображається користувачам, непотокова передача є простішою та має незначну перевагу затримки. Потокове передавання мінімально ускладнює код у більшості SDK і підтримується всіма основними постачальниками без додаткової плати. Відчутне покращення затримки від потокового передавання є суттєвим: 10-секундна відповідь виглядає як 1 секунда під час потокового передавання.
Як зменшити TTFT для моєї програми?
Ключові оптимізації TTFT включають: використання швидкого кешування, щоб пропустити обробку повторюваних префіксів запитів (заощаджує від 200 до 500 мс), вибір географічно ближчих кінцевих точок API (зберігає від 50 до 200 мс мережі в обидві сторони), зменшення тривалості підказки для введення (зберігає від 100 до 500 мс) і використання швидших моделей, таких як GPT-4o-mini (збереження). від 100 до 300 мс проти GPT-4o). Для моделей, які розміщено на власному хості, прискорене GPU виведення з оптимізованими платформами обслуговування, такими як vLLM, може досягти TTFT менше 100 мс.
Яка прийнятна затримка для різних типів програм?
Пошук і автозаповнення: менше 500 мс. Відповіді чат-бота: менше 3 секунд (з потоковою передачею). Генерація контенту: менше 10 секунд (з індикатором прогресу трансляції). Пакетна обробка: від хвилин до годин (без затримки). Голосові помічники: загальна тривалість конвеєра менше 2 секунд. Завершення коду: менше 500 мс для вбудованих пропозицій. Ці порогові значення базуються на дослідженні взаємодії з користувачем і конкурентних тестах.
Поширені помилки
▾
- !Оптимізація лише для вартості маркерів без урахування впливу затримки:
- !Не використовується потокове передавання для довгих відповідей:
- !Ігнорування дисперсії TTFT і затримки P99:
Порада профі
Застосуйте бюджет затримки для всього конвеєра запитів і розподіліть його між компонентами. Для 3-секундного бюджету чат-бота: 200 мс для мережі та попередньої обробки, 200 мс для отримання RAG, 300 мс для TTFT і 2300 мс для генерації токенів (дозволяє приблизно 300 токенів зі швидкістю 130 ток/с на GPT-4o-mini). Такий бюджетний підхід запобігає споживанню окремих компонентів більше, ніж їхня частка, і підкреслює, коли компонент потребує оптимізації або потрібна швидша модель.
Чи знаєте ви?
Людська розмова по черзі має природний проміжок близько 200 мілісекунд між тим, як одна особа закінчує, а інша починає говорити. Коли час відповіді чат-бота штучного інтелекту перевищує 3 секунди, користувачі несвідомо приймають розумову модель «веб-пошуку» замість розумової моделі «розмови», стаючи менш залученими та, швидше за все, відмовляться від неї. Досягнення відповідей менш ніж за 2 секунди зберігає у користувачів розмовний настрій, підвищуючи показники взаємодії та задоволеності на 25–40 відсотків.
Regional Guides
▾
North America▾
Europe▾
Asia-Pacific▾
Джерела
Отримуйте щотижневі поради з математики
Приєднуйтеся до 12 000+ підписників, які щотижня отримують поради щодо калькулятора.