ทำไม Claude ถึงคิดราคา Output Token แพงกว่า Input 5 เท่า

เหตุใด output token จึงมีราคาสูงกว่า input token

ในโมเดล Claude ทุกรุ่นที่มีอยู่ในรายการปัจจุบัน output token มีราคาสูงกว่า input token ถึง 5 เท่า สาเหตุมาจากลักษณะของการประมวลผล การอ่าน prompt เป็นการประมวลผลผ่านโมเดลเพียงรอบเดียว แต่การเขียนคำตอบนั้นต้องประมวลผลทีละ token และแต่ละขั้นตอนต้องรอผลลัพธ์จากขั้นตอนก่อนหน้าเสมอ

อัตราส่วนนี้เท่ากันในทุกรายการราคา ดังนั้นการเลือกโมเดลจึงไม่ส่งผลต่อสัดส่วนค่าใช้จ่ายในส่วนของ output แต่ขึ้นอยู่กับลักษณะงานของคุณ งานประเภท agent ที่อ่าน 60,000 tokens และตอบกลับ 800 tokens จะมีค่าใช้จ่ายในส่วน output ต่ำมาก ในขณะที่งานร่างเอกสารที่อ่าน 2,000 tokens และเขียน 12,000 tokens จะมีค่าใช้จ่ายในส่วน input ต่ำมาก ทั้งสองกรณีคำนวณตามอัตราค่าบริการของ Anthropic ประจำเดือนสิงหาคม 2026 ดังนี้

Prefill ทำงานหนึ่งครั้ง, Decoding ทำงานหนึ่งครั้งต่อหนึ่ง token

Inference server จัดการคำขอโดยแบ่งเป็นสองระยะที่มีต้นทุนต่างกันอย่างมาก ระยะ Prefill คือการอ่าน prompt ส่วนระยะ Decoding คือการเขียนคำตอบ

Prefill จะประมวลผล prompt ทั้งหมดในคราวเดียว โดย token ทุกตัวใน prompt จะเข้าสู่เครือข่ายใน forward pass เดียวกัน ทำให้งานด้าน attention และ feed-forward กลายเป็นการคูณเมทริกซ์ขนาดใหญ่จำนวนไม่กี่ครั้งที่ครอบคลุม token หลายพันตัวในครั้งเดียว การอ่าน model weights ออกจากหน่วยความจำเพียงครั้งเดียวก็เพียงพอสำหรับ prompt ทั้งหมด ส่งผลให้หน่วยประมวลผลเมทริกซ์ของ accelerator ทำงานได้อย่างเต็มที่ ดังนั้น Prefill จึงเป็นกระบวนการที่ถูกจำกัดด้วยพลังการคำนวณ (compute-bound): ขีดจำกัดอยู่ที่ความเร็วในการคูณเลขของชิป

Decoding ไม่สามารถทำงานในลักษณะเดียวกันได้ เนื่องจาก token ที่ 2 ต้องอาศัย token ที่ 1 ดังนั้น token ที่โมเดลเพิ่งสร้างขึ้นจะกลายเป็นส่วนหนึ่งของอินพุตในขั้นตอนถัดไป ทำให้ไม่สามารถประมวลผลขั้นตอนเหล่านี้พร้อมกันได้ แต่ละ output token จะต้องผ่าน forward pass ของตัวเอง และแต่ละ pass จะต้องอ่าน model weights ทั้งชุดออกจาก high-bandwidth memory เพื่อสร้าง token เพียงตัวเดียว ทำให้ Decoding เป็นกระบวนการที่ถูกจำกัดด้วยความเร็วหน่วยความจำ (memory-bound): ขีดจำกัดอยู่ที่ความเร็วในการย้ายข้อมูล weights ไม่ใช่ความเร็วในการคูณเลข ปริมาณการรับส่งข้อมูล weights เท่าเดิมที่ใช้ประมวลผล prompt ทั้งชุดในช่วง Prefill จะให้ผลลัพธ์เป็น token เพียงตัวเดียวในช่วง Decoding

ระบบให้บริการจึงแก้ปัญหานี้ด้วยการทำ batching โดยนำหลายคำขอมาทำ Decoding พร้อมกัน เพื่อให้การอ่าน weights หนึ่งครั้งสามารถสร้าง token ให้กับทุกคำขอใน batch นั้นได้ นี่คือเหตุผลที่ Decoding มีต้นทุนที่ยอมรับได้ โดยมีขีดจำกัดอยู่ที่หน่วยความจำเช่นเดิม คำขอแต่ละรายการที่กำลังประมวลผลจะต้องเก็บ KV cache (key/value cache ซึ่งเป็นสถานะ attention ที่บันทึกไว้สำหรับแต่ละ token ที่ผ่านมา) โดย cache นี้จะขยายขนาดขึ้นตามจำนวน token ที่สร้าง และเมื่อ cache เต็มพื้นที่ของ accelerator ก็จะไม่สามารถเพิ่มจำนวน batch ได้อีก

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

วัดช่องว่างระหว่างอินพุตและเอาต์พุตด้วยตัวคุณเอง

ติดตั้งเครื่องมือบนเครื่อง Ubuntu ใดก็ได้:

sudo apt update && sudo apt install -y curl jq moreutils

จากนั้นให้สตรีม prompt สั้นๆ ที่ต้องการคำตอบยาวๆ และประทับเวลาที่แต่ละบรรทัดได้รับ

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s จะใส่คำนำหน้าแต่ละบรรทัดด้วยจำนวนวินาทีที่ผ่านไปนับตั้งแต่เริ่มคำสั่ง มีสองสิ่งที่ควรสังเกตจากผลลัพธ์นี้ บรรทัด content_block_delta แรกคือเวลาที่คุณได้รับ token แรก ซึ่งกระบวนการ prefill ทั้งหมดเกิดขึ้นภายในช่วงเวลานั้น ทุกบรรทัดหลังจากนั้นคือขั้นตอนการถอดรหัส (decoding) ทีละส่วน และตัวเลขเวลาจะเพิ่มขึ้นเรื่อยๆ จนกว่า message_stop จะมาถึง

คราวนี้ลองสลับรูปแบบ โดยใส่เอกสารยาวๆ ลงใน prompt และจำกัดคำตอบไว้เพียงไม่กี่ token:

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

delta แรกจะใช้เวลานานกว่าเมื่อเทียบกับ prompt สั้นๆ เนื่องจาก prefill ต้องอ่านข้อความจำนวนมาก หลังจากได้รับส่วนแรกแล้ว การตอบกลับจะสิ้นสุดลงเกือบจะทันทีเพราะเหลือ token ให้ถอดรหัสเพียงไม่กี่ตัว ข้อมูลหลายหมื่น token ถูกส่งเข้าไปแต่เวลาแทบไม่ขยับ ในขณะที่ข้อมูลเพียงไม่กี่ร้อย token ถูกส่งออกมาแต่ใช้เวลาไปตลอดช่วงการทำงาน

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

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

บันทึกทั้งสี่ฟิลด์ต่อการร้องขอหนึ่งครั้ง output_tokens รวมการคิดวิเคราะห์แบบขยายความ (extended thinking) ไว้ด้วย ดังนั้นโมเดลที่คิดก่อนตอบจะเรียกเก็บค่าใช้จ่ายส่วนการคิดนั้นในอัตราเดียวกับ output หากต้องการประเมินราคาก่อนส่ง prompt จริง POST /v1/messages/count_tokens จะรับ request body เดียวกันและส่งคืน {"input_tokens": N} โดยไม่ต้องรันโมเดลและไม่มีค่าใช้จ่าย นี่ไม่ใช่ส่วนเดียวของ API ที่ไม่มีค่าใช้จ่าย และการตรวจสอบ ส่วนประกอบของ Claude API ที่ไม่มีการเรียกเก็บเงิน เป็นสิ่งที่ควรทำก่อนที่คุณจะวางงบประมาณสำหรับโปรเจกต์แรก

ราคาต่อล้านโทเค็นของ Claude ณ เดือนสิงหาคม 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

คอลัมน์สุดท้ายคือผลหารของ output ต่อ input ซึ่งแสดงค่า 5 ในทุกแถว Haiku 4.5 คิดค่าบริการขาเข้า $1 และขาออก $5 ส่วน Opus 5 คิดค่าบริการ $5 และ $25 สำหรับ Fable 5 ซึ่งมีราคาสูงที่สุด คิดค่าบริการ $10 และ $50 โดยเนื้อหาใน สิ่งที่ราคาของ Fable 5 มอบให้คุณ เป็นสิ่งที่ควรศึกษาให้เข้าใจก่อนจะตัดสินใจมองข้ามแถวบนสุดไป การขยับขึ้นไปใช้รุ่นที่สูงกว่าจะคูณค่าใช้จ่ายทั้งสองฝั่งด้วยตัวคูณเดียวกัน ซึ่งจะเปลี่ยนยอดรวมของคุณแต่ยังคงสัดส่วนระหว่าง input และ output ไว้เท่าเดิม

Sonnet 5 ปรากฏชื่อสองครั้งเนื่องจากราคาช่วงเปิดตัวจะหมดอายุลง โดยจนถึงวันที่ 31 สิงหาคม 2026 จะคิดค่าบริการ $2 และ $10 และตั้งแต่วันที่ 1 กันยายน 2026 เป็นต้นไป จะปรับเป็นราคามาตรฐานที่ $3 และ $15 ซึ่งเพิ่มขึ้น 50% ในทั้งสองฝั่ง ตัวอย่างการคำนวณทั้งหมดด้านล่างนี้ใช้ราคาของเดือนสิงหาคม

ราคาอาจมีการเปลี่ยนแปลง และหน้านี้ไม่ใช่แหล่งข้อมูลที่คุณควรใช้ตรวจสอบราคาล่าสุด claude.com/pricing คือแหล่งข้อมูลที่ถูกต้องที่สุด สิ่งที่ยังคงใช้ได้เสมอแม้ราคาจะเปลี่ยนไปคือวิธีการคำนวณ

มีข้อควรระวังประการหนึ่งที่รายการราคาไม่ได้แสดงไว้ เอกสารของ Anthropic ระบุว่า Claude 4.7 และรุ่นที่ใหม่กว่าใช้ tokenizer แบบใหม่ ซึ่งสร้างโทเค็นมากกว่า tokenizer ใน Sonnet 4.6 และรุ่นก่อนหน้าประมาณ 30% สำหรับข้อความชุดเดียวกัน การเปรียบเทียบสองโมเดลด้วยราคาต่อล้านโทเค็นเพียงอย่างเดียวอาจทำให้รุ่นใหม่ดูคุ้มค่ากว่าความเป็นจริง เพราะเอกสารชุดเดียวกันจะถูกนับเป็นจำนวนโทเค็นที่มากกว่าในรุ่นใหม่ ให้เปรียบเทียบจากต้นทุนต่อชิ้นงานที่เสร็จสมบูรณ์ และทดสอบ prompt จริงของคุณกับโมเดลที่คุณวางแผนจะใช้งานจริง กับดักแบบเดียวกันนี้ยังเกิดขึ้นเมื่อเปรียบเทียบระหว่างผู้ให้บริการแต่ละราย ซึ่งมี tokenizer ที่แตกต่างกันมากกว่านั้น ดังนั้น การคำนวณต้นทุนงานจริงบนทั้ง Claude และ ChatGPT จะให้ข้อมูลที่เป็นประโยชน์มากกว่าการนำตารางราคาของทั้งสองมาวางเทียบกัน และ มูลค่าของหนึ่งล้านโทเค็นของ Claude ในรูปแบบข้อความจริง จะช่วยให้เห็นภาพว่าปริมาณดังกล่าวมีขนาดเท่าใดในทางปฏิบัติ

เมื่อใดที่ค่าใช้จ่ายจาก output จะเริ่มส่งผลต่อบิลของคุณมากกว่าส่วนอื่น

ด้วยราคาของ output ที่สูงเป็น 5 เท่าของ input ทำให้จุดคุ้มทุนเป็นสิ่งที่คำนวณในใจได้ง่าย ให้แทนจำนวน token ของ input ด้วย I และจำนวน token ของ output ด้วย O ต้นทุนของ input คือ I ส่วนต้นทุนของ output คือ 5 เท่าของ O ค่าใช้จ่ายส่วน output จะเกินครึ่งหนึ่งของงบประมาณเมื่อ 5 เท่าของ O มีค่ามากกว่า I ซึ่งคิดเป็นอัตราส่วน token คือ input 5 ส่วนต่อ output 1 ส่วน

ดังนั้น หาก prompt ของคุณมีความยาวมากกว่าคำตอบเกิน 5 เท่า ต้นทุนของ input จะเป็นรายการที่แพงที่สุด แต่หากต่ำกว่านั้น ต้นทุนของ output จะเป็นรายการที่แพงกว่า

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

ที่อัตราส่วน 100 ต่อ 1 ต้นทุนของ output จะคิดเป็น 4.8% ของค่าใช้จ่ายทั้งหมด ซึ่งการลดขนาด prompt จะเป็นงานเดียวที่คุ้มค่าในการทำ ที่อัตราส่วน 5 ต่อ 1 ทั้งสองฝั่งจะมีต้นทุนเท่ากัน และที่อัตราส่วน 1 ต่อ 6 ต้นทุนของ output จะคิดเป็น 96.8% ซึ่งทำให้ต้นทุนของ prompt กลายเป็นเพียงตัวเลขส่วนเกินที่ไม่มีนัยสำคัญ คนส่วนใหญ่มักประเมินอัตราส่วนของตนเองผิดพลาด ดังนั้นควรดึงข้อมูลจาก log ของคุณก่อนที่จะเริ่มปรับแต่งสิ่งใดก็ตาม

ภาระงานของเอเจนต์: บริบทขาเข้ายาวและคำตอบขาออกสั้น

พิจารณาขั้นตอนการดึงข้อมูลของเอเจนต์หนึ่งขั้นตอน: มีการนำเข้าเอกสารที่ดึงมาและประวัติการสนทนารวม 60,000 tokens และได้คำตอบ 800 tokens ซึ่งคิดเป็นอัตราส่วน 75 ต่อ 1 ถือเป็นเรื่องปกติสำหรับกระบวนการที่ต้องอ่านข้อมูลก่อนเขียนผลลัพธ์

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

ผลลัพธ์คือ 6.25% ของการเรียกใช้งานนั้นในทุกโมเดล เนื่องจากอัตราส่วนนี้ถูกกำหนดไว้คงที่ตลอดรายการราคา การเรียกใช้งานนี้มีค่าใช้จ่าย $0.32 บน Opus 5, $0.128 บน Sonnet 5 ตามอัตราค่าบริการเดือนสิงหาคม และ $0.064 บน Haiku 4.5 หากมีการเรียกใช้งานขั้นตอนดังกล่าววันละ 200 ครั้งบน Opus 5 จะมีค่าใช้จ่ายวันละ $64

จุดที่สามารถปรับเปลี่ยนได้นั้นชัดเจนเมื่อพิจารณาการแบ่งสัดส่วน การลดคำตอบจาก 800 tokens เหลือ 400 tokens ช่วยประหยัดค่าใช้จ่ายได้เพียงประมาณ 3% ของการเรียกใช้งานนั้น แต่การตัดบริบทที่ไม่จำเป็นออกไป 20,000 tokens จาก prompt จะช่วยประหยัดค่าใช้จ่ายได้ถึงประมาณหนึ่งในสาม ดังนั้นการพยายามลดความยาวของผลลัพธ์ในเอเจนต์ที่เน้นการอ่านข้อมูลเป็นหลักจึงแทบไม่เกิดประโยชน์ จุดที่ tokens ของเอเจนต์เขียนโค้ดถูกใช้ไปจริง จะแจกแจงรายละเอียดว่าสิ่งใดที่เติมเต็ม prompt เหล่านั้นตั้งแต่แรก

ภาระงานสร้างเนื้อหา: คำสั่งสั้น, ร่างยาว

คราวนี้ลองสลับรูปแบบกันบ้าง หากมีโจทย์ความยาว 2,000 token และต้องการร่างเนื้อหา 12,000 token ซึ่งคิดเป็นอัตราส่วน 1 ต่อ 6

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

ผลลัพธ์คือ 96.8% ของค่าใช้จ่ายนี้ Opus 5 มีค่าใช้จ่ายอยู่ที่ $0.31 ต่อการร่างหนึ่งฉบับ เทียบกับ $0.062 บน Haiku 4.5 ส่วนต่างที่สูงถึง 5 เท่านี้มาจากฝั่ง output เกือบทั้งหมด ซึ่งเป็นจุดที่โมเดลราคาประหยัดช่วยคุณประหยัดค่าใช้จ่ายได้มากที่สุด

คอลัมน์สุดท้ายคืองานเดียวกันที่ประมวลผลผ่าน Batch API ซึ่งช่วยลดค่าใช้จ่ายทั้ง input และ output ลง 50% ทำให้ Opus 5 ลดราคาลงเหลือ $0.155 ต่อการร่างหนึ่งฉบับ การประมวลผลแบบ Batch จะส่งผลลัพธ์กลับมาภายใน 24 ชั่วโมงแทนที่จะได้ทันที จึงเหมาะสำหรับงานสร้างรายงานข้ามคืนหรืองานจำแนกข้อมูลจำนวนมาก แต่ไม่เหมาะกับงานที่ต้องรอผลลัพธ์ในขณะนั้น

การเลือกใช้โมเดล (Model routing) ในจุดนี้ให้ความคุ้มค่าในแบบที่ขั้นตอนการทำงานของ agent ให้ไม่ได้ หากส่วนที่ต้องเขียนเนื้อหายาวๆ เป็นงานเชิงกลไก เช่น การจัดรูปแบบข้อความใหม่หรือการขยายความจากโครงร่างที่คุณอนุมัติไว้แล้ว โมเดลราคาประหยัดสามารถสร้าง token เหล่านั้นได้ในราคาเพียงหนึ่งในห้า การเลือกระหว่าง Opus, Sonnet และ Haiku จะอธิบายถึงจุดที่เส้นแบ่งด้านคุณภาพอยู่จริง

การแคชช่วยลดราคาเฉพาะส่วน input เท่านั้น

Prompt caching จะจัดเก็บส่วนนำของ prompt ไว้บนเซิร์ฟเวอร์ และคิดค่าบริการในอัตราส่วนหนึ่งของราคา input ปกติเมื่อมีการอ่านข้อมูลนั้นซ้ำ ณ เดือนสิงหาคม 2026 ตัวคูณราคาคือ 1.25 เท่าของอัตรา input พื้นฐานสำหรับการเขียนแคชที่มีอายุ 5 นาที, 2 เท่าสำหรับการเขียนแคชที่มีอายุ 1 ชั่วโมง และ 0.1 เท่าสำหรับการอ่านข้อมูลที่พบในแคช (cache hit)

ส่วน output ไม่รวมอยู่ในข้อเสนอนี้ ไม่มีการแคช output ใดๆ ทุก token ที่โมเดลเขียนจะถูกเรียกเก็บเงินในอัตรา output เต็มจำนวนเสมอ ไม่ว่าส่วนใดของ prompt จะถูกดึงกลับมาจากการเป็น cache hit ก็ตาม

ลองพิจารณาขั้นตอนการทำงานของ agent เดียวกันบน Opus 5 โดยมี input token 55,000 จากทั้งหมด 60,000 token ที่ดึงมาจากแคชที่พร้อมใช้งาน

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

ค่าใช้จ่ายในการเรียกใช้งานจะลดลงจาก $0.32 เหลือ $0.0725 ส่วนบรรทัดค่าใช้จ่ายของ output จะไม่มีการเปลี่ยนแปลง คือ $0.02 ก่อนการแคช และ $0.02 หลังการแคช การแคชช่วยลดค่าใช้จ่ายรวมและเปลี่ยนโครงสร้างของต้นทุน เดิมที output คิดเป็น 6.25% ของการเรียกใช้งานนั้น แต่ตอนนี้สัดส่วนดังกล่าวเพิ่มขึ้นเป็นมากกว่าหนึ่งในสี่ ซึ่งส่งผลต่อการตัดสินใจว่าควรปรับปรุงส่วนใดต่อไปเพื่อให้เกิดความคุ้มค่าที่สุด

การเรียกใช้งานครั้งแรกจะเป็นการจ่ายค่าเขียนแคช การเขียนแคชอายุ 5 นาทีมีต้นทุน 1.25 เท่าของ input พื้นฐาน ดังนั้นจึงคุ้มทุนหลังจากเกิด cache hit เพียงครั้งเดียว ส่วนการเขียนแคชอายุ 1 ชั่วโมงมีต้นทุน 2 เท่า จึงต้องใช้ cache hit สองครั้ง ตัวคูณสำหรับการเขียนและการอ่าน และจุดที่การแคชไม่คุ้มทุนอีกต่อไป ได้อธิบายรายละเอียดการคำนวณดังกล่าวไว้แล้ว

สี่กลไกที่คุณควบคุมได้

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

max_tokens เป็นเพดานจำกัดสูงสุด การตั้งค่าไว้สูงไม่ได้ทำให้เสียค่าใช้จ่ายเพิ่มในตัวมันเอง เพราะคุณถูกเรียกเก็บเงินตามจำนวนโทเค็นที่สร้างจริง ไม่ใช่ตามเพดานที่ตั้งไว้ การตั้งค่าเพดานที่ยืดหยุ่นช่วยป้องกันไม่ให้คำตอบที่ผิดพลาดถูกตัดจบกลางคัน ให้ดึงข้อมูลการกระจายตัวของ output_tokens ออกจาก log ของคุณ แล้วตั้งค่าเพดานให้สูงกว่าเปอร์เซ็นไทล์ที่ 95 เล็กน้อย จากนั้นจัดการกับ stop_reason: "max_tokens" ในโค้ดโดยการสั่งให้สร้างคำตอบต่อหรือลองใหม่ การตรวจพบการตัดจบ (truncation) มีต้นทุนต่ำกว่าการปล่อยให้โมเดลร่ายยาวถึง 4,000 โทเค็นที่คุณต้องจ่ายเงินและไม่ได้ใช้งานจริง กระบวนการคิดที่ยาวขึ้นจะถูกนับรวมใน output_tokens ด้วย ดังนั้นให้กำหนดงบประมาณส่วนนี้จากข้อมูลชุดเดียวกัน

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

Batching เป็นกลไกเดียวที่ช่วยลดราคาเอาต์พุตได้ โดยลดค่าใช้จ่ายลง 50% ทั้งขาเข้าและขาออก โดยแลกกับการได้รับผลลัพธ์ภายใน 24 ชั่วโมง ซึ่งงานที่ตั้งเวลาไว้ล่วงหน้าทั้งหมดสามารถใช้กลไกนี้ได้

กลไกสุดท้ายคือสิ่งที่คนมักมองข้าม วลีอย่าง "be thorough" หรือ "explain your reasoning" จะเพิ่มความยาวของเอาต์พุตในทุกการเรียกใช้งาน ให้เปลี่ยนมาใช้การกำหนดรูปแบบที่ต้องการแทน เช่น "Answer in at most three sentences" หรือ "Return only the JSON object, with no preamble" การตั้งค่า system prompt ที่เพิ่มโทเค็นเข้าไป 300 โทเค็นในทุกคำตอบ จะมีต้นทุนสูงกว่าการใส่ 300 โทเค็นนั้นไว้ใน prompt ปกติถึงห้าเท่า การควบคุมค่าใช้จ่ายของเอเจนต์ที่ทำงานต่อเนื่อง ครอบคลุมด้านการตรวจสอบ และ การเปรียบเทียบว่า API หรือการสมัครสมาชิกแบบเหมาจ่ายแบบไหนถูกกว่าสำหรับรูปแบบการใช้งานของคุณ เป็นสิ่งที่ควรตัดสินใจก่อนที่คุณจะเสียเวลาเป็นสัปดาห์เพื่อปรับจูนค่าใช้จ่ายต่อโทเค็น ซึ่งการสมัครสมาชิกอาจครอบคลุมส่วนนี้ไปแล้ว สำหรับนักพัฒนาหนึ่งคน เรื่องนี้มักขึ้นอยู่กับว่า Claude Pro ราคา 20 ดอลลาร์ต่อเดือนและขีดจำกัดการใช้งานที่มาพร้อมกัน เพียงพอต่อปริมาณงานที่คุณต้องจ่ายเงินตามจริงหรือไม่ หากคุณพบว่าใช้งานถึงขีดจำกัดกลางคันบ่อยครั้ง การวิเคราะห์ว่าคุณกำลังรอคอยหน้าต่างการทำงานส่วนไหน คือสิ่งแรกที่ต้องทำ เพราะวิธีแก้ไขคือการใช้โมเดลที่เล็กลง, บริบทที่เบาลง, การซื้อเครดิตเพิ่ม หรือย้ายงานนั้นไปทำบน API แบบคิดเงินตามจริง หาก API แบบคิดเงินตามจริงกลายเป็นทางเลือกที่ถูกกว่าสำหรับงานนั้น การลดระดับแผนการใช้งานหรือยกเลิก จะไม่ทำให้เดือนที่คุณจ่ายเงินไปแล้วสูญเปล่า ดังนั้นการเปลี่ยนแผนจึงไม่มีต้นทุนแฝง หากแผนที่คุณกำลังเปรียบเทียบกับ Pro คือ ChatGPT แทนที่จะเป็น API แบบคิดเงินตามจริง การเปรียบเทียบราคาการสมัครสมาชิกทั้งสองแบบ จะแสดงให้เห็นว่าแบบไหนถูกกว่าสำหรับงานเขียนโค้ด หากคำถามนี้มาจากทีมแทนที่จะเป็นนักพัฒนาคนเดียว โปรดทราบว่า Claude Enterprise คิดค่าธรรมเนียมต่อที่นั่งควบคู่ไปกับโทเค็นในอัตราเดียวกับ API ดังนั้นกลไกทุกอย่างในหน้านี้จึงยังคงใช้ได้กับส่วนของค่าใช้จ่ายที่คิดตามจริงในบิลนั้น

FAQ

ทำไม output token ถึงมีราคาสูงกว่า input token?

การสร้าง token เหล่านี้ต้องใช้เวลาประมวลผลบน accelerator ต่อหนึ่ง token มากกว่ามาก โดย prompt จะถูกประมวลผลในรอบ forward pass เดียวสำหรับข้อมูลทั้งหมด ทำให้การอ่าน model weights เพียงครั้งเดียวครอบคลุม token หลายพันรายการ และฮาร์ดแวร์จะถูกจำกัดด้วยความเร็วในการคูณเมทริกซ์ (multiply throughput) ในขณะที่การตอบกลับจะถูกสร้างขึ้นทีละ token ซึ่งแต่ละ token จำเป็นต้องทำ forward pass ของตัวเองโดยต้องอ่าน model weights ทั้งหมดใหม่อีกครั้ง ทำให้ฮาร์ดแวร์ถูกจำกัดด้วย memory bandwidth แทน Anthropic กำหนดราคา output ไว้ที่ 5 เท่าของ input สำหรับผลิตภัณฑ์ทั้งหมดในปัจจุบัน ตั้งแต่ Haiku 4.5 ไปจนถึง Fable 5

การทำ prompt caching ช่วยให้ output token มีราคาถูกลงหรือไม่?

ไม่ การทำ prompt caching มีผลกับ input เท่านั้น ณ เดือนสิงหาคม 2026 การอ่านจาก cache มีค่าใช้จ่าย 0.1 เท่าของอัตรา input พื้นฐาน และการเขียนลง cache มีค่าใช้จ่าย 1.25 เท่าสำหรับระยะเวลา 5 นาที หรือ 2 เท่าสำหรับระยะเวลา 1 ชั่วโมง ส่วน output จะถูกเรียกเก็บเงินในอัตราเต็มเสมอในทุกการเรียกใช้งาน ไม่ว่า cache จะทำงานอย่างไรก็ตาม นี่คือเหตุผลที่การทำ caching เปลี่ยนแปลงทั้งรูปแบบและขนาดของค่าใช้จ่ายของคุณ เมื่อค่าใช้จ่ายฝั่ง input ลดลง สัดส่วนของค่าใช้จ่ายฝั่ง output จึงกลายเป็นส่วนสำคัญที่ต้องพิจารณา

การตั้งค่า max_tokens ไว้สูงจะทำให้เสียเงินเพิ่มหรือไม่หากการตอบกลับสั้น?

ไม่ คุณจะถูกเรียกเก็บเงินตามจำนวน token ที่โมเดลสร้างขึ้นจริง ดังนั้น max_tokens จึงเป็นเพียงเพดานสูงสุดไม่ใช่การจองทรัพยากร อย่างไรก็ตามค่านี้ยังคงมีความสำคัญเพราะเป็นข้อจำกัดเดียวที่ป้องกันไม่ให้การตอบกลับยาวเกินความจำเป็น ควรตั้งค่าให้สูงกว่าค่าเฉลี่ยเปอร์เซ็นไทล์ที่ 95 ของ output_tokens ที่คุณสังเกตได้เล็กน้อย จากนั้นให้จัดการกับ stop_reason: "max_tokens" ในโค้ดแทนการปล่อยให้คำตอบถูกตัดทอนโดยไม่แจ้งเตือน

ฉันจะหาอัตราส่วน input ต่อ output token ของตัวเองได้อย่างไร?

ให้บันทึกค่า input_tokens, output_tokens, cache_read_input_tokens และ cache_creation_input_tokens จากออบเจกต์ usage ของทุกการตอบกลับ จากนั้นให้นำผลรวมมาหารกันในรอบสัปดาห์ หากอัตราส่วนสูงกว่า 5 ต่อ 1 แสดงว่าค่าใช้จ่ายส่วนใหญ่อยู่ที่ prompt ดังนั้นควรทำ cache ส่วนที่คงที่และตัดส่วนที่เหลือออก หากอัตราส่วนต่ำกว่านั้น แสดงว่าค่าใช้จ่ายส่วนใหญ่อยู่ที่การตอบกลับ ดังนั้นควรจำกัดความยาวและย้ายขั้นตอนที่สร้าง token จำนวนมากไปใช้โมเดลที่ราคาถูกกว่าหรือใช้ Batch API แทน