Token અર્થશાસ્ત્ર

ખર્ચ-અસરકારક LLM એપ્લિકેશનો બનાવવા માટે ટોકન અર્થશાસ્ત્ર સમજવું મૂળભૂત છે. યોગ્ય મોનિટરિંગ અને ઑપ્ટિમાઇઝેશન વ્યૂહરચનાઓ વિના ટોકન ખર્ચ ઝડપથી વધી શકે છે.

પરિચય

જ્યારે તમે ટોકન ટ્રૅક કર્યા વિના LLM ફીચર શિપ કરો છો, ત્યારે પહેલું આશ્ચર્ય સામાન્ય રીતે ઇન્વૉઇસ હોય છે — dev માં "સસ્તો લાગતો" ચેટબોટ વાસ્તવિક ટ્રાફિક આવતાં મહિને પાંચ-આંકડાની રકમ બાળી શકે છે, કારણ કે દરેક પ્રોમ્પ્ટ પુનરાવર્તન, દરેક લાંબો પ્રતિસાદ અને દરેક અનકૅશ્ડ સિસ્ટમ સૂચના પ્રતિ ટોકન બિલ થાય છે. જે ટીમો બિલ આવ્યા પછી ટોકન ગણિત શીખે છે તે બગાડ ઘટાડવાને બદલે ફીચર કાપવા કે યુઝર્સને રેટ-લિમિટ કરવા મજબૂર બને છે. આ પાઠના અંત સુધીમાં તમે કોઈપણ પ્રોવાઇડર માટે ટોકન ચોક્કસ રીતે ગણી શકશો, ડિપ્લોય કરતાં પહેલાં વર્કલોડનો દૈનિક ખર્ચ ગણી શકશો, અને ઓળખી શકશો કે કયું ઑપ્ટિમાઇઝેશન (પ્રોમ્પ્ટ કૅશિંગ, આઉટપુટ ટ્રંકેશન, મોડેલ ટિયરિંગ) તમારા ટ્રાફિકના આકાર માટે ખરેખર ફરક પાડે છે.

મુખ્ય પરિભાષા

• ટોકન — એક સબવર્ડ એકમ (~4 અંગ્રેજી અક્ષરો) જેને પ્રોવાઇડર મીટર કરે છે અને પ્રતિ મિલિયન બિલ કરે છે; તે મહત્વનું છે કારણ કે તમારા પ્રોમ્પ્ટ અને પ્રતિસાદનો દરેક અક્ષર કિંમત લાગુ થાય તે પહેલાં ટોકનમાં રૂપાંતરિત થાય છે.
• ઇનપુટ વિ. આઉટપુટ ટોકન દર — પ્રોવાઇડર તમે મોકલો છો તે ટોકન (ઇનપુટ) અને મોડેલ જનરેટ કરે છે તે ટોકન (આઉટપુટ) માટે અલગ-અલગ ચાર્જ કરે છે, જેમાં આઉટપુટ સામાન્ય રીતે 3-5× વધુ મોંઘું હોય છે; આ વિભાજનને અવગણતા ખર્ચ મોડેલ લાંબા-કમ્પ્લીશન વર્કલોડ પરના ખર્ચને ઓછો આંકે છે.
• પ્રોમ્પ્ટ કૅશિંગ — પ્રોવાઇડરનું એક ફીચર જે પુનરાવર્તિત પ્રોમ્પ્ટના પ્રિફિક્સને સંગ્રહે છે અને કૅશ્ડ રીડ્સને બેઝ ઇનપુટ દરના 10-50% પર બિલ કરે છે; તે મહત્વનું છે કારણ કે હજારો રિક્વેસ્ટમાં ફરી વપરાતો સ્થિર સિસ્ટમ પ્રોમ્પ્ટ ઇનપુટ ખર્ચ ઘટાડવા માટેનું સૌથી મોટું એકલ લીવર છે.
• ટોકનાઇઝર — એન્કોડિંગ (દા.ત. cl100k_base, o200k_base) જે ટેક્સ્ટને પૂર્ણાંક ટોકન ID માં ફેરવે છે; અંદાજ અને બિલિંગ વચ્ચે મેળ ન ખાતા ટોકનાઇઝર 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) તરીકે વિઘટિત થાય છે. જે લીવર લગભગ હંમેશા જીતે છે તે પ્રોમ્પ્ટ કૅશિંગ છે: રિક્વેસ્ટોમાં તમે ફરી વાપરો છો તે કોઈપણ પ્રિફિક્સ — સિસ્ટમ પ્રોમ્પ્ટ, few-shot ઉદાહરણો, રિટ્રીવ કરેલા દસ્તાવેજો — પહેલા હિટ પછી કૅશ્ડ દરે બિલ થાય છે. જે વર્કલોડમાં 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 ગણો અને તેને પ્રોડક્ટ મેટ્રિક તરીકે ટ્રૅક કરો.