టోకెన్ ఎకనామిక్స్

ఖర్చు-సమర్థవంతమైన LLM అప్లికేషన్‌లను నిర్మించడానికి టోకెన్ ఎకనామిక్స్‌ను అర్థం చేసుకోవడం ప్రాథమికం. సరైన పర్యవేక్షణ మరియు ఆప్టిమైజేషన్ వ్యూహాలు లేకుండా టోకెన్ ఖర్చులు వేగంగా పెరిగిపోతాయి.

పరిచయం

టోకెన్‌లను ట్రాక్ చేయకుండా మీరు ఒక LLM ఫీచర్‌ను షిప్ చేసినప్పుడు, మొదటి ఆశ్చర్యం సాధారణంగా ఇన్‌వాయిస్ అవుతుంది — డెవ్‌లో "చౌకగా అనిపించిన" ఒక చాట్‌బాట్ నిజమైన ట్రాఫిక్ వచ్చిన తర్వాత నెలకు ఐదు అంకెల మొత్తాన్ని ఖర్చు చేయగలదు, ఎందుకంటే ప్రతి ప్రాంప్ట్ పునరావృతం, ప్రతి సుదీర్ఘ ప్రతిస్పందన మరియు క్యాష్ చేయని ప్రతి సిస్టమ్ సూచన టోకెన్ వారీగా బిల్ చేయబడుతుంది. బిల్లు వచ్చిన తర్వాత టోకెన్ గణితం నేర్చుకునే బృందాలు వ్యర్థాన్ని తగ్గించడానికి బదులు ఫీచర్లను తొలగించడం లేదా వినియోగదారులకు రేట్-లిమిట్ విధించడం చేస్తాయి. ఈ పాఠం ముగిసే సమయానికి మీరు ఏ ప్రొవైడర్‌కైనా టోకెన్‌లను ఖచ్చితంగా లెక్కించగలరు, డిప్లాయ్ చేయడానికి ముందే ఒక వర్క్‌లోడ్ యొక్క రోజువారీ ఖర్చును గణించగలరు, మరియు మీ ట్రాఫిక్ ఆకృతికి ఏ ఆప్టిమైజేషన్ (ప్రాంప్ట్ క్యాషింగ్, అవుట్‌పుట్ ట్రంకేషన్, మోడల్ టైరింగ్) వాస్తవంగా ప్రభావం చూపుతుందో గుర్తించగలరు.

కీలక పదజాలం

• Token — ప్రొవైడర్లు కొలిచి మిలియన్‌కు బిల్ చేసే ఒక సబ్‌వర్డ్ యూనిట్ (~4 ఇంగ్లీష్ అక్షరాలు); మీ ప్రాంప్ట్ మరియు ప్రతిస్పందనలోని ప్రతి అక్షరం ధర వర్తించడానికి ముందు టోకెన్‌లుగా మారుతుంది కాబట్టి ఇది ముఖ్యం.
• Input vs. output token rate — మీరు పంపే టోకెన్‌లకు (ఇన్‌పుట్) మరియు మోడల్ ఉత్పత్తి చేసే టోకెన్‌లకు (అవుట్‌పుట్) ప్రొవైడర్లు విడివిడిగా ఛార్జ్ చేస్తారు, అవుట్‌పుట్ సాధారణంగా 3-5× ఖరీదైనది; ఈ విభజనను విస్మరించే ఖర్చు మోడల్‌లు దీర్ఘ-కంప్లీషన్ వర్క్‌లోడ్‌లపై ఖర్చును తక్కువగా అంచనా వేస్తాయి.
• Prompt caching — పునరావృతమయ్యే ప్రాంప్ట్ యొక్క ప్రిఫిక్స్‌ను నిల్వ చేసి, క్యాష్ చేసిన రీడ్‌లను బేస్ ఇన్‌పుట్ రేటులో 10-50% వద్ద బిల్ చేసే ఒక ప్రొవైడర్ ఫీచర్; వేలాది అభ్యర్థనలలో పునర్వినియోగమయ్యే స్థిరమైన సిస్టమ్ ప్రాంప్ట్ ఇన్‌పుట్ ఖర్చును తగ్గించడానికి అతి పెద్ద లివర్ కాబట్టి ఇది ముఖ్యం.
• Tokenizer — టెక్స్ట్‌ను పూర్ణాంక టోకెన్ IDలుగా మార్చే ఎన్‌కోడింగ్ (ఉదా. cl100k_base, o200k_base); అంచనా మరియు బిల్లింగ్ మధ్య సరిపోలని టోకెనైజర్లు 30% వరకు తప్పుడు ఖర్చు అంచనాలను ఉత్పత్తి చేస్తాయి.
• Cost per conversation — టోకెన్‌లను ఉత్పత్తి ఆదాయంతో తిరిగి అనుసంధానించే యూనిట్-ఎకనామిక్ మెట్రిక్: ప్రతి వినియోగదారు పరస్పర చర్యకు (input_tokens × in_rate) + (output_tokens × out_rate); ఇది లేకుండా, "ఈ ఫీచర్ లాభదాయకమా?" అనే ప్రశ్నకు మీరు సమాధానం చెప్పలేరు.

భావనలు

టెక్స్ట్ బిల్ చేయదగిన టోకెన్‌లుగా ఎలా మారుతుంది

ధర నిర్ణయం టోకెన్-వారీగా కొలుస్తారు, అక్షరం-వారీగా లేదా అభ్యర్థన-వారీగా కాదు. ప్రొవైడర్ అందించే టోకెనైజర్ ఒక నిర్దిష్ట స్ట్రింగ్ ఎన్ని టోకెన్‌లు ఖర్చవుతుందో నిర్ణయిస్తుంది, మరియు ఆ మ్యాపింగ్ ప్రొవైడర్ల మధ్య 1:1 కాదు — ఒకే పేరా ఒక మోడల్‌లో 180 టోకెన్‌లు, మరొక మోడల్‌లో 220 టోకెన్‌లు కావచ్చు. కోడ్, JSON మరియు ఇంగ్లీష్-కాని టెక్స్ట్ అన్నీ గద్యం కంటే దట్టంగా టోకెనైజ్ అవుతాయి, కాబట్టి ఒక "చిన్న" 2KB JSON పేలోడ్ 700+ టోకెన్‌లకు చేరవచ్చు. స్థూల బడ్జెటింగ్ కోసం అక్షరాల సంఖ్య నుండి అంచనా వేయడం సరిపోతుంది; ఫైనాన్స్‌కు మీరు పంపే అంచనాల కోసం, ప్రొవైడర్ యొక్క వాస్తవ టోకెనైజర్‌ను ఉపయోగించండి (కోడ్ వాక్‌త్రూ చూడండి).

ఖర్చు సమీకరణం మరియు క్యాషింగ్ దాన్ని ఎక్కడ మార్చుతుంది

రోజువారీ ఖర్చు requests × (input_tokens × in_rate + output_tokens × out_rate) గా విడిపోతుంది. దాదాపు ఎప్పుడూ గెలిచే లివర్ ప్రాంప్ట్ క్యాషింగ్: అభ్యర్థనల మధ్య మీరు పునర్వినియోగించే ఏ ప్రిఫిక్స్ అయినా — సిస్టమ్ ప్రాంప్ట్, ఫ్యూ-షాట్ ఉదాహరణలు, రిట్రీవ్ చేసిన డాక్యుమెంట్లు — మొదటి హిట్ తర్వాత క్యాష్ రేటు వద్ద బిల్ చేయబడుతుంది. ఇన్‌పుట్ టోకెన్‌లలో 80% స్థిరమైన సిస్టమ్ ప్రాంప్ట్ అయిన వర్క్‌లోడ్‌కు, 90% క్యాష్ డిస్కౌంట్ మొత్తం ఇన్‌పుట్ ఖర్చును ~70% తగ్గిస్తుంది. అవుట్‌పుట్ టోకెన్‌లను క్యాష్ చేయలేము, కాబట్టి రెండవ లివర్ max_tokens, స్ట్రక్చర్డ్ అవుట్‌పుట్ లేదా స్టాప్ సీక్వెన్స్‌ల ద్వారా ప్రతిస్పందనలను కుదించడం.

ప్రథమ-శ్రేణి అంశంగా ఖర్చు ఆపాదింపు

వినియోగదారు, ఫీచర్ లేదా టెనెంట్ వారీగా ఖర్చును ట్యాగ్ చేయలేకపోతే, ఏది ఖరీదైనదో మీరు కనుగొనలేరు — మరియు "LLM ఖరీదైనది" అనేది మీ అతి చౌకైన మరియు అతి ఖరీదైన కాల్ సైట్‌ల మధ్య ఉన్న 10× వ్యత్యాసాన్ని సగటు చేసేస్తుంది. ఆపాదింపు అభ్యర్థనతో సమానమైన లాగింగ్ మార్గంలోనే ఉండాలి: ప్రతి కాల్‌కు model, input_tokens, output_tokens, cached_tokens మరియు ఒక feature_id లాగ్ చేయండి. రోజువారీగా సమీకరించండి; ఖర్చు ప్రకారం టాప్-3 ఫీచర్లే దాదాపు ఎప్పుడూ ఆప్టిమైజేషన్ ఫలితం ఇచ్చే చోటు.

కోడ్ వాక్‌త్రూ

మునుపటి విభాగంలోని టోకెనైజర్ మోడల్, ఖర్చు సమీకరణం మరియు ఆపాదింపు భావనలపై నిర్మిస్తూ, ఈ వాక్‌త్రూ వాటిని రన్ చేయదగిన కోడ్‌గా మార్చుతుంది: ప్రొవైడర్ యొక్క వాస్తవ టోకెనైజర్‌తో టోకెన్‌లను లెక్కించడం, మరియు క్యాషింగ్‌ను పరిగణనలోకి తీసుకునే ప్రతి-సంభాషణ ఖర్చును గణించడం. స్క్రిప్ట్ రన్ చేసినప్పుడు మీ ప్రాంప్ట్‌కు ఖచ్చితమైన టోకెన్ సంఖ్య మరియు ప్రొవైడర్ బిల్లింగ్ డాష్‌బోర్డ్‌తో కొన్ని శాతం లోపల సరిపోయే రోజువారీ-ఖర్చు సంఖ్య రెండూ ప్రింట్ అయితే అది పనిచేస్తుందని మీకు తెలుస్తుంది.

Code snippetpython
1import tiktoken
2
3# Provider rates as of model release; verify against current pricing page.
4RATES_PER_MILLION = {
5    "gpt-4o": {"input": 2.50, "cached_input": 1.25, "output": 10.00},
6    "claude-sonnet": {"input": 3.00, "cached_input": 0.30, "output": 15.00},
7}
8
9def count_tokens(text: str, model: str = "gpt-4o") -> int:
10    """Return exact token count using the model's tokenizer."""
11    try:
12        encoding = tiktoken.encoding_for_model(model)
13    except (KeyError, AttributeError):
14        encoding = tiktoken.get_encoding("cl100k_base")
15    return len(encoding.encode(text))
16
17def conversation_cost(
18    system_tokens: int,
19    user_tokens: int,
20    output_tokens: int,
21    requests_per_day: int,
22    model: str,
23    cache_hit_rate: float = 0.0,
24) -> dict:
25    """Project daily cost for a workload with optional prompt caching."""
26    rates = RATES_PER_MILLION[model]
27    cached = system_tokens * cache_hit_rate
28    uncached_input = system_tokens * (1 - cache_hit_rate) + user_tokens
29
30    daily_input = (
31        cached * rates["cached_input"] + uncached_input * rates["input"]
32    ) * requests_per_day / 1_000_000
33    daily_output = output_tokens * rates["output"] * requests_per_day / 1_000_000
34
35    return {
36        "input_usd": round(daily_input, 2),
37        "output_usd": round(daily_output, 2),
38        "total_usd": round(daily_input + daily_output, 2),
39    }
40
41if __name__ == "__main__":
42    # 10k conversations/day, stable 500-token system prompt, 90% cache hit.
43    projection = conversation_cost(
44        system_tokens=500,
45        user_tokens=100,
46        output_tokens=300,
47        requests_per_day=10_000,
48        model="claude-sonnet",
49        cache_hit_rate=0.9,
50    )
51    print(projection)  # {'input_usd': 4.5, 'output_usd': 45.0, 'total_usd': 49.5}

count_tokens ఫంక్షన్ ప్రొవైడర్ టోకెనైజర్‌ను cl100k_base ఫాల్‌బ్యాక్‌తో ఉపయోగిస్తుంది, తద్వారా తెలియని మోడల్‌పై మీరు ఎప్పుడూ క్రాష్ అవ్వరు; కాంటెక్స్ట్-విండో పరిమితులను అమలు చేయడానికి మరియు ప్రతి అభ్యర్థనకు ఖచ్చితమైన టోకెన్ వినియోగాన్ని లాగ్ చేయడానికి అభ్యర్థన పంపే ముందు దీన్ని ఉపయోగించండి. conversation_cost ఫంక్షన్ నాలుగు ఇన్‌పుట్‌లను (టోకెన్ సంఖ్యలు, ట్రాఫిక్, మోడల్, క్యాష్ హిట్ రేటు) రోజువారీ-ఖర్చు అంచనాగా మార్చుతుంది — క్యాషింగ్‌ను అమలు చేయడానికి ముందు దాని ROIని లెక్కించడానికి cache_hit_rateను 0.0 నుండి 0.95 వరకు స్వీప్ చేయండి. ఒక రోజు అంచనా ఖర్చును ప్రొవైడర్ బిల్లింగ్ డాష్‌బోర్డ్‌తో పోల్చి ధృవీకరించండి; ~5% కంటే ఎక్కువ తేడాలు సాధారణంగా మీ cache_hit_rate అంచనా తప్పు అని సూచిస్తాయి.

కోసం ఆచరణలో

ఇప్పుడే కోడ్‌లో టోకెన్ లెక్కింపు మరియు ఖర్చు అంచనాను అనుసంధానించిన తర్వాత, ఆ సాధనాలను మొదట ఎక్కడ ప్రయోగించాలి అనేది తదుపరి ప్రశ్న. పైన చెప్పిన యంత్రాంగం — టోకెన్ లెక్కింపు, ఖర్చు అంచనా, క్యాష్-హిట్ గణితం — సార్వత్రికమైనది, కానీ లివరేజ్ ఎక్కడ ఉంటుందనేది మీరు వాస్తవంగా నిర్వహించే వర్క్‌లోడ్‌పై ఆధారపడి ఉంటుంది.

చేయవలసినవి మరియు చేయకూడనివి

పైన ఉన్న విభాగ-నిర్దిష్ట దృక్కోణంపై నిర్మిస్తూ, ఇప్పటివరకు కవర్ చేసిన ప్రతి వర్క్‌లోడ్ ఆకృతిలో ఖర్చును స్థిరంగా తగ్గించేది ఏమిటి — మరియు స్థిరంగా అడ్డుకునేది ఏమిటి — అనే విషయాన్ని కింది నియమాలు సంక్షిప్తంగా అందిస్తాయి.

చేయవలసినవి

1. ప్రతి అభ్యర్థనకు టోకెన్ సంఖ్యలు మరియు మోడల్‌ను లాగ్ చేయండి — మీ లాగ్‌లలో input_tokens, output_tokens, cached_tokens మరియు model లేకుండా, మీరు ఖర్చును ఆపాదించలేరు లేదా రిగ్రెషన్‌లను గుర్తించలేరు; ఇది సిస్టమ్‌లో అతి చౌకైన ఇన్‌స్ట్రుమెంటేషన్.
2. లాంచ్‌కు ముందు ప్రొవైడర్ టోకెనైజర్‌తో ఖర్చులను అంచనా వేయండి — అక్షర-ఆధారిత అంచనాలు కోడ్ లేదా ఇంగ్లీష్-కాని ఇన్‌పుట్‌లపై సాధారణంగా 20-30% తప్పుతాయి, ఇది నెలవారీ $5k మరియు $7k బిల్లు మధ్య వ్యత్యాసం.
3. క్యాష్ హిట్ రేటును ప్రథమ-శ్రేణి మెట్రిక్‌గా కొలవండి — ప్రిఫిక్స్‌లు స్థిరంగా ఉన్నప్పుడే క్యాషింగ్ సహాయపడుతుంది; 30% హిట్ రేటు అంటే మీ "క్యాష్ చేసిన" ప్రాంప్ట్‌లో ఎక్కువ భాగం అప్‌స్ట్రీమ్‌లో నిశ్శబ్దంగా తిరిగి రాయబడుతోందని అర్థం.

చేయకూడనివి

1. ఇన్‌పుట్ పరిమాణాన్ని తనిఖీ చేయకముందే అవుట్‌పుట్ పొడవును ఆప్టిమైజ్ చేయవద్దు — మీ టోకెన్‌లలో 80% ఉబ్బిన సిస్టమ్ ప్రాంప్ట్ అయితే, ప్రతిస్పందనలను కుదించడం ఒక-అంకె శాతాలను ఆదా చేస్తుంది, అదే ప్రిఫిక్స్‌ను క్యాష్ చేయడం 60%+ ఆదా చేస్తుంది.
2. టోకెనైజర్లు ప్రొవైడర్ల మధ్య ఒకేలా పనిచేస్తాయని అనుకోవద్దు — ఒక మోడల్ కాంటెక్స్ట్ విండోలో సరిపోయే ప్రాంప్ట్ మరొక మోడల్‌లో వందల టోకెన్‌లతో మించిపోవచ్చు; మోడల్‌లను మార్చినప్పుడు తిరిగి లెక్కించండి.
3. ప్రతి-సంభాషణ ఖర్చు సంఖ్య లేకుండా ఫీచర్‌ను షిప్ చేయవద్దు — "LLM ఖర్చులు బాగానే ఉన్నాయి" అనేది ఫైనాన్స్ అంగీకరించే సమాధానం కాదు; లాంచ్‌కు ముందు cost_per_user_actionను గణించి దాన్ని ఒక ఉత్పత్తి మెట్రిక్‌గా ట్రాక్ చేయండి.