პრომპტის ქეშირება

როგორ მუშაობს

• პრეფიქსი, თანმიმდევრობით — პრომპტი იკითხება თანმიმდევრობით: სისტემური პრომპტი, ხელსაწყოების დეფინიციები, შემდეგ კი შეტყობინებები. ქეში ემთხვევა ამ თანმიმდევრობის დასაწყისიდან პირველ ტოკენამდე, რომელიც განსხვავდება.
• რა ითვლება hit-ად — მოთხოვნა, რომლის პრომპტიც იწყება იმავე კონტენტით, чем ახლახან გაგზავნილი მოთხოვნა — როგორც წესი, ერთი და იმავე კონვერსაციის წინა ეტაპი, რომელსაც დაემატა ახალი შეტყობინებები. დამთხვევა პრეფიქსი არის ქეშირებული შემავალი; ყველაფერი მას შემდეგ არის ჩვეულებრივი შემავალი.
• گرانულარულობა — ქეში პრომპტს ინახავს 1,568 ტოკენიანი ბლოკებით, ამიტომ დაახლოებით 1,500 ტოკენზე მოკლე პრომპტი არ ქეშირდება. პასუხში ქეშირებულის რაოდენობა არის თქვენი შემავალის რაოდენობა გამრავლებული პრომპტის ქეშირებულ წილზე, დამრგვალებული ქვემოთ. ის სავალდებულოდ არ არის ბლოკის ზომის ჯერადი.
• hit-ის გარეშე — მოთხოვნა, რომლის დასაწყისიც ქეშში არ არის, ჩვეულებრივი შემავალის ტარიფით ირიცხება. ქეშირებული პრომპტების სიცოცხლის ხანგრძლივობა არ არის გამოქვეყნებული და hit გარანტირებული არ არის: წაიკითხეთ usage, რომ ნახოთ, რა აიღო მოთხოვნამ ქეშიდან.
• ჩამრთველი არ არის — მოთხოვნა ქეშირებაზე არ ეთანხმება და არც ერთი ველი ქეშირებას არ ითიშება.
• რომელი მოდელები — ყველა hosted open-weight ID. GET /v1/models ატყობინებს capabilities.prompt_caching: true-ს და pricing.cached_input_per_million_usd-ს მათთვის. Shannon მოდელები იყენებენ ერთიან ფიქსირებულ ტარიფს.

ქეშის hit პასუხში

გააგზავნეთ ორი მოთხოვნა, რომლებიც ერთი და იმავე გრძელი system prompt-ით იწყება, და დაბეჭდეთ თითოეულის usage. პირველი რიცხვი მოთხოვნის შემავალია, მეორე — მისი ის ნაწილი, რომელიც ქეშიდან წაიკითხა.

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-მდე 1M-ზე. ქეშიში ჩაწერა დამატებით არაფერი ღირს, გამომავალი კი ჩვეულებრივად იანგარიშებს. თითოეული 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
  }
}

სტრიმული პასუხი იმავე ველებს საბოლოო usage-ში ატარებს. მის მოთხოვნა არ გჭირდებათ:

როგორ მივიღოთ მეტი cache hit

• შეინარჩუნეთ სისტემური პრომპტისა და ხელსაწყოების დეფინიციების ზუსტი სტაბილურობა გამოძახებებს შორის. ყოველი გამოძახების ცვლადები, როგორიცაა თარიღები ან მოთხოვნის ID-ები, მოათავსეთ ბოლო შეტყობინებაში და არა სისტემურ პრომპტში.
• მხოლოდ დაამატეთ ისტორიას. წინა ეტაპების რედაქტირება, შეკვეცა ან შეჯამება ცვლის პრეფიქსს, და პირველივე ცვლილების შემდეგ ყველაფერი იანგარიშებს როგორც ჩვეულებრივი შემავალი.
• ნუ შეცვლით ხელსაწყოების, შეტყობინებების ან კონტენტ-ბლოკების თანმიმდევრობას გამოძახებებს შორის და ყოველთვის ერთნაირად სერიალიზasikan JSON (ხელსაწყოს სქემები, არგუმენტები და შედეგები).
• საუბრის განმავლობაში დარჩით ერთ მოდელის id-ზე და შემდეგი გამოძახება წინას მალევე გააგზავნეთ.

API საუბრის დასაწყისს სტაბილურად ინახავს ამ შემთხვევებში:

• system ან developer შეტყობინება, რომელიც საუბარში მოგვიანებით იგზავნება, თავის ადგილზე რჩება. ის პრომპტის დასაწყისს არ ცვლის, ამიტომ მის წინა ბიჯები ქეშირებული რჩება.
• წინა assistant ბიჯებში ინსტრუმენტების გამოძახების არგუმენტები მნიშვნელობით შედარდება. ამ JSON-ის გასაღებების თანმიმდევრობას და ინტერვალებს მნიშვნელობა არ აქვს.
• სამივე endpoint საუბარს ერთნაირად კითხულობს. საუბარი, რომელიც სხვა endpoint-ზე გაგრძელდა, თავის საერთო პრეფიქსს ინარჩუნებს, თუ შინაარსი იგივეა.

მოთხოვნის ველები

prompt_cache_key (Chat Completions და Responses) და cache_control Messages-ის კონტენტ ბლოკებში მიღებულია, ამ因此 არსებული კლიენტის კოდი უცვლელად მუშაობს. არცერთი მათგანი სავალდებულო არ არის: ქეშირება ავტომატურია და მათ გარეშეც identical მუშაობს.

ტოკენების დათვლა

ორი უფასო endpoint, POST /v1/tokenize და POST /v1/messages/count_tokens, hosted open-weight მოდელებისთვის ითვლის ტექსტის ან მთელი მოთხოვნის ტოკენებს გაგზავნამდე. მათ საკუთარი გვერდი აქვთ: ტოკენების დათვლა