Приоритетная обработка (priority)готовится

Обычные запросы к /v1/chat/completions обслуживаются в общей очереди. Когда мощности заняты, запрос ждёт свободного слота, и время до первого токена растёт.

Приоритетная обработка ставит ваш запрос в отдельную очередь, которая разбирается раньше общей. Вы платите двойную ставку и получаете более предсказуемое время ответа под нагрузкой.

Приоритет влияет только на очередь. Модель, качество ответа, размер контекста (1 млн токенов) и лимит max_tokens (до 32 000) остаются теми же.

Рассматриваются два способа включения приоритета — они не противоречат друг другу, поэтому описаны оба.

Способ 1 — признак в теле запроса. К обычному запросу добавляется поле service_tier со значением "priority" (значение по умолчанию — "default", для пакетной обработки — "batch").

curl https://api.librachat.kz/v1/chat/completions \
  -H "Authorization: Bearer sk-libra-…" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "libra-pro",
    "service_tier": "priority",
    "messages": [
      {"role": "user", "content": "Коротко: что такое приоритетная очередь?"}
    ]
  }'

Ответ повторяет обычный формат, но содержит подтверждение фактически применённого класса обслуживания. Ориентируйтесь именно на него: если приоритет по какой-то причине не был применён, вы увидите это в ответе и не заплатите вдвое.

{
  "id": "chatcmpl-…",
  "object": "chat.completion",
  "model": "libra-pro",
  "service_tier": "priority",
  "choices": [ … ],
  "usage": {
    "prompt_tokens": 812,
    "completion_tokens": 240,
    "total_tokens": 1052
  }
}

Способ 2 — отдельный ключ. Вы выпускаете ключ с признаком приоритета, и все запросы этим ключом идут в быструю очередь без изменения тела запроса. Это удобно, когда фронтенд и фоновый обработчик — разные сервисы: каждому даёте свой ключ и ничего не правите в коде. Ограничение «до 10 ключей на аккаунт» остаётся общим, приоритетные ключи считаются в тот же лимит (409 too_many_keys при превышении).

Планируемое правило совмещения: если запрос приоритетным ключом пришёл с service_tier "default" или "batch", выигрывает значение из тела запроса. Так один и тот же ключ можно временно вернуть в обычную очередь.

Приоритетная обработка удваивает ставки. Пакетная обработка, наоборот, даёт −20%. Ниже — сравнение по текстовым моделям, за 1 млн токенов.

Удвоение планируется применять ко всем тарифицируемым позициям, а не только к тексту. Для нетокенных позиций ставки выглядят так.

Хранение (файлы 6,75 ₽ / ГиБ в сутки, коллекции 27 ₽ / ГиБ в сутки, скачивание 54 ₽ / ГиБ) от приоритета не зависит: это не обработка запроса, множитель к нему не применяется.

Списание идёт с общего предоплаченного баланса аккаунта в токенах. Пополнение — от 1 млн токенов по 450 ₽ за 1 млн. Приоритетные запросы просто расходуют баланс вдвое быстрее; отдельного кошелька под приоритет не планируется. Каждая операция должна попадать в журнал с пометкой класса обслуживания, чтобы двойное списание было видно и объяснимо.

Приоритет нужен там, где ответа ждёт живой человек и задержка видна глазом.

• Чат в интерфейсе продукта: пользователь смотрит на курсор и ждёт первых токенов.
• Голосовой диалог: пауза дольше секунды ломает разговор.
• Автодополнение и подсказки по ходу набора текста.
• Ответ бота в мессенджере, где сообщение уже отправлено и человек ждёт.
• Пиковые часы и рекламные всплески трафика, когда общая очередь длиннее обычного.
• Демонстрации и презентации, где важна не средняя скорость, а отсутствие провалов.

Приоритет не нужен там, где никто не ждёт у экрана. Переплата вдвое в этих сценариях не даёт ничего.

• Ночная переработка накопленных данных, отчёты, пересчёты.
• Массовая разметка, классификация, извлечение полей из архива документов.
• Индексация коллекций и подготовка данных для поиска.
• Прогрев кеша и генерация контента впрок.
• Повторные попытки упавших фоновых задач.
• Оффлайн-тесты и прогоны на эталонных наборах.

Для второй группы выгоднее пакетная обработка: −20% к ставкам вместо +100%. Разница между приоритетом и пакетом — 2,5 раза по деньгам, и на большом объёме это основная статья счёта.

Практичная схема: два ключа. Один приоритетный — для фронтенда и голоса. Один обычный или пакетный — для всего фонового. Тогда решение о цене принимается один раз при выпуске ключа, а не в каждом месте кода.

Лимиты на ключ остаются прежними: 120 запросов в минуту и 1 000 000 токенов в минуту. Планируется, что приоритет не поднимает эти пороги — при превышении вы получите 429 rate_limited так же, как на обычном ключе. Приоритет сокращает ожидание внутри очереди, а не расширяет вашу квоту.

Приоритет не ускоряет саму генерацию: скорость выдачи токенов после старта та же. Экономия — на времени до первого токена.

Приоритет не является гарантией времени ответа — конкретных цифр по задержке мы не обещаем.