Paritok ช่วยลดค่าใช้จ่าย Token ให้ Coding Agent ได้จริงไหม

สิ่งที่ Paritok ทำกับคำขอ

Paritok คือ token gateway ซึ่งทำหน้าที่เป็นพร็อกซีคั่นกลางระหว่าง coding agent ของคุณกับ model API โดยจะบีบอัดคำขอก่อนส่งต่อไปยังปลายทาง Agent ของคุณจะสื่อสารกับ http://127.0.0.1:8080 แทนที่จะเป็นผู้ให้บริการโดยตรง พร็อกซีจะเขียน schema ของเครื่องมือ, การอ่านไฟล์, ผลลัพธ์จากเครื่องมือ และประวัติการสนทนาก่อนหน้าใหม่ทั้งหมด จากนั้นจึงส่ง payload ที่มีขนาดเล็กลงไปยัง upstream และส่งคำตอบกลับมาโดยไม่มีการเปลี่ยนแปลง

ผู้ให้บริการจะเรียกเก็บเงินตามปริมาณข้อมูลที่ได้รับ ดังนั้น payload ที่เล็กลงจึงหมายถึงค่าใช้จ่ายที่ลดลง นี่คือแนวคิดหลักของเครื่องมือนี้ ซึ่งแตกต่างจากการกล่าวอ้างเรื่อง "การขยาย context ให้ยาวขึ้น" และเป็นเหตุผลว่าทำไมเครื่องมือนี้จึงมีความน่าสนใจมากกว่าแค่การจัดระเบียบข้อมูลทั่วไป

โครงการนี้ยังอยู่ในช่วงเริ่มต้น โดย tag สาธารณะแรกเริ่มเมื่อเดือนกรกฎาคม 2026 และ tag ปัจจุบันคือ v1.3.0 เมื่อวันที่ 5 สิงหาคม 2026 ทั้งตัว weight และโค้ดของ gateway ใช้สัญญาอนุญาตแบบ Apache 2.0 โดยโมเดลการบีบอัดเป็น LoRA (low-rank adaptation) adapter ที่ทำงานบน Qwen3-4B-Instruct-2507 ซึ่งผ่านการฝึกฝนด้วยตัวอย่างที่กลั่นกรองจากอาจารย์ (teacher-distilled) จำนวน 45,000 ตัวอย่าง จากเส้นทางการทำงานจริงของ coding agent

เหตุใดนี่จึงไม่ใช่การตัดทอนบริบท (context trimming)

การตัดทอน (trimming) คือการลบข้อมูลทิ้ง เมื่อเอเจนต์เข้าใกล้ขีดจำกัดของบริบทและลบการสนทนาช่วงแรกๆ ออกไป ไฟล์ที่เอเจนต์อ่านในรอบที่ 3 จะหายไป หากเอเจนต์จำเป็นต้องใช้ไฟล์นั้นในรอบที่ 20 เอเจนต์จะต้องอ่านไฟล์นั้นใหม่อีกครั้ง ซึ่งทำให้คุณต้องเสียค่าใช้จ่ายสำหรับโทเค็นเหล่านั้นเป็นครั้งที่สอง การประหยัดที่เกิดขึ้นจึงเป็นเพียงการยืมมาใช้ชั่วคราวเท่านั้น

Paritok จะแทนที่ส่วนของข้อมูลด้วยรูปแบบที่สั้นลงพร้อมกับแท็ก [REF:id] และเก็บข้อความฉบับเต็มไว้บนพร็อกซี โมเดลจะกู้คืนส่วนของข้อมูลนั้นได้โดยการเรียกใช้ read_original หรือ expand_context สิ่งนี้เปลี่ยนรูปแบบความล้มเหลวไปโดยสิ้นเชิง ตัวตัดทอนจะล้มเหลวด้วยการลืมข้อมูลและไม่เคยแจ้งให้คุณทราบ ส่วนตัวบีบอัดจะล้มเหลวด้วยการส่งสรุปข้อมูลที่สูญเสียรายละเอียดบางส่วนไปให้โมเดล และโมเดลสามารถร้องขอข้อมูลต้นฉบับได้เมื่อสรุปนั้นไม่เพียงพอ

ตัวกรองเครื่องมือ (tool filter) มีการทำงานในลักษณะเดียวกัน สคีมาของเครื่องมือที่ถูกกรองจะถูกแทนที่ด้วย stub แทนที่จะถูกลบออกไป และโมเดลจะกู้คืนเครื่องมือดังกล่าวได้โดยการเรียกใช้ gateway_search_tools สิ่งนี้มีความสำคัญเนื่องจากตัวกรองที่ซ่อนเครื่องมือไว้อย่างถาวรจะเปลี่ยนความสามารถของเอเจนต์ และคุณจะทราบเรื่องนี้ก็ต่อเมื่อมีงานที่ล้มเหลวไปอย่างเงียบๆ เท่านั้น

กลไกทั้งสามและสิ่งที่ใช้งานได้ฟรี

กลไกที่หนึ่งคือตัวกรอง tool-schema ทุกคำขอจะพ่วงอาร์เรย์ tools ทั้งหมดมาด้วย ในการทำงานของ Claude Code ที่มีการเชื่อมต่อ MCP (model context protocol) servers ไว้หลายตัว โปรเจกต์วัดขนาดบล็อกดังกล่าวได้ประมาณ 29,000 tokens ตัวกรองจะทำการฝัง (embed) คำขอของผู้ใช้และคำอธิบายเครื่องมือแต่ละรายการด้วย BAAI/bge-small-en-v1.5 ซึ่งเป็น embedding model ขนาด 130 MB จากนั้นจะเก็บเฉพาะเครื่องมือที่ตรงกันไว้และตัดส่วนที่เหลือออก ทำให้บล็อกลดขนาดลงเหลือประมาณ 8,000 tokens โดย embedding model นี้จะทำงานบน 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% เท่านั้น และคุณจะต้องจ่ายค่าใช้จ่ายในระดับ frontier เพื่อประหยัดค่าใช้จ่ายในระดับ frontier

โปรดพิจารณาคอลัมน์คุณภาพอย่างตรงไปตรงมา การรักษาอัตราการแก้ปัญหาไว้ได้ 86.5% หมายความว่าการรันแบบบีบอัดล้มเหลวในปัญหาที่การรันแบบไม่บีบอัดทำได้สำเร็จ ซึ่งใกล้เคียงกับหนึ่งในเจ็ดของงานทั้งหมด ในเกณฑ์มาตรฐานตัวเลขนี้เป็นเพียงค่าในตาราง แต่ใน 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
  }
]

การประหยัดทรัพยากรแบบ end-to-end จะเพิ่มขึ้นเมื่อเซสชันดำเนินไป เนื่องจากประวัติการทำงานจะสะสมมากขึ้นและประวัติเหล่านั้นคือสิ่งที่ถูกนำไปบีบอัด โครงการรายงานว่าประหยัดได้ประมาณ 25% ในการทำงานรอบเดียว, 39% ในรอบที่ 5 และ 63% ในรอบที่ 20 นอกจากนี้ยังระบุจุดที่การเติบโตจะหยุดลง โดยที่งบประมาณ 200,000 token การประหยัดแบบสัมบูรณ์จะคงที่อยู่ที่ประมาณ 48,000 token ต่อรอบ ซึ่งจะเกิดขึ้นในช่วงรอบที่ 8 ถึง 12 เพราะเมื่อ context เต็มแล้ว ประวัติการทำงานจะไม่เพิ่มขึ้นอีก ตัวเลข "มากกว่า 85%" ที่ถูกอ้างถึงอย่างแพร่หลายนั้นอธิบายถึงเซสชันที่ context อิ่มตัวแล้ว นั่นคือกรณีที่ดีที่สุด ดังนั้นอย่าใช้ตัวเลขนี้เป็นฐานในการวางแผนงานของคุณ

GPU ขนาด 24GB คุ้มค่าสำหรับ Paritok หรือไม่

การ์ดจอขนาด 24 GB เป็นหน่วยมาตรฐานสำหรับการเช่าเพื่อรันโมเดลขนาดนี้ ณ วันที่ 7 สิงหาคม 2026 อัตราค่าเช่าแบบ on-demand สำหรับ RTX 4090 ขนาด 24 GB โดยเฉลี่ยอยู่ที่ $0.44 ต่อชั่วโมง และราคาถูกที่สุดอยู่ที่ประมาณ $0.20 หากคิดที่ราคา $0.44 และเปิดใช้งานตลอดทั้งเดือน (730 ชั่วโมง) จะมีค่าใช้จ่าย $321 หากเปิดใช้งานเฉพาะช่วงเวลาทำงาน 8 ชั่วโมงต่อวัน เป็นเวลา 22 วัน จะเท่ากับ 176 ชั่วโมง คิดเป็นค่าใช้จ่าย $77

คราวนี้ให้เปลี่ยนการลดจำนวน token เป็นการลดค่าใช้จ่าย การลดนี้มีผลกับ input tokens เท่านั้น ส่วน output tokens จะผ่าน proxy ไปโดยไม่มีการเปลี่ยนแปลง ดังนั้นจึงไม่มีผลต่อค่าใช้จ่ายในส่วนนี้ สมมติว่า input tokens คิดเป็น 80% ของค่าใช้จ่ายทั้งหมดของคุณ ซึ่งเป็นสัดส่วนปกติสำหรับ coding agent ให้ตรวจสอบสมมตินี้กับใบแจ้งหนี้ของคุณ ค่าใช้จ่ายที่คุณประหยัดได้จะเท่ากับการลดลงของ 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
  }
]

ที่ระดับ saturated-session ซึ่งอยู่ที่ 85% คุณจะประหยัดค่าใช้จ่ายได้ 68% ดังนั้นการ์ดจอที่เปิดทิ้งไว้จะคุ้มทุนเมื่อค่าใช้จ่ายรายเดือนสำหรับ agent ของคุณเกินประมาณ $472 หรือประมาณ $114 หากคุณหยุดการทำงานของ instance นอกเวลาทำงาน สำหรับระดับ turn-20 ที่ 63% ตัวเลขดังกล่าวจะกลายเป็น $637 และ $154 ส่วนที่ระดับ turn-5 ซึ่งอยู่ที่ 39% ซึ่งเป็นลักษณะการใช้งานจริงในช่วงสั้นๆ คุณจำเป็นต้องมีค่าใช้จ่ายประมาณ $1,030 ต่อเดือน จึงจะคุ้มค่าที่จะเช่าการ์ดจอมาใช้งาน

มีสองปัจจัยที่ทำให้ผลลัพธ์ดีกว่าที่ตารางแนะนำไว้ ประการแรก โมเดลไม่จำเป็นต้องใช้หน่วยความจำถึง 24 GB โดยที่ build แบบ q4 ใช้พื้นที่ประมาณ 2.5 GB และแบบ bf16 ใช้ประมาณ 8 GB ดังนั้นการใช้การ์ดจอขนาดเล็กลง หรือใช้ GPU box ที่คุณใช้งานอย่างอื่นอยู่แล้ว จะช่วยลดตัวเลขทุกตัวในตารางนี้ลงได้ ประการที่สอง การหยุด instance เมื่อไม่มีการเขียนโค้ดเป็นวิธีที่มีประสิทธิภาพที่สุด เพราะช่วยลดค่าเช่าลงได้ถึงประมาณสามในสี่

มีหนึ่งปัจจัยที่ทำให้ผลลัพธ์แย่ลง คือขั้นตอนการบีบอัด (compression pass) ที่ต้องใช้ทรัพยากรจริง ทุก token ที่โมเดลขนาด 4B บีบอัด คือ token ที่มันต้องอ่านและเขียน ซึ่งจะเพิ่ม latency ในแต่ละรอบการทำงานของ agent บนการ์ดจอที่คุณเช่าเป็นรายชั่วโมง ต้นทุนนี้จะปรากฏในรูปแบบของเวลาที่ต้องรอ ไม่ใช่ตัวเลขในใบแจ้งหนี้ จึงเป็นเรื่องง่ายที่จะมองข้ามจนกว่าคุณจะรู้สึกได้ด้วยตัวเอง

หากคุณกำลังเปรียบเทียบระหว่างค่าเช่า GPU รายชั่วโมงกับค่า API tokens โดยทั่วไป จุดคุ้มทุนระหว่าง GPU VPS กับ API tokens จะใช้หลักการคำนวณเดียวกันนี้สำหรับการทำ inference

การรัน Paritok gateway บน VPS

จำเป็นต้องใช้ Python 3.10 หรือใหม่กว่า Ubuntu 24.04 มาพร้อมกับ Python 3.12 ดังนั้นอิมเมจ VPS มาตรฐานจึงเพียงพอสำหรับการรันในโหมด CPU-only

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 version) ตัว repository มีการติดแท็ก v1.2.8 เมื่อวันที่ 29 กรกฎาคม 2026 และ v1.3.0 เมื่อวันที่ 5 สิงหาคม 2026 โปรเจกต์ที่มีการพัฒนาด้วยความเร็วระดับนี้มักมีการเปลี่ยนชื่อ config keys ระหว่างการ release การใช้ 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

เนื่องจากโมเดลในเครื่องจะเขียนการเขียนใหม่ (rewrite) สำหรับทุกส่วนที่บีบอัด การประมวลผลการบีบอัดที่ใช้เวลานานจะปรากฏเป็นสถานะ agent turn ที่ค้างอยู่ และ ขีดจำกัด num_predict ของ Ollama สำหรับความยาว output คือตัวแปรที่ใช้ควบคุมสิ่งนี้

ให้เขียน 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 object ขนาดเล็กที่มี "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 จัดการคำขอพร้อมกัน (concurrent requests) ได้ดีกว่ามาก ซึ่งจะเริ่มมีความสำคัญทันทีที่มี agent มากกว่าหนึ่งตัวใช้งานบนเครื่องเดียวกัน ความแตกต่างในทางปฏิบัติระหว่าง Ollama และ vLLM คือปัจจัยที่จะช่วยให้คุณตัดสินใจในเรื่องนี้

กำหนดเป้าหมาย agent ไปที่ proxy ด้วย environment variable ของ 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/config.toml ให้คุณเมื่อมีการตั้งค่า codex.enabled: true ไว้ใน paritok.yaml การ export ตัวแปรนี้เพียงอย่างเดียวจะทำให้ Codex สื่อสารตรงไปยังผู้ให้บริการ และสัญญาณที่บ่งบอกถึงปัญหานี้คือตัวนับ /stats ที่ไม่ขยับเลยในขณะที่คุณทำงาน

ให้ listener ทำงานบน 127.0.0.1 เท่านั้น ห้ามรันบน 0.0.0.0 โดยเด็ดขาด เนื่องจาก proxy จะส่งต่อ API key ของผู้ให้บริการของคุณไปยัง upstream ดังนั้นหาก proxy สามารถเข้าถึงได้จากอินเทอร์เน็ต มันจะกลายเป็น open relay สำหรับ key นั้นทันที: ใครก็ตามที่พบพอร์ตนี้จะสามารถใช้เงินของคุณได้โดยไม่ต้องเห็นตัว key เอง ให้เข้าถึงผ่าน SSH tunnel หรือ VPN จากแล็ปท็อปแทนการเปิดพอร์ตทิ้งไว้

รันภายใต้ systemd เพื่อให้ทำงานต่อได้หลังการ reboot ปรับแต่ง path ให้ตรงกับการติดตั้งของคุณ

[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 อีกครั้ง หาก unit เริ่มทำงานแล้วหยุดทันที มักหมายความว่า path ของไฟล์ config ไม่ถูกต้อง และ journalctl -u paritok -n 50 จะแสดงสาเหตุของปัญหาให้ทราบ

ตัวเลือกแบบโฮสต์และค่าใช้จ่ายที่เกี่ยวข้อง

โครงการนี้ยังให้บริการการบีบอัดข้อมูลในรูปแบบบริการ (Service) อีกด้วย หากตั้งค่า use_gpu_server: true ด้วย API key โมเดลขนาด 4B จะทำงานบนฮาร์ดแวร์ของผู้ให้บริการ โดยมีราคาอยู่ที่ $0.30 ต่อ 1 ล้านโทเค็นที่ประมวลผล ซึ่งตามเอกสารระบุว่าใช้งานได้ฟรีจนถึงสิ้นเดือนสิงหาคม 2026 วิธีนี้ช่วยลดภาระค่าเช่า GPU และงานด้านปฏิบัติการทั้งหมดที่กล่าวมาข้างต้น

นอกจากนี้ยังหมายความว่า prompt และไฟล์ที่เอเจนต์ของคุณอ่าน จะต้องออกจากเครื่องของคุณและไปถึงบุคคลที่สามก่อนที่จะไปถึงผู้ให้บริการโมเดลของคุณ การทำ self-hosting มีไว้เพื่อหลีกเลี่ยงขั้นตอนดังกล่าวโดยเฉพาะ คุณควรตัดสินใจว่าต้องการเพิ่มประสิทธิภาพในด้านใดก่อนที่จะตั้งค่า flag ดังกล่าว เพราะการเปลี่ยน flag ทำได้เพียงแค่แก้ไขบรรทัดเดียว แต่ผลลัพธ์ที่ตามมานั้นไม่สามารถแก้ไขได้ง่ายเช่นนั้น

วิธีวัดผลก่อนและหลังใช้งานด้วยตัวคุณเอง

ตัวเลขที่เผยแพร่เป็นตัวเลขของโครงการ ซึ่งได้มาจากชุดทดสอบของโครงการบน SWE-bench Lite แต่ repository ของคุณไม่ใช่ 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 ต่อล้าน tokens ช่องว่างระหว่างราคาของ input และ output tokens คือสิ่งที่ตัดสินว่าตัวบีบอัดข้อมูลฝั่ง input คุ้มค่าสำหรับคุณหรือไม่ ตำแหน่งที่ tokens ของ Claude Code ถูกใช้งานจริง จะบอกคุณว่าส่วนใดของบริบท (context) ของคุณมีขนาดใหญ่พอที่จะคุ้มค่าต่อการบีบอัด

การทำ prompt caching ทำให้การคำนวณตัวกรองเครื่องมือ (tool-filter) มีความซับซ้อนขึ้น โดยเฉพาะอย่างยิ่งบล็อกเครื่องมือจะวางอยู่ที่ส่วนหน้าของคำขอ ดังนั้นหลังจากรอบแรก โดยปกติแล้วจะเป็นการ cache hit ที่ราคา 10% ของราคา input การตัด tokens ออก 21,000 tokens จากบล็อกที่ถูก cache ไว้จะช่วยประหยัดค่าใช้จ่ายได้ 21,000 tokens ที่ราคา $0.30 ต่อล้าน หรือประมาณ $0.006 ต่อรอบ แทนที่จะเป็น $0.063 ตามอัตราที่ไม่ได้ cache ไว้ โครงการนี้จะคงบล็อกที่ผ่านการกรองไว้ตลอดทั้งเซสชันเพื่อให้ prefix ที่ถูก cache ไว้ไม่เปลี่ยนแปลง ตัวกรองที่เลือกเครื่องมือใหม่ทุกรอบจะทำให้ prefix นั้นใช้งานไม่ได้และมีค่าใช้จ่ายสูงกว่าที่ประหยัดได้

สิ่งที่ยังไม่ได้รับการตรวจสอบ

ตัวเลขประสิทธิภาพทั้งหมดข้างต้นมาจากทางโครงการโดยตรง ยังไม่มีการทำซ้ำผลลัพธ์ SWE-bench Lite โดยหน่วยงานอิสระ และเนื่องจากแท็กแรกมีวันที่ระบุเป็นเดือนกรกฎาคม 2026 โค้ดชุดนี้จึงยังมีประวัติการใช้งานจริงน้อยมาก อัตราการบีบอัดและตัวเลขคุณภาพที่คงเหลืออยู่ล้วนวัดโดยฝ่ายที่ได้รับประโยชน์จากการที่ตัวเลขเหล่านั้นดูดี ซึ่งไม่ได้หมายความว่าตัวเลขเหล่านั้นผิด แต่หมายความว่ายังไม่ได้รับการยืนยัน และคุณควรปฏิบัติต่อตัวเลขเหล่านี้ต่างจากตัวเลขที่คุณวัดผลด้วยตนเอง

มีพฤติกรรมที่บันทึกไว้ประการหนึ่งที่คุณควรทราบก่อนจะโทษว่าเกิดจากระบบของคุณ คือ embedding model ที่เครื่องมือกรองใช้งานจะโหลดเมื่อมีการเรียกใช้ครั้งแรกแทนที่จะโหลดตอนเริ่มต้นทำงาน โครงการจึงระบุว่าต้องใช้เวลา warm-up ประมาณ 10 ถึง 15 วินาที จากนั้นจะใช้เวลาประมาณ 15 ms ต่อการเรียกใช้ในครั้งถัดไป ให้ส่งคำขอทดสอบทิ้งไปหนึ่งครั้งหลังจาก proxy เริ่มทำงาน แล้วการทำงานของ agent ครั้งแรกของคุณจะไม่ดูเหมือนค้าง

มีสี่สิ่งที่สามารถตรวจสอบได้ด้วยตนเองภายในช่วงบ่าย: proxy เริ่มทำงานและคงสถานะอยู่ได้หรือไม่, /stats มีการเปลี่ยนแปลงขณะที่คุณทำงานหรือไม่, ปริมาณ input-token ของผู้ให้บริการของคุณลดลงจริงหรือไม่ และ agent ยังคงทำงานจนเสร็จสิ้นหรือไม่ สิ่งเหล่านี้เป็นตัวตัดสินสำหรับระบบของคุณได้ดีกว่าเกณฑ์มาตรฐานใดๆ ที่เผยแพร่ไว้

สำหรับตำแหน่งของเครื่องมือนี้เมื่อเทียบกับเครื่องมืออื่นที่คุณมี: 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% คืออัตราการบีบอัดของเนื้อหาที่ถูกบีบอัด หากมองแบบ end-to-end โครงการรายงานว่าลดลงประมาณ 25% ในการโต้ตอบรอบเดียว และ 63% เมื่อถึงรอบที่ 20 โดยมีเพียง input tokens เท่านั้นที่ถูกบีบอัด ส่วน output tokens จะถูกส่งผ่านไปโดยไม่มีการเปลี่ยนแปลง

ต้องใช้ GPU มากแค่ไหนในการโฮสต์โมเดลบีบอัดด้วยตนเอง?

build แบบ q4 มีขนาดประมาณ 2.5 GB และ build แบบ bf16 มีขนาดประมาณ 8 GB ดังนั้นโมเดลจึงสามารถทำงานบนการ์ดจอขนาด 24 GB ได้โดยเหลือพื้นที่ว่างอีกมาก การ์ดจอขนาดเล็กลงก็สามารถใช้งานได้เช่นกัน ซึ่งจะช่วยให้จุดคุ้มทุนในการใช้งานของคุณดีขึ้น ส่วนตัวกรอง tool-schema ไม่จำเป็นต้องใช้ GPU เลย เนื่องจากใช้ BAAI/bge-small-en-v1.5 ซึ่งเป็นโมเดล embedding ขนาด 130 MB ที่ทำงานบน 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 ms ต่อการเรียกใช้งานในครั้งถัดไป ให้ส่งคำขอทดสอบหนึ่งครั้งด้วย curl หลังจากเริ่ม proxy แล้ว การโต้ตอบของ agent ครั้งแรกที่ใช้งานจริงก็จะไม่ติดขัด

ฉันควรใช้เซิร์ฟเวอร์ GPU แบบ hosted แทนการโฮสต์เองหรือไม่?

การใช้บริการดังกล่าวช่วยลดภาระค่าเช่า GPU และการบำรุงรักษา โดยมีราคาอยู่ที่ $0.30 ต่อล้าน tokens ที่ประมวลผล ณ เดือนสิงหาคม 2026 อย่างไรก็ตาม วิธีนี้จะส่ง prompt และไฟล์ที่ agent ของคุณอ่านไปยังบุคคลที่สามก่อนที่จะถึงผู้ให้บริการโมเดลของคุณ หากคุณกำลังโฮสต์ด้วยตนเองเพื่อเก็บโค้ดไว้บนโครงสร้างพื้นฐานที่คุณควบคุมได้ การตั้งค่านี้จะทำลายเหตุผลที่คุณเริ่มต้นใช้งานตั้งแต่แรก การโฮสต์ด้วยตนเองจะช่วยให้ทั้ง context และ API key ของผู้ให้บริการยังคงอยู่บนเครื่องของคุณเอง