Кеширање на промптови

Како функционира

• Префикс, по редослед — Промптот се чита по редослед: системски промпт, дефиниции за алатки, па пораките. Кешот се совпаѓа од почетокот на таа секвенца до првиот токен што се разликува.
• Што се смета за погодок (hit) — Барање чиј промпт започнува со содржина идентична со неодамнешно барање — обично претходниот заобиколење на истиот разговор со додадени нови пораки. Заедничкиот префикс е кеширан влез; сè по него е регуларен влез.
• Грануларност — Кешот чува prompt во блокови од 1,568 токени, па prompt пократок од околу 1,500 токени не се кешира. Кешираниот број во одговорот е вашиот број на влез помножен со кешираниот дел од prompt-от, заокружен надолу. Не е нужно повеќекратник на големината на блокот.
• Без hit — Барање чиј почеток не е во кешот се наплатува по редовната цена на влез. За кешираните prompt-и не е објавен рок на траење и hit не е загарантиран: прочитајте usage за да видите што барањето зело од кешот.
• Без прекинувач — Барањето не се пријавува за кеширање, и ниедно поле не го исклучува кеширањето.
• Кои модели — Секој hosted open-weight id. GET /v1/models известува capabilities.prompt_caching: true и pricing.cached_input_per_million_usd за нив. Shannon моделите наплатуваат една унифицирана стапка.

Видете cache hit во одговор

Испратете две барања што започнуваат со ист долг system prompt и испечатете ја употребата на секое. Првиот број е влезот на барањето, вториот е делот од него прочитан од кешот.

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.shannon-ai.com/v1")

handbook = open("handbook.txt").read()  # a long text that stays the same


def ask(question):
    response = client.chat.completions.create(
        model="Kimi-K3-3BIT-REAP",
        messages=[
            {"role": "system", "content": handbook},
            {"role": "user", "content": question},
        ],
    )
    usage = response.usage
    print(usage.prompt_tokens, usage.prompt_tokens_details.cached_tokens)


ask("What is the refund policy?")
ask("Who approves travel?")  # same start: read the second number

import { readFileSync } from "node:fs";
import OpenAI from "openai";

const client = new OpenAI({ apiKey: "YOUR_API_KEY", baseURL: "https://api.shannon-ai.com/v1" });

const handbook = readFileSync("handbook.txt", "utf8"); // a long text that stays the same

async function ask(question) {
  const response = await client.chat.completions.create({
    model: "Kimi-K3-3BIT-REAP",
    messages: [
      { role: "system", content: handbook },
      { role: "user", content: question },
    ],
  });
  const usage = response.usage;
  console.log(usage.prompt_tokens, usage.prompt_tokens_details.cached_tokens);
}

await ask("What is the refund policy?");
await ask("Who approves travel?"); // same start: read the second number

# handbook.txt is a long text that stays the same. jq builds the JSON body from it
# and prints the usage object of the reply. Run it twice with different questions.
jq -Rs '{
    model: "Kimi-K3-3BIT-REAP",
    messages: [
      {role: "system", content: .},
      {role: "user", content: "What is the refund policy?"}
    ]
  }' handbook.txt \
  | curl -s https://api.shannon-ai.com/v1/chat/completions \
      -H "Authorization: Bearer YOUR_API_KEY" \
      -H "Content-Type: application/json" \
      -d @- \
  | jq .usage

Цени

Кешираните токени за влез се наплатуваат со 25% од стапката за влез на моделот, заокружено на $0.001 per 1M. Запишувањето во кешот не чини ништо ekstra, а излезот се наплатува како вообичаено. Кешираната стапка за секој id е во табелата Модели и цени. Модели и цени

Влезот на повикот се наплатува како (влез − кеширано) × цена на влез + кеширано × цена на кеширано. Кешираниот број никогаш не е поголем од бројот на влез.

Дневникот на употреба го наведува кешираниот влез на секој повик. Наплатените токени и трошокот веќе ја вклучуваат кешираната цена. Клучеви и употреба

Полиња за употреба

{
  "usage": {
    "prompt_tokens": 20000,
    "completion_tokens": 812,
    "total_tokens": 20812,
    "prompt_tokens_details": {
      "cached_tokens": 18000
    },
    "completion_tokens_details": {
      "reasoning_tokens": 604
    }
  }
}

{
  "usage": {
    "input_tokens": 20000,
    "input_tokens_details": {
      "cached_tokens": 18000
    },
    "output_tokens": 812,
    "output_tokens_details": {
      "reasoning_tokens": 604
    },
    "total_tokens": 20812
  }
}

{
  "usage": {
    "input_tokens": 2000,
    "cache_read_input_tokens": 18000,
    "cache_creation_input_tokens": 0,
    "output_tokens": 812
  }
}

Одговор со streaming ги носи истите полиња во својата завршна употреба. Не мора да го барате:

Како да постигнете повеќе cache hits

• Држете ги системскиот промпт и дефинициите за алатките стабилни дојт во бајтовите помеѓу повиците. Ставете ги вредностите специфични за повик, како што се временскито печати или ID-ата на барањата, на крајот од последната порака, а не во системскиот промпт.
• Додавајте само на историјата. Уредувањето, кратењето или резимирањето на претходните заобиколења го менува префиксот, и сè по првата промена се наплатува како регуларен влез.
• Не менувајте го редоследот на алатките, пораките или блоковите со содржина помеѓу повиците, и серијализирајте JSON (шеми за алатки, аргументи и резултати) на истиот начин секогаш.
• Останете на еден ид на модел во рамки на разговор и испратете го следниот повик наскоро по претходниот.

API-то го одржува почетокот на разговорот стабилен во овие случаи:

• Порака system или developer испратена подоцна во разговорот останува на своето место. Не го менува почетокот на prompt-от, па претходните потези остануваат кеширани.
• Аргументите на повиците на алатки во претходните потези на assistant се споредуваат по вредност. Редоследот на клучевите и празнините во тој JSON не се важни.
• Трите endpoint-и го читаат разговорот на ист начин. Разговор продолжен на друг endpoint го задржува заедничкиот почеток кога содржината е иста.

Полиња за барање

Прифатени се prompt_cache_key (Chat Completions и Responses) и cache_control на блоковите со содржина на Messages, па постоечкиот код на клиентот работи без промени. Ниеден од нив не е задолжителен: кеширањето е автоматско и работи исто и без нив.

Броење токени

Два бесплатни endpoint-и, POST /v1/tokenize и POST /v1/messages/count_tokens, ги бројат токените на текст или на цело барање за хостираните open-weight модели пред да го испратите. Тие имаат своја страница: Броење токени