Budgets, caps, र quotas · AI प्रणाली शिप गर्ने

हरेक LLM उत्पादसँग एउटा wallet छ, र wallet को एक तल छ। एक रातमा Rs 200,000 बिलहरूको कथाहरू ती परियोजनाहरूबाट आउँछन् जुनमा कुनै limits थिएनन् — एक loop, एक script, एक Facebook share ले एक काम गर्ने app लाई आठ घण्टामा दिवालियापनमा परिणत गर्यो। यो खण्ड ती तीन hard limits हो जुन त्यो हुनबाट रोक्दछ। हरेक AI उत्पादले तीनैसँग ship गर्दछ, वा यो ship गर्दैन।

तीन limits

हरेक LLM service, चाहे जति सानो होस्, चाहिन्छ:

कुल बजेट cap — मासिक खर्चमा एक hard ceiling। यदि तपाईंले यसलाई पार गर्नुभयो भने, service ले मोडेल call गर्न रोक्दछ।
प्रति-प्रयोगकर्ता quota — कुनै एकल प्रयोगकर्ताले कति उपभोग गर्न सक्दछ त्यसमा limit।
प्रति-request cap — कुनै एकल call को आकारमा limit।

यी layers पूरक छन्। प्रति-request cap ले single-call abuse रोक्दछ। प्रति-प्रयोगकर्ता quota ले एउटा account लाई 10,000 calls abuse गर्न रोक्दछ। बजेट cap ले पहिलो दुई भन्दा पहिले जान्ने सबै कुरा catch गर्दछ।

कुनै एउटा छोड्नुहोस् र तपाईंसँग एक holes छ। तीनै ship गर्नुहोस् र सबैभन्दा खराब-केस bill bounded हुन्छ।

Layer 1 — कुल बजेट cap

सबैभन्दा बलियो limit, र छोड्न सबैभन्दा सजिलो किनकि यसले तपाईंको उत्पाद छोड्ने जस्तो महसुस हुन्छ।

Provider तहमा। Anthropic र OpenAI दुबैले तपाईंलाई dashboard मा मासिक खर्च cap सेट गर्न दिन्छन्। एक line कोड लेख्नुभन्दा पहिले यो गर्नुहोस्। यो fire door हो जुन guarantee गर्दछ कि जब wallet खाली हुन्छ, तपाईंको आफ्नै कोडमा कुनै bug भए पनि, तपाईंको service ले मोडेल call गर्न रोक्दछ।

Anthropic Console → Billing → Usage limits।
OpenAI dashboard → Billing → Usage limits।

Cap लाई एक नम्बरमा सेट गर्नुहोस् जुन तपाईं वास्तवमा गुमाउन सक्नुहुन्छ। एक सानो परियोजनाको लागि, यो प्राय: “$50/month” वा “$200/month” हो — जानाजानी “$5,000” होइन।

App तहमा। आफ्नो आफ्नै tracking सँग provider cap को पूरक गर्नुहोस्। हरेक call को cost अनुमान लाई database मा log गर्नुहोस्। एक cron job (वा middleware) ले running total जाँच गर्दछ र बजेट पुगेपछि नयाँ calls स्वीकार गर्न रोक्दछ। प्रयोगकर्ताहरूलाई स्पष्ट सन्देश देखाउनुहोस्: “दैनिक बजेट पुग्यो; service NPT मध्यरातमा फेरि सुरु हुनेछ।”

दुई layers को मतलब एउटा असफल हुँदा तपाईंलाई नडुबाउँदैन।

Layer 2 — प्रति-प्रयोगकर्ता quota

केही प्रयोगकर्ताहरू, केही scripts, केही bots ले औसत प्रयोगकर्ताहरू भन्दा धेरै requests पठाउँछन्। कुनै एकल प्रयोगकर्ताले कति उपभोग गर्न सक्दछ त्यो cap गर्नुहोस्।

एउटा simple key-value store (Redis) प्रयोग गर्ने न्यूनतम in-Python quota:

import redis
import time

r = redis.Redis()

DAILY_CALL_LIMIT = 100
DAILY_TOKEN_LIMIT = 50_000


def check_and_record_usage(user_id: str, tokens_used: int) -> bool:
    """Return True if within quota; False if the user has exceeded it today."""
    day = time.strftime("%Y-%m-%d")

    calls_key = f"quota:{user_id}:{day}:calls"
    tokens_key = f"quota:{user_id}:{day}:tokens"

    calls = int(r.get(calls_key) or 0)
    tokens = int(r.get(tokens_key) or 0)

    if calls >= DAILY_CALL_LIMIT or tokens + tokens_used > DAILY_TOKEN_LIMIT:
        return False

    r.incr(calls_key)
    r.incrby(tokens_key, tokens_used)
    r.expire(calls_key, 86_400 * 2)
    r.expire(tokens_key, 86_400 * 2)
    return True

आफ्नो endpoint मा:

@app.post("/summarise")
def summarise(req: SummariseRequest, user_id: str = Depends(get_current_user)):
    if not check_and_record_usage(user_id, estimated_tokens(req)):
        raise HTTPException(
            status_code=429,
            detail="Daily quota reached. Please try again tomorrow.",
        )
    # ... normal handling

Quota का दुई dimensions: call count (runaway loops रोक्दछ) र token consumption (एक प्रयोगकर्ताले धेरै पटक ठूला inputs submit गर्न रोक्दछ)। दुबै track गर्नुहोस्।

Free tier vs. paid tier। एक real उत्पादमा, तपाईंसँग सम्भवतः दुई quota tiers छन्: सानो free-tier daily limit र ठूलो paid-tier limit। जाँच उही हो; प्रयोगकर्ताको plan मा आधारित number मात्र परिवर्तन हुन्छ।

Layer 3 — प्रति-request cap

रक्षाको अन्तिम रेखा: कुनै एकल call ले परिभाषित आकार भन्दा बढी हुन सक्दैन।

MAX_INPUT_CHARS = 10_000
MAX_OUTPUT_TOKENS = 500

@app.post("/summarise")
def summarise(req: SummariseRequest):
    if len(req.text) > MAX_INPUT_CHARS:
        raise HTTPException(400, "Text exceeds maximum length.")

    response = client.messages.create(
        model="claude-3-5-sonnet-latest",
        max_tokens=MAX_OUTPUT_TOKENS,   # hard cap on output length
        messages=[{"role": "user", "content": build_prompt(req)}],
    )
    ...

Input cap — सीमामा oversized input अस्वीकार गर्नुहोस्। दस हजार characters कुनै वैध summarisation ले चाहिने भन्दा बढी हो; 5MB payload लगभग सधैँ abuse वा bug हो।
Output cap — API call मा max_tokens। यो केवल cost को लागि होइन; लामा outputs ले प्रतिक्रियाहरूलाई slow पनि बनाउँछन् र quality घटाउँछन्। यसलाई कम सेट गर्नुहोस् जबसम्म तपाईंलाई विशेष रूपमा लामा outputs चाहिँदैन।

“असामान्य” कस्तो देखिन्छ

एकपटक तपाईंको quotas र caps ठाउँमा छन्, near-misses log गर्नुहोस्। एक प्रयोगकर्ता जसले तीन लगातार दिन daily quota को 95% हिट गर्दछ, या त वास्तवमा भारी-प्रयोग हो (paid tier बारे सम्पर्क गर्न लायक) वा bot behavior हो (जाँच गर्न लायक)।

if calls > DAILY_CALL_LIMIT * 0.9:
    log_event("quota_near_limit", user_id=user_id, calls=calls)

सानो बानी; महिनौंमा ठूलो payoff।

Rate limits, संक्षेपमा

slowapi library (खण्ड 1.2 मा introduced) ले rate limits स्वच्छ रूपमा सम्हाल्दछ:

from slowapi import Limiter
from slowapi.util import get_remote_address

limiter = Limiter(key_func=get_remote_address)

@app.post("/summarise")
@limiter.limit("10/minute")     # by IP
def summarise(request: Request, req: SummariseRequest):
    ...

राम्रो: प्रयोगकर्ता ID द्वारा rate-limit गर्नुहोस् एकपटक तपाईंसँग authentication छ:

def get_user_key(request):
    return request.state.user_id

limiter = Limiter(key_func=get_user_key)

प्रति प्रयोगकर्ता प्रति मिनेट दस requests interactive AI services को लागि उचित default हो। authentication सँग वैध high-volume use cases को लागि बढाउनुहोस्।

एकसाथ राख्ने — layer stack

मोडेल call गर्ने endpoint को लागि, guard sequence यस्तो देखिन्छ:

@app.post("/summarise")
@limiter.limit("10/minute")
def summarise(req: SummariseRequest, user_id: str = Depends(get_current_user)):
    # Layer 3 — per-request
    if len(req.text) > MAX_INPUT_CHARS:
        raise HTTPException(400, "Text too long.")

    # Layer 2 — per-user quota
    if not check_and_record_usage(user_id, estimated_tokens(req)):
        raise HTTPException(429, "Daily quota reached.")

    # Layer 1 — total budget (in middleware, before the request even arrives)
    # handled by budget_middleware() above

    response = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=MAX_OUTPUT_TOKENS,
        messages=[...],
    )
    ...

हरेक LLM-facing endpoint यस जस्तै देखिनुपर्दछ। हरेक।

Limits communicate गर्नुहोस्

जब प्रयोगकर्ताले limit हिट गर्दछ, तिनीहरूसँग ईमानदार हुनुहोस्:

“तपाईंले 100 सन्देशहरूको आफ्नो दैनिक limit पुग्नुभयो। यो NPT मध्यरातमा reset हुन्छ।”
“यो service आफ्नो मासिक बजेट भन्दा माथि छ। यो 1st मा फेरि सुरु हुनेछ। माफ गर्नुहोस्।”
“तपाईंको input धेरै लामो छ (12,000 chars)। कृपया 10,000 वा कमको लागि छोटो गर्नुहोस्।”

प्रयोगकर्ताहरूले जब बुझ्दछन् limits सहन्छन्। Silent failures ले अविश्वास उत्पादन गर्दछ। रहस्यमय errors ले क्रोध उत्पादन गर्दछ। एक स्पष्ट, मैत्रीपूर्ण quota सन्देशले सम्बन्धलाई अक्षुण्ण राख्दछ।

आफ्नो बुझाइ जाँच्नुहोस्

Quick check

—

एक टिमले 'हामी आवश्यक भएमा limits सेट गर्नेछौँ' सँग chatbot ship गर्दछ। एक साथीले यसलाई Facebook मा share गर्दछ र यो रातारात viral हुन्छ। ईमानदार अपेक्षित परिणाम के हो?

Chatbot राम्रोसँग काम गर्दछ; धेरै प्रयोगकर्ताहरू राम्रो समाचार हो।
कुल बजेट cap, प्रति-प्रयोगकर्ता quota, वा प्रति-request cap बिना, एउटा viral क्षणले घण्टौंमा provider account balance जल्न सक्दछ। टिम Rs 200,000 invoice (वा खराब: तिनीहरूको card decline भएपछि locked-out API access) को साथ ब्युँझन्छ, र सुन्दर chatbot अब एक cautionary कथा हो। 'हामी आवश्यक भएमा limits सेट गर्नेछौँ' प्लान त्यो प्लान हो जसले businesses लाई अन्त्य गर्दछ। हरेक LLM-facing endpoint तीनै layers सँग ship गर्दछ, वा यो ship गर्दैन।
तिनीहरूले cheaper provider मा host गर्नुपर्थ्यो।
तिनीहरूले सानो मोडेल प्रयोग गर्नुपर्थ्यो।