کاهش هزینه توکن با 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 (تطبیق رتبه پایین) روی Qwen3-4B-Instruct-2507 است که روی 45,000 نمونه تقطیرشده توسط معلم (teacher-distilled) از مسیرهای واقعی agentهای کدنویسی آموزش دیده است.

چرا این کار «هرس کردن محتوا» (context trimming) نیست

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

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

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

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

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

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

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

فقط اهرم دوم به 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 درصد از کل هزینه دلاری شما را تشکیل می‌دهند که برای یک عامل برنامه‌نویسی (coding agent) معمول است؛ این فرض را با صورت‌حساب خود تطبیق دهید. صرفه‌جویی دلاری شما برابر است با میزان کاهش توکن ضرب‌در 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 که از قبل برای کار دیگری روشن است، تمام اعداد جدول را کاهش می‌دهد. همچنین، متوقف کردن نمونه در زمانی که کسی در حال کدنویسی نیست، بزرگ‌ترین اهرم صرفه‌جویی است، زیرا هزینه اجاره را حدود سه چهارم کاهش می‌دهد.

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

اگر در حال مقایسه ساعات اجاره 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

عبارت 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 اجرا می‌کند. پیش از آنکه ایجنتی را به سمت پروکسی هدایت کنید، آن را بررسی کنید.

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) می‌فرستد، بنابراین پروکسی که از اینترنت در دسترس باشد، یک relay باز برای آن کلید است: هر کسی که پورت را پیدا کند، بدون اینکه هرگز کلید را ببیند، می‌تواند اعتبار شما را خرج کند. به‌جای باز کردن پورت، از طریق یک SSH tunnel یا 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 کنید. واحدی که شروع می‌شود و بلافاصله خارج می‌شود، معمولاً به این معنی است که مسیر فایل پیکربندی اشتباه است و 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 نیست. نتایج خود را اندازه‌گیری کنید.

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

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

کش کردن پرامپت (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 میلی‌ثانیه زمان می‌برد. پس از شروع به کار پروکسی، یک درخواست آزمایشی ارسال کنید تا اولین نوبت واقعی ایجنت شما، دچار وقفه به نظر نرسد.

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

در مورد جایگاه این ابزار در کنار سایر ابزارهای شما: یک درگاه LiteLLM خودمیزبان (self-hosted) درخواست‌ها را بدون تغییر محتوا، مسیریابی و اندازه‌گیری می‌کند؛ بنابراین این دو ابزار مشکلات متفاوتی را حل می‌کنند و می‌توانند به صورت زنجیره‌ای استفاده شوند، به طوری که 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 بازیابی می‌کند. اسکیماهای ابزار فیلترشده به جای حذف شدن، 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 این است که کدها را روی زیرساختی که کنترل می‌کنید نگه دارید، این تنظیمات دلیل اصلی شروع کار شما را از بین می‌برد. در self-hosting، هم context و هم کلید API ارائه‌دهنده روی سیستم خودتان باقی می‌ماند.