Скільки насправді коштують токени LLM і як заплатити за їх меншу кількість

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

Лексема — це не слово

Моделі не читають символи чи слова. Вони зчитують маркери — фрагменти, створені кодувальником пари байтів, який під час навчання дізнався, які послідовності трапляються досить часто, щоб заслужити власний символ. Загальноприйняті англійські слова — це одна лексема. Рідкісні розколюються. Отже token є одним і tokenization дорівнює трьом, тоді як випадковий рядок, як x7Qp2 може коштувати п'ять.

Основні правила, які варто дотримуватися:

• Англійська проза: приблизно чотири символи на лексему, або приблизно 0,75 лексем на слово. Стаття з тисячі слів містить близько 1300 токенів.
• код: значно гірше. Відступи, знаки пунктуації та ідентифікатори верблюжого регістру – усі фрагменти. Зробіть бюджет ближче до трьох символів на токен і сприймайте мінімізований код як власну катастрофу — він погано токенізується саме тому, що він незвичний.
• Нелатинські шрифти: знову набагато гірше. Китайська, японська та корейська зазвичай розташовуються біля одного токена на один або два символи, тому той самий вміст японською мовою може коштувати в кілька разів більше, ніж англійська версія. Поміж ними стоять кирилиця та грецька.
• JSON: розділовий знак — справжні гроші. Кожна лапка, дужка, двокрапка та кома є принаймні частиною токена, а глибоко вкладені структури з довгими іменами ключів можуть витрачати більше на синтаксис, ніж на значення.

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

Вихід коштує в кілька разів більше, ніж вихід

Люди пропускають деталі ціноутворення: постачальники стягують плату окремо за токени, які ви надсилаєте, і токени, які генерує модель, і вихід зазвичай у чотири-вісім разів перевищує швидкість введення. Підказка з 10 000 токенів контексту та відповідь із 200 токенів домінує над введенням. Підказка з 500 токенами інструкцій, яка дає есе з 4000 токенів, переважає — значною мірою — на виході.

Це перевертає багато інстинктів оптимізації. Скорочення системної підказки з 900 до 600 токенів економить дуже мало, якщо модель пише довгі відповіді на кожен виклик. Якщо наказати моделі відповідати трьома реченнями замість трьох абзаців, це значно заощадить. Запитайте, на якій стороні транзакції насправді лежить ваше робоче навантаження, перш ніж оптимізувати неправильну.

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

Чат є квадратичним, і саме тут гинуть бюджети

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

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

Скорочення підказки перед її надсиланням

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

Ручні розрізи, які варто зробити перед цим:

1. Надсилайте уривки, а не файли. Модельна увага теж не безкоштовна; невідповідний контекст помітно погіршує відповіді, а також коштує грошей.
2. Зачищення журналів до несправної області. Десять тисяч рядків результату успішного запуску нічого не сприяють діагностиці.
3. Відкинути повторюваний шаблон. Ліцензійні заголовки, згенерований імпорт, однакова відмова від відповідальності для кожного запису.
4. Підсумуйте замість повторної відправки. У довгій розмові заміна розворотів з першого по п’ятнадцятий абзацом стану є найбільшою доступною економією.

Коли вхідні дані справді не підходять

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

Примітка щодо одиниць: токени не є байтами. The Лічильник байтів UTF-8 відповідає на інше запитання — скільки місця займає текст у дроті або в стовпці бази даних — і ці два числа різко розходяться для нелатинського тексту, де кількість байтів на символ зростає в той же час, коли кількість символів на маркер зменшується. Використовуйте байти для обмежень пам’яті та маркери для обмежень моделі та ніколи не замінюйте одне іншим.

Спрацьований приклад

Припустімо, ви відповідаєте на двадцять запитань на тлі тридцятисторінкового документа. Тридцять сторінок — це приблизно 15 000 слів, тобто приблизно 20 000 токенів. Наївно ви надсилаєте документ із кожним запитанням: 20 × 20 000 = 400 000 вхідних токенів плюс, можливо, 20 × 300 вихідних токенів.

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

І лічильник, і компресор повністю працюють у вашому браузері: підказка, яку ви визначаєте, не завантажується ніде для вимірювання.