Часто Задаваемые Вопросы (FAQ)

Поддерживается ли кэширование токенов?

Нет, кэширование токенов не поддерживается, и на это есть две важные причины:

Особенности нашей архитектуры. Наш сервис работает через пул аккаунтов у нескольких провайдеров для обеспечения стабильности и низких цен. Из-за этого технически почти невозможно сопоставить ваши последовательные запросы с одним и тем же аккаунтом, что необходимо для корректной работы кэша.
Снижение качества и отсутствие выгоды. Вопреки распространенному мнению, кэширование токенов неэффективно и может навредить качеству ответов:
- Нарушение контекста: Нейросети генерируют каждый следующий токен на основе всей предыдущей последовательности. Попытка «подставить» кэшированные части из старых запросов нарушает эту логику, что ведет к несвязным, нелогичным или повторяющимся ответам.
- Отсутствие экономии: Тарификация API-запросов учитывает общее количество токенов, обработанных моделью, включая как входящие (input), так и сгенерированные (output) токены. Важно понимать, что кэширование не уменьшает объем контекста, который анализируется моделью для генерации ответа. Его основная функция — оптимизация стоимости за счет повторного использования уже обработанных входящих токенов. Это снижает итоговую цену запроса, однако эффект может быть менее значительным, чем ожидается. Основной вклад в стоимость вносят сгенерированные токены, поскольку их тарификация, как правило, выше. Кроме того, следует учитывать, что за использование кэша может взиматься отдельная плата, а срок его хранения ограничен.

Пример расчета кэша

Основные переменные

Для начала определим переменные, которые будем использовать в расчетах:

N — общее количество запросов за период жизни кэша.
P_hit — процент вхождения токенов (коэффициент кэширования). Это доля токенов в повторных запросах, которые уже есть в кэше. Выражается как число от 0 до 1 (например, 70% = 0.7).
T — среднее количество токенов в одном запросе.
C — базовая стоимость одного токена (полная стоимость).
C_cached — стоимость одного кэшированного токена. По условию, C_cached = C / 2.

Итоговая формула расчета экономии в процентах

Это самая простая и главная формула, которая отвечает на ваш вопрос. Она не зависит от абсолютной стоимости и количества токенов, что делает ее универсальной.

Экономия (%) = ( (N - 1) / N ) * ( P_hit / 2 ) * 100%

Расшифровка формулы:

(N - 1) / N: Этот множитель учитывает, что первый запрос всегда оплачивается по полной стоимости и не дает экономии. Экономия возможна только на последующих N - 1 запросах. Чем больше общее количество запросов N, тем ближе этот множитель к 1, и тем меньше влияние первого "дорогого" запроса на общую экономию.
P_hit / 2: Эта часть показывает среднюю скидку на один повторный запрос.
- P_hit — это доля токенов, которые мы удешевляем.
- / 2 — это размер скидки (50%, так как цена в 2 раза ниже).

Детальный расчет (Как мы пришли к этой формуле)

Чтобы понять логику, давайте рассчитаем полную стоимость в двух сценариях: с кэшем и без него.

Стоимость без кэширования (Baseline)

Здесь все просто: каждый из N запросов оплачивается по полной стоимости.

Стоимость_без_кэша = N * T * C

Стоимость с кэшированием

Здесь мы разделяем стоимость на две части:

Стоимость первого запроса (он всегда по полной цене).
Стоимость последующих N - 1 запросов (они используют кэш).

Стоимость 1-го запроса = T * C

Стоимость одного последующего запроса:

Часть токенов берется из кэша: T * P_hit. Их стоимость: (T * P_hit) * (C / 2).
Часть токенов новые (не из кэша): T * (1 - P_hit). Их стоимость: (T * (1 - P_hit)) * C.
Итого за один повторный запрос: (T * P_hit * C / 2) + (T * (1 - P_hit) * C)

Общая стоимость с кэшем: Стоимость_с_кэшем = (Стоимость 1-го запроса) + (N - 1) * (Стоимость одного последующего запроса) Стоимость_с_кэшем = (T * C) + (N - 1) * [ (T * P_hit * C / 2) + (T * (1 - P_hit) * C) ]

Расчет экономии

Абсолютная экономия (в деньгах): Экономия_абс = Стоимость_без_кэша - Стоимость_с_кэшем

Если упростить это выражение, мы получим элегантную формулу: Экономия_абс = (N - 1) * T * C * (P_hit / 2)

Процентная экономия: Экономия_% = (Экономия_абс / Стоимость_без_кэша) * 100% Экономия_% = ( (N - 1) * T * C * (P_hit / 2) ) / ( N * T * C ) * 100%

Сокращаем T и C: Экономия (%) = ( (N - 1) / N ) * ( P_hit / 2 ) * 100% Мы вернулись к нашей итоговой формуле.

Пример расчета

Предположим, у нас есть следующие данные:

Период жизни кэша: 1 час.
Количество запросов за этот час (N): 20 запросов.
Процент вхождения токенов (P_hit): 80% или 0.8.
Среднее кол-во токенов в запросе (T): 1500 токенов.
Базовая стоимость токена (C): $0.001.

1. Рассчитаем процент экономии (быстрый способ):

Экономия (%) = ( (20 - 1) / 20 ) * ( 0.8 / 2 ) * 100%
Экономия (%) = ( 19 / 20 ) * 0.4 * 100% Экономия (%) = 0.95 * 0.4 * 100% Экономия (%) = 38%

2. Проверим расчет через абсолютные значения (длинный способ):

Стоимость без кэша: 20 * 1500 * 0.001 = 30
Стоимость с кэшем:
- Цена 1-го запроса: 1500 * 0.001 = 1.50
- Цена одного из 19-ти последующих запросов:
  - Кэшированные токены: (1500 * 0.8) * (0.001/2) = $0.60
  - Новые токены: (1500 * 0.2) * 0.001 = $0.30
  - Итого за повторный запрос: 0.60+0.30 = $0.90
- Общая стоимость с кэшем: 1.5+19*0.90 = 1.5+17.10 = $18.60
Абсолютная экономия: 30 - 18.60 = $11.40
Процентная экономия: (11.4/30) * 100% = 38%

Как видите, оба способа дают одинаковый результат.

Ключевые выводы

Количество запросов (N): Экономия тем выше, чем больше запросов вы делаете в течение жизни кэша. При N=2 экономия будет небольшой, а при N=100 она приблизится к своему максимуму.
Коэффициент кэширования (P_hit): Это самый мощный рычаг. Увеличение доли кэшируемых токенов напрямую и линейно увеличивает вашу экономию.
Период жизни кэша: Сам по себе он не влияет на формулу, но он определяет, сколько запросов (N) вы успеете в него "уместить". Короткий кэш с большим количеством однотипных запросов может быть выгоднее, чем долгий кэш с редкими и разнородными запросами.

Вместо кэширования мы рекомендуем управлять историей диалога и формировать каждый новый запрос с учетом актуального контекста.

Могут ли заблокировать мой API ключ?

Только в случае злоупотреблений (DDoS, спам, попытки взлома, массовое использование тестовых API ключей) или систематического превышения лимитов без реакции на предупреждения. Для защиты от случайных ошибок мы сначала временно приостанавливаем доступ.

Массовое использование тестовых API-ключей.

За создание и использование нескольких API-ключей с суммой пополнения менее 1000 руб. без согласования с администрацией, все ключи будут заблокированы без возможности восстановления и возврата средств.

Это сделано для борьбы с обходом RPM лимита и создания массовых спам-запросов.

Я получаю ошибки при запросах. Что делать?

Проверьте страницу статуса API, чтобы убедиться в отсутствии глобальных сбоев.
Убедитесь, что ваш запрос полностью соответствует документации (метод, параметры, формат данных).
Если проблема сохраняется, свяжитесь с нами в Telegram, предоставив как можно больше деталей: сам запрос (без секретных данных), полученный ответ с ошибкой и ID запроса.

Нужна модель, которой нет в списке. Добавите?

Да, мы постоянно расширяем список доступных моделей. Напишите нам в Telegram, укажите точное название модели и примерный объем запросов, который вам нужен. Мы рассмотрим вашу заявку. Приоритет отдается популярным моделям и запросам от активных пользователей.

Как обеспечивается низкая цена? Это легально?

Абсолютно легально. Мы не используем взломанные аккаунты или какие-либо обходные пути. Низкие цены — результат нашей работы:

Официальные партнерства с разработчиками AI.
Участие в программах поддержки и получение грантов.
Оптовые скидки за большие объемы запросов, которые мы агрегируем.

Как обеспечивается анонимность?

Анонимность и конфиденциальность ваших данных являются для нас приоритетом. Подробнее об этом можно прочитать в разделе нашей документации: Анонимность и конфиденциальность данных

Почему у нас меньший объём контекста, чем у официального API?

Мы агрегируем доступ к моделям AI, чтобы предлагать более выгодные цены. Это накладывает ряд ограничений:

Партнёрские условия: Наш доступ к моделям от OpenAI, Anthropic и других компаний регламентируется партнёрскими соглашениями. Эти соглашения часто включают фиксированные лимиты на количество токенов, которые мы не можем превышать.
Гранты и поддержка: Участие в программах поддержки разработчиков AI (например, от Google AI, Microsoft) часто требует соблюдения определённых условий. Одним из таких условий может быть ограничение контекста для обеспечения справедливого распределения ресурсов среди всех участников программ.
Оптовые скидки: Мы закупаем большие пакеты запросов у поставщиков, получая за это оптовые скидки. Чтобы сохранить эти скидки, мы должны равномерно распределять доступные токены между всеми клиентами. Введение ограничений на количество токенов в запросе и ответе позволяет нам контролировать общую нагрузку и бюджет.

Итог: Эти ограничения позволяют нам сохранять конкурентоспособные цены, поддерживать партнёрские отношения и обеспечивать справедливый доступ к моделям для всех пользователей.

Почему у вас нет моделей для работы с аудио и видео? Будут ли они в будущем?

На текущий момент наш сервис предоставляет доступ к моделям для работы с текстом, изображениями и эмбеддингами текста, однако работа с аудио и видео не поддерживается, и их интеграция в обозримом будущем не планируется. Это обусловлено рядом стратегических и операционных причин:

Инфраструктурные ограничения: Обработка аудио и видео файлов требует значительно более сложной и масштабируемой инфраструктуры по сравнению с текстовыми данными, изображениями и эмбеддингами. Такие файлы генерируют большие объемы данных и требуют специфических вычислительных ресурсов, которые существенно превышают требования к обработке текущих типов данных. Текущая архитектура нашего API не рассчитана на подобные нагрузки. Попытка интеграции без надлежащей подготовки может привести к снижению общей стабильности сервиса, сбоям и замедлению работы для всех пользователей.
Экономическая целесообразность и рыночный спрос: Модели для работы с медиа-контентом, как правило, отличаются высокой стоимостью. Анализ рыночного спроса на данные типы моделей в контексте нашего основного предложения показывает, что на данный момент этот спрос является относительно низким по сравнению со спросом на модели для текста, изображений и эмбеддингов. Сочетание высокой стоимости и ограниченного спроса делает экономически нецелесообразным введение и поддержку таких функциональностей.
Приоритезация развития текущих направлений: Наш основной приоритет заключается в обеспечении максимальной стабильности, надежности и производительности уже существующих моделей для работы с текстом, изображениями и эмбеддингами. Мы концентрируем наши ресурсы на оптимизации существующей функциональности, устранении потенциальных проблем, расширении возможностей текущих моделей и добавлении новых моделей в этих направлениях. Наша цель – предоставить пользователям максимально широкий спектр возможностей и высокую производительность в тех областях, которые уже поддерживаются нашим API.

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

Поддерживаются ли stream ответы? Почему возвращается ответ единым чанком?

Текущая поддержка: Псевдо-стрим ответы

В настоящее время наша система поддерживает только псевдо-стрим ответы. Это означает, что мы имитируем поведение потоковых ответов, но фактически данные отправляются единым блоком.

Причины использования псевдо-стрим ответов

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

Совместимость с существующими сервисами и программами:
- Многие программы и сервисы, с которыми интегрируется наша система, ожидают получить ответ в формате, который они интерпретируют как потоковый (stream).
- Используя псевдо-стрим, мы предоставляем ответ таким образом, чтобы он был понятен и обрабатывался этими системами, избегая проблем с интеграцией.
Ограничения обработки ошибок в истинных стрим ответах:
- При работе с истинно потоковыми ответами (где данные поступают частями) возникает сложность с корректной обработкой ошибок.
- Отправка единым чанком позволяет нам сначала выполнить полную валидацию запроса, обработать все возможные ошибки на стороне сервера и только затем отправить полный ответ. Это значительно упрощает логику обработки ошибок для клиента и повышает надежность.
Проблемы и ограничения провайдеров:
- Не все внешние провайдеры, с которыми мы взаимодействуем, полноценно поддерживают работу в режиме истинных стрим ответов.
- Некоторые провайдеры могут иметь проблемы с производительностью, стабильностью или корректностью обработки данных при работе в стрим режиме.
Снижение стоимости и повышение стабильности:
- Используя единый чанк, мы можем более эффективно управлять ресурсами и снижать вероятность возникновения непредвиденных сбоев, связанных с неполной обработкой данных или ошибок.
- Это приводит к снижению операционных расходов и повышению общей стабильности работы системы.

Почему не полноценные stream ответы?

Переход на полноценные стрим ответы (где данные отправляются и обрабатываются по мере поступления) привел бы к следующим негативным последствиям:

Значительное повышение стоимости.
Уменьшение стабильности.

Текущий подход с использованием псевдо-стрим ответов является компромиссным решением, которое позволяет нам достичь баланса между совместимостью, стабильностью, экономической эффективностью и функциональностью. Мы стремимся обеспечить максимально гладкую интеграцию с различными системами и провайдерами, минимизируя при этом риски.

В чем разница между обычными, Uncensored и NSFW моделями?

Разница между этими типами моделей заключается в уровне ограничений на генерируемый контент.

Обычные модели

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

Uncensored модели (Нецензурированные)

Модели с ослабленными или удаленными ограничениями. Они могут обсуждать более широкий спектр тем без автоматического отказа, но не специализированы на создании откровенного контента. Идеальны для исследований, творческих проектов и работы со сложными темами в академическом контексте. Модели с пометкой -uncensored в конце ID относятся к этому типу.

NSFW модели (Not Safe For Work)

Специализированные модели, созданные для генерации контента для взрослых (откровенного, сексуального, жестокого). Они практически не имеют ограничений на темы, которые отвергают другие модели. Используются в узкоспециализированных случаях и требуют особой ответственности и соответствия законодательству. Модели с пометкой -nsfw в конце ID относятся к этому типу.