Paritok token gateway: coding agent کا خرچ کم؟

درخواست پر Paritok کا اثر

Paritok ایک token gateway ہے: یہ ایک proxy ہے جو آپ کے coding agent اور model API کے درمیان کام کرتا ہے اور ہر درخواست کو آگے بھیجنے سے پہلے compress کرتا ہے۔ آپ کا agent provider کے بجائے http://127.0.0.1:8080 سے بات کرتا ہے۔ proxy tool schemas، file reads، tool output اور سابقہ turns کو دوبارہ لکھتا ہے، چھوٹا payload upstream بھیجتا ہے، اور جواب میں کوئی تبدیلی کیے بغیر واپس کرتا ہے۔

Provider آپ سے اس مواد کے لیے billing کرتا ہے جو provider تک پہنچتا ہے، اس لیے چھوٹا payload کم invoice کا باعث بنتا ہے۔ یہی پورا تصور ہے۔ یہ دعوے سے مختلف بات ہے کہ "آپ کا context زیادہ دیر تک برقرار رہتا ہے"، اور یہی وجہ ہے کہ یہ tool صرف ترتیب بہتر بنانے کے بجائے دلچسپ ہے۔

یہ project ابھی نیا ہے۔ اس کے پہلے public tags July 2026 کے ہیں، اور موجودہ tag v1.3.0 ہے، جس کی تاریخ 5 August 2026 ہے۔ weights اور gateway code Apache 2.0 کے تحت ہیں۔ compression model Qwen3-4B-Instruct-2507 پر مبنی LoRA (low-rank adaptation) adapter ہے، جسے حقیقی coding-agent trajectories سے حاصل کردہ 45,000 teacher-distilled samples پر train کیا گیا ہے۔

یہ context trimming کیوں نہیں ہے

Trimming حذف کر دیتی ہے۔ جب کوئی agent اپنی context limit کے قریب پہنچ کر سب سے پرانے turns حذف کرتا ہے تو turn 3 میں پڑھی گئی file ختم ہو جاتی ہے۔ اگر turn 20 پر اسے اسی file کی ضرورت ہو تو وہ file دوبارہ پڑھتا ہے، اور آپ ان tokens کی دوبارہ قیمت ادا کرتے ہیں۔ حاصل ہونے والی بچت عارضی ادھار تھی۔

Paritok کسی segment کو ایک مختصر شکل اور tag، [REF:id]، سے replace کرتا ہے، جبکہ مکمل text proxy پر محفوظ رہتا ہے۔ Model read_original یا expand_context کو call کر کے segment بحال کرتا ہے۔ اس سے failure mode بدل جاتا ہے۔ Trimmer بھولنے کی وجہ سے fail ہوتا ہے، اور آپ کو کبھی نہیں بتاتا۔ Compressor model کو lossily خلاصہ فراہم کرنے کی وجہ سے fail ہوتا ہے، اور جب خلاصہ کافی نہ ہو تو model اصل text طلب کر سکتا ہے۔

Tool filter بھی اسی طرح کام کرتا ہے۔ Filter کیے گئے tool schemas کو remove کرنے کے بجائے stub کیا جاتا ہے، اور model gateway_search_tools کو call کر کے کسی schema کو بحال کرتا ہے۔ یہ اس لیے اہم ہے کہ جو filter کسی tool کو مستقل طور پر چھپا دے، وہ آپ کے agent کی انجام دی جانے والی کارروائیاں بدل دیتا ہے، اور آپ کو اس کا علم صرف اس task سے ہوتا ہے جو خاموشی سے غلط ہو چکا ہو۔

تین طریقے، اور ان میں سے مفت کون سا ہے

پہلا طریقہ tool-schema filter ہے۔ ہر request میں مکمل tools array شامل ہوتی ہے۔ چند MCP (model context protocol) servers منسلک ہونے والی Claude Code turn میں project اس block کا حجم تقریباً 29,000 tokens بتاتا ہے۔ یہ filter صارف کی request اور ہر tool description کو BAAI/bge-small-en-v1.5 کے ذریعے embed کرتا ہے۔ یہ 130 MB کا embedding model ہے۔ filter مطابقت رکھنے والے tools رکھتا ہے اور باقی tools کے لیے stub بناتا ہے۔ اس طرح block کا حجم تقریباً 8,000 tokens رہ جاتا ہے۔ یہ embedding model CPU پر چلتا ہے۔

دوسرا طریقہ content compression ہے۔ اسی حصے کے لیے GPU پر 4B model درکار ہوتا ہے۔ File reads، tool output اور history کو ان کے اصل حجم کے 25.7% تک مختصر کیا جاتا ہے۔ 74% کی headline اسی عمل سے حاصل ہوتی ہے۔ اسے احتیاط سے سمجھیں: 74% اس content کی compression rate ہے جسے compress کیا جاتا ہے، آپ کے bill میں کمی نہیں۔

تیسرا طریقہ history summarization ہے۔ جب context budget بھر جاتا ہے تو recent window سے باہر کی turns کا خلاصہ بنا دیا جاتا ہے۔ اس طرح لمبی session limit سے ٹکرانے کے بجائے جاری رہتی ہے۔

صرف دوسرے طریقے کے لیے GPU درکار ہے۔ اس صفحے کا یہ سب سے اہم جملہ ہے۔ pip install "paritok[toolselect]" عام CPU VPS پر tool filter فراہم کرتا ہے، اور یہ product کا وہ نصف ہے جس کے لیے ماہانہ کوئی لاگت نہیں ہوتی۔ GPU card rent کرنے سے پہلے اسے آزمائیں۔

پروجیکٹ نے کیا پیمائش کی، اور کس harness پر

[
  {
    "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% تک compress کرتا ہے، جبکہ غیر compressed solve rate کا 86.5% برقرار رکھتا ہے۔ gpt-5 کو compressor کے طور پر استعمال کرنے سے زیادہ quality برقرار رہتی ہے، یعنی 93.6%، لیکن compression صرف 61.9% تک ہوتی ہے۔ اس صورت میں frontier prices بچانے کے لیے frontier prices ادا کرنا ہوں گے۔

quality column کو دیانت داری سے پڑھیں۔ solve rate کا 86.5% برقرار رہنے کا مطلب ہے کہ compressed runs ان مسائل میں ناکام ہوئے جنہیں uncompressed runs نے حل کیا؛ یعنی تقریباً ہر سات میں سے ایک solve ضائع ہوا۔ benchmark پر یہ table میں موجود ایک عدد ہے۔ آپ کی repository میں یہ وہ task ہے جسے آپ دو مرتبہ چلاتے ہیں۔

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

End-to-end saving session کے چلنے کے ساتھ بڑھتی ہے، کیونکہ history جمع ہوتی رہتی ہے اور compress ہونے والی چیز یہی history ہے۔ پروجیکٹ کے مطابق single turn پر تقریباً 25% saving ہوتی ہے، turn 5 تک 39%، اور turn 20 تک 63%۔ پروجیکٹ یہ بھی بتاتا ہے کہ یہ اضافہ کہاں رک جاتا ہے: 200,000 token budget پر absolute saving تقریباً 48,000 tokens فی turn پر آ کر مستحکم ہو جاتی ہے، عموماً turn 8 سے 12 کے درمیان، کیونکہ context بھر جانے کے بعد history مزید نہیں بڑھتی۔ عام طور پر quoted "past 85%" figure context-saturated sessions کو بیان کرتی ہے۔ یہ بہترین صورت ہے، اس لیے planning اسی بنیاد پر نہ کریں۔

کیا 24GB GPU Paritok کے اخراجات پورے کرتا ہے؟

اس سائز کے model کے لیے 24 GB card عام rental unit ہے۔ 7 August 2026 تک، 24 GB والے RTX 4090 کی published on-demand rate کا median $0.44 فی گھنٹہ تھا، جبکہ سب سے سستی listings تقریباً $0.20 کے قریب تھیں۔ ہم $0.44 استعمال کرتے ہیں۔ اگر یہ پورا مہینہ چلتا رہے تو 730 hours بنتے ہیں، یعنی $321۔ اگر اسے صرف working hours میں، روزانہ 8 hours اور 22 دن چلائیں، تو 176 hours بنتے ہیں، یعنی $77۔

اب token reduction کو dollar reduction میں تبدیل کریں۔ یہ کمی input tokens پر لاگو ہوتی ہے۔ Output tokens proxy سے بغیر تبدیلی کے گزرتے ہیں، اس لیے ان میں کوئی کمی نہیں آتی۔ فرض کریں کہ آپ کے dollar total کا 80% input tokens پر مشتمل ہے، جو coding agent کے لیے معمول کی بات ہے، اور اپنی bill سے اس مفروضے کی تصدیق کریں۔ اس کے بعد dollar saving، token reduction کو 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 figure پر bill کا 68% برقرار رہتا ہے۔ اس لیے ہمیشہ چلنے والا card اس وقت اپنے اخراجات پورے کر لیتا ہے جب آپ کا ماہانہ agent spend تقریباً $472 سے زیادہ ہو جائے، یا اگر آپ working hours کے علاوہ instance بند کر دیں تو تقریباً $114 پر۔ 63% کے turn-20 figure پر یہ حدیں بالترتیب $637 اور $154 بن جاتی ہیں۔ 39% کے turn-5 figure پر، جو مختصر sessions کی حقیقی صورت حال ہے، card کو rent کرنا قابلِ قدر بنانے کے لیے ماہانہ تقریباً $1,030 خرچ ہونا چاہیے۔

دو عوامل اس نتیجے کو table کے اعداد سے بہتر بناتے ہیں۔ Model کو 24 GB درکار نہیں: q4 build تقریباً 2.5 GB اور bf16 build تقریباً 8 GB ہے۔ اس لیے چھوٹا card، یا وہ GPU box جو آپ پہلے ہی کسی اور کام کے لیے چلا رہے ہیں، chart کے ہر عدد کو کم کر دیتا ہے۔ اس کے علاوہ، جب کوئی coding نہ کر رہا ہو تو instance بند کرنا یہاں سب سے مؤثر قدم ہے، کیونکہ اس سے rent تقریباً تین چوتھائی کم ہو جاتا ہے۔

ایک عامل صورت حال کو خراب کرتا ہے۔ Compression pass واقعی computational work ہے۔ 4B model جس token کو compress کرتا ہے، اسے پہلے پڑھنا اور پھر لکھنا پڑتا ہے، جس سے ہر agent turn میں latency بڑھ جاتی ہے۔ فی گھنٹہ rent کیے گئے card پر یہ cost invoice کی الگ سطر کے طور پر نہیں بلکہ waiting time کی صورت میں ظاہر ہوتی ہے، اس لیے اسے محسوس ہونے تک نظر انداز کرنا آسان ہے۔

اگر آپ عمومی طور پر rented GPU hours اور API tokens کے درمیان انتخاب کر رہے ہیں تو GPU VPS اور API tokens کے درمیان break-even inference کے لیے یہی حساب چلاتا ہے۔

VPS پر Paritok gateway چلانا

Python 3.10 یا اس کے بعد کا ورژن درکار ہے۔ Ubuntu 24.04 میں Python 3.12 شامل ہے، اس لیے CPU-only حصے کے لیے سادہ 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"

ورژن کو pin کریں۔ Repository نے 29 July 2026 کو v1.2.8 اور 5 August 2026 کو v1.3.0 tag کیا تھا۔ اس رفتار سے تبدیل ہونے والے project میں releases کے درمیان configuration keys کے نام بدل سکتے ہیں۔ ایک سادہ pip install paritok، یا main کا git clone، اگلے ہفتے مختلف gateway فراہم کرے گا اور یہ ریکارڈ بھی نہیں رہے گا کہ آپ کی پیمائش کے numbers کس ورژن نے پیدا کیے تھے۔

Default backend Ollama ہے۔ Model pull کریں، پھر اسے وہ مختصر نام دیں جسے proxy تلاش کرتا ہے۔

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

چونکہ local model compress کیے جانے والے ہر segment کے لیے rewrite لکھتا ہے، اس لیے طویل compression pass agent turn کے رک جانے کی صورت میں ظاہر ہوتا ہے۔ Ollama کا output length کے لیے num_predict cap اس عمل کی حد مقرر کرتا ہے۔

اس کے ساتھ paritok.yaml لکھیں۔ use_gpu_server: false compression کو آپ کے اپنے hardware پر جاری رکھتا ہے۔

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

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

paritok up مذکورہ تمام کاموں کا مختصر طریقہ ہے: یہ model کو، اگر موجود نہ ہو، pull کرتا ہے اور proxy کو port 8080 پر start کرتا ہے۔ کسی 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 totals اور proxy کے اپنے اندازے کے مطابق بچائی گئی مقدار واپس کرتا ہے۔ اس اندازے کو proxy کی اپنی کارکردگی کی جانچ سمجھیں، اور اپنے provider کے usage page سے اس کی تصدیق کریں۔

سہولت کے بجائے throughput درکار ہو تو vLLM base model کے اوپر adapter serve کرتا ہے۔

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

Ollama کو شروع کرنا زیادہ آسان ہے۔ vLLM concurrent requests کو کہیں بہتر طریقے سے handle کرتا ہے، اور جب ایک سے زیادہ agents اسی machine کو share کریں تو یہ فرق اہم ہو جاتا ہے۔ 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 کو نظرانداز کرتا ہے، اس لیے جب codex.enabled: true کو paritok.yaml میں set کیا جائے تو project آپ کے لیے ~/.codex/config.toml لکھتا ہے۔ صرف یہ variable export کرنے سے Codex براہ راست provider سے بات کرتا رہتا ہے۔ اس کی علامت /stats counter ہے جو کام کے دوران کبھی نہیں بڑھتا۔

Listener کو 127.0.0.1 پر رکھیں، 0.0.0.0 پر ہرگز نہیں۔ Proxy آپ کی provider API key کو upstream forward کرتا ہے۔ اس لیے internet سے قابل رسائی proxy اس key کے لیے open relay بن جاتی ہے۔ جسے بھی port مل جائے، وہ خود key دیکھے بغیر آپ کے پیسے خرچ کر سکتا ہے۔ Port کھولنے کے بجائے اسے SSH tunnel یا VPN کے ذریعے laptop سے access کریں۔

اسے systemd کے تحت چلائیں تاکہ reboot کے بعد بھی یہ جاری رہے۔ Paths کو اپنی installation کے مطابق تبدیل کریں۔

[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 start ہوتے ہی exit کر جائے، اس کا عام مطلب configuration file path کا غلط ہونا ہے۔ journalctl -u paritok -n 50 وجہ ظاہر کرتا ہے۔

میزبان فراہم کردہ اختیار، اور اس کی لاگت

یہ project compression کو بطور service بھی فراہم کرتا ہے۔ API key کے ساتھ use_gpu_server: true سیٹ کریں، تو 4B model اس کے hardware پر چلتا ہے۔ اس کی قیمت process کیے گئے ہر million tokens کے لیے $0.30 ہے، تاہم اس کی اپنی documentation کے مطابق August 2026 کے اختتام تک یہ مفت ہے۔ اس سے GPU کا کرایہ اور اوپر بیان کردہ تمام operational کام ختم ہو جاتے ہیں۔

اس کا مطلب یہ بھی ہے کہ آپ کے prompts اور وہ files جنہیں آپ کا agent پڑھتا ہے، آپ کی machine سے نکل کر کسی third party تک پہنچتے ہیں، اور اس کے بعد model provider تک جاتے ہیں۔ Self-hosting کا مقصد ہی ایسے hop سے بچنا ہے۔ یہ flag set کرنے سے پہلے طے کریں کہ آپ ان دونوں میں سے کس چیز کو ترجیح دے رہے ہیں، کیونکہ flag کو تبدیل کرنا ایک سطر کا کام ہے، لیکن اس کے نتائج معمولی نہیں ہیں۔

اپنے کام میں پہلے اور بعد کے نتائج کی پیمائش کیسے کریں

شائع شدہ اعداد و شمار project کے اپنے اعداد و شمار ہیں، جو project کے harness سے SWE-bench Lite پر حاصل کیے گئے ہیں۔ آپ کی repository SWE-bench Lite نہیں ہے۔ اپنے نتائج کی پیمائش کریں۔

• ایک معمول کا ہفتہ proxy کے بغیر چلائیں۔ provider کے usage page سے input tokens، cache-read tokens اور output tokens کو الگ الگ سطروں میں درج کریں، صرف ایک مجموعی dollar رقم درج نہ کریں۔
• اگلا ہفتہ proxy کو سامنے رکھ کر اسی نوعیت کا کام کریں۔
• input اور cache-read کی سطروں کا موازنہ کریں۔ output تقریباً یکساں رہنا چاہیے، کیونکہ کوئی چیز اسے compress نہیں کرتی۔ اگر output میں نمایاں تبدیلی آئی ہے تو proxy کے علاوہ کچھ اور بھی بدلا ہے۔
• ان tasks کو شمار کریں جنہیں آپ کو دوبارہ کرنا پڑا۔ یہ اس تبادلے کا quality والا حصہ ہے، اور کسی dashboard میں اس کی رپورٹ نہیں ہوتی۔
• totals کا موازنہ کرنے سے پہلے دوسرے ہفتے کے GPU hours بھی شامل کریں۔

input کو output سے الگ رکھنا اہم ہے، کیونکہ دونوں کی قیمتیں بہت مختلف ہیں اور compressor ان میں سے صرف ایک پر اثر انداز ہوتا ہے۔ August 2026 تک Claude Sonnet 4.6 کی قیمت $3 فی million input tokens اور $15 فی million output tokens ہے، جبکہ prompt-cache read کی قیمت input rate کا 10%، یعنی $0.30 فی million ہے۔ input اور output token cost کے درمیان فرق یہ طے کرتا ہے کہ input-side compressor آپ کے لیے قابلِ قدر ہے یا نہیں۔ Claude Code کے tokens حقیقت میں کہاں خرچ ہوتے ہیں سے معلوم ہوتا ہے کہ آپ کے context کا کون سا حصہ اتنا بڑا ہے کہ اسے compress کرنا مفید ہو۔

Prompt caching خاص طور پر tool-filter کے حساب کو پیچیدہ بناتی ہے۔ tool block request کے آغاز میں ہوتا ہے، اس لیے پہلے turn کے بعد یہ عموماً input price کے 10% پر cache hit ہوتا ہے۔ کسی cached block سے 21,000 tokens کم کرنے سے $0.30 فی million کے حساب سے 21,000 tokens کی بچت ہوتی ہے، یعنی تقریباً $0.006 فی turn؛ یہ $0.063 نہیں ہے جو uncached rate سے ظاہر ہوتا۔ project session کے دوران filtered block کو مستقل رکھتا ہے، تاکہ cached prefix تبدیل نہ ہو۔ ایسا filter جو ہر turn پر tools دوبارہ منتخب کرے، اس prefix کو invalidate کر دے گا اور جتنی بچت کرے گا اس سے زیادہ لاگت پیدا کرے گا۔

جو چیزیں اب بھی غیر مصدقہ ہیں

اوپر دی گئی کارکردگی کی ہر تعداد خود project سے حاصل کی گئی ہے۔ SWE-bench Lite کے نتائج کی کوئی آزادانہ طور پر دوبارہ تصدیق نہیں ہوئی، اور چونکہ پہلے tags July 2026 کے ہیں، اس لیے code کے پیچھے عملی operational history بھی بہت کم ہے۔ Compression rate اور quality-retained figure دونوں اسی فریق نے ناپے ہیں جسے ان کے بہتر نظر آنے سے فائدہ ہوتا ہے۔ اس کا مطلب یہ نہیں کہ یہ اعداد غلط ہیں۔ اس کا مطلب یہ ہے کہ یہ غیر مصدقہ ہیں، اور آپ کو انہیں اپنے تیار کردہ عدد سے مختلف درجے کے اعتماد کے ساتھ دیکھنا چاہیے۔

ایک documented behaviour ایسا ہے جسے اپنی setup کو موردِ الزام ٹھہرانے سے پہلے جان لینا چاہیے۔ Tool filter میں استعمال ہونے والا embedding model startup کے وقت نہیں بلکہ پہلی request پر load ہوتا ہے۔ اسی لیے project کے documentation میں 10 سے 15 seconds کا warm-up، اور اس کے بعد ہر call کے لیے تقریباً 15 ms درج ہے۔ Proxy start ہونے کے بعد ایک غیر اہم request بھیج دیں، تو آپ کی پہلی حقیقی agent turn رکی ہوئی محسوس نہیں ہوگی۔

چار چیزیں آپ خود ایک دوپہر میں طے کر سکتے ہیں: آیا proxy start ہو کر چلتا رہتا ہے، آیا /stats آپ کے کام کے دوران تبدیل ہوتا ہے، آیا آپ کے provider کی input-token line واقعی کم ہوتی ہے، اور آیا agent پھر بھی کام مکمل کر لیتا ہے۔ آپ کی setup کے لیے یہی چیزیں کسی بھی published benchmark سے کہیں زیادہ فیصلہ کن ہیں۔

یہ آپ کے دیگر tooling کے مقابلے میں کہاں آتا ہے: self-hosted LiteLLM gateway requests کو ان کے contents میں تبدیلی کیے بغیر route اور meter کرتا ہے، اس لیے دونوں مختلف مسائل حل کرتے ہیں اور انہیں chain کیا جا سکتا ہے، جبکہ Paritok agent کے سب سے قریب رہتا ہے۔ اگر اصل مقصد اسی مخصوص tool کے بجائے bill کم کرنا ہے، تو VPS پر agent کے لیے cost controls کی وسیع تر فہرست میں ایسی کئی تبدیلیاں شامل ہیں جنہیں پہلے آزمانے پر کوئی لاگت نہیں آتی۔

FAQ

کیا Paritok میرا API bill کم کرتا ہے یا صرف context usage؟

یہ bill کم کرتا ہے، کیونکہ proxy request کو provider تک پہنچنے سے پہلے rewrite کرتا ہے، اور provider اس مواد کے عوض charge کرتا ہے جو اسے موصول ہوتا ہے۔ اس کمی کا حجم headline میں دی گئی شرح سے کم ہے۔ 74% کا figure compress کیے جانے والے content کی compression rate ہے۔ end to end، project کے مطابق single turn پر تقریباً 25% اور turn 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 بھی کام کرتا ہے، اور break-even arithmetic آپ کے حق میں بدل دیتا ہے۔ tool-schema filter کے لیے GPU کی کوئی ضرورت نہیں: یہ BAAI/bge-small-en-v1.5 استعمال کرتا ہے، جو 130 MB کا embedding model ہے اور CPU پر چلتا ہے۔ عام VPS پر paritok[toolselect] install کریں، اور تھوڑی سی RAM کی لاگت پر tool-block reduction حاصل کریں۔

اگر compressor agent کی ضرورت کی کوئی چیز ہٹا دے تو کیا ہوتا ہے؟

کچھ بھی نہیں ہٹایا جاتا۔ Compressed segments میں [REF:id] tag شامل ہوتا ہے، اور model read_original یا expand_context کے ذریعے مکمل text بحال کرتا ہے۔ Filtered tool schemas کو delete کرنے کے بجائے stub کیا جاتا ہے، اور model gateway_search_tools کے ذریعے ایک schema بحال کرتا ہے۔ اصل risk کسی missing file سے زیادہ خاموش ہے: model lossy summary کی بنیاد پر کام کرتا ہے اور اسے کبھی احساس نہیں ہوتا کہ اسے original مانگنا چاہیے۔ SWE-bench Lite پر 86.5% quality-retained figure یہی چیز measure کرتا ہے۔

میری پہلی request کو پندرہ seconds کیوں لگتے ہیں؟

tool filter کے پیچھے موجود embedding model startup کے وقت load ہونے کے بجائے پہلی request پر load ہوتا ہے۔ Project کے مطابق warm-up میں 10 سے 15 seconds لگتے ہیں، اور اس کے بعد ہر call میں تقریباً 15 ms لگتے ہیں۔ Proxy start کرنے کے بعد curl کے ساتھ ایک throwaway request بھیج دیں، تو پہلے حقیقی agent turn میں تاخیر نہیں ہوگی۔

کیا مجھے self-hosting کے بجائے hosted GPU server استعمال کرنا چاہیے؟

اس سے GPU rent اور maintenance ختم ہو جاتی ہے، اور August 2026 تک اس کی قیمت processed ہر million tokens کے لیے $0.30 ہے۔ تاہم یہ آپ کے prompts اور وہ files بھی third party کو بھیجتا ہے جنہیں آپ کا agent پڑھتا ہے، اس سے پہلے کہ وہ آپ کے model provider تک پہنچیں۔ اگر آپ code کو اپنے زیر انتظام infrastructure پر رکھنے کے لیے self-hosting کر رہے ہیں، تو یہ setting آپ کے شروع کرنے کی وجہ ہی ختم کر دیتی ہے۔ Self-hosting سے context اور provider API key دونوں آپ کے اپنے box پر رہتے ہیں۔