کاهش هزینه توکن با Paritok: راهنمای کامل

عملکرد Paritok روی یک درخواست

ابزار Paritok یک gateway توکن است: یک پروکسی که بین agent برنامه‌نویسی شما و API مدل قرار می‌گیرد و هر درخواست را پیش از ارسال، فشرده می‌کند. agent شما به‌جای ارتباط مستقیم با ارائه‌دهنده، با http://127.0.0.1:8080 صحبت می‌کند. این پروکسی طرح‌واره‌های ابزار (tool schemas)، خواندن فایل‌ها، خروجی ابزار و تعاملات قدیمی را بازنویسی کرده، payload کوچک‌تر را به سمت بالا (upstream) می‌فرستد و پاسخ را بدون تغییر به شما بازمی‌گرداند.

ارائه‌دهنده، هزینه را بر اساس آنچه دریافت می‌کند محاسبه می‌کند، بنابراین payload کوچک‌تر به معنای صورت‌حساب کمتر است. کل ایده همین است. این ادعا با «طولانی‌تر شدن context شما» متفاوت است و به همین دلیل است که این ابزار به‌جای آنکه صرفاً مرتب‌کننده باشد، جذاب است.

این پروژه نوپا است. اولین تگ‌های عمومی آن مربوط به ژوئیه 2026 است و تگ فعلی v1.3.0 است که در تاریخ 5 اوت 2026 منتشر شده است. وزن‌ها و کد gateway تحت لایسنس Apache 2.0 هستند. مدل فشرده‌سازی یک آداپتور LoRA (مخفف low-rank adaptation) روی Qwen3-4B-Instruct-2507 است که با استفاده از 45,000 نمونه آموزشیِ استخراج‌شده از مسیرهای واقعی agentهای برنامه‌نویسی، آموزش دیده است.

چرا این کار حذف محتوا (context trimming) نیست

حذف محتوا (Trimming) باعث پاک شدن داده‌ها می‌شود. وقتی یک عامل (agent) به محدودیت ظرفیت محتوای خود نزدیک می‌شود و قدیمی‌ترین نوبت‌های گفتگو را حذف می‌کند، فایلی که در نوبت 3 خوانده بود از بین می‌رود. اگر در نوبت 20 به آن فایل نیاز داشته باشد، باید دوباره آن را بخواند و در نتیجه شما هزینه آن توکن‌ها را برای بار دوم پرداخت می‌کنید. صرفه‌جویی در اینجا در واقع یک وام بوده است.

Paritok یک بخش را با شکلی کوتاه‌تر به همراه یک تگ، یعنی [REF:id]، جایگزین می‌کند و متن کامل را روی پروکسی نگه می‌دارد. مدل با فراخوانی read_original یا expand_context، آن بخش را بازیابی می‌کند. این کار نحوه بروز خطا را تغییر می‌دهد. یک ابزار حذف محتوا با فراموشی شکست می‌خورد و هرگز شما را مطلع نمی‌کند. اما یک ابزار فشرده‌سازی با ارائه یک خلاصه ناقص به مدل شکست می‌خورد و مدل می‌تواند در صورتی که خلاصه کافی نباشد، نسخه اصلی را درخواست کند.

فیلتر ابزار (tool filter) نیز به همین شکل عمل می‌کند. طرح‌واره‌های (schemas) ابزارهای فیلترشده به جای حذف شدن، به صورت stub در می‌آیند و مدل با فراخوانی gateway_search_tools یکی از آن‌ها را بازیابی می‌کند. این موضوع اهمیت دارد، زیرا فیلتری که یک ابزار را به‌طور دائمی پنهان می‌کند، توانایی‌های عامل شما را تغییر می‌دهد و شما تنها زمانی از آن مطلع می‌شوید که یک وظیفه به‌طور بی‌سروصدا با شکست مواجه شود.

سه اهرم، و کدام‌یک رایگان است

اهرم اول، فیلتر طرح‌واره ابزار (tool-schema) است. هر درخواست، کل آرایه tools را با خود حمل می‌کند. در یک نوبت اجرای Claude Code با چند سرور MCP (پروتکل زمینه مدل) متصل، پروژه این بلوک را تقریباً 29,000 توکن اندازه‌گیری می‌کند. این فیلتر، درخواست کاربر و شرح هر ابزار را با استفاده از BAAI/bge-small-en-v1.5 که یک مدل embedding با حجم 130 مگابایت است، تعبیه (embed) می‌کند، ابزارهای منطبق را نگه می‌دارد و بقیه را به صورت stub در می‌آورد. حجم این بلوک به حدود 8,000 توکن کاهش می‌یابد. آن مدل embedding روی CPU اجرا می‌شود.

اهرم دوم، فشرده‌سازی محتوا است و این بخشی است که به مدل 4B روی GPU نیاز دارد. خواندن فایل‌ها، خروجی ابزار و تاریخچه، تا 25.7 درصد اندازه اصلی‌شان بازنویسی می‌شوند. عدد 74 درصد که در تیتر آمده از همین‌جا می‌آید. آن را با دقت بخوانید: 74 درصد نرخ فشرده‌سازی روی محتوایی است که فشرده می‌شود، نه میزان کاهش هزینه صورت‌حساب شما.

اهرم سوم، خلاصه‌سازی تاریخچه است. هنگامی که بودجه context پر می‌شود، نوبت‌های فراتر از پنجره اخیر خلاصه‌سازی می‌شوند تا یک نشست طولانی به جای رسیدن به محدودیت، همچنان ادامه یابد.

فقط اهرم دوم به GPU نیاز دارد. این مفیدترین جمله در این صفحه است. pip install "paritok[toolselect]" فیلتر ابزار را روی یک VPS معمولی با CPU در اختیار شما قرار می‌دهد و این نیمی از محصول است که هیچ هزینه ماهانه‌ای برای شما ندارد. پیش از اجاره کارت گرافیک، آن را امتحان کنید.

آنچه پروژه اندازه‌گیری کرده است و بر روی چه بستری

[
  {
    "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 اندازه‌گیری شده‌اند. مدل Paritok-4B-v1 محتوا را به 25.7% از اندازه اصلی فشرده می‌کند، در حالی که 86.5% از نرخ حل مسائل در حالت فشرده‌نشده را حفظ می‌کند. استفاده از gpt-5 به عنوان فشرده‌ساز، کیفیت بیشتری یعنی 93.6% را حفظ می‌کند، اما تنها تا 61.9% فشرده‌سازی انجام می‌دهد و شما برای صرفه‌جویی در هزینه‌های مدل‌های پیشرو، مجبور به پرداخت هزینه‌های همان مدل‌های پیشرو خواهید بود.

ستون کیفیت را صادقانه بخوانید. حفظ 86.5% از نرخ حل مسائل به این معناست که اجراهای فشرده‌شده در حل مسائلی شکست خورده‌اند که اجراهای فشرده‌نشده موفق به حل آن‌ها شده بودند؛ یعنی نزدیک به یک شکست در هر هفت تلاش. در یک بنچمارک، این فقط عددی در یک جدول است. اما در مخزن کد شما، این وظیفه‌ای است که باید دو بار آن را اجرا کنید.

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

صرفه‌جویی نهایی با ادامه یافتن نشست (session) افزایش می‌یابد، زیرا تاریخچه انباشته می‌شود و تاریخچه همان چیزی است که فشرده می‌شود. این پروژه گزارش می‌دهد که حدود 25% صرفه‌جویی در یک نوبت (turn)، 39% تا نوبت 5 و 63% تا نوبت 20 حاصل می‌شود. همچنین بیان می‌کند که این رشد کجا متوقف می‌شود: در یک بودجه 200,000 توکنی، صرفه‌جویی مطلق در حدود 48,000 توکن در هر نوبت ثابت می‌ماند که جایی بین نوبت 8 تا 12 رخ می‌دهد، زیرا وقتی کانتکست پر شود، رشد تاریخچه متوقف می‌گردد. رقم "بیش از 85%" که به‌طور گسترده نقل می‌شود، نشست‌های اشباع‌شده از کانتکست را توصیف می‌کند. این بهترین حالت ممکن است، بنابراین برنامه‌ریزی خود را بر اساس آن انجام ندهید.

آیا یک GPU با 24GB حافظه هزینه Paritok را پوشش می‌دهد؟

یک کارت 24GB واحد اجاره‌ای معمول برای مدلی با این اندازه است. تا تاریخ 7 August 2026، میانگین نرخ اعلام‌شده برای اجاره آنی (on-demand) یک RTX 4090 با 24GB حافظه، 0.44 دلار در ساعت بوده و ارزان‌ترین لیست‌ها نزدیک به 0.20 دلار هستند. عدد 0.44 دلار را در نظر بگیرید. اگر کارت در تمام طول ماه روشن بماند، یعنی 730 ساعت، هزینه آن 321 دلار خواهد بود. اگر فقط در ساعات کاری، یعنی 8 ساعت در روز و 22 روز در ماه از آن استفاده کنید، مجموعاً 176 ساعت می‌شود که هزینه آن 77 دلار است.

حالا کاهش توکن‌ها را به کاهش هزینه دلاری تبدیل کنید. این کاهش روی توکن‌های ورودی اعمال می‌شود. توکن‌های خروجی بدون تغییر از پروکسی عبور می‌کنند، بنابراین در هزینه آن‌ها تغییری ایجاد نمی‌شود. فرض کنید توکن‌های ورودی 80 درصد از کل هزینه دلاری شما را تشکیل می‌دهند که برای یک ایجنت کدنویسی معمول است؛ این فرض را با صورت‌حساب خود تطبیق دهید. صرفه‌جویی دلاری شما در واقع حاصل‌ضرب میزان کاهش توکن در 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 درصد، شما 68 درصد از صورت‌حساب را حفظ می‌کنید؛ بنابراین اگر کارت همیشه روشن باشد، زمانی که هزینه ماهانه ایجنت شما از حدود 472 دلار فراتر رود، هزینه کارت اجاره‌ای پوشش داده می‌شود، یا اگر instance را خارج از ساعات کاری متوقف کنید، این رقم حدود 114 دلار خواهد بود. با نرخ 63 درصد (turn-20)، این ارقام به 637 و 154 دلار تغییر می‌کنند. در نرخ 39 درصد (turn-5) که وضعیت واقعی جلسات کوتاه است، پیش از آنکه اجاره کارت توجیه اقتصادی داشته باشد، باید ماهانه حدود 1,030 دلار هزینه کنید.

دو عامل باعث می‌شوند وضعیت از آنچه جدول نشان می‌دهد بهتر باشد. مدل لزوماً به 24GB حافظه نیاز ندارد: نسخه q4 حدود 2.5GB و نسخه bf16 حدود 8GB فضا اشغال می‌کند، بنابراین استفاده از یک کارت کوچک‌تر یا یک سرور GPU که از قبل برای کارهای دیگر در اختیار دارید، تمام اعداد این جدول را کاهش می‌دهد. همچنین، متوقف کردن instance زمانی که کسی در حال کدنویسی نیست، بزرگ‌ترین اهرم صرفه‌جویی است، زیرا هزینه اجاره را حدود سه چهارم کاهش می‌دهد.

یک عامل وضعیت را بدتر می‌کند. فرآیند فشرده‌سازی، کار واقعی است. هر توکنی که مدل 4B فشرده می‌کند، توکنی است که باید خوانده و سپس نوشته شود؛ این کار باعث افزایش تأخیر (latency) در هر نوبت ایجنت می‌شود. روی کارتی که ساعتی اجاره می‌کنید، این هزینه به شکل زمان انتظار ظاهر می‌شود، نه به عنوان یک ردیف در صورت‌حساب، بنابراین تا زمانی که آن را حس نکنید، نادیده گرفتن آن آسان است.

اگر در حال مقایسه ساعات اجاره GPU با توکن‌های API هستید، نقطه سربه‌سر بین یک GPU VPS و توکن‌های API همین محاسبات را برای خودِ استنتاج (inference) انجام می‌دهد.

اجرای Paritok gateway روی یک VPS

به Python 3.10 یا جدیدتر نیاز دارید. توزیع Ubuntu 24.04 به‌صورت پیش‌فرض شامل Python 3.12 است، بنابراین یک ایمیج ساده VPS برای بخش فقط-CPU کافی است.

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) کنید. مخزن پروژه در تاریخ 29 July 2026 نسخه v1.2.8 و در 5 August 2026 نسخه v1.3.0 را منتشر کرد؛ پروژه‌ای که با این سرعت پیش می‌رود، کلیدهای پیکربندی را بین نسخه‌ها تغییر می‌دهد. یک pip install paritok ساده، یا یک git clone از main، هفتهٔ آینده نسخهٔ متفاوتی از gateway را به شما می‌دهد و هیچ رکوردی از اینکه کدام نسخه اعداد اندازه‌گیری‌شدهٔ شما را تولید کرده است، باقی نمی‌گذارد.

بک‌اند پیش‌فرض Ollama است. مدل را Pull کنید و سپس نام کوتاهی که پروکسی به دنبال آن است را به آن اختصاص دهید.

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

از آنجا که مدل محلی برای هر بخشی که فشرده می‌کند یک بازنویسی (rewrite) می‌نویسد، یک عملیات فشرده‌سازی طولانی به‌صورت یک نوبتِ متوقف‌شدهٔ عامل (agent turn) نمایش داده می‌شود و محدودیت num_predict در Ollama برای طول خروجی اهرمی است که آن را کنترل می‌کند.

مقدار paritok.yaml را در کنار آن بنویسید. 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 میان‌بری برای تمام موارد بالاست: اگر مدل موجود نباشد آن را Pull می‌کند و پروکسی را روی پورت 8080 اجرا می‌کند. پیش از آنکه عاملی (agent) را به سمت پروکسی هدایت کنید، آن را بررسی کنید.

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

/health یک شیء JSON کوچک شامل "status":"ok" و یک رشتهٔ نسخه برمی‌گرداند. /stats مجموع فشرده‌سازی و برآورد خودِ پروکسی از میزان صرفه‌جویی را برمی‌گرداند. این برآورد را به چشم نمره‌ای که پروکسی به کار خودش می‌دهد نگاه کنید و آن را با صفحهٔ میزان مصرف در پنل ارائه‌دهندهٔ خود تطبیق دهید.

برای دستیابی به توان عملیاتی (throughput) بالاتر به‌جای راحتی در استفاده، vLLM آداپتور را روی مدل پایه اجرا می‌کند.

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

راه‌اندازی Ollama سریع‌تر است. vLLM درخواست‌های همزمان را بسیار بهتر مدیریت می‌کند، که به‌محض اشتراک‌گذاری سرور توسط بیش از یک عامل، اهمیت پیدا می‌کند. تفاوت عملی بین Ollama و vLLM همان چیزی است که تصمیم نهایی را برای شما رقم می‌زند.

عامل را با استفاده از متغیرهای محیطی base URL به سمت پروکسی هدایت کنید.

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 تنظیم شده باشد، پروژه برای شما ~/.codex/config.toml را می‌نویسد. Export کردن متغیر به‌تنهایی باعث می‌شود Codex مستقیماً با ارائه‌دهنده صحبت کند؛ نشانهٔ این اتفاق، شمارندهٔ /stats است که هنگام کار شما هرگز تغییر نمی‌کند.

شنونده (listener) را روی 127.0.0.1 نگه دارید و هرگز آن را روی 0.0.0.0 قرار ندهید. پروکسی کلید API ارائه‌دهندهٔ شما را به سمت بالا‌دست (upstream) می‌فرستد، بنابراین پروکسیِ در دسترس از اینترنت، یک رلهٔ باز برای آن کلید است: هر کسی که پورت را پیدا کند، بدون اینکه هرگز کلید را ببیند، می‌تواند اعتبار شما را خرج کند. به‌جای باز کردن پورت، از طریق یک تونل SSH یا VPN از روی لپ‌تاپ به آن متصل شوید.

آن را تحت systemd اجرا کنید تا پس از reboot باقی بماند. مسیرها را مطابق با نصب خود تنظیم کنید.

[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 فعال کنید، سپس دوباره /health را با curl بررسی کنید. واحدی (unit) که شروع می‌شود و بلافاصله خارج می‌شود، معمولاً به این معنی است که مسیر فایل پیکربندی اشتباه است و journalctl -u paritok -n 50 دلیل آن را چاپ می‌کند.

گزینه میزبانی‌شده و هزینه‌های آن

این پروژه، فشرده‌سازی را به‌عنوان یک سرویس نیز ارائه می‌دهد. با تنظیم use_gpu_server: true و استفاده از یک API key، مدل 4B روی سخت‌افزار آن‌ها اجرا می‌شود. هزینه این سرویس طبق مستندات خود پروژه، 0.30 دلار به ازای هر یک میلیون توکن پردازش‌شده است و تا پایان اوت 2026 رایگان خواهد بود. این روش، هزینه‌های اجاره GPU و تمام عملیات نگهداری ذکرشده در بالا را حذف می‌کند.

این موضوع همچنین به این معناست که پرامپت‌ها و فایل‌هایی که عامل (agent) شما می‌خواند، پیش از رسیدن به ارائه‌دهنده مدل، از دستگاه شما خارج شده و به دست شخص ثالث می‌رسند. هدف از self-hosting دقیقاً اجتناب از همین واسطه است. پیش از تنظیم آن flag، تصمیم بگیرید که اولویت شما کدام‌یک از این دو مورد است؛ چرا که تغییر آن flag تنها یک خط کد است، اما پیامدهای آن چنین نیست.

چگونه اندازه‌گیری‌های قبل و بعد خود را انجام دهید

اعداد منتشرشده، ارقام مربوط به پروژه و حاصل از محیط تست SWE-bench Lite هستند. مخزن کد شما SWE-bench Lite نیست. اندازه‌گیری‌های خود را انجام دهید.

• یک هفته عادی را بدون وجود proxy در مسیر اجرا کنید. تعداد توکن‌های ورودی (input tokens)، توکن‌های خوانده‌شده از کش (cache-read tokens) و توکن‌های خروجی (output tokens) را به صورت خطوط جداگانه از صفحه گزارش مصرف ارائه‌دهنده خود ثبت کنید، نه به عنوان یک مبلغ دلاری کلی.
• هفته بعد را با قرار دادن proxy در مسیر و انجام همان نوع کار، اجرا کنید.
• خطوط ورودی و خواندن از کش را مقایسه کنید. خروجی باید تقریباً ثابت بماند، زیرا هیچ‌چیز آن را فشرده نمی‌کند. اگر خروجی تغییر زیادی کرده است، عاملی غیر از proxy تغییر کرده است.
• تعداد وظایفی که مجبور به انجام مجدد آن‌ها شدید را بشمارید. این بخشِ کیفیِ معامله است و هیچ داشبوردی آن را گزارش نمی‌کند.
• پیش از مقایسه مجموع هزینه‌ها، ساعات GPU هفته دوم را به محاسبات اضافه کنید.

تفکیک ورودی از خروجی اهمیت دارد، زیرا قیمت این دو بسیار متفاوت است و فشرده‌ساز تنها یکی از آن‌ها را تحت تأثیر قرار می‌دهد. تا اوت 2026، هزینه Claude Sonnet 4.6 برابر با 3 دلار به ازای هر میلیون توکن ورودی و 15 دلار به ازای هر میلیون توکن خروجی است، و هزینه خواندن از prompt-cache معادل 10 درصد نرخ ورودی، یعنی 0.30 دلار به ازای هر میلیون توکن است. شکاف بین هزینه توکن ورودی و خروجی تعیین می‌کند که آیا یک فشرده‌ساز در سمت ورودی برای شما ارزش اقتصادی دارد یا خیر. اینکه توکن‌های Claude Code واقعاً کجا مصرف می‌شوند به شما می‌گوید کدام بخش از context شما به اندازه‌ای بزرگ است که ارزش فشرده‌سازی داشته باشد.

کش کردن prompt (Prompt caching)، محاسبات فیلتر ابزارها را به‌ویژه پیچیده می‌کند. بلوک ابزارها در ابتدای درخواست قرار می‌گیرد، بنابراین پس از اولین نوبت، معمولاً با نرخ 10 درصد قیمت ورودی، یک cache hit محسوب می‌شود. حذف 21,000 توکن از یک بلوک کش‌شده، 21,000 توکن را با نرخ 0.30 دلار به ازای هر میلیون ذخیره می‌کند که حدود 0.006 دلار در هر نوبت است، نه 0.063 دلاری که نرخ بدون کش پیشنهاد می‌دهد. این پروژه بلوک فیلترشده را برای طول نشست (session) ثابت نگه می‌دارد تا پیشوند کش‌شده تغییر نکند. فیلتری که در هر نوبت ابزارها را دوباره انتخاب کند، آن پیشوند را باطل کرده و هزینه‌ای بیش از صرفه‌جویی ایجاد خواهد کرد.

مواردی که هنوز تأیید نشده‌اند

تمام اعداد مربوط به عملکرد در بالا، توسط خود پروژه ارائه شده‌اند. هیچ بازتولید مستقلی از نتایج SWE-bench Lite وجود ندارد و با توجه به اینکه اولین تگ‌ها مربوط به ژوئیه 2026 هستند، سابقه عملیاتی بسیار کمی برای این کد وجود دارد. نرخ فشرده‌سازی و عدد مربوط به کیفیت حفظ‌شده، هر دو توسط طرفی اندازه‌گیری شده‌اند که از مطلوب نشان داده شدن آن‌ها سود می‌برد. این موضوع به معنای نادرست بودن آن‌ها نیست، بلکه به این معناست که تأیید نشده‌اند و شما باید با آن‌ها متفاوت از اعدادی که خودتان تولید کرده‌اید، برخورد کنید.

یک رفتار مستند وجود دارد که پیش از مقصر دانستن تنظیمات خود، باید از آن آگاه باشید. مدل embedding که توسط فیلتر ابزار استفاده می‌شود، به جای زمان راه‌اندازی، در اولین درخواست بارگذاری می‌شود؛ بنابراین پروژه یک زمان گرم‌شدن (warm-up) بین 10 تا 15 ثانیه را مستند کرده است و پس از آن، هر فراخوانی حدود 15 میلی‌ثانیه زمان می‌برد. پس از شروع پروکسی، یک درخواست آزمایشی ارسال کنید تا اولین نوبت واقعی عامل (agent) شما، کند به نظر نرسد.

چهار مورد وجود دارد که می‌توانید در یک بعدازظهر خودتان آن‌ها را بررسی کنید: اینکه آیا پروکسی شروع به کار می‌کند و فعال می‌ماند، آیا /stats در حین کار شما تغییر می‌کند، آیا خط مربوط به توکن‌های ورودی ارائه‌دهنده شما واقعاً کاهش می‌یابد، و اینکه آیا عامل همچنان کار را به پایان می‌رساند یا خیر. این موارد برای تنظیمات شما بسیار بهتر از هر بنچمارک منتشرشده‌ای تصمیم‌گیری می‌کنند.

در مورد جایگاه این ابزار در کنار سایر ابزارهای شما: یک درگاه LiteLLM خودمیزبان درخواست‌ها را بدون تغییر محتوا مسیریابی و اندازه‌گیری می‌کند؛ بنابراین این دو ابزار مشکلات متفاوتی را حل می‌کنند و می‌توانند به صورت زنجیره‌ای استفاده شوند، به طوری که Paritok نزدیک‌ترین ابزار به عامل باشد. اگر هدف اصلی کاهش هزینه‌هاست و نه استفاده از این ابزار خاص، مجموعه گسترده‌تری از کنترل‌های هزینه برای یک عامل روی VPS شامل چندین تغییر است که امتحان کردن آن‌ها هیچ هزینه‌ای ندارد.

FAQ

آیا Paritok صورت‌حساب API من را کاهش می‌دهد یا فقط مصرف context را؟

این ابزار صورت‌حساب را کاهش می‌دهد، زیرا پروکسی درخواست را پیش از رسیدن به ارائه‌دهنده بازنویسی می‌کند و ارائه‌دهنده هزینه آنچه را دریافت می‌کند، محاسبه می‌نماید. میزان این کاهش از آنچه در تیترها مطرح می‌شود کمتر است. عدد 74% نرخ فشرده‌سازی محتوایی است که فشرده می‌شود. در مقیاس end-to-end، این پروژه حدود 25% کاهش در یک نوبت (turn) و 63% تا نوبت 20 را گزارش می‌دهد و تنها توکن‌های ورودی تغییر می‌کنند. توکن‌های خروجی بدون تغییر عبور می‌کنند.

برای میزبانی مدل فشرده‌سازی به چه مقدار GPU نیاز دارم؟

نسخه q4 حدود 2.5 گیگابایت و نسخه bf16 حدود 8 گیگابایت حجم دارد، بنابراین مدل در یک کارت 24 گیگابایتی با فضای خالی بسیار زیاد جای می‌گیرد. کارت‌های کوچک‌تر نیز کار می‌کنند و محاسبات نقطه سربه‌سر را به نفع شما تغییر می‌دهند. فیلتر tool-schema اصلاً به GPU نیاز ندارد: این فیلتر از BAAI/bge-small-en-v1.5 استفاده می‌کند، یک مدل embedding با حجم 130 مگابایت که روی CPU اجرا می‌شود. با نصب paritok[toolselect] روی یک VPS معمولی، می‌توانید کاهش tool-block را تنها با صرف مقدار کمی RAM به دست آورید.

اگر فشرده‌ساز چیزی را که عامل (agent) به آن نیاز دارد حذف کند چه می‌شود؟

هیچ‌چیزی حذف نمی‌شود. بخش‌های فشرده‌شده دارای برچسب [REF:id] هستند و مدل متن کامل را با read_original یا expand_context بازیابی می‌کند. طرح‌های ابزار (tool schemas) فیلترشده به جای حذف، stub می‌شوند و مدل یکی از آن‌ها را با gateway_search_tools بازیابی می‌کند. ریسک واقعی بسیار نامحسوس‌تر از یک فایل گمشده است: مدل بر اساس یک خلاصه lossy کار می‌کند و هرگز متوجه نمی‌شود که باید نسخه اصلی را درخواست کند. این همان چیزی است که عدد 86.5% حفظ کیفیت در SWE-bench Lite اندازه‌گیری می‌کند.

چرا اولین درخواست من پانزده ثانیه طول می‌کشد؟

مدل embedding پشت فیلتر ابزار، به جای زمان راه‌اندازی، در اولین درخواست بارگذاری می‌شود. مستندات پروژه به یک زمان گرم‌شدن (warm-up) بین 10 تا 15 ثانیه اشاره دارند و پس از آن، هر فراخوانی تقریباً 15 میلی‌ثانیه زمان می‌برد. پس از راه‌اندازی پروکسی، یک درخواست آزمایشی با curl بفرستید تا اولین نوبت واقعی عامل دچار وقفه نشود.

آیا باید به جای میزبانی شخصی (self-hosting) از سرور GPU میزبانی‌شده استفاده کنم؟

این کار هزینه اجاره GPU و نگهداری را حذف می‌کند و تا اوت 2026، قیمت آن 0.30 دلار به ازای هر میلیون توکن پردازش‌شده است. همچنین این کار باعث می‌شود پرامپت‌ها و فایل‌هایی که عامل شما می‌خواند، پیش از رسیدن به ارائه‌دهنده مدل، به یک شخص ثالث ارسال شود. اگر دلیل شما برای self-hosting این است که کدها روی زیرساختی باشند که کنترلش می‌کنید، این تنظیمات دلیل اصلی شروع کار شما را از بین می‌برد. میزبانی شخصی باعث می‌شود هم context و هم کلید API ارائه‌دهنده روی دستگاه خودتان باقی بماند.