Paritok token gateway: ஏஜென்ட் கட்டணத்தை குறைப்பது எப்படி?

Paritok ஒரு கோரிக்கையை எவ்வாறு கையாள்கிறது

Paritok என்பது ஒரு token gateway ஆகும்: இது உங்கள் coding agent-க்கும் model API-க்கும் இடையில் அமர்ந்து, ஒவ்வொரு கோரிக்கையையும் முன்னோக்கி அனுப்பும் முன் சுருக்கும் ஒரு proxy ஆகும். உங்கள் agent, provider-க்கு பதிலாக http://127.0.0.1:8080-உடன் தொடர்பு கொள்கிறது. இந்த proxy, tool schemas, file reads, tool output மற்றும் பழைய உரையாடல் சுற்றுகளை (turns) மாற்றி எழுதி, சிறிய அளவிலான தரவை (payload) upstream-க்கு அனுப்பி, பதிலைப் பெறுகிறது.

Provider-க்கு வந்து சேரும் தரவின் அளவிற்கே அவர்கள் கட்டணம் வசூலிப்பார்கள், எனவே சிறிய payload என்பது குறைந்த கட்டணத்தைக் குறிக்கும். இதுவே இதன் அடிப்படை நோக்கம். இது "உங்கள் context நீண்ட காலம் நீடிக்கும்" என்ற கூற்றிலிருந்து மாறுபட்டது; வெறும் நேர்த்தியான கருவியாக மட்டுமன்றி, இது பயனுள்ள கருவியாக இருப்பதற்குக் காரணமும் இதுவே.

இந்தத் திட்டம் புதியது. இதன் முதல் பொது வெளியீட்டுத் tags ஜூலை 2026-ல் இடப்பட்டுள்ளன, தற்போதைய tag v1.3.0, ஆகஸ்ட் 5, 2026 தேதியிட்டது. இதன் weights மற்றும் gateway code ஆகியவை Apache 2.0 உரிமத்தின் கீழ் உள்ளன. இதன் compression model, Qwen3-4B-Instruct-2507-ன் மீது அமைக்கப்பட்ட ஒரு LoRA (low-rank adaptation) adapter ஆகும்; இது உண்மையான coding-agent செயல்பாடுகளிலிருந்து பெறப்பட்ட 45,000 teacher-distilled மாதிரிகளைக் கொண்டு பயிற்றுவிக்கப்பட்டது.

இது ஏன் context trimming அல்ல

Trimming என்பது நீக்குவதாகும். ஒரு agent அதன் context வரம்பை நெருங்கி, பழைய உரையாடல்களை நீக்கும்போது, 3-வது turn-ல் அது படித்த கோப்பு மறைந்துவிடும். 20-வது turn-ல் அந்த கோப்பு தேவைப்பட்டால், அது மீண்டும் அதை வாசிக்கும், எனவே அந்த tokens-க்கு நீங்கள் இரண்டாவது முறையாக கட்டணம் செலுத்த வேண்டியிருக்கும். அந்த சேமிப்பு ஒரு கடன் போன்றது.

Paritok ஒரு பகுதியை சுருக்கமான வடிவமாகவும் ஒரு tag-ஆகவும் மாற்றுகிறது, [REF:id], மேலும் முழு உரையையும் proxy-ல் வைத்திருக்கிறது. read_original அல்லது expand_context-ஐ அழைப்பதன் மூலம் model அந்த பகுதியை மீட்டெடுக்கிறது. இது தோல்வி அடையும் முறையை மாற்றுகிறது. Trimmer மறப்பதன் மூலம் தோல்வியடைகிறது, அது உங்களுக்குத் தெரிவிப்பதும் இல்லை. Compressor ஒரு இழப்புள்ள சுருக்கத்தை (lossy summary) model-க்கு வழங்குவதன் மூலம் தோல்வியடைகிறது, மேலும் சுருக்கம் போதுமானதாக இல்லாதபோது model அசல் உரையை கேட்க முடியும்.

Tool filter-ம் இதேபோல் செயல்படுகிறது. வடிகட்டப்பட்ட tool schemas நீக்கப்படுவதற்குப் பதிலாக stub செய்யப்படுகின்றன, மேலும் gateway_search_tools-ஐ அழைப்பதன் மூலம் model ஒன்றை மீட்டெடுக்கிறது. இது முக்கியமானது, ஏனெனில் ஒரு tool-ஐ நிரந்தரமாக மறைக்கும் filter, உங்கள் agent-ன் செயல்பாட்டுத் திறனை மாற்றுகிறது, மேலும் அமைதியாகத் தோல்வியடைந்த ஒரு பணியின் மூலம் மட்டுமே நீங்கள் அதை அறிந்துகொள்ள முடியும்.

மூன்று நெம்புகோல்கள் மற்றும் இலவசமான ஒன்று

முதல் நெம்புகோல் tool-schema filter ஆகும். ஒவ்வொரு கோரிக்கையும் முழுமையான tools வரிசையைச் சுமந்து செல்கிறது. சில MCP (model context protocol) servers இணைக்கப்பட்டிருக்கும் Claude Code சுழற்சியில், அந்தத் தொகுதி சுமார் 29,000 tokens அளவுள்ளதாக இருக்கும். இந்த filter, பயனரின் கோரிக்கையையும் ஒவ்வொரு tool விளக்கத்தையும் BAAI/bge-small-en-v1.5 (130 MB அளவுள்ள embedding model) மூலம் உட்பொதிக்கிறது (embed). இது பொருத்தமான கருவிகளை மட்டும் வைத்துக்கொண்டு, மற்றவற்றை நீக்குகிறது. இதனால் அந்தத் தொகுதி சுமார் 8,000 tokens ஆகக் குறைகிறது. இந்த embedding model CPU-வில் இயங்குகிறது.

இரண்டாவது நெம்புகோல் content compression ஆகும்; இதற்குத்தான் GPU-வில் 4B model தேவைப்படுகிறது. கோப்பு வாசிப்புகள் (file reads), tool output மற்றும் வரலாறு ஆகியவை அவற்றின் அசல் அளவில் 25.7% ஆகச் சுருக்கப்படுகின்றன. அந்த 74% என்ற தலைப்பு இதிலிருந்துதான் வருகிறது. இதை கவனமாகப் படிக்கவும்: 74% என்பது சுருக்கப்படும் உள்ளடக்கத்தின் சுருக்க விகிதமே தவிர, உங்கள் கட்டணத்தில் குறைக்கப்படும் தொகை அல்ல.

மூன்றாவது நெம்புகோல் history summarization ஆகும். context budget நிறைந்தவுடன், சமீபத்திய காலத்திற்கு அப்பால் உள்ள சுழற்சிகள் சுருக்கப்படுகின்றன. இதனால் வரம்பை எட்டுவதற்குப் பதிலாக நீண்ட session தொடர்ந்து இயங்குகிறது.

இரண்டாவது நெம்புகோலுக்கு மட்டுமே GPU தேவைப்படுகிறது. இந்தப் பக்கத்தில் உள்ள மிக முக்கியமான வாக்கியம் இதுதான். pip install "paritok[toolselect]" சாதாரண CPU VPS-ல் tool filter-ஐ வழங்குகிறது, மேலும் இது மாதந்தோறும் உங்களுக்கு எந்தச் செலவும் வைக்காத தயாரிப்பின் பாதியாகும். ஒரு GPU-வை வாடகைக்கு எடுக்கும் முன் இதை முயற்சி செய்து பாருங்கள்.

இந்தத் திட்டம் எதை அளவிட்டது மற்றும் எந்தச் சூழலில் அளவிட்டது

[
  {
    "label": "Paritok-4B-v1",
    "compressed_to_pct": 25.7,
    "quality_retained_pct": 86.5
  },
  {
    "label": "gpt-4.1-mini",
    "compressed_to_pct": 50.2,
    "quality_retained_pct": 85.6
  },
  {
    "label": "gpt-5",
    "compressed_to_pct": 61.9,
    "quality_retained_pct": 93.6
  }
]

இவை திட்டத்தின் சொந்த வெளியீட்டு புள்ளிவிவரங்கள்; இவை SWE-bench Lite-ஐப் பயன்படுத்தி, அதன் சொந்த சோதனைச் சூழலில் (harness) அளவிடப்பட்டவை. Paritok-4B-v1 உள்ளடக்கத்தை அதன் அசல் அளவில் 25.7% ஆகச் சுருக்குகிறது, அதே சமயம் சுருக்கப்படாத நிலையில் இருந்த solve rate-ல் 86.5% அளவைத் தக்கவைத்துக் கொள்கிறது. சுருக்குவதற்கு gpt-5-ஐப் பயன்படுத்தினால் அதிக தரம் தக்கவைக்கப்படுகிறது, அதாவது 93.6%, ஆனால் அது 61.9% அளவுக்கு மட்டுமே சுருக்குகிறது. மேலும், frontier விலையைச் சேமிப்பதற்காக நீங்கள் frontier விலையையே செலவிட வேண்டியிருக்கும்.

தரவு வரிசையை (quality column) கவனமாகப் பார்க்கவும். 86.5% solve rate-ஐத் தக்கவைத்தல் என்பது, சுருக்கப்படாத நிலையில் தீர்க்கப்பட்ட சிக்கல்கள் சுருக்கப்பட்ட நிலையில் தோல்வியடைந்தன என்று பொருள்; இது ஏறக்குறைய ஏழு சிக்கல்களில் ஒன்று. ஒரு benchmark-ல் இது வெறும் அட்டவணை எண். உங்கள் repository-ல் இது நீங்கள் இரண்டு முறை இயக்கும் ஒரு பணி.

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

வரலாறு (history) சேகரிக்கப்படுவதாலும், அந்த வரலாறுதான் சுருக்கப்படுவதாலும், ஒரு session இயங்க இயங்க end-to-end சேமிப்பு அதிகரிக்கிறது. இந்தத் திட்டம் ஒரு single turn-ல் சுமார் 25% சேமிப்பையும், 5-வது turn-ல் 39% சேமிப்பையும், 20-வது turn-ல் 63% சேமிப்பையும் தெரிவிக்கிறது. இந்த வளர்ச்சி எங்கே நிற்கிறது என்பதையும் அது குறிப்பிடுகிறது: 200,000 token budget-ல், 8 முதல் 12-வது turn-க்கு அருகில், ஒரு turn-க்கு சுமார் 48,000 tokens என்ற அளவில் முழுமையான சேமிப்பு சமநிலையை அடைகிறது. ஏனெனில், context முழுமையடைந்தவுடன் வரலாறு வளர்வது நின்றுவிடுகிறது. பரவலாகக் குறிப்பிடப்படும் "85%-க்கு மேல்" என்ற புள்ளிவிவரம், context முழுமையாக நிரம்பிய session-களை விவரிக்கிறது. இதுவே சிறந்த சூழல் என்பதால், இதை அடிப்படையாகக் கொண்டு திட்டமிட வேண்டாம்.

24GB GPU, Paritok-க்கு லாபகரமானதா?

இந்த அளவிலான ஒரு model-க்கு 24 GB card பொதுவாக வாடகைக்கு எடுக்கப்படும் ஒரு அலகாகும். 7 August 2026 நிலவரப்படி, 24 GB கொண்ட RTX 4090-ன் சராசரி on-demand வாடகை ஒரு மணி நேரத்திற்கு $0.44 ஆகும், மிகக் குறைந்த விலையாக $0.20 வரை கிடைக்கிறது. $0.44-ஐ கணக்கில் கொள்வோம். மாதம் முழுவதும் இயங்கினால், அது 730 மணி நேரம், அதாவது $321. வேலை நேரத்தில் மட்டும், அதாவது ஒரு நாளைக்கு 8 மணி நேரம் வீதம் 22 நாட்களுக்கு இயக்கினால், அது 176 மணி நேரம், அதாவது $77.

இப்போது token குறைப்பை டாலர் குறைப்பாக மாற்றுவோம். இந்த குறைப்பு input tokens-க்கு மட்டுமே பொருந்தும். Output tokens proxy வழியாக மாற்றமின்றி செல்வதால், அவை எந்த மாற்றத்தையும் அடைவதில்லை. ஒரு coding agent-க்கு இயல்பாக இருக்கும் 80% input tokens-ஐ உங்கள் செலவில் கணக்கில் கொண்டு, உங்கள் சொந்த bill-உடன் ஒப்பிட்டுப் பாருங்கள். உங்கள் டாலர் சேமிப்பு என்பது token குறைப்புடன் 0.8-ஐப் பெருக்குவதற்குச் சமம்.

[
  {
    "label": "Turn 5 (39% saved)",
    "bill_always_on_usd": "1,030",
    "bill_workday_only_usd": 248
  },
  {
    "label": "Turn 20 (63% saved)",
    "bill_always_on_usd": 637,
    "bill_workday_only_usd": 154
  },
  {
    "label": "Saturated (85% saved)",
    "bill_always_on_usd": 472,
    "bill_workday_only_usd": 114
  }
]

85% saturated-session அளவில், நீங்கள் bill-ல் 68%-ஐச் சேமிக்கிறீர்கள். எனவே, உங்கள் மாதாந்திர agent செலவு $472-ஐத் தாண்டும்போது, எப்போதும் இயங்கும் card-க்கான செலவு ஈடுசெய்யப்படுகிறது. வேலை நேரத்தில் மட்டும் இயக்கினால், இந்த அளவு $114 ஆக இருக்கும். 63% turn-20 அளவில், இவை $637 மற்றும் $154 ஆக மாறுகின்றன. குறுகிய sessions-ல் காணப்படும் 39% turn-5 அளவில், card-ஐ வாடகைக்கு எடுப்பது லாபகரமாக இருக்க மாதம் சுமார் $1,030 செலவு தேவைப்படுகிறது.

இந்த அட்டவணை காட்டுவதை விட இரண்டு விஷயங்கள் இதைச் சாதகமாக்குகின்றன. இந்த model-க்கு 24 GB தேவைப்படுவதில்லை: q4 build சுமார் 2.5 GB மற்றும் bf16 build சுமார் 8 GB மட்டுமே. எனவே, சிறிய card அல்லது ஏற்கனவே பிற பணிகளுக்குப் பயன்படுத்தும் GPU box-ஐப் பயன்படுத்தினால், அட்டவணையில் உள்ள அனைத்து எண்களும் குறையும். யாரும் coding செய்யாதபோது instance-ஐ நிறுத்துவதுதான் இதில் மிகப்பெரிய சேமிப்பு காரணி, ஏனெனில் இது வாடகையை நான்கில் மூன்று பங்கு குறைக்கிறது.

ஒரு விஷயம் இதைச் சவாலாக்குகிறது. Compression செயல்முறை கூடுதல் வேலைப்பளுவை உருவாக்குகிறது. 4B model compress செய்யும் ஒவ்வொரு token-ம் அது படித்து எழுத வேண்டிய ஒன்றாக இருப்பதால், ஒவ்வொரு agent turn-லும் latency அதிகரிக்கிறது. மணிநேர அடிப்படையில் வாடகைக்கு எடுக்கும் card-ல், இந்தச் செலவு invoice-ல் தெரியாமல் காத்திருப்பு நேரமாக வெளிப்படும், எனவே நீங்கள் அதை உணரும் வரை கவனிப்பது கடினம்.

நீங்கள் வாடகைக்கு எடுக்கப்படும் GPU மணிநேரங்களை API tokens-உடன் ஒப்பிட்டுப் பார்க்கிறீர்கள் என்றால், GPU VPS மற்றும் API tokens-க்கு இடையிலான break-even கணக்கீடு inference-க்கு இதே கணித முறையைப் பயன்படுத்துகிறது.

VPS-ல் Paritok gateway-ஐ இயக்குதல்

Python 3.10 அல்லது அதற்குப் பிந்தைய பதிப்பு அவசியம். Ubuntu 24.04-ல் Python 3.12 உள்ளதால், CPU-மட்டும் பயன்படுத்தும் பகுதிக்கு சாதாரண VPS image போதுமானது.

sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"

பதிப்பை (version) உறுதிப்படுத்தவும். இந்த repository-ல் 29 July 2026 அன்று v1.2.8 மற்றும் 5 August 2026 அன்று v1.3.0 வெளியிடப்பட்டன. இவ்வளவு வேகமான மாற்றங்களைக் கொண்ட திட்டங்களில், ஒவ்வொரு release-க்கும் இடையே config keys-ன் பெயர்கள் மாறக்கூடும். வெறும் pip install paritok அல்லது git clone-ஐ main-ல் பயன்படுத்துவது, அடுத்த வாரம் வேறொரு gateway-ஐ உங்களுக்குத் தரும். நீங்கள் அளந்த எண்கள் எந்தப் பதிப்பால் வந்தன என்பதற்கான எந்தப் பதிவும் இருக்காது.

இதன் இயல்புநிலை (default) backend Ollama ஆகும். முதலில் model-ஐ pull செய்யவும், பிறகு proxy எதிர்பார்க்கும் அதன் சுருக்கமான பெயரை வழங்கவும்.

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

அதற்கு அருகில் paritok.yaml-ஐ எழுதவும். உங்கள் hardware-லேயே compression-ஐத் தக்கவைப்பது use_gpu_server: false தான்.

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

மேலே உள்ள அனைத்திற்கும் paritok up ஒரு குறுக்குவழி: இது model விடுபட்டிருந்தால் அதை pull செய்து, 8080 port-ல் proxy-ஐத் தொடங்கும். ஒரு agent-ஐ அதனுடன் இணைக்கும் முன் proxy-ஐச் சரிபார்க்கவும்.

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

/health ஒரு சிறிய JSON object-ஐத் தரும், அதில் "status":"ok" மற்றும் version string இருக்கும். /stats compression-ன் மொத்த அளவையும், proxy சேமித்ததாகக் கருதும் மதிப்பீட்டையும் தரும். இந்த மதிப்பீட்டை proxy தனது வேலையைத் தானே மதிப்பிடுவதாகக் கருதி, உங்கள் provider-ன் usage பக்கத்துடன் ஒப்பிட்டு உறுதிப்படுத்தவும்.

வசதியை விட throughput முக்கியம் என்றால், base model-க்கு மேல் adapter-ஐ இயக்க vLLM-ஐப் பயன்படுத்தவும்.

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

Ollama-வை அமைப்பது விரைவானது. vLLM ஒரே நேரத்தில் வரும் கோரிக்கைகளை (concurrent requests) சிறப்பாகக் கையாளும்; ஒன்றுக்கும் மேற்பட்ட agent-கள் ஒரே server-ஐப் பயன்படுத்தும்போது இது முக்கியமானது. Ollama மற்றும் vLLM-க்கு இடையிலான நடைமுறை வேறுபாடுகள் இதற்கான முடிவை எடுக்க உங்களுக்கு உதவும்.

Base URL environment variables மூலம் agent-ஐ proxy-க்குச் சுட்டிக்காட்டவும்.

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

Codex CLI OPENAI_BASE_URL-ஐப் புறக்கணிக்கும், எனவே paritok.yaml-ல் codex.enabled: true அமைக்கப்பட்டிருக்கும்போது, இந்தத் திட்டம் உங்களுக்காக ~/.codex/config.toml-ஐ எழுதும். இந்த variable-ஐ மட்டும் export செய்தால், Codex நேரடியாக provider-உடன் பேசும். நீங்கள் வேலை செய்யும்போது /stats counter நகரவில்லை என்றால், அதுவே இதற்கான அறிகுறியாகும்.

Listener-ஐ எப்போதும் 127.0.0.1-ல் வைத்திருக்கவும், 0.0.0.0-ல் வைக்க வேண்டாம். Proxy உங்கள் provider API key-ஐ upstream-க்கு அனுப்பும். எனவே, இணையத்திலிருந்து அணுகக்கூடிய proxy, அந்த key-க்கான open relay ஆகிவிடும்: அந்த port-ஐக் கண்டுபிடிப்பவர், key-ஐப் பார்க்காமலேயே உங்கள் பணத்தைச் செலவிட முடியும். Port-ஐத் திறப்பதற்குப் பதிலாக, SSH tunnel அல்லது VPN மூலம் laptop-லிருந்து அதை அணுகவும்.

Reboot-க்குப் பிறகும் இயங்குவதற்கு, இதை systemd-ன் கீழ் இயக்கவும். உங்கள் install-க்கு ஏற்ப paths-ஐ மாற்றியமைக்கவும்.

[Unit]
Description=Paritok compression proxy
After=network-online.target

[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now paritok மூலம் அதை enable செய்யவும், பிறகு மீண்டும் /health-ஐ curl செய்யவும். ஒரு unit தொடங்கி உடனடியாக நின்றுவிடுகிறது என்றால், config file path தவறாக உள்ளது என்று பொருள்; journalctl -u paritok -n 50 அதற்கான காரணத்தைக் காட்டும்.

Hosted விருப்பம் மற்றும் அதன் செலவுகள்

இந்தத் திட்டம் compression-ஐ ஒரு சேவையாகவும் வழங்குகிறது. use_gpu_server: true-ஐ ஒரு API key மூலம் அமைத்தால், 4B model அவர்களின் hardware-ல் இயங்கும். இதன் விலை ஒரு மில்லியன் tokens-க்கு $0.30 ஆகும். அவர்களின் ஆவணங்களின்படி, ஆகஸ்ட் 2026 இறுதி வரை இது இலவசம். இது GPU வாடகை மற்றும் மேலே குறிப்பிட்டுள்ள அனைத்து செயல்பாட்டு வேலைகளையும் தவிர்க்க உதவுகிறது.

இதன் பொருள், உங்கள் prompts மற்றும் உங்கள் agent படிக்கும் கோப்புகள் உங்கள் machine-ஐ விட்டு வெளியேறி, உங்கள் model provider-ஐ அடைவதற்கு முன்பே ஒரு மூன்றாம் தரப்பினரைச் சென்றடையும் என்பதாகும். இந்தத் தேவையற்ற பரிமாற்றத்தைத் தவிர்க்கவே self-hosting பயன்படுத்தப்படுகிறது. அந்த flag-ஐ அமைப்பதற்கு முன், நீங்கள் எதற்கு முன்னுரிமை அளிக்கிறீர்கள் என்பதை முடிவு செய்யுங்கள். ஏனெனில், flag-ஐ மாற்றுவது ஒரு வரியிலான வேலை, ஆனால் அதன் விளைவு அத்தகையது அல்ல.

உங்கள் சொந்த முன்னும் பின்னும் நிலையை எவ்வாறு அளவிடுவது

வெளியிடப்பட்ட எண்கள் திட்டத்தின் எண்கள், இவை SWE-bench Lite-ல் உள்ள திட்டத்தின் சோதனை அமைப்பிலிருந்து பெறப்பட்டவை. உங்கள் களஞ்சியம் (repository) SWE-bench Lite அல்ல. எனவே, உங்கள் சொந்த அளவீடுகளை நீங்களே மேற்கொள்ளுங்கள்.

• ஒரு சாதாரண வாரத்தை, எந்த proxy-யும் இல்லாமல் இயக்கவும். உங்கள் provider-ன் usage பக்கத்திலிருந்து input tokens, cache-read tokens மற்றும் output tokens ஆகியவற்றை தனித்தனி வரிகளாகப் பதிவு செய்யவும்; மொத்த டாலர் மதிப்பாக மட்டும் பார்க்க வேண்டாம்.
• அடுத்த வாரத்தை, அதே வகையான பணிகளைச் செய்து, proxy-யை முன்னால் வைத்து இயக்கவும்.
• Input மற்றும் cache-read வரிகளை ஒப்பிடவும். Output மாறாமல் இருக்க வேண்டும், ஏனெனில் அதை எதுவும் சுருக்குவதில்லை. Output கணிசமாக மாறியிருந்தால், proxy-யைத் தவிர வேறு ஏதோ ஒன்று மாறியுள்ளது என்று அர்த்தம்.
• நீங்கள் மீண்டும் செய்ய வேண்டியிருந்த பணிகளின் எண்ணிக்கையைக் கணக்கிடுங்கள். இது தரத்தின் ஒரு பாதியாகும், இதை எந்த dashboard-ம் காட்டுவதில்லை.
• மொத்த மதிப்புகளை ஒப்பிடுவதற்கு முன், இரண்டாவது வாரத்தின் GPU hours-ஐ அதனுடன் சேர்க்கவும்.

Input மற்றும் output ஆகிய இரண்டிற்கும் விலை மாறுபடுவதாலும், compressor ஒன்று மட்டுமே அவற்றில் ஒன்றைப் பாதிப்பதாலும், இரண்டையும் பிரித்துப் பார்ப்பது முக்கியம். ஆகஸ்ட் 2026 நிலவரப்படி, Claude Sonnet 4.6-ன் விலை ஒரு மில்லியன் input tokens-க்கு $3 மற்றும் ஒரு மில்லியன் output tokens-க்கு $15 ஆகும். ஒரு prompt-cache read என்பது input விலையில் 10%, அதாவது ஒரு மில்லியனுக்கு $0.30 ஆகும். Input மற்றும் output token விலைகளுக்கு இடையிலான இடைவெளி தான், input-side compressor உங்களுக்குப் பயனுள்ளதா என்பதைத் தீர்மானிக்கிறது. Claude Code-ன் tokens உண்மையில் எங்கே செல்கின்றன என்பது, உங்கள் context-ல் எந்தப் பகுதி சுருக்குவதற்குத் தகுந்த அளவு பெரியது என்பதை உங்களுக்குத் தெரிவிக்கும்.

Prompt caching, குறிப்பாக tool-filter கணக்கீட்டைச் சிக்கலாக்குகிறது. Tool block கோரிக்கையின் தொடக்கத்தில் இருப்பதால், முதல் முறைக்குப் பிறகு அது பொதுவாக 10% input விலையில் cache hit ஆகிறது. Cached block-லிருந்து 21,000 tokens-ஐக் குறைப்பது, ஒரு மில்லியனுக்கு $0.30 வீதம் 21,000 tokens-ஐச் சேமிக்கிறது, அதாவது ஒரு முறைக்கு சுமார் $0.006 சேமிப்பு. இது, cache செய்யப்படாத விலையில் கணக்கிட்டால் கிடைக்கும் $0.063-ஐ விடக் குறைவு. இந்தத் திட்டம், filtered block-ஐ session முழுவதும் அப்படியே வைத்திருக்கிறது, எனவே cached prefix மாறுவதில்லை. ஒவ்வொரு முறையும் tool-களை மீண்டும் தேர்ந்தெடுக்கும் ஒரு filter, அந்த prefix-ஐச் செல்லாததாக்கி, சேமிப்பதை விட அதிகச் செலவை உண்டாக்கும்.

இன்னும் சரிபார்க்கப்படாதவை

மேலே உள்ள ஒவ்வொரு செயல்திறன் மதிப்பும் அந்தத் திட்டத்தின் தரவுகளிலிருந்தே பெறப்பட்டவை. SWE-bench Lite முடிவுகளைத் தனிப்பட்ட முறையில் யாரும் மீண்டும் உறுதிப்படுத்தவில்லை. மேலும், ஜூலை 2026-ல் இடப்பட்ட முதல் tags-ஐக் கருத்தில் கொண்டால், இந்த code-க்கு நீண்டகால செயல்பாட்டு வரலாறு இல்லை. compression rate மற்றும் quality-retained ஆகிய இரண்டுமே, அந்த முடிவுகளால் பயனடையும் தரப்பினராலேயே அளவிடப்பட்டுள்ளன. இது அந்தத் தரவுகள் தவறானவை என்று அர்த்தமல்ல. அவை இன்னும் உறுதிப்படுத்தப்படாதவை, எனவே நீங்கள் நீங்களாகவே தயாரித்த தரவுகளை அணுகுவது போல இவற்றை அணுகக்கூடாது.

உங்கள் setup-ல் தவறு இருப்பதாகக் கருதும் முன், ஆவணப்படுத்தப்பட்ட ஒரு செயல்பாட்டைத் தெரிந்துகொள்வது அவசியம். இந்த tool-ல் பயன்படுத்தப்படும் embedding model, startup-ல் ஏற்றப்படாமல் முதல் request வரும்போதுதான் ஏற்றப்படுகிறது. எனவே, 10 முதல் 15 வினாடிகள் வரை warm-up தேவைப்படும் என்றும், அதன் பிறகு ஒவ்வொரு call-க்கும் சுமார் 15 ms எடுக்கும் என்றும் திட்டம் குறிப்பிடுகிறது. proxy தொடங்கிய பிறகு ஒரு தேவையற்ற request-ஐ அனுப்பி வைத்தால், உங்கள் முதல் உண்மையான agent turn தாமதமாவது போலத் தெரியாது.

ஒரு மதிய நேரத்தில் நீங்களே சரிபார்க்கக்கூடிய நான்கு விஷயங்கள்: proxy தொடங்கப்பட்டு தொடர்ந்து இயங்குகிறதா, நீங்கள் வேலை செய்யும்போது /stats மாறுகிறதா, உங்கள் provider-ன் input-token அளவு உண்மையில் குறைகிறதா, மற்றும் agent வேலையை முழுமையாக முடிக்கிறதா என்பவை. வெளியிடப்பட்ட எந்த benchmark-ஐ விடவும், உங்கள் setup-க்கு இவைதான் சிறந்த முடிவுகளைத் தரும்.

உங்கள் பிற கருவிகளுடன் இது எங்கே பொருந்துகிறது என்பது குறித்து: ஒரு self-hosted LiteLLM gateway என்பது அதன் உள்ளடக்கத்தை மாற்றாமல் request-களை வழிநடத்தி அளவிடும். எனவே, இவை இரண்டும் வெவ்வேறு சிக்கல்களைத் தீர்க்கின்றன, இவற்றை ஒன்றிணைத்துப் பயன்படுத்தலாம்; இதில் Paritok, agent-க்கு மிக அருகில் இருக்கும். உங்கள் உண்மையான இலக்கு இந்த குறிப்பிட்ட கருவியைப் பயன்படுத்துவதை விட செலவைக் குறைப்பதாக இருந்தால், ஒரு VPS-ல் இயங்கும் agent-க்கான விரிவான செலவுக் கட்டுப்பாடுகள் என்பதில், எந்தச் செலவுமின்றி முதலில் முயற்சி செய்யக்கூடிய பல மாற்றங்கள் உள்ளன.

FAQ

Paritok எனது API கட்டணத்தைக் குறைக்குமா அல்லது context பயன்பாட்டை மட்டும் குறைக்குமா?

இது கட்டணத்தைக் குறைக்கும், ஏனெனில் கோரிக்கை (request) வழங்குநரைச் சென்றடைவதற்கு முன்பே proxy அதை மாற்றியமைக்கிறது; வழங்குநர் தமக்குக் கிடைக்கும் தரவுகளுக்கே கட்டணம் வசூலிக்கிறார். இந்தச் சேமிப்பின் அளவு தலைப்பில் குறிப்பிடப்பட்டுள்ளதை விடக் குறைவானது. 74% என்பது சுருக்கப்படும் உள்ளடக்கத்தின் சுருக்க விகிதம் (compression rate) மட்டுமே. ஒட்டுமொத்தமாகப் பார்த்தால், ஒரு சுற்றில் (turn) சுமார் 25% மற்றும் 20-வது சுற்றில் 63% சேமிப்பை இந்தத் திட்டம் காட்டுகிறது. மேலும், input tokens மட்டுமே சுருக்கப்படுகின்றன. Output tokens மாற்றமின்றி அப்படியே அனுப்பப்படுகின்றன.

compression model-ஐ self-host செய்ய எனக்கு எவ்வளவு GPU தேவை?

q4 build சுமார் 2.5 GB அளவும், bf16 build சுமார் 8 GB அளவும் கொண்டவை. எனவே, இந்த model ஒரு 24 GB card-ல் தாராளமாகப் பொருந்தும். சிறிய card-களைப் பயன்படுத்தினாலும் வேலை செய்யும், இது உங்கள் லாபக் கணக்கீட்டிற்குச் சாதகமாக அமையும். tool-schema filter-க்கு GPU தேவையில்லை: இது 130 MB அளவுள்ள BAAI/bge-small-en-v1.5 என்ற embedding model-ஐப் பயன்படுத்துகிறது, இது CPU-விலேயே இயங்கும். ஒரு சாதாரண VPS-ல் paritok[toolselect]-ஐ நிறுவினால், சிறிது RAM பயன்பாட்டின் மூலம் tool-block சுருக்கத்தைப் பெறலாம்.

compressor, agent-க்குத் தேவையான ஒன்றை நீக்கிவிட்டால் என்னவாகும்?

எதுவும் நீக்கப்படுவதில்லை. சுருக்கப்பட்ட பகுதிகள் [REF:id] tag-ஐக் கொண்டிருக்கும், மேலும் read_original அல்லது expand_context மூலம் model முழு உரையையும் மீட்டெடுக்கும். வடிகட்டப்பட்ட tool schemas நீக்கப்படாமல், சுருக்கமான வடிவில் (stubbed) வைக்கப்படுகின்றன; model gateway_search_tools மூலம் அவற்றை மீட்டெடுக்கும். உண்மையான ஆபத்து என்னவென்றால், ஒரு கோப்பு விடுபடுவதை விட இது நுட்பமானது: model ஒரு lossy summary-யிலிருந்து செயல்படுகிறது, எனவே அசல் தரவைக் கேட்க வேண்டும் என்பதை அது உணராமல் போகலாம். SWE-bench Lite-ல் குறிப்பிடப்பட்டுள்ள 86.5% quality-retained என்ற புள்ளிவிவரம் இதையே அளவிடுகிறது.

எனது முதல் கோரிக்கை ஏன் 15 வினாடிகள் எடுத்துக்கொள்கிறது?

tool filter-க்குப் பின்னால் உள்ள embedding model, தொடக்கத்திலேயே (startup) ஏற்றப்படாமல், முதல் கோரிக்கையின் போதுதான் ஏற்றப்படுகிறது. இந்தத் திட்டம் 10 முதல் 15 வினாடிகள் warm-up நேரத்தைக் குறிப்பிடுகிறது, அதன் பிறகு ஒவ்வொரு அழைப்பிற்கும் சுமார் 15 ms மட்டுமே ஆகும். proxy-ஐத் தொடங்கிய பிறகு curl-ஐப் பயன்படுத்தி ஒரு தேவையற்ற கோரிக்கையை (throwaway request) அனுப்பினால், முதல் உண்மையான agent turn தாமதமடையாது.

நான் self-hosting-க்கு பதிலாக hosted GPU server-ஐப் பயன்படுத்த வேண்டுமா?

இது GPU வாடகை மற்றும் பராமரிப்புச் செலவை நீக்குகிறது; ஆகஸ்ட் 2026 நிலவரப்படி, செயலாக்கப்படும் பத்து லட்சம் tokens-க்கு $0.30 கட்டணம் வசூலிக்கப்படுகிறது. ஆனால், இது உங்கள் prompts மற்றும் agent படிக்கும் கோப்புகளை, உங்கள் model வழங்குநரைச் சென்றடைவதற்கு முன்பே மூன்றாம் தரப்பினருக்கு அனுப்புகிறது. நீங்கள் உங்கள் கட்டுப்பாட்டில் உள்ள உள்கட்டமைப்பில் குறியீட்டை (code) வைத்திருக்கவே self-hosting செய்கிறீர்கள் என்றால், இந்த அமைப்பு உங்கள் நோக்கத்தையே சிதைத்துவிடும். Self-hosting மூலம் context மற்றும் provider API key ஆகிய இரண்டையும் உங்கள் சொந்த server-லேயே வைத்திருக்க முடியும்.