—
системная подсказка / мес.—общий счет в месяц
—это преамбула
—сохранений в кеше/мес.
Куда идут ваши входные токены
Ежемесячный счет разделен на фиксированную преамбулу, которую вы повторно отправляете каждый раз, динамические токены пользователя и контекста, а также выходные данные. Первая строка — это налог — он не уменьшается, когда пользователи говорят меньше.
| Часть | Токены/запрос | Стоимость / мес. | Делиться |
|---|
Как быстрый размер влияет на размер налога
Каждая строка имеет разную длину системного приглашения на текущем томе. Некэшированный столбец — это наивная стоимость; в кешированном столбце применяется ваш коэффициент попадания и скидка. Именно поэтому приглашение, которое выросло с 500 до 4000 токенов, незаметно умножило ваш счет.
| Системная подсказка | Без кэширования / мес. | Кэшировано/мес. | против твоего |
|---|
За подсказку, которую написал один раз, вы платите миллион раз
Системное приглашение выглядит свободным, потому что вы пишете его один раз и забываете, но API не имеет состояния, поэтому преамбула используется при каждом отдельном вызове и каждый раз оплачивается как входные токены. Ловушка заключается в коротких запросах большого объема: классификатор или маршрутизатор, который получает двадцать токенов пользовательского текста и блок инструкций из двух тысяч токенов, тратит 99% своего входного бюджета на слова, которые пользователь никогда не отправлял. Решение скучное и эффективное — читайте подсказку системы так, как если бы вы платили за слово, потому что так и есть, и уберите вежливый заполнитель, дублированные правила и схемы инструментов, которые вы почти никогда не вызываете. Затем кэшируйте то, что уцелело, поскольку стабильная преамбула — это именно то, для чего было создано кэширование подсказок, а чтение из кэша стоит примерно десятую часть свежего. Причина, по которой обрезка стоит на первом месте, заключается в том, что она помогает безоговорочно, как при промахах, так и при попаданиях в кеш, в то время как кэширование окупается только для запросов, которые поступают, пока кеш горячий, и только если префикс остается побайтовым идентичным — одна временная метка вверху, и скидка испаряется. Размер рычага кэширования точно соответствует быстрый калькулятор экономии кэширования, проверьте безубыточность операций записи и чтения на калькулятор безубыточности при записи в кэши подсчитайте токены в текущем приглашении с помощью счетчик токенов.
Оперативная экономия при кэшированииБезубыточность записи в кэшСтоимость вызова функцииСчетчик токеновОптимизация затрат на получение степени LLM
Как работает этот калькулятор
Он считает ваши ежемесячные запросы как запросы в день, умноженные на 30,4. Каждый запрос оплачивает системное приглашение плюс динамический ввод со скоростью ввода и вывод со скоростью вывода. Стоимость системного приглашения равна количеству токенов, умноженному на ежемесячные запросы по входной скорости; кэширование снижает долю попаданий до дисконтированной ставки, в то время как доля промахов остается полной ценой. Общий счет суммирует фиксированную преамбулу, динамический ввод и вывод. Доля — это стоимость системного запроса по сравнению с этой общей суммой, а экономия в кэше — это стоимость некэшированной преамбулы минус кэшированная. Таблица масштабирования повторно просчитывает стоимость преамбулы для нескольких длин приглашения, чтобы вы могли видеть, как она растет, а показатель обрезки применяет процентное сокращение к текущему приглашению.
Часто задаваемые вопросы
Почему подсказка системы стоит денег при каждом запросе?
Поскольку API не сохраняет состояние — он не запоминает ваш предыдущий вызов — поэтому все, что вы хотите, чтобы модель знала каждый раз, должно отправляться каждый раз. Системное приглашение, персонаж, несколько примеров и схемы инструментов — все они живут в этой фиксированной преамбуле, и каждый из них считается входными токенами при каждом запросе. Пользователь, набирающий одно слово, по-прежнему платит за всю преамбулу, идущую вместе с ним, поэтому раздутое системное приглашение ведет себя как фиксированный налог, взимаемый полностью как с самых маленьких, так и с самых больших запросов.
Какую часть моего счета подскажет система?
Это зависит от соотношения вашей фиксированной преамбулы к переменному содержимому каждого запроса. Приглашение на две тысячи токенов против пятисот жетонов пользовательского поворота — это большая часть ваших входных токенов, и они могут доминировать в счете — особенно при коротких, объемных вызовах, таких как классификация, где почти нет пользовательского текста, который мог бы разбавить его. Если ваши запросы содержат длинные документы или истории чатов, преамбула представляет собой меньший фрагмент. Опасный случай — большой объем плюс короткие запросы плюс длинное приглашение.
Уменьшает ли кэширование подсказок стоимость системных подсказок?
Он удаляет большую часть вызовов, попавших в кеш. Кэширование сохраняет стабильный префикс (ваша системная подсказка является идеальным кандидатом), и счета считываются по нему с огромной скидкой, обычно около 90%, поэтому кэшированное системное приглашение стоит примерно десятую часть некэшированного. Загвоздка в том, что скидка предоставляется только запросам, поступающим, пока кеш горячий, иногда существует небольшая надбавка за запись, а префикс должен быть побайтно идентичен, поэтому отметка времени вверху нарушает его.
Что лучше: обрезать системное приглашение или кэшировать его?
Сделайте и то, и другое, но они решают разные проблемы. Обрезка сокращает количество токенов в преамбуле, снижая стоимость каждого запроса, включая промахи в кэше, и освобождает контекстное окно. Кэширование делает приглашение длинным, но делает повторные чтения дешевыми при «горячих» вызовах. Обрезка — более надежный выигрыш, поскольку она помогает безоговорочно, в то время как кеширование зависит от того, поддерживает ли ваш трафик «теплый» кеш. Сначала удалите все, что не заработало свои токены, а затем кэшируйте то, что осталось.