Token பொருளாதாரம்

செலவு-திறன் கொண்ட LLM பயன்பாடுகளை உருவாக்குவதற்கு டோக்கன் பொருளாதாரத்தைப் புரிந்துகொள்வது அடிப்படையானது. சரியான கண்காணிப்பு மற்றும் மேம்படுத்தல் உத்திகள் இல்லாமல் டோக்கன் செலவுகள் விரைவாக அதிகரிக்கக்கூடும்.

அறிமுகம்

டோக்கன்களைக் கண்காணிக்காமல் ஒரு LLM அம்சத்தை நீங்கள் வெளியிடும்போது, முதல் ஆச்சரியம் பொதுவாக இன்வாய்ஸ் ஆகும் — டெவ் சூழலில் "மலிவாகத் தோன்றிய" ஒரு சாட்பாட், உண்மையான ட்ராஃபிக் வந்தவுடன் மாதத்திற்கு ஐந்து இலக்கத் தொகையை எரிக்கக்கூடும், ஏனெனில் ஒவ்வொரு ப்ராம்ப்ட் மீண்டும் வருதலும், ஒவ்வொரு நீண்ட பதிலும், கேஷ் செய்யப்படாத ஒவ்வொரு சிஸ்டம் வழிமுறையும் டோக்கனுக்குக் கட்டணம் விதிக்கப்படுகிறது. பில் வந்த பிறகு டோக்கன் கணிதத்தைக் கற்றுக்கொள்ளும் குழுக்கள், வீணான செலவைக் குறைப்பதற்குப் பதிலாக அம்சங்களை வெட்டுவது அல்லது பயனர்களுக்கு ரேட்-லிமிட் விதிப்பதில் முடிகின்றன. இந்தப் பாடத்தின் முடிவில், எந்தவொரு வழங்குநருக்கும் டோக்கன்களைத் துல்லியமாக எண்ணவும், ஒரு வொர்க்லோடை டெப்ளாய் செய்வதற்கு முன்பே அதன் தினசரி செலவைக் கணக்கிடவும், உங்கள் ட்ராஃபிக் வடிவத்திற்கு எந்த மேம்படுத்தல் (ப்ராம்ப்ட் கேஷிங், அவுட்புட் சுருக்கம், மாடல் அடுக்குமுறை) உண்மையில் பலனளிக்கிறது என்பதை அடையாளம் காணவும் நீங்கள் முடியும்.

முக்கிய சொற்கள்

• டோக்கன் — வழங்குநர்கள் அளவிட்டு மில்லியனுக்குக் கட்டணம் விதிக்கும் ஒரு துணைச்சொல் அலகு (~4 ஆங்கில எழுத்துகள்); உங்கள் ப்ராம்ப்ட் மற்றும் பதிலில் உள்ள ஒவ்வொரு எழுத்தும் விலை நிர்ணயிக்கப்படுவதற்கு முன் டோக்கன்களாக மாற்றப்படுவதால் இது முக்கியமானது.
• இன்புட் vs. அவுட்புட் டோக்கன் விலை — நீங்கள் அனுப்பும் டோக்கன்களுக்கும் (இன்புட்) மாடல் உருவாக்கும் டோக்கன்களுக்கும் (அவுட்புட்) வழங்குநர்கள் தனித்தனியாகக் கட்டணம் விதிக்கிறார்கள்; அவுட்புட் பொதுவாக 3-5× அதிக விலை; இந்தப் பிரிவைப் புறக்கணிக்கும் செலவு மாதிரிகள், நீண்ட-கம்ப்ளீஷன் வொர்க்லோடுகளின் செலவைக் குறைத்து மதிப்பிடுகின்றன.
• ப்ராம்ப்ட் கேஷிங் — மீண்டும் வரும் ப்ராம்ப்ட்டின் முன்பகுதியைச் சேமித்து, கேஷ் செய்யப்பட்ட ரீடுகளுக்கு அடிப்படை இன்புட் விலையின் 10-50% கட்டணம் விதிக்கும் ஒரு வழங்குநர் அம்சம்; ஆயிரக்கணக்கான கோரிக்கைகளில் மீண்டும் பயன்படுத்தப்படும் ஒரு நிலையான சிஸ்டம் ப்ராம்ப்ட், இன்புட் செலவைக் குறைப்பதற்கான மிகப்பெரிய ஒற்றை வழிமுறை என்பதால் இது முக்கியமானது.
• டோக்கனைசர் — உரையை முழு எண் டோக்கன் ID-களாக மாற்றும் என்கோடிங் (எ.கா. cl100k_base, o200k_base); மதிப்பீட்டிற்கும் பில்லிங்கிற்கும் இடையே பொருந்தாத டோக்கனைசர்கள் 30% வரை தவறான செலவு முன்னறிவிப்புகளை உருவாக்குகின்றன.
• ஒரு உரையாடலுக்கான செலவு — டோக்கன்களைத் தயாரிப்பு வருவாயுடன் இணைக்கும் யூனிட்-பொருளாதார அளவீடு: ஒரு பயனர் தொடர்புக்கு (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 ஐக் கணக்கிட்டு, அதை ஒரு தயாரிப்பு அளவீடாகக் கண்காணியுங்கள்.