วิธีลดต้นทุนโทเค็นของเอเจนต์ AI ในการใช้งานจริง

TL;DR

ต้นทุนโทเค็นของ AI agent เพิ่มขึ้นเมื่อแต่ละขั้นตอนต้องประมวลผลคำสั่ง ประวัติการสนทนา ผลลัพธ์จากเครื่องมือ และสถานะกลางซ้ำแล้วซ้ำเล่า

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

ตัวชี้วัดที่มีประโยชน์ที่สุดในการใช้งานจริงคือ cost per successful task วัดจากทั้งรันทั้งหมด—not ราคาต่อคำขอหรือขนาดบริบทของการเรียกครั้งสุดท้าย

คู่มือนี้เน้นเฉพาะ AI agent แบบหลายขั้นตอน อธิบายว่าบริบทที่ส่งซ้ำสะสมตลอดรันได้อย่างไร วิธีระบุแหล่งสิ้นเปลืองที่ใหญ่ที่สุด และควรใช้งานการควบคุมใดก่อน

บทนำ

แชตบอทอาจเรียกโมเดลหนึ่งครั้งต่อข้อความผู้ใช้ แต่ AI agent อาจเรียก 10, 20 ครั้ง หรือมากกว่านั้นก่อนจะเสร็จสิ้นหนึ่งงาน

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

เมื่อปริมาณการใช้งานขยาย ต้นทุนเหล่านี้จะคาดเดาได้ยากขึ้นและอาจลดมาร์จินของผลิตภัณฑ์อย่างรวดเร็ว การลดต้นทุนต้องปรับให้เหมาะสมทั้งวงรอบของเอเจนต์—not เพียงแค่เปลี่ยนไปใช้โมเดลที่ถูกกว่า

บทความนี้เน้นเฉพาะต้นทุนที่จำเพาะกับ Agent สำหรับคำแนะนำที่กว้างขึ้นครอบคลุมการแคชพรอมต์ การแคชคำตอบตรง การแคชเชิงความหมาย การจัดเส้นทางโมเดล และการจัดการต้นทุน API โดยทั่วไป ดู How to Reduce AI API Costs

เหตุใดต้นทุนโทเค็นของ AI agent จึงทบต้น?

ในเอเจนต์แบบหลายขั้นตอน ต้นทุนของหนึ่งงานคือผลรวมของทุกการเรียกโมเดล—not เพียงคำตอบสุดท้าย

แหล่งการใช้โทเค็นหลักของเอเจนต์ได้แก่:

มีสองวิธีลดบิลที่แตกต่างกัน:

1. ประมวลผลโทเค็นให้น้อยลง ด้วยการกรอง การย่อบริบท การจำกัดเอาต์พุต และการควบคุมลูป
2. ลดราคาที่มีผลจริงของโทเค็นที่จำเป็น ด้วยการแคชพรอมต์หรือเลือกโมเดล

ความแตกต่างหลัก: การแคชพรอมต์ลดต้นทุนของอินพุตที่ซ้ำ การย่อบริบทลดอินพุตที่ถูกส่งซ้ำเอง

เอเจนต์ 12 ขั้นตอนจะประมวลผลได้ 147,000 โทเค็นได้อย่างไร?

พิจารณาเอเจนต์ช่วยเหลือลูกค้าที่สมมติว่ามี:

• คำนำที่คงที่ 4,000 โทเค็น
• เพิ่มโทเค็นใหม่ 1,500 หลังแต่ละขั้น
• ส่งประวัติที่สะสมครบทุกครั้งในการร้องขอแต่ละครั้ง
• เรียกโมเดลรวม 12 ครั้ง

อินพุตที่ขั้น n คือ:

Input at step n = 4,000 + 1,500 × (n - 1)

อินพุตสะสมตลอด 12 ครั้งคือ:

Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens

การเรียกครั้งสุดท้ายมีเพียง 20,500 โทเค็นอินพุต แต่ทั้งรันประมวลผลโทเค็นอินพุตสะสมถึง 147,000

ตอนนี้ลองใช้การควบคุมสองอย่าง:

1. แคชคำนำ 4,000 โทเค็นหลังการเรียกครั้งแรก
2. ย่อประวัติหลังขั้นที่หกให้เป็นสถานะสรุปขนาด 2,500 โทเค็น

นี่เป็นการคำนวณเพื่อการวางแผน ไม่ใช่การเปรียบเทียบผู้ให้บริการ

สมมติว่าทุกร้องขอรวมประวัติสะสมทั้งหมด เอเจนต์ที่สร้างสถานะแบบคัดเลือก สรุปข้อความเก่า หรือดึงข้อมูลที่เกี่ยวข้องเท่านั้น อาจมีเส้นโค้งต้นทุนที่แตกต่างกัน

กฎการเติบโตของต้นทุน: วัดอินพุตสะสมตลอดทั้งรัน ขนาดบริบทของการเรียกครั้งสุดท้ายไม่สะท้อนจำนวนโทเค็นทั้งหมดที่ถูกประมวลผล

ตัวชี้วัดใดเผยให้เห็นการสิ้นเปลืองโทเค็นของเอเจนต์?

อย่าเริ่มจากการเปลี่ยนโมเดล ก่อนอื่นระบุว่ากระบวนงานใช้โทเค็นไปกับส่วนที่ไม่ช่วยให้ผลลัพธ์ดีขึ้นตรงไหน

บันทึกฟิลด์เหล่านี้สำหรับทุกขั้นของเอเจนต์:

ตัวชี้วัดหลักควรเป็น:

cost per successful task
= total workflow cost
/ accepted tasks

รันที่ถูกลงไม่ถือว่าดีขึ้น หากทำให้เกิดงานล้มเหลวมากขึ้น เรียกเครื่องมือซ้ำ หรือจำเป็นต้องให้มนุษย์แก้ไขเพิ่ม

มีสี่ตัวชี้วัดเฉพาะเอเจนต์ที่ช่วยระบุต้นตอปัญหา

การขยายบริบท

context amplification
= cumulative input tokens
/ final-step input tokens

ค่าสูงบ่งชี้ว่าบริบทก่อนหน้าได้รับการประมวลผลซ้ำหลายครั้ง

อัตราการคงผลลัพธ์จากเครื่องมือ

tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools

ค่าสูงอาจบ่งชี้ว่าเอเจนต์แบกหลักฐานดิบมากเกินไประหว่างขั้นตอน

ภาษีการลองใหม่

retry tax
= retry and repair cost
/ total workflow cost

สัดส่วนการให้เหตุผล

reasoning share
= reasoning-token cost
/ total model cost

วัดงานแต่ละประเภทแยกกัน เอเจนต์ด้านวิจัย เขียนโค้ด เบราว์เซอร์ และซัพพอร์ตลูกค้า ไม่ควรใช้ฐานเดียวกัน

หกวิธีเพื่อลดต้นทุนโทเค็นของ AI agent

1. ตั้งงบประมาณสำหรับทั้งรัน

การจำกัดเอาต์พุตต่อคำขอไม่สามารถควบคุมเอเจนต์แบบหลายขั้นตอนได้

กำหนดขีดจำกัดระดับรันสำหรับ:

• จำนวนขั้นของโมเดลรวม
• อินพุตและเอาต์พุตสะสม
• การเรียกใช้เครื่องมือและขนาดผลลัพธ์จากเครื่องมือ
• การลองใหม่ตามประเภทความล้มเหลว
• ซับเอเจนต์
• เวลารวมที่ผ่านไปหรือค่าประเมินต้นทุน

ตัวอย่าง Python แบบไม่ผูกกับผู้ให้บริการ ประเมินรันก่อนแต่ละการเรียกโมเดล:

from dataclasses import dataclass
from enum import Enum


class Action(str, Enum):
    CONTINUE = "continue"
    COMPACT = "compact"
    STOP = "stop"


@dataclass(frozen=True)
class Budget:
    max_steps: int = 12
    max_input_tokens: int = 120_000
    max_output_tokens: int = 18_000
    compact_at: float = 0.80


@dataclass
class Usage:
    steps: int = 0
    input_tokens: int = 0
    output_tokens: int = 0


def evaluate_budget(usage: Usage, budget: Budget) -> Action:
    if (
        usage.steps >= budget.max_steps
        or usage.input_tokens >= budget.max_input_tokens
        or usage.output_tokens >= budget.max_output_tokens
    ):
        return Action.STOP

    input_ratio = usage.input_tokens / budget.max_input_tokens

    if input_ratio >= budget.compact_at:
        return Action.COMPACT

    return Action.CONTINUE

รันการตรวจสอบก่อนทุกคำขอโมเดล และอัปเดต Usage จากข้อมูลโทเค็นที่ผู้ให้บริการรายงาน

เมื่อถึง 80% ของงบอินพุต ให้ย่อสถานะหรือจำกัดคำค้นเครื่องมือครั้งถัดไป เมื่อถึง 100% ให้หยุดพร้อมเหตุผลเชิงโครงสร้าง

ข้อผิดพลาดทั่วไป: จำกัดแต่ละคำตอบแต่ปล่อยให้จำนวนขั้น เครื่องมือ และการลองใหม่ไม่จำกัด

2. กรองผลลัพธ์จากเครื่องมือก่อนใส่ลงในทรานสคริปต์

ส่งกลับเฉพาะหลักฐานที่จำเป็นต่อการตัดสินใจถัดไปของเอเจนต์

อย่าเพิ่มทั้ง:

• เว็บเพจ
• ไฟล์
• บันทึก (logs)
• โครงสร้างที่เก็บซอร์สโค้ด (repository tree)
• ผลตอบกลับจากฐานข้อมูล
• เซสชันเทอร์มินัล
• เพย์โหลด API

เมื่อขั้นถัดไปต้องการเพียงไม่กี่ฟิลด์

เครื่องมือค้นหาอาจส่งกลับ:

{
  "source_id": "search_17",
  "title": "Relevant page title",
  "url": "https://example.com/page",
  "relevant_passage": "A short evidence block"
}

เก็บอาร์ติแฟกต์ฉบับเต็มไว้นอกพรอมต์ และดึงเฉพาะส่วนที่แคบลงในภายหลัง

กฎการกรองเครื่องมือ: ส่งเฉพาะฟิลด์ที่จำเป็นต่อการตัดสินใจถัดไป—not ทุกฟิลด์ที่อาจเป็นประโยชน์ในอนาคต

ข้อผิดพลาดทั่วไป: ตัดทอน 1,000 อักขระแรกของเพย์โหลด JSON วิธีนี้อาจทำลายโครงสร้างหรือทำให้ระเบียนที่ต้องการหายไป

ให้พาร์เซเพย์โหลดก่อน เลือกฟิลด์เชิงโครงสร้าง จำกัดอาร์เรย์ แล้วซีเรียไลซ์ JSON ที่ถูกต้อง

3. ทำให้สถานะการปฏิบัติงานกะทัดรัด ไม่ใช่แค่ข้อความสนทนา

การย่อควรรักษาข้อมูลที่จำเป็นต่อการทำงานต่อไป ขณะลบประวัติที่ไม่ส่งผลต่อการกระทำถัดไป

สถานะสรุปที่ใช้งานได้ควรมี:

• เป้าหมายของผู้ใช้และเกณฑ์ความสำเร็จ
• การตัดสินใจที่ได้ทำไปแล้ว
• ข้อเท็จจริงที่ตรวจสอบแล้วและรหัสแหล่งที่มา
• ไฟล์หรือระเบียนที่ถูกเปลี่ยน
• แนวทางที่ล้มเหลว
• คำถามที่ยังเปิดอยู่
• การกระทำถัดไป
• ข้อจำกัดด้านความปลอดภัยและเอาต์พุต

ไม่ควรเล่าเรื่องสนทนาทั้งหมดใหม่

OpenAI มีเอกสารเกี่ยวกับการย่อบริบทสำหรับการโต้ตอบแบบยาวของ Responses API Anthropic มีตัวควบคุมการจัดการบริบทสำหรับการล้างหรือสรุปเนื้อหาเก่า การทำงานต่างกัน ควรตรวจสอบฟิลด์ล่าสุดของผู้ให้บริการก่อนผนวกรวม

กฎการย่อ: รักษาการตัดสินใจและงานที่ยังไม่เสร็จ ลบการบรรยายและหลักฐานที่เรียกใช้ใหม่ได้

ข้อผิดพลาดทั่วไป: ทิ้งรหัสแหล่งที่มา ชื่อไฟล์ที่เปลี่ยน แนวทางที่ถูกปฏิเสธ หรือข้อจำกัดที่ยังไม่แก้

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

4. รักษาคำนำที่ใช้ซ้ำให้คงที่

พรอมต์ของเอเจนต์มักมีบล็อกที่ใช้ซ้ำได้ขนาดใหญ่ เช่น:

• คำสั่งระบบ
• สคีมาของเครื่องมือ
• นโยบายด้านความปลอดภัย
• รูปแบบเอาต์พุต
• เอกสารอ้างอิงร่วม
• คำแนะนำของรีโพซิทอรีหรือผลิตภัณฑ์

วางองค์ประกอบที่คงที่เหล่านี้ไว้ก่อนข้อมูลที่เฉพาะคำขอ:

1. System instructions
2. Policies and constraints
3. Tool definitions
4. Stable examples
5. Shared reference material
6. Request-specific data

หลีกเลี่ยงการวางเวลา ID คำขอ ข้อมูลเซสชัน หรือค่าที่เปลี่ยนบ่อยไว้ตอนต้น

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

ข้อผิดพลาดทั่วไป: เพิ่มอัตรา cache-hit โดยไม่วัดต้นทุนการเขียน อ่าน หรือเก็บแคช

สำหรับการเปรียบเทียบที่กว้างขึ้นระหว่างการแคชพรอมต์ การแคชคำตอบตรง และการแคชเชิงความหมาย ดู How to Reduce AI API Costs

5. ป้องกันการลองใหม่ไม่ให้เล่นบริบทเดิมซ้ำ

การลองใหม่คืออีกหนึ่งขั้นของเอเจนต์ มักมาพร้อมพรอมต์ขนาดใหญ่ชุดเดิม

อย่าทำคำขอที่ล้มเหลวซ้ำ โดยไม่เปลี่ยนสาเหตุของความล้มเหลว

ใช้ idempotency keys สำหรับปฏิบัติการที่มีผลข้างเคียง เช่น การชำระเงิน อีเมล ดีพลอย และการเขียนฐานข้อมูล

ข้อผิดพลาดทั่วไป: ลองเรียกโมเดลที่ถูกจำกัดอัตราซ้ำหลายครั้ง โดยส่งบริบททั้งเอเจนต์ซ้ำทุกครั้ง

ติดตามภาษีการลองใหม่แยกตามประเภทความล้มเหลว เพื่อให้ทีมแก้ลูปที่ใหญ่ที่สุดก่อน

6. จำกัดการให้เหตุผลและซับเอเจนต์ไว้เฉพาะขั้นที่จำเป็น

ไม่ใช่ทุกขั้นของเอเจนต์ต้องการการให้เหตุผลเชิงลึก

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

สงวนความพยายามในการให้เหตุผลระดับสูงไว้สำหรับงานเช่น:

• การวางแผนที่ซับซ้อน
• การเขียนโค้ดที่ยาก
• การสังเคราะห์ข้อมูลหลายเอกสาร
• การตัดสินใจที่คลุมเครือ
• การกู้คืนจากการดำเนินการที่ล้มเหลว

กฎการให้เหตุผล: ใช้ความพยายามในการให้เหตุผลต่ำที่สุด ที่ยังรักษาอัตรางานสำเร็จที่ยอมรับได้

ซับเอเจนต์ก็ต้องมีขอบเขตที่ชัดเจน ให้แต่ละตัวทำงานมี:

• งานที่แคบชัดเจน
• บริบทเฉพาะส่วนที่ตรงงาน
• รายการเครื่องมือที่อนุญาต
• งบโทเค็น
• สคีมาของเอาต์พุตแบบกะทัดรัด

เอเจนต์รากมักต้องการผลการค้นพบ รหัสหลักฐาน ระดับความเชื่อมั่น และประเด็นที่ยังไม่แก้—not ทรานสคริปต์เต็มของตัวทำงาน

กฎซับเอเจนต์: ทำงานคู่ขนานเฉพาะงานที่เป็นอิสระ ไม่ใช่ส่งบริบทซ้ำซ้อน

ข้อผิดพลาดทั่วไป: ส่งประวัติของเอเจนต์รากทั้งหมดให้ทุกตัวทำงาน ก่อนมอบหมายงานที่แคบ

ควรเริ่มปรับปรุงตรงไหนก่อน?

ใช้เทเลเมทรีของเอเจนต์เพื่อเลือกการแทรกแซงแรก

ค่าที่กำหนดด้านล่างคือสัญญาณให้ตรวจสอบ ไม่ใช่มาตรฐานสากล

ลำดับการทำงานที่ปลอดภัยคือ:

1. วัดอินพุตสะสม การคงผลลัพธ์จากเครื่องมือ การลองใหม่ และการให้เหตุผล
2. ตั้งขีดจำกัดแข็งสำหรับจำนวนขั้น เครื่องมือ การลองใหม่ และจำนวนโทเค็นรวม
3. กรองผลลัพธ์จากเครื่องมือที่มีขนาดใหญ่
4. ย่อสถานะเก่าที่จุดเกณฑ์ที่วัดได้
5. ทำให้คำนำพรอมต์ที่ใช้ซ้ำคงที่
6. เปรียบเทียบเส้นทางโมเดลที่ถูกกว่า หลังจากทำความสะอาดลูปเอเจนต์แล้ว

เปลี่ยนตัวแปรหลักครั้งละหนึ่งอย่าง และใช้ชุดประเมินเดียวกันซ้ำ

เปรียบเทียบ:

• อัตรางานที่ยอมรับได้
• ต้นทุนต่อภารกิจที่สำเร็จ
• อินพุตสะสม
• จำนวนการเรียกเครื่องมือ
• ภาษีการลองใหม่
• สัดส่วนการให้เหตุผล
• เวลาแฝง p50 และ p95
• เวลารีวิวโดยมนุษย์

ย้อนการเปลี่ยนแปลงที่ประหยัดโทเค็น แต่ลดคุณภาพงานหรือทำให้หลักฐานที่จำเป็นหายไป

ทดสอบเวิร์กโฟลว์ของเอเจนต์ด้วย CometAPI

ก่อนรันทดสอบหลายโมเดล ใช้หน้า pricing ของ CometAPI และ คู่มือประมาณการต้นทุน เพื่อประมาณอินพุต เอาต์พุต โทเค็นที่แคช และต้นทุนการให้เหตุผล

จากนั้นใช้ model catalog เพื่อหาเส้นทางที่เหมาะสม และ Quickstart เพื่อกำหนดค่าคลไคลเอนต์ที่เข้ากันได้กับ OpenAI

สำหรับ fallback ในการผลิต ให้ทำตาม คู่มือ model fallback ของ CometAPI เพื่อสลับเส้นทางโดยไม่ต้องทำเครื่องมือที่เสร็จแล้วซ้ำหรือทิ้งสถานะที่ตรวจสอบแล้ว

การเข้าถึงแบบรวมทำให้ง่ายต่อการเปรียบเทียบโมเดลและบูรณาการ fallback แต่งบโทเค็น การย่อ การตรวจสอบความถูกต้อง การกรองผลลัพธ์เครื่องมือ ขีดจำกัดการลองใหม่ และเกณฑ์การยอมรับ ควรอยู่ในระดับแอปพลิเคชัน

คำถามที่พบบ่อย

ทำไม AI agent ถึงใช้โทเค็นมากกว่าแชตบอท?

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

การแคชพรอมต์ลดการใช้หน้าต่างบริบทหรือไม่?

ไม่ การแคชพรอมต์ช่วยลดราคา/เวลาแฝงของอินพุตที่ซ้ำ แต่โทเค็นที่แคชแล้วยังนับเป็นบริบทที่ถูกประมวลผล ควรใช้อีกทั้งการย่อบริบท การกรอง หรือการดึงแบบคัดเลือกเพื่อทำให้พรอมต์เล็กลง

เอเจนต์ควรย่อบริบทเมื่อใด?

ย่อก่อนที่การเติบโตของบริบทจะเริ่มกระทบต้นทุน เวลาแฝง หรือพื้นที่เอาต์พุต ตรวจสอบว่าสถานะที่ย่อรักษาการตัดสินใจ รหัสหลักฐาน ชื่อไฟล์ที่เปลี่ยน คำถามที่ยังเปิด และข้อจำกัดด้านความปลอดภัยไว้ครบ

ซับเอเจนต์ช่วยลดต้นทุนโทเค็นหรือไม่?

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

ตัวชี้วัดใดดีที่สุดสำหรับการเพิ่มประสิทธิภาพต้นทุนของ AI agent?

ใช้ cost per successful task เป็นตัวชี้วัดหลัก วิเคราะห์ด้วยอินพุตสะสม การขยายบริบท อัตราการคงผลลัพธ์เครื่องมือ ภาษีการลองใหม่ สัดส่วนการให้เหตุผล เวลาแฝง และเวลารีวิวโดยมนุษย์