Paritok ช่วยลดค่าใช้จ่าย 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 ทั้งตัว weights และโค้ดของ 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 สิ่งนี้เปลี่ยนรูปแบบความล้มเหลวไปโดยสิ้นเชิง ตัวตัดทอน (trimmer) จะล้มเหลวด้วยการลืมข้อมูลและไม่เคยแจ้งให้คุณทราบ ในขณะที่ตัวบีบอัด (compressor) จะล้มเหลวด้วยการส่งสรุปข้อมูลที่สูญเสียรายละเอียดบางส่วนไปให้โมเดล ซึ่งโมเดลสามารถเรียกขอข้อมูลต้นฉบับได้หากสรุปนั้นไม่เพียงพอ

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

กลไกทั้งสามและกลไกที่ไม่มีค่าใช้จ่าย

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

กลไกที่สองคือการบีบอัดเนื้อหา และนี่คือส่วนที่จำเป็นต้องใช้โมเดล 4B บน GPU การอ่านไฟล์ ผลลัพธ์จากเครื่องมือ และประวัติการทำงานจะถูกเขียนใหม่ให้เหลือขนาดเพียง 25.7% ของขนาดเดิม ซึ่งเป็นที่มาของตัวเลข 74% ที่ระบุไว้ โปรดอ่านอย่างละเอียด: 74% คืออัตราการบีบอัดของเนื้อหาที่ถูกบีบอัด ไม่ใช่ส่วนลดในค่าใช้จ่ายของคุณ

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

มีเพียงกลไกที่สองเท่านั้นที่ต้องใช้ GPU นี่คือประโยคที่มีประโยชน์ที่สุดในหน้านี้ pip install "paritok[toolselect]" ช่วยให้คุณใช้ตัวกรองเครื่องมือบน CPU VPS ทั่วไปได้ และเป็นส่วนหนึ่งของผลิตภัณฑ์ที่คุณไม่ต้องเสียค่าใช้จ่ายรายเดือน ลองใช้งานส่วนนี้ก่อนที่คุณจะเช่าการ์ดจอ

สิ่งที่โครงการวัดผลและชุดทดสอบที่ใช้

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

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

ที่ระดับ 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) ต้องใช้ทรัพยากรจริง ทุกโทเค็นที่โมเดลขนาด 4B บีบอัด คือโทเค็นที่โมเดลต้องอ่านและเขียน ซึ่งเพิ่ม latency ในแต่ละรอบของ agent สำหรับการ์ดจอที่คุณเช่าเป็นรายชั่วโมง ต้นทุนนี้จะปรากฏในรูปแบบของเวลาที่ต้องรอ ไม่ใช่ตัวเลขในใบแจ้งหนี้ จึงสังเกตได้ยากจนกว่าคุณจะรู้สึกถึงความล่าช้านั้นด้วยตัวเอง

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

การรัน Paritok gateway บน VPS

จำเป็นต้องใช้ Python 3.10 หรือใหม่กว่า Ubuntu 24.04 มาพร้อมกับ Python 3.12 ดังนั้น VPS image แบบมาตรฐานก็เพียงพอสำหรับการรันในส่วนที่ใช้ 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 version) ตัว repository มีการติด tag v1.2.8 เมื่อวันที่ 29 กรกฎาคม 2026 และ v1.3.0 เมื่อวันที่ 5 สิงหาคม 2026 โครงการที่พัฒนาด้วยความเร็วระดับนี้มักมีการเปลี่ยนชื่อ config keys ระหว่างการปล่อย release ต่างๆ การใช้ pip install paritok เปล่าๆ หรือการ git clone ของ main จะทำให้คุณได้ gateway เวอร์ชันที่ต่างออกไปในสัปดาห์หน้า และไม่มีบันทึกว่าเวอร์ชันใดเป็นตัวที่สร้างตัวเลขที่คุณวัดผลไว้

backend เริ่มต้นคือ Ollama ให้ดึง model มาก่อน จากนั้นตั้งชื่อย่อที่ proxy ต้องการ

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 เป็นคำสั่งลัดสำหรับขั้นตอนทั้งหมดข้างต้น โดยจะดึง model มาให้หากยังไม่มี และเริ่มการทำงานของ 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 บน base model

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 variables ของ 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 ที่เปลี่ยนแปลงไป
• นับจำนวนงานที่คุณต้องทำซ้ำ นั่นคือส่วนของคุณภาพในการแลกเปลี่ยน ซึ่งไม่มี dashboard ใดรายงานค่านี้
• เพิ่มจำนวนชั่วโมง 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 การลดจำนวน 21,000 tokens จากบล็อกที่ถูก cache ไว้จะช่วยประหยัดได้ 21,000 tokens ที่ราคา $0.30 ต่อล้าน หรือประมาณ $0.006 ต่อรอบ แทนที่จะเป็น $0.063 ตามที่อัตราแบบไม่ใช้ cache จะบ่งชี้ โครงการจะคงบล็อกที่ผ่านการกรองไว้ตลอดทั้ง session เพื่อไม่ให้ส่วนนำ (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 มากแค่ไหนในการ self-host โมเดลบีบอัด?

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 summary) และอาจไม่รู้ตัวว่าควรขอข้อมูลต้นฉบับ ซึ่งนั่นคือสิ่งที่ตัวเลขความคงทนของคุณภาพ 86.5% บน SWE-bench Lite กำลังวัดผลอยู่

ทำไมคำขอแรกของฉันถึงใช้เวลาถึง 15 วินาที?

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

ฉันควรใช้เซิร์ฟเวอร์ GPU แบบ hosted แทนการ self-host หรือไม่?

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