வழங்குநர் நிலப்பரப்பு பகுப்பாய்வு

அறிமுகம்

மாற்று வழிகளை ஆய்வு செய்யாமல் ஒரு production பணிச்சுமைக்காக ஒரே ஒரு LLM வழங்குநரைத் தேர்ந்தெடுக்கும்போது, நீங்கள் பொதுவாக 3–10× அதிகமாகச் செலவு செய்கிறீர்கள், அல்லது ஆறு மாதங்களுக்குப் பிறகு விலையுயர்ந்த மறுஎழுத்தைக் கட்டாயப்படுத்தும் context-window உச்சவரம்பைச் சந்திக்கிறீர்கள். Anthropic, OpenAI மற்றும் Google ஒவ்வொன்றும் ஒன்றுடன் ஒன்று மேலெழும் திறன்களை வழங்குகின்றன, ஆனால் அவற்றின் விலை வளைவுகள், cache தள்ளுபடிகள், context வரம்புகள் மற்றும் tool-use பயன்பாட்டு வசதிகள் கூர்மையாக வேறுபடுகின்றன — மேலும் அந்த வேறுபாடுகள் ஒவ்வொன்றும் எந்தப் பணிச்சுமைகளில் சிறந்தது என்பதை நேரடியாகத் தீர்மானிக்கின்றன.

இந்தப் பாடத்தின் முடிவில், inference engineering-க்கு முக்கியமான பரிமாணங்களில் — model அடுக்குகள், context window, input/output விலை மற்றும் cache தள்ளுபடி — மூன்று முக்கிய frontier வழங்குநர்களை ஒப்பிடவும், ஒரு எளிய செலவு மாதிரியைப் பயன்படுத்தி ஒரு குறிப்பிட்ட பணிச்சுமைக்கான வழங்குநர் தேர்வை நியாயப்படுத்தவும் உங்களால் முடியும்.

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

• Frontier model — ஒரு வழங்குநர் தற்போது வெளியிடும் மிக உயர்ந்த திறன் கொண்ட அடுக்கு (எ.கா. Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro). நீங்கள் என்ன செய்ய முடியும் என்பதன் மேல் வரம்பை நிர்ணயிக்கிறது; ஒரு token-க்கு நீங்கள் எவ்வளவு செலுத்துவீர்கள் என்பதன் மேல் வரம்பையும் நிர்ணயிக்கிறது.
• Context window — ஒரு ஒற்றைக் கோரிக்கையில் உள்ளடக்கக்கூடிய அதிகபட்ச token எண்ணிக்கை (prompt + completion). RAG அல்லது சுருக்கம் தேவைப்படுவதற்கு முன் ஒரு turn-இல் எவ்வளவு மீட்டெடுக்கப்பட்ட அல்லது வரலாற்று உள்ளடக்கத்தைத் திணிக்க முடியும் என்பதை வரம்பிடுகிறது.
• Prompt caching — மீண்டும் அனுப்பப்படும் prefix token-களுக்குக் குறைந்த கட்டணம் வசூலிக்கும் ஒரு வழங்குநர்-வாரியான அம்சம். Anthropic cache செய்யப்பட்ட input-இல் 90% வரை தள்ளுபடி வழங்குகிறது; OpenAI தானியங்கி 50% தள்ளுபடி வழங்குகிறது; Google கைமுறை lifecycle-உடன் வெளிப்படையான context caching வழங்குகிறது.
• Token விலை சமச்சீரின்மை — ஒவ்வொரு வழங்குநரிடமும் output token-கள் input token-களை விட தோராயமாக 4–5× அதிக விலை. இந்த விகிதம், chat பணிச்சுமைகளில் prompt நீளம் அல்ல, உருவாக்க நீளமே பொதுவாகச் செலவில் ஆதிக்கம் செலுத்துகிறது என்பதைக் குறிக்கிறது.
• Reasoning model — காணக்கூடிய பதிலுக்கு முன் கூடுதல் மறைந்த "reasoning token-களை" நுகரும் ஒரு அடுக்கு (OpenAI o1/o3, Gemini Thinking). கணிதம்/code-இல் அதிக துல்லியம், ஆனால் அந்த மறைந்த token-களுக்கும் கட்டணம் விதிக்கப்படுகிறது.

கருத்துகள்

மூன்று வழங்குநர்களும் அவை எதற்காக உகந்தவை என்பதன் அடிப்படையில் குழுவாகின்றன: cache-தீவிர நிறுவனப் பணிச்சுமைகளுக்கு Anthropic, அம்சங்களின் பரந்த அளவு மற்றும் reasoning model-களுக்கு OpenAI, மிக நீண்ட context-கள் மற்றும் multimodal input-க்கு Google. கீழே உள்ள வரைபடம் அடுக்குகளையும் வழங்குநர் தேர்வை இயக்கும் வேறுபடுத்திகளையும் வரைபடமாக்குகிறது.

Anthropic Claude அடுக்குகள்

ஒரே 200K-token context window-இல் மூன்று அடுக்குகள். Sonnet என்பது ஒரு மில்லியன் token-களுக்கு $3 input / $15 output என்ற விலையில் இயல்புநிலை பணிக்குதிரை. Haiku $0.25 / $1.25 ஆகக் குறைகிறது — உச்ச reasoning-ஐ விட latency-யும் volume-ம் முக்கியமாக இருக்கும்போது மலிவான தீவிர அடுக்கு. Opus என்பது Sonnet கண்கூடாகக் குறைவாகச் செயல்படும் பணிகளுக்கான $15 / $75 விலையிலான premium அடுக்கு. முதன்மை வேறுபடுத்தி என்பது cache செய்யப்பட்ட input-இல் 90% வரை தள்ளுபடியுடன் கூடிய prompt caching — சந்தையில் மிகச் செங்குத்தான cache தள்ளுபடி — இது ஒரே system prompt மற்றும் ஆவணத் தொகுப்பு turn-களுக்கு இடையே மீண்டும் வரும் retrieval-augmented chat-க்கு Anthropic-ஐ ஆதிக்கம் செலுத்த வைக்கிறது.

OpenAI GPT மற்றும் reasoning அடுக்குகள்

$2.50 / $10 விலையிலான GPT-4o 128K context கொண்ட முதன்மை multimodal model ஆகும். $0.15 / $0.60 விலையிலான GPT-4o-mini பெரும்பாலான non-frontier பணிச்சுமைகளுக்கான விலை-செயல்திறன் இனிமையான புள்ளி. o1 / o3 reasoning model-கள் நீங்கள் இன்னும் கட்டணம் செலுத்தும் மறைந்த reasoning token-களை நுகர்வதன் மூலம் கணிதம், code மற்றும் பல-படி தர்க்கத்தில் துல்லியத்திற்காக latency-ஐப் பரிமாறிக்கொள்கின்றன. OpenAI-இன் தனித்துவமான நகர்வுகள்: code மாற்றங்கள் இல்லாத தானியங்கி 50% cache தள்ளுபடி, 24-மணி நேர திருப்பத்திற்கு 50% தள்ளுபடியிலான Batch API, மற்றும் constrained decoding மூலம் JSON-schema இணக்கத்தை உத்தரவாதம் செய்யும் Structured Outputs (Code Walkthrough பார்க்கவும்).

Google Gemini நீண்ட-context அடுக்குகள்

1M-token context உடன் $0.075 / $0.30 விலையிலான Gemini 2.0 Flash சந்தையில் மலிவான தீவிர frontier model ஆகும். $1.25 / $5.00 விலையிலான Gemini 1.5 Pro 2M-token context வரை நீட்டிக்கிறது — தொழில்துறையில் மிகப் பெரியது — RAG இல்லாமல் முழு codebase-களையோ அல்லது புத்தக-நீள ஆவணங்களையோ ஒரே prompt-இல் பொருத்த உங்களை அனுமதிக்கிறது. Native multimodal input (படம், ஆடியோ, வீடியோ) மற்றும் கைமுறை TTL உடன் வெளிப்படையான context caching ஆகியவை வேறுபடுத்திகளை நிறைவு செய்கின்றன.

Code Walkthrough

இப்போது மூன்று வழங்குநர்களின் அடுக்குகள், context window-கள் மற்றும் cache-தள்ளுபடி இயங்குமுறைகள் உங்கள் பார்வையில் இருப்பதால், கீழே உள்ள snippet அவற்றை ஒரு முடிவெடுக்கும் கருவியாக இணைக்கிறது: ஒரு பணிச்சுமையின் input/output token அளவுகளையும் cache hit rate மதிப்பீட்டையும் எடுத்துக்கொண்டு, பின்னர் ஒவ்வொரு வழங்குநர் அடுக்கிற்கும் எதிர்பார்க்கப்படும் மாதாந்திரச் செலவை அச்சிடும் ஒரு சிறிய செலவு மதிப்பீட்டாளர் — இதனால் உணர்வுகளின் அடிப்படையில் அல்ல, எண்களின் அடிப்படையில் நீங்கள் தேர்ந்தெடுக்கலாம்.

Code snippetpython
1from dataclasses import dataclass
2
3@dataclass(frozen=True)
4class Tier:
5    provider: str
6    name: str
7    input_per_mtok: float   # USD per million input tokens
8    output_per_mtok: float  # USD per million output tokens
9    cache_discount: float   # fraction off input on cache hit (0.0-1.0)
10    context_tokens: int
11
12TIERS = [
13    Tier("anthropic", "claude-3.5-sonnet", 3.00, 15.00, 0.90, 200_000),
14    Tier("anthropic", "claude-3.5-haiku",  0.25,  1.25, 0.90, 200_000),
15    Tier("openai",    "gpt-4o",            2.50, 10.00, 0.50, 128_000),
16    Tier("openai",    "gpt-4o-mini",       0.15,  0.60, 0.50, 128_000),
17    Tier("google",    "gemini-2.0-flash",  0.075, 0.30, 0.75, 1_000_000),
18    Tier("google",    "gemini-1.5-pro",    1.25,  5.00, 0.75, 2_000_000),
19]
20
21def monthly_cost(tier: Tier, input_mtok: float, output_mtok: float,
22                 cache_hit_rate: float) -> float:
23    cached_in  = input_mtok * cache_hit_rate
24    fresh_in   = input_mtok * (1 - cache_hit_rate)
25    input_cost = (fresh_in + cached_in * (1 - tier.cache_discount)) * tier.input_per_mtok
26    return input_cost + output_mtok * tier.output_per_mtok
27
28def rank_for_workload(input_mtok: float, output_mtok: float,
29                      cache_hit_rate: float, min_context: int) -> list[tuple[Tier, float]]:
30    eligible = [t for t in TIERS if t.context_tokens >= min_context]
31    return sorted(((t, monthly_cost(t, input_mtok, output_mtok, cache_hit_rate))
32                   for t in eligible), key=lambda x: x[1])
33
34# Example: RAG chat — 500 Mtok in, 50 Mtok out, 70% cache hit, needs 128K ctx.
35for tier, cost in rank_for_workload(500, 50, 0.70, 128_000):
36    print(f"{tier.provider:10s} {tier.name:22s} ${cost:>10,.0f}/mo")

உங்கள் பணிச்சுமையின் உண்மையான input/output token அளவுகள் மற்றும் cache hit rate-க்கு இதை இயக்கும்போது ஒவ்வொரு அடுக்கிற்கும் ஒரு மாதாந்திரச் செலவு மதிப்பீடு கிடைத்து, மலிவான தகுதியான அடுக்கு உங்கள் latency மற்றும் திறன் தேவைகளுடன் பொருந்தினால் பணி முடிந்தது. மலிவான அடுக்கு தரத்தில் குறைவாகச் சேவை செய்தால், அடுத்த கட்டுப்பாட்டின் (reasoning திறன், multimodal, structured output) அடிப்படையில் மறு-தரவரிசைப்படுத்தி, அதைக் கடக்கும் மலிவான அடுக்கைத் தேர்ந்தெடுக்கவும்.

-க்கான நடைமுறையில்

நீங்கள் இப்போது பார்த்த செலவு மதிப்பீட்டாளரின் அடிப்படையில், அதே model மற்றும் அடுக்கு ஒப்பீடு வழங்குநர்களுக்கு இடையே பொதுமைப்படுத்தப்படுகிறது — ஆனால் தேர்வை இயக்கும் பணிச்சுமை வடிவம் துறை-சார்ந்தது. கீழே உள்ள overlay உங்கள் பணிப்பாத்திரத்திற்கு வழங்குநர் தேர்வு எப்படி இருக்கும் என்பதைக் காட்டுகிறது.

செய்ய வேண்டியவை மற்றும் செய்யக்கூடாதவை

உங்கள் துறையின் பணிச்சுமைக்கு ஏற்ப வழங்குநர் தேர்வை இப்போது அளவிட்ட நிலையில், கீழே உள்ள விதிகள் அந்தத் தேர்வை தொடர்ந்து மலிவாகவும் மீளக்கூடியதாகவும் வைத்திருக்கும் நகர்வுகளையும் — அமைதியாக கட்டணத்தை உயர்த்தும் பொறிகளையும் — சுருக்கித் தருகின்றன.

செய்ய வேண்டியவை

1. உண்மையான token அளவுகளில் செலவை மாதிரியாக்குங்கள் — ஒரு வார production log-களை எடுத்து, ஒரு கோரிக்கைக்கான சராசரி input/output token-களையும் cache-hit ஆகக்கூடிய prefix நீளத்தையும் அளந்து, பின்னர் அந்த எண்களை மதிப்பீட்டாளரில் செருகுங்கள். வழங்குநர் விலைப் பக்கங்கள் உங்களிடம் உண்மையில் இல்லாத அளவுகளை அனுமானிக்கின்றன.
2. தரத் தடையைக் கடக்கும் மலிவான அடுக்கைத் தேர்ந்தெடுங்கள் — செலவு-வரிசைப்படுத்தப்பட்ட பட்டியலில் இருந்து தொடங்கி, பின்னர் உங்கள் eval தொகுப்பில் தோல்வியடையும் அடுக்குகளை நீக்குங்கள். "பாதுகாப்பாக இருக்க" மிகவும் திறன் வாய்ந்த அடுக்கைத் தேர்ந்தெடுப்பதுதான் குழுக்கள் 5× அதிகமாகச் செலவிடுவதற்கான வழி.
3. cache hit-களுக்காக prompt prefix-ஐ வடிவமையுங்கள் — நிலையான உள்ளடக்கத்தை (system prompt, மீட்டெடுக்கப்பட்ட ஆவணங்கள், few-shot எடுத்துக்காட்டுகள்) முதலிலும், மாறும் உள்ளடக்கத்தை (பயனர் turn) கடைசியிலும் வைக்கவும். Anthropic-இன் 90% தள்ளுபடியுடன், நன்கு வரிசைப்படுத்தப்பட்ட prefix chat பணிச்சுமைகளில் input செலவை 80%+ குறைக்க முடியும்.

செய்யக்கூடாதவை

1. கட்டமைப்பு நேரத்தில் ஒரே வழங்குநரிடம் பூட்டிக்கொள்ளாதீர்கள் — விலை மற்றும் திறன்கள் மாறும்போது ஒவ்வொரு காலாண்டிலும் பணிச்சுமையை மறு-ஏலம் விட முடியும் வகையில் வழங்குநர் அழைப்பை ஒரு மெல்லிய adapter-க்குப் பின்னால் வைத்திருங்கள். இந்தப் பாடத்தில் உள்ள ஒரு மில்லியன் token-க்கு மலிவான அடுக்கு உங்கள் அடுத்த perf review-க்கு முன்பே மாறிவிடும்.
2. output-token செலவைப் புறக்கணிக்காதீர்கள் — ஒவ்வொரு வழங்குநரிடமும் output விலை input-ஐ விட 4–5× அதிகம், எனவே உருவாக்க நீளம் ஆதிக்கம் செலுத்துகிறது. ஒரு max_tokens வரம்பும் "சுருக்கமாக இரு" என்ற system அறிவுறுத்தலும் பெரும்பாலும் செலவில் எந்த வழங்குநர் மாற்றத்தையும் விட சிறப்பாகச் செயல்படுகின்றன.
3. நீங்கள் பயன்படுத்தாத context-க்குக் கட்டணம் செலுத்தாதீர்கள் — Gemini-இன் 2M window ஒரு அம்சமே தவிர, இயல்புநிலைக் கோரிக்கை அளவு அல்ல. 20K போதுமானதாக இருக்கும்போது 500K-token prompt அனுப்புவது நேரடியான அதிகச் செலவு; பதிலைக் கொண்டிருக்கும் மிகச் சிறிய context-க்கு ஏற்ப கோரிக்கையை அளவிடுங்கள்.