Підсумок
- Потокові відповіді вимагають надійного парсингу SSE для обробки неповних фрагментів та даних про використання останніх токенів.
- Помилки режиму JSON зазвичай виникають через те, що модель генерує текст після об'єкта JSON, що виходить за межі суворої схеми.
- Контекстне вікно 100k спільне для запиту та завершення, тому довгі виводи зменшують доступний простір вводу.
- Оцінка вартості має враховувати вищу ціну вихідних токенів порівняно з входними.
Чому ваша потокова відповідь зависає
Потокова передача відповідей зависає, коли клієнт не зчитує останній фрагмент Server-Sent Events (SSE), що містить дані про використання токенів. Наш API потоково передає токени по мірі їх генерації, але з'єднання повністю закривається лише після надходження останнього фрагмента. Якщо код вашого клієнта розриває з'єднання рано або ігнорує останній фрагмент, ви втрачаєте точні кількості токенів, необхідні для перевірки білінгу.
Прочитайте кожен чанк до завершення потоку. Не припускайте, що останній чанк містить лише останній токен. Останній чанк у нашому SSE-потоці включає usage поле з загальною кількістю вхідних і вихідних токенів. Якщо ви відкинете ці дані, ви не зможете точно відстежувати споживання вашого передоплаченого кредиту.
Поширені пастки
- Ігнорування фінального події SSE.
- Тайм-аути встановлено занадто низько для довгих завершень.
- Не обробляє частковий JSON у режимі потокового передавання.
Завжди споживайте весь потік, щоб сервер знав, що клієнт отримав повну відповідь. Це запобігає виток ресурсів на нашому боці та гарантує наявність даних, необхідних для ваших власних журналів.
Вирішення помилок режиму JSON у продакшені
Помилки режиму JSON виникають, тому що модель може генерувати текст після закриваючої дужки, порушуючи суворі правила парсингу JSON. Коли ви встановлюєте response_format до {"type": "json_object", модель намагається вивести дійсний JSON, але часто додає розмовні вставки, такі як 'Ось дані:', після закриваючої дужки. Ваш парсер потім видає помилку через зайвий текст.
Видаліть текст після останньої коректної закриваючої фігурної дужки. Не покладайтеся на модель, щоб вона зупинилася рівно в кінці структури JSON. Ви повинні реалізувати крок постобробки, щоб знайти останній символ '}' або ']' і відкинути все, що йде після нього. Це критично важливо при парсингу масивів або вкладених об'єктів.
Найкращі практики
- Використовуйте регулярний вираз (regex) для виділення останнього валідного блоку JSON.
- Перевіряйте витягнутий рядок за допомогою парсера JSON.
- Повторіть спробу з нижчою температурою, якщо вивід хаотичний.
Цей підхід забезпечує стабільність вашого виробничого конвеєра навіть тоді, коли модель вирішує бути допитливою. Uncensored моделі менш обмежені, тому вони можуть відчувати себе більш «творчими» у своєму форматуванні.
Розуміння лімітів вікна контексту
Ліміт контекстного вікна становить 100,000 токенів для поєднаного промпта та завершення. Це означає, що якщо ваш вхідний обсяг становить 50,000 токенів, ви можете згенерувати лише до 50,000 токенів, перш ніж досягнете ліміту. Ліміт стосується не лише вхідних даних; це спільний бюджет для всього запиту.
Розрахуйте доступний простір для вихідних даних, віднявши кількість входних токенів від 100 000. Якщо ви надсилаєте великий системний запит або довгу історію повідомлень, ваш доступний простір для вихідних даних зменшується відповідно. Це критично важливо для додатків, які підтримують довгі історії розмов.
Приклад розрахунку
- Загальне вікно: 100 000 токенів.
- Вхідні токени: 20 000 токенів.
- Максимальний вихід: 80,000 токенів.
Якщо ви перевищите цей ліміт, API поверне помилку. Тщательно моніторьте використання токенів, щоб уникнути несподіваного обрізання відповіді моделі. Модель не обрізає автоматично; вона просто відхиляє запит, якщо загальна кількість перевищує вікно.
Підрахунок токенів та оцінка витрат
Оцінка вартості має враховувати різницю в ціні між входними та вихідними токенами. Вхідні токени коштують $0.15 за 1M токенів, тоді як вихідні — $0.50 за 1M токенів. Вихідні токени значно дорожчі, тому генерація довгих відповідей швидше збільшить ваші витрати, ніж надсилання довгих запитів.
Оцініть свої витрати, помноживши очікувану кількість токенів на відповідну ціну. Наприклад, 10 000 вхідних токенів і 5 000 вихідних токенів коштуватимуть: (10 000/1 000 000 * $0.15) + (5 000/1 000 000 * $0.50). Це дорівнює $0.0015 + $0.0025 = $0.004 за запит.
Цінова таблиця
| Тип токенів | Ціна за 1M токенів |
|---|---|
| Вхід | $0.15 |
| Вивід | $0.50 |
Відстежуйте своє використання через останній чанк SSE або відповідь API. Це гарантує, що ви зможете точно планувати бюджет для додатків з великим обсягом. Попередньо оплачений кредит не має строку дії, тому ви можете планувати витрати з часом без щомісячних платежів.
Лімітування частоти: пояснення 300 RPM
Лімітування обмежує ваші запити до 300 на хвилину на кожен API-ключ. Цей ліміт діє для всіх запитів, незалежно від розміру корисного навантаження або кількості токенів. Якщо ви перевищите цей ліміт, API поверне помилку 429. Ви повинні реалізувати експоненційне сповільнення для коректного оброблення цих помилок.
Моніторьте частоту запитів та регулюйте паралельність відповідно. Якщо ви використовуєте кілька потоків або процесів, переконайтеся, що вони використовують один API-ключ і разом не перевищують ліміт 300 запитів на хвилину. Перевищення цього ліміту призведе до тимчасових помилок до скидання ліміту.
Обробка помилок 429
- Реалізуйте експоненційне сповільнення.
- Логувати невдалі запити для аналізу.
- Зменшіть паралелізм, якщо обмеження виникають часто.
Наш API призначено для високого навантаження, але ліміт швидкості забезпечує справедливе використання для всіх клієнтів. Якщо вам потрібні вищі ліміти, ви можете згенерувати новий API-ключ, але зверніть увагу, що кожен обліковий запис обмежений одним активним ключем одночасно.
Вирішення невдач Function Calling
Збої виклику функцій виникають, коли визначення інструменту моделі не відповідає очікуваній схемі або коли модель не виводить дійсний JSON для аргументів інструменту. Переконайтеся, що ваші визначення інструментів є точними та містять усі обов'язкові параметри. Невизначені схеми призводять до пошкоджених викликів інструментів.
Перевіряйте аргументи інструмента перед виконанням функції. Модель може генерувати аргументи, у яких відсутні обов'язкові поля або містяться неправильні типи. Ваш клієнтський код повинен обробляти ці помилки, повторюючи запит із чіткішим промптом або коригуючи визначення інструмента.
Кроки налагодження
- Перевірте синтаксис визначення інструменту.
- Перевірте типи та значення аргументів.
- Огляд Вивід моделі на наявність відсутніх полів.
Виклик функцій — це потужна функція, але вона вимагає ретельного проектування схеми. Моделі без цензури можуть бути менш послідовними у визначеннях інструментів порівняно з їхніми відфільтрованими аналогами, тому суворе валідування є суттєвим.
Чому 'uncensored' не означає повної необмеженості
Мітка 'uncensored' означає, що модель не відмовляє в законних дорослих, художніх або дискусійних темах, але все ще має жорсткий ліміт на контент сексуального характеру з участю неповнолітніх. Це єдине жорстке обмеження контенту, яке завжди діє. Запити, що містять такий контент, будуть відхилені, навіть якщо решта промпту ідеально коректна.
Інші відмови можуть все ще виникати через технічні помилки або ліміти швидкості. Модель не є магічною; вона все ще може не згенерувати відповідь, якщо вхідні дані занадто складні або перевищено вікно контексту. Розумійте, що «uncensored» стосується політики контенту, а не технічної надійності.
Обмеження контенту
- Немає сексуального контенту з залученням неповнолітніх.
- Законний дорослий контент дозволено.
- Технічні помилки все ще можуть призводити до відмов.
Ця відмінність важлива для додатків, які повинні обробляти широкий спектр тем. Знання конкретного ліміту допомагає правильно спроектувати вашу логіку фільтрації.
Налагодження помилок 400 та 429
Помилки 400 вказують на проблему з самим запитом, наприклад, недійсний JSON, відсутність обов'язкових полів або перевищення ліміту тіла запиту в 8 МБ. Помилки 429 вказують на перевищення ліміту швидкості — 300 запитів на хвилину. Розрізнення цих помилок допомагає швидко виправити правильну проблему.
Для помилок 400 перевірте корисне навантаження запиту та схему. Для помилок 429 реалізуйте затримку та зменшіть одночасність. Якщо ви отримуєте помилку 400 із повідомленням про розмір тіла запиту, переконайтеся, що ви не надсилаєте занадто багато даних в одному запиті. Ліміт 8 МБ є суворим.
Коди помилок
| Код помилки | Значення |
|---|---|
| 400 | Неправильний запит |
| 429 | Ліміт частоти перевищено |
Логування цих помилок із їхнім контекстом (набір даних, мітка часу) значно полегшує налагодження. Використовуйте ці дані для оптимізації інтеграції та уникнення повторних невдач.
Наступні кроки для оптимізації Heretic LLM
Оптимізація починається з моніторингу використання токенів та рівня помилок. Використовуйте дані токенів з останнього чанка SSE для відстеження фактичного споживання. Порівняйте це з вашими оціненими витратами, щоб забезпечити точність. Налаштуйте стратегії паралелізму та обмеження швидкості на основі спостережуваних шаблонів використання.
Розгляньте використання нижчої температури для більш послідовного виводу JSON або виклику функцій. Якщо вам потрібні більш творчі відповіді, збільште температуру, але будьте готові до більшої кількості помилок парсингу. Експериментуйте з різними параметрами, щоб знайти правильний баланс для вашого сценарію використання.
Поради з оптимізації
- Уважно моніторьте використання токенів.
- Налаштуйте temperature для балансу між узгодженістю та креативністю.
- Реалізуйте надійну обробку помилок.
Почніть з безкоштовного пробного тесту, щоб перевірити інтеграцію. Це спосіб з мінімальним ризиком, щоб переконатися, що ваш клієнтський код правильно обробляє потокову передачу, JSON-режим та ліміти швидкості перед придбанням передоплаченого кредиту.
