Paritok: איך להוזיל עלויות שימוש בסוכני קידוד?

מה Paritok עושה לבקשה

Paritok הוא שער (gateway) לאסימונים: שרת proxy שיושב בין סוכן הקידוד שלך לבין ה-API של המודל ומדחס כל בקשה לפני העברתה הלאה. הסוכן שלך מתקשר עם http://127.0.0.1:8080 במקום עם הספק. ה-proxy משכתב את סכימות הכלים, את קריאות הקבצים, את פלט הכלים ואת התכתובות הישנות, שולח את המטען (payload) המוקטן במעלה הזרם, ומחזיר את התשובה ללא שינוי.

הספק מחייב אותך על מה שמגיע אליו, לכן מטען קטן יותר משמעו חשבונית קטנה יותר. זהו כל הרעיון. זו טענה שונה מ"ההקשר שלך מחזיק מעמד זמן רב יותר", וזו הסיבה שהכלי הזה מעניין ולא רק מסודר.

הפרויקט צעיר. התגיות הציבוריות הראשונות שלו מתוארכות ליולי 2026 והתגית הנוכחית היא v1.3.0, מתאריך 5 באוגוסט 2026. המשקולות וקוד השער מופצים תחת רישיון Apache 2.0. מודל הדחיסה הוא מתאם LoRA (קיצור של low-rank adaptation) על גבי Qwen3-4B-Instruct-2507, שאומן על 45,000 דגימות שזוקקו ממורים ונלקחו ממסלולי עבודה אמיתיים של סוכני קידוד.

מדוע אין מדובר בקיצוץ הקשר (context trimming)

קיצוץ מוחק נתונים. כאשר סוכן מתקרב למגבלת ההקשר שלו ומשמיט את התורות (turns) הישנים ביותר, הקובץ שקרא בתורה 3 נמחק. אם הוא זקוק לקובץ זה בתורה 20, הוא קורא אותו שוב, ולכן אתם משלמים על אותם אסימונים (tokens) פעם שנייה. החיסכון היה הלוואה בלבד.

Paritok מחליף מקטע בצורה מקוצרת בתוספת תגית, [REF:id], ושומר את הטקסט המלא ב-proxy. המודל משחזר מקטע על ידי קריאה ל-read_original או ל-expand_context. זה משנה את אופן הכשל. מקצץ נכשל על ידי שכחה, והוא לעולם לא ידווח לכם על כך. דוחס נכשל על ידי העברת סיכום מאבד-מידע למודל, והמודל יכול לבקש את המקור כאשר הסיכום אינו מספיק.

מסנן הכלים (tool filter) פועל באותו אופן. סכימות כלים מסוננות מוחלפות ב-stub במקום להימחק, והמודל משחזר אחת מהן על ידי קריאה ל-gateway_search_tools. זה משמעותי מכיוון שמסנן שמסתיר כלי באופן קבוע משנה את היכולות של הסוכן שלכם, ואתם הייתם מגלים זאת רק דרך משימה שנכשלה בשקט.

שלושת המנופים, ואיזה מהם הוא בחינם

המנוף הראשון הוא מסנן ה-tool-schema. כל בקשה נושאת את המערך המלא של tools. בסבב של Claude Code עם כמה שרתי MCP (פרוטוקול הקשר מודל) מחוברים, הפרויקט מודד את הבלוק הזה בכ-29,000 אסימונים (tokens). המסנן מטמיע את בקשת המשתמש ואת התיאור של כל כלי באמצעות BAAI/bge-small-en-v1.5, מודל הטמעה (embedding model) של 130 MB, שומר את הכלים התואמים ומחליף את השאר ב-stubs. הבלוק מצטמצם לכ-8,000 אסימונים. מודל ההטמעה הזה רץ על ה-CPU.

המנוף השני הוא דחיסת תוכן, וזה החלק שדורש את מודל ה-4B על גבי GPU. קריאות קבצים, פלט של כלים והיסטוריה נכתבים מחדש לכדי 25.7% מהגודל המקורי שלהם. מכאן מגיעה כותרת ה-74%. קראו זאת בעיון: 74% הוא שיעור הדחיסה על התוכן שעובר דחיסה, לא החיסכון בחשבון שלכם.

המנוף השלישי הוא סיכום היסטוריה. ברגע שתקציב ההקשר מתמלא, סבבים שמעבר לחלון הזמן האחרון מסוכמים, כך שסשן ארוך ממשיך לרוץ במקום להגיע למגבלה.

רק המנוף השני דורש 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% משיעור הפתרונות משמעותה שהרצות דחוסות נכשלו בבעיות שהרצות לא-דחוסות פתרו; מדובר בערך בכישלון אחד מכל שבעה פתרונות. ב-benchmark זהו מספר בטבלה. במאגר הקוד שלכם, זו משימה שתצטרכו להריץ פעמיים.

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

החיסכון מקצה לקצה גדל ככל שהסשן מתמשך, כיוון שההיסטוריה מצטברת והיא הדבר שעובר דחיסה. הפרויקט מדווח על כ-25% בסיבוב בודד, 39% בסיבוב 5, ו-63% בסיבוב 20. הוא גם מציין היכן הצמיחה נעצרת: בתקציב של 200,000 טוקנים, החיסכון המוחלט מתייצב על כ-48,000 טוקנים לסיבוב, איפשהו בין סיבוב 8 ל-12, כיוון שברגע שה-context מלא, ההיסטוריה מפסיקה לגדול. הנתון המצוטט רבות של "מעל 85%" מתאר סשנים רוויי-context. זהו תרחיש המקרה הטוב ביותר, לכן אל תתכננו לפיו.

האם כרטיס מסך עם 24GB משתלם עבור Paritok?

כרטיס עם 24GB הוא יחידת ההשכרה הסטנדרטית עבור מודל בגודל זה. נכון ל-7 באוגוסט 2026, התעריף החציוני שפורסם להשכרה לפי דרישה של RTX 4090 עם 24GB עמד על $0.44 לשעה, כאשר הרישומים הזולים ביותר קרובים ל-$0.20. נניח $0.44. אם המכונה פועלת לאורך כל החודש, מדובר ב-730 שעות, כלומר $321. אם היא פועלת רק בשעות העבודה, 8 שעות ביום במשך 22 ימים, מדובר ב-176 שעות, כלומר $77.

כעת נמיר את החיסכון בטוקנים לחיסכון בדולרים. ההפחתה חלה על טוקני קלט. טוקני פלט עוברים דרך ה-proxy ללא שינוי, ולכן הם אינם משתנים כלל. נניח שטוקני קלט מהווים 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, או כ-$114 אם אתה עוצר את ה-instance מחוץ לשעות העבודה. בנתון של 63% עבור turn-20, המספרים הופכים ל-$637 ו-$154. בנתון של 39% עבור turn-5, שזהו המצב בסשנים קצרים, אתה זקוק לכ-$1,030 בחודש כדי שהשכרת הכרטיס תהיה כדאית בכלל.

שני גורמים הופכים את המצב לטוב יותר ממה שהטבלה מציעה. המודל אינו זקוק ל-24GB: גרסת ה-q4 היא כ-2.5GB וגרסת ה-bf16 היא כ-8GB, כך שכרטיס קטן יותר, או שרת GPU שאתה כבר מריץ עבור משהו אחר, מפחיתים כל מספר בטבלה. עצירת ה-instance כאשר אף אחד לא מתכנת היא המנוף המשמעותי ביותר כאן, כיוון שהיא מקצצת את עלות ההשכרה בכשלושה רבעים.

גורם אחד הופך את המצב לגרוע יותר. תהליך הדחיסה דורש עבודה ממשית. כל טוקן שהמודל בגרסת 4B דוחס הוא טוקן שהוא חייב לקרוא ואז לכתוב, מה שמוסיף latency לכל turn של הסוכן. בכרטיס שאתה שוכר לפי שעה, עלות זו מופיעה כזמן המתנה, לא כשורה בחשבונית, ולכן קל לפספס אותה עד שמרגישים אותה.

אם אתה שוקל שעות GPU מושכרות מול טוקני API באופן כללי, נקודת האיזון בין GPU VPS לבין טוקני API מבצעת את אותו חישוב עבור ה-inference עצמו.

הרצת ה-gateway של Paritok על גבי 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"

קבעו את גרסת התוכנה (pinning). המאגר תייג את v1.2.8 ב-29 ביולי 2026 ואת v1.3.0 ב-5 באוגוסט 2026; פרויקט שמתקדם בקצב כזה משנה שמות של מפתחות הגדרה בין גרסאות. שימוש ב-pip install paritok חשוף, או ב-git clone של main, יספק לכם gateway שונה בשבוע הבא ולא ישאיר תיעוד לגבי הגרסה שהפיקה את הנתונים שמדדתם.

ה-backend המוגדר כברירת מחדל הוא Ollama. משכו את המודל, ולאחר מכן הגדירו לו את השם הקצר שה-proxy מחפש.

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

מכיוון שהמודל המקומי כותב שכתוב עבור כל מקטע שהוא דוחס, תהליך דחיסה ממושך ייראה כקיפאון בתור של ה-agent, והערך Ollama's num_predict cap on output length הוא הפרמטר שקובע את הגבול לכך.

כתבו את 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 הוא קיצור הדרך לכל הפעולות לעיל: הוא מושך את המודל אם הוא חסר ומפעיל את ה-proxy בפורט 8080. בדקו את ה-proxy לפני שאתם מפנים אליו agent.

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

/health מחזיר אובייקט JSON קטן המכיל את "status":"ok" ומחרוזת גרסה. /stats מחזיר את סיכומי הדחיסה ואת הערכת ה-proxy לחיסכון שהושג. התייחסו להערכה זו כאל ציון שה-proxy נותן לעצמו, ואמתו אותה מול דף השימוש אצל ספק השירות שלכם.

עבור תעבורה (throughput) ולא עבור נוחות, vLLM מגיש את ה-adapter על גבי מודל הבסיס.

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

Ollama מהיר יותר להקמה. vLLM מטפל בבקשות בו-זמניות בצורה טובה בהרבה, מה שמתחיל להיות משמעותי ברגע שיותר מ-agent אחד חולק את השרת. The practical difference between Ollama and vLLM הוא מה שיכריע עבורכם את הבחירה.

הפנו את ה-agent אל ה-proxy באמצעות משתני הסביבה של ה-base URL.

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

ה-CLI של Codex מתעלם מ-OPENAI_BASE_URL, לכן הפרויקט כותב עבורכם את ~/.codex/config.toml כאשר codex.enabled: true מוגדר ב-paritok.yaml. ייצוא המשתנה לבדו ישאיר את Codex בתקשורת ישירה מול הספק, והסימן לכך הוא מונה /stats שלעולם לא זז בזמן העבודה.

השאירו את המאזין (listener) על 127.0.0.1, לעולם לא על 0.0.0.0. ה-proxy מעביר את מפתח ה-API של הספק שלכם הלאה, כך ש-proxy שנגיש מהאינטרנט הוא ממסר פתוח (open relay) עבור המפתח הזה: כל מי שימצא את הפורט יבזבז את כספכם מבלי לראות את המפתח עצמו. גשו אליו ממחשב נייד דרך מנהרת SSH או VPN במקום לפתוח את הפורט.

הריצו אותו תחת systemd כדי שישרוד אתחול. התאימו את הנתיבים להתקנה שלכם.

[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, ולאחר מכן בצעו שוב curl ל-/health. יחידה שמתחילה ונסגרת מיד מעידה בדרך כלל על נתיב שגוי לקובץ ההגדרה, ו-journalctl -u paritok -n 50 ידפיס את הסיבה לכך.

האפשרות המנוהלת, והעלות שלה

הפרויקט מציע גם שירות דחיסה במודל של SaaS. הגדרה של use_gpu_server: true עם מפתח API מאפשרת להריץ את מודל ה-4B על החומרה שלהם, בעלות של $0.30 למיליון טוקנים מעובדים; השירות ניתן בחינם עד סוף אוגוסט 2026, על פי התיעוד הרשמי. אפשרות זו חוסכת את הצורך בשכירת GPU ואת כל עבודת התפעול שפורטה לעיל.

משמעות הדבר היא שה-prompts שלכם והקבצים שהסוכן קורא עוזבים את המכונה שלכם ומגיעים לצד שלישי לפני שהם מגיעים לספק המודל. אירוח עצמי (self-hosting) נועד בדיוק כדי להימנע מהשלב הזה. החליטו מהו סדר העדיפויות שלכם לפני הגדרת ה-flag, כיוון ששינוי ה-flag דורש שורת קוד אחת בלבד, אך ההשלכות שלו משמעותיות הרבה יותר.

כיצד למדוד את הביצועים שלכם לפני ואחרי

המספרים המפורסמים הם הנתונים של הפרויקט, מתוך סביבת הבדיקות של הפרויקט, על גבי SWE-bench Lite. המאגר שלכם אינו SWE-bench Lite. מדדו את הנתונים שלכם בעצמכם.

• הריצו שבוע עבודה רגיל ללא ה-proxy בנתיב. תעדו את ה-input tokens, ה-cache-read tokens וה-output tokens כשורות נפרדות מתוך דף השימוש של ספק השירות שלכם, ולא כסכום דולרי אחד כולל.
• הריצו את השבוע הבא עם ה-proxy בחזית, תוך ביצוע סוג עבודה דומה.
• השוו בין שורות ה-input וה-cache-read. ה-output אמור להישאר יציב בערך, כיוון ששום דבר לא דוחס אותו. אם ה-output השתנה משמעותית, משהו אחר מלבד ה-proxy השתנה.
• ספרו את המשימות שנאלצתם לבצע מחדש. זהו חצי האיכות של המשוואה, ואף לוח מחוונים לא מדווח על כך.
• הוסיפו את שעות ה-GPU לשבוע השני לפני שתשוו בין הסכומים הכוללים.

הפרדה בין ה-input ל-output היא קריטית מכיוון ששניהם מתומחרים בצורה שונה מאוד, ודוחס נוגע רק באחד מהם. נכון לאוגוסט 2026, Claude Sonnet 4.6 עולה 3$ למיליון input tokens ו-15$ למיליון output tokens, וקריאת prompt-cache עולה 10% מתעריף ה-input, כלומר 0.30$ למיליון. הפער בין עלות ה-input ל-output tokens הוא שקובע אם דוחס בצד ה-input משתלם עבורכם. לאן ה-tokens של Claude Code באמת הולכים יסביר לכם איזה חלק מה-context שלכם גדול מספיק כדי להצדיק דחיסה.

ה-prompt caching מסבך במיוחד את החישוב של סינון הכלים. בלוק הכלים נמצא בתחילת הבקשה, לכן לאחר ה-turn הראשון הוא בדרך כלל נחשב ל-cache hit במחיר של 10% מעלות ה-input. קיצוץ של 21,000 tokens מבלוק שעבר caching חוסך 21,000 לפי 0.30$ למיליון, כלומר כ-0.006$ ל-turn, במקום ה-0.063$ שהיו מתקבלים לפי התעריף ללא cache. הפרויקט שומר על הבלוק המסונן קפוא למשך הסשן, כך שה-prefix שנשמר ב-cache אינו משתנה. מסנן שיבחר כלים מחדש בכל turn יגרום לפסילת ה-prefix הזה ויעלה יותר ממה שיחסוך.

מה שטרם אומת

כל נתוני הביצועים שלעיל מגיעים מהפרויקט עצמו. לא קיימת שחזור בלתי תלוי של תוצאות SWE-bench Lite, ומכיוון שהתגיות הראשונות מתוארכות ליולי 2026, אין כמעט היסטוריה תפעולית מאחורי הקוד. שיעור הדחיסה והנתון של איכות משומרת נמדדים שניהם על ידי הגורם שנהנה מכך שהם נראים טוב. זה לא הופך אותם לשגויים. זה הופך אותם לבלתי מאומתים, ועליך להתייחס אליהם אחרת מאשר לנתון שהפקת בעצמך.

התנהגות אחת מתועדת שראוי להכיר לפני שמאשימים את ה-setup שלכם: מודל ה-embedding שבו משתמש מסנן הכלים נטען בבקשה הראשונה ולא בזמן ה-startup, לכן הפרויקט מתעד זמן חימום של 10 עד 15 שניות, ולאחר מכן כ-15 ms לכל קריאה. שלחו בקשת בדיקה אחת לאחר שה-proxy עולה, וכך התור הראשון של ה-agent לא ייראה כאילו הוא קפוא.

ארבעה דברים שניתן לבדוק באופן עצמאי בתוך אחר הצהריים אחד: האם ה-proxy עולה ונשאר פעיל, האם /stats משתנה בזמן העבודה, האם צריכת ה-input-token אצל הספק שלכם אכן יורדת, והאם ה-agent עדיין מסיים את העבודה. אלו יכריעו עבור ה-setup שלכם הרבה יותר טוב מכל benchmark מפורסם.

לגבי המיקום של כלי זה ביחס לכלים אחרים שלכם: a self-hosted LiteLLM gateway מנתב ומודד בקשות מבלי לשנות את תוכנן, כך ששני הכלים פותרים בעיות שונות וניתן לשרשר אותם, כאשר Paritok ממוקם הכי קרוב ל-agent. אם המטרה האמיתית היא חשבון קטן יותר ולא כלי ספציפי זה, the wider set of cost controls for an agent on a VPS כולל כמה שינויים שלא עולים דבר לנסותם תחילה.

FAQ

האם Paritok מפחית את חשבון ה-API שלי או רק את השימוש ב-context?

הוא מפחית את החשבון, כיוון שה-proxy משכתב את הבקשה לפני שהיא מגיעה לספק, והספק מחייב על מה שהוא מקבל. היקף ההפחתה קטן ממה שהכותרות מרמזות. הנתון של 74% הוא שיעור הדחיסה על התוכן שעובר דחיסה. מקצה לקצה, הפרויקט מדווח על כ-25% בסיבוב בודד ו-63% בסיבוב ה-20, ורק ה-input tokens עוברים שינוי. ה-output tokens עוברים ללא שינוי.

כמה GPU אני צריך כדי לארח בעצמי את מודל הדחיסה?

גרסת ה-q4 היא בגודל של כ-2.5 GB וגרסת ה-bf16 היא כ-8 GB, כך שהמודל נכנס לכרטיס של 24 GB עם הרבה מקום פנוי. כרטיס קטן יותר יעבוד, וזה משנה את חישוב נקודת האיזון לטובתך. מסנן ה-tool-schema אינו זקוק ל-GPU כלל: הוא משתמש ב-BAAI/bge-small-en-v1.5, מודל embedding של 130 MB שרץ על ה-CPU. התקן את paritok[toolselect] על שרת VPS רגיל ותקבל את צמצום ה-tool-block במחיר של מעט RAM.

מה קורה אם הדוחס מסיר משהו שהסוכן היה זקוק לו?

שום דבר לא מוסר. מקטעים דחוסים נושאים תגית [REF:id] והמודל משחזר את הטקסט המלא עם read_original או expand_context. סכימות כלים מסוננות עוברות תהליך של stubbing במקום מחיקה, והמודל משחזר אחת מהן עם gateway_search_tools. הסיכון האמיתי שקט יותר מקובץ חסר: המודל עובד מסיכום מאבד נתונים (lossy) ולעולם לא מבין שהוא צריך לבקש את המקור. זה מה שהנתון של 86.5% שימור איכות ב-SWE-bench Lite מודד.

מדוע הבקשה הראשונה שלי לוקחת חמש עשרה שניות?

מודל ה-embedding שמאחורי מסנן הכלים נטען בבקשה הראשונה במקום בזמן העלייה (startup). הפרויקט מתעד זמן חימום של 10 עד 15 שניות, ולאחר מכן בערך 15 ms לכל קריאה. שלח בקשת בדיקה אחת עם curl לאחר הפעלת ה-proxy, וסיבוב הסוכן האמיתי הראשון לא יתעכב.

האם כדאי לי להשתמש בשרת GPU מאוחסן במקום אירוח עצמי?

זה חוסך את עלות השכירות של ה-GPU ואת התחזוקה, במחיר של $0.30 למיליון tokens מעובדים נכון לאוגוסט 2026. זה גם שולח את ה-prompts שלך ואת הקבצים שהסוכן שלך קורא לצד שלישי לפני שהם מגיעים לספק המודל שלך. אם אתה מארח בעצמך כדי לשמור את הקוד על תשתית שבשליטתך, הגדרה זו מבטלת את הסיבה שבגללה התחלת. אירוח עצמי שומר גם את ה-context וגם את ה-API key של הספק על השרת שלך.