У 2026 році на інференс (вивід результатів) припадає приблизно дві третини всіх обчислювальних ресурсів у сфері ШІ. Він обігнав тренування і став домінуючим навантаженням. Моделі навчають нечасто, а інференс — це перманентне навантаження. Один цикл тренування моделі на 70 мільярдів параметрів займає тижні на кластері з сотень відеокарт. Далі ця ж модель обробляє мільйони запитів на день, кожен з яких споживає ресурси GPU. У великих масштабах витрати на інференс суттєво перевищують витрати на навчання.
Це має принципове архітектурне значення, оскільки тренування та інференс мають різні вузькі місця. Тренування обмежене обчислювальними ресурсами: потрібна максимальна кількість терафлопсів для найшвидшого виконання кожного прямого та зворотного проходу (forward/backward pass).
Інференс при малих розмірах батча обмежений пропускною здатністю пам’яті: GPU більшу частину часу витрачає на вичитування вагових коефіцієнтів з відеопам’яті в обчислювальні блоки, а не на саме множення матриць. Nvidia L40S має у 5.6 раза меншу пропускну здатність пам’яті, ніж H200. Проте для моделі Llama 3.1 8B, яка обробляє 1–4 одночасних запити, вимоги до шини пам’яті (Memory Bandwidth) з боку батча мінімальні — обсяг вагових коефіцієнтів, що зчитується для генерації кожного токена, спокійно вкладається у можливості L40S. У результаті на таких малих навантаженнях обидва графічних процесори демонструють практично однакову продуктивність, оскільки їхні обчислювальні блоки простоюють в очікуванні даних, а не впираються в стелю пропускної здатності шини.
При великих батчах розрахунки змінюються. Коли виконується понад 64 одночасних запити, продуктивність перестає впиратися у швидкість пам’яті й починає напряму залежати від обчислювальних ресурсів GPU, роблячи показник TFLOPS ключовим фактором. У цьому режимі 1979 TFLOPS у FP8 у H200 (у щільному режимі dense, та до 3958 TFLOPS у режимі 2:4 sparsity) проти 733 TFLOPS у L40S забезпечують майже трикратну перевагу у продуктивності, дозволяючи H200 повністю розкрити потенціал свого обчислювального ядра.
Ще одне вузьке місце, специфічне саме для інференсу, — кэш ключ-значення (KV-кєш). Генерація йде авторегресійно (токен за токеном), і на кожному кроці модель змушена перечитувати весь попередній контекст. Щоб не перераховувати його заново, у відеопам’яті утримуються проміжні тензори уваги — «ключі» та «значення» (по парі на кожен токен).
Обсяг KV-кешу розраховується за формулою:
KV-кэш = 2 х кількість_шарів х ширина_KV х кількість_токенів х размір_батча х байт_на_елемент
Де двійка відповідає за K і V, ширина_KV — це добуток кількості KV-голів на їхню розмірність, а «байт на елемент» дорівнює 2 при FP16.
На практиці це дає наступні цифри:
- Llama-3-70B: потрібно 320 КБ на токен ($\sim 42\text{ ГБ}$ на контекст у 128K).
- Llama-3-8B: потрібно 128 КБ на токен ($\sim 16\text{ ГБ}$).
Важливий нюанс: менша модель — не завжди економніша. Розмір кешу залежить від архітектури шарів та типу уваги (Attention), а не від загальної кількості параметрів. У Llama-2-7B на класичному Multi-Head Attention (MHA) іде 512 КБ на токен — вчотирьох більше, ніж у 70B-моделі на Grouped Query Attention (GQA). Саме архітектура GQA зробила довгі контексти економічно доступними.
З цього випливають три практичні наслідки:
- Квантування вагових коефіцієнтів не зменшує кеш — за замовчуванням він залишається в FP16, і після агресивного стиснення вагових коефіцієнтів саме KV-кеш починає впиратися у стелю VRAM.
- Вікно задає ліміт: Ви платите за фактично згенеровані токени, але розмір вікна задає верхню межу, а кожен паралельний запит множить цей обсяг на розмір батча.
- Час читання напряму впливає на затримку (Latency): Під час фази декодингу GPU обмежений не обчисленнями, а швидкістю читання з пам’яті: щоб згенерувати один токен, потрібно вичитати весь кеш. При контексті в 128K це 42 ГБ даних — майже стільки ж, скільки важать самі квантовані вагові коефіцієнти моделі!
Порівняння поведінки карт під час роботи з моделлю 70B у 4-бітних вагових коефіцієнтах (вага займає 40ГБ VRAM):
| Карта | VRAM | Пропускна здатність | Вільно під кеш | Стеля контексту (сумарно) | Час читання KV на 1 токен (при 128K) |
|---|---|---|---|---|---|
| L40S | 48 ГБ | 864 ГБ/с | ~8 ГБ | ~26К токенів | ~ 49мc |
| H200 | 141 ГБ | 4,8 ТБ/с | ~101 ГБ | ~320К токенів | ~ 9мc |
| B200 | 192 ГБ | 8,0 ТБ/с | ~152 ГБ | ~480К токенів | ~ 5мc |
Як видно з таблиці, читання 42 ГБ кешу на L40S займає близько 49 мс проти 5 мс на B200. Тому для робочих навантажень із довгим контекстом (вікна понад 128 000 токенів) обсяг відеопамяті та швидкість шини стають критично важливими факторами, а управління KV-кешем перетворюється на окрему інженерну задачу.
Ключові показники ефективності GPU при інференсі
1. Токени в секунду (Пропускна здатність / Throughput)
Основний показник сумарної продуктивності — кількість вихідних токенів, що генеруються графічним процесором за секунду (ток/сек) при заданому розмірі батча (batch size).
З зростанням розміру батча пропускна здатність спочатку збільшується лінійно, поки не впирається в предел шини пам’яті GPU, а потім виходить на плато у міру насичення обчислювальних ядер (TFLOPS).
Важливо: Пропускну здатність завжди потрібно вимірювати при реально очікуваному розмірі батча в продакшені. Синтетичні тести при
batch=1(де все впирається в затримку пам’яті) абоbatch=512(де обчислення повністю насичені, але затримка відповіді неприйнятна для користувачів) дають викривлену картину.
2. Час до першого токена (TTFT / Time to First Token)
TTFT вимірює затримку від моменту відправки запиту до отримання користувачем найпершого згенерованого токена. Цей показник критично важливий для інтерактивних застосунків (чат-боти, Copilots, голосові асистенти), де користувач очікує миттєвого відгуку.
TTFT напряму залежить від швидкості фази попереднього заповнення (prefill phase): GPU зобов’язаний повністю вичитати й обробити весь вхідний промпт (вхідний контекст), перш ніж перейти до авторегресійної генерації. Пам’ять типу HBM3/HBM3e дає колосальну перевагу у TTFT порівняно з GDDR6, оскільки дозволяє миттєво завантажувати вагові коефіцієнти й обробляти довгий промпт. Графічні процесори H100 та H200 демонструють кратну перевагу за показником TTFT над L40S при однакових розмірах батча саме на фазі префілу.
3. Вартість за мільйон токенів (Cost per 1M Tokens)
Складений економічний показник, який дозволяє чесно порівняти між собою відеокарти з різною погодинною вартістю та продуктивністю. Він розраховується за формулою:частоксек
Примітка до фінансових розрахунків:
У наведених далі розрахунках та зведеній таблиці вказано середньоринкові ціни за оренду GPU в хмарних сервісах (On-Demand / Spot).
Спроби розрахувати чесну вартість мільйона токенів при власному володінні залізом (CAPEX) виявилися вкрай складною та практично глухий кут задачею для автора. При купівлі власних серверів доводиться закладати амортизацію, витрати на ЦОД (Colocation), електрику, охолодження, обслуговування, а головне — коефіцієнт простою/завантаження (Load Factor). Усі реальні підрахунки та моделі TCO показують: якщо ваше власне обладнання не завантажене корисною роботою на 90–95% у режимі 24/7, вартість мільйона токенів при власному володінні виявляється в рази вищою, ніж при гнучкій хмарній оренді.
Нижче представлена зведена таблиця зіставлення відеокарт, їхніх характеристик та фінансової ефективності:
| GPU | VRAM | Пропускна здатність пам’яті | FP8 TFLOPS | Ціна On-Demand / час | Оптимальний розмір моделі | Найкраще підходить для |
|---|---|---|---|---|---|---|
| L40S | 48 GB GDDR6 | 864 GB/s | 733 TFLOPS (dense) | $0.96 / год | 7B–13B | Економічно ефективний при помірному трафіку |
| H200 | 141 GB HBM3e | 4.8 TB/s | 1,979 TFLOPS (dense) | $4.80 / год | 70B–200B | Великомасштабні моделі, тривалий контекст |
| B200 | 192 GB HBM3e | 8.0 TB/s | 4,500 TFLOPS (dense) | $11.06 / год | 160B+ | Максимальна пропускна здатність |
Висновки: три карти, три задачі
L40S — робоча конячка для 7B–13B
Ada Lovelace, 48 ГБ GDDR6, 864 ГБ/с, 733 TFLOPS FP8. Ключова відмінність — це не HBM: пропускної здатності вистачає для моделей 7–13B при помірній паралельності, а грошей вона коштує помітно менше. Немає MIG і немає NVLink — одна карта, без масштабування, без тонкого поділу ресурсів.
За нашою формулою KV-кешу: у 70B у 4-бітних вагових коефіцієнтах (~40ГБ) на кеш залишається близько 8 ГБ, тобто приблизно 26 тисяч токенів контексту — довгий контекст сюди просто не поміщається.
- Обирати, якщо: 7B–13B у FP16 або до 34B у INT4, до $\sim 30$ одночасних запитів, пакетне та експериментальне навантаження, де передбачувана вартість години важливіша за пікову пропускну здатність.
- Не обирати, якщо: вікно більше за 32K на великій моделі або потрібен multi-GPU паралелізм.
H200 — великі моделі та довгий контекст
Той самий обчислювальний чіп Hopper, що й у H100, але 141 ГБ HBM3e та 4,8 ТБ/с: +76% пам’яті та +43% пропускної здатності. На Llama 2 70B це дає приблизно на 40% більше токенів на секунду, ніж H100.
Але вирішальна перевага не в швидкості, а в запасі під KV-кеш. 70B у FP8 займає ~70 ГБ вагових коефіцієнтів: на H200 під кеш залишається ~71ГБ, тобто семикратна різниця при однаковій моделі.
- Обирати, якщо: 70B у FP16 (140 ГБ — на H100 не влазить взагалі), вікна понад 128K, висока стійка паралельність, і TTFT із запасом кешу важливіші за найнижчу погодинну ставку.
B200 — максимум відеопам’яті та ставка на FP4
Blackwell, 192 ГБ HBM3e, 8,0 ТБ/с, 4500 TFLOPS FP8 та 9000 TFLOPS FP4 у щільному режимі (зі структурованою розрідженістю — вдвічі більше). За даними MLPerf v5.1 система з восьми B200 показує ~102 700 ток/сек на Llama 2 70B у FP4, що приблизно у 2,9 раза вище за зіставну конфігурацію на H200.
Головне ж — 192 ГБ VRAM: вони дозволяють тримати на одній карті щільні моделі 160–190B у FP8 або 70B з величезним запасом під контекст.
- Обирати, якщо: потрібна максимальна пропускна здатність на один GPU, навантаження перевірене під FP4, або потрібно більше ніж 141 ГБ відеопам’яті.
- Обмеження: FP4 вимагає перевірки якості на кожній конкретній задачі — це не «безкоштовне» прискорення; а дуже великі MoE (на кшталт Llama 4 Maverick на ~400B параметрів) усе одно вимагають паралелізму на кількох GPU, тому що ваги всіх експертів мають одночасно лежати у пам’яті.
Резюме
Ми віддаємо перевагу підходу «модель насамперед»: спочатку визначається модель і необхідне вікно контексту, потім за формулою KV-кешу рахується сумарний апетит — ваги плюс кеш з урахуванням батча — і тільки потім підбирається карта. Такий порядок майже завжди веде до менших витрат: різниця між H200 та B200 у ціні години суттєвіша, ніж різниця у швидкості на моделі, яка все одно чудово поміщається на L40S.
Підхід «GPU насамперед» — беремо максимум доступної пам’яті й підганяємо модель під неї — теж має право на життя. Він виправданий, коли залізо вже куплене або зарезервоване, коли навантаження завідомо зростатиме й хочеться запасу, або коли сервіс оптимізується під пікову пропускну здатність і додавання карти пізніше обходиться дорожче за простій. Але за замовчуванням він зазвичай призводить або до переплати за невикористовувану пам’ять, або, що гірше, до несподіваного стелі контексту на моделі, яка «нібито влізла».
