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

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

ในโมเดล Claude ทุกรุ่นที่มีอยู่ในรายการปัจจุบัน output tokens มีราคาสูงกว่า input tokens ถึง 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 ทั้งหมดในคราวเดียว prompt token ทุกตัวจะเข้าสู่โครงข่ายใน 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 ที่ถูกสร้าง และเมื่อมันเต็มพื้นที่ของ 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 ทั้งหมดเกิดขึ้นภายในช่วงเวลานั้น ทุกบรรทัดหลังจากนั้นคือขั้นตอนการถอดรหัสทีละส่วน และตัวเลขเวลาจะเพิ่มขึ้นเรื่อยๆ จนกว่า 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'

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

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

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

ให้บันทึกข้อมูลทั้งสี่ฟิลด์ต่อการร้องขอหนึ่งครั้ง output_tokens จะรวมถึงการคิดวิเคราะห์แบบขยายความ ดังนั้นโมเดลที่คิดก่อนตอบจะคิดค่าบริการส่วนการคิดนั้นในอัตราเดียวกับเอาต์พุต หากต้องการประเมินราคา prompt ก่อนส่ง POST /v1/messages/count_tokens จะรับ 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
  }
]

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

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

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

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

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

เนื่องจากราคาของ output สูงกว่า input ถึง 5 เท่า จุดคุ้มทุนจึงเป็นสิ่งที่คำนวณในใจได้ง่าย ให้กำหนดจำนวน input token เป็น I และ output token เป็น 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 ของคุณก่อนที่จะเริ่มทำการปรับแต่งใดๆ

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

พิจารณาขั้นตอนการดึงข้อมูลของเอเจนต์หนึ่งขั้นตอน: มีเอกสารที่ดึงมาและประวัติการสนทนาเป็น input tokens จำนวน 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 ต่อหนึ่งร่าง ในขณะที่ Haiku 4.5 มีต้นทุนอยู่ที่ $0.062 ส่วนต่างราคาที่สูงถึง 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 โดยมี 55,000 จาก 60,000 input tokens ที่ถูกดึงมาจากแคชที่พร้อมใช้งาน

[
  {
    "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. ทำ Batch งานทุกอย่างที่ไม่มีใครรอผลลัพธ์แบบทันที
4. ลบคำสั่งที่ทำให้คำตอบยืดยาวเกินจำเป็น

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

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

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

กลไกสุดท้ายคือสิ่งที่คนมักมองข้าม วลีอย่าง "จงอธิบายอย่างละเอียด" หรือ "จงอธิบายเหตุผลของคุณ" เป็นการกำหนดความยาวของผลลัพธ์ในทุกการเรียกใช้งาน ให้เปลี่ยนมาใช้การกำหนดรูปแบบที่ต้องการแทน เช่น "ตอบไม่เกินสามประโยค" หรือ "ส่งคืนเฉพาะ JSON object โดยไม่ต้องมีคำนำ" System prompt ที่เพิ่มจำนวน token เข้าไป 300 token ในทุกคำตอบ จะมีต้นทุนสูงกว่าการใส่ 300 token นั้นไว้ใน prompt ปกติถึงห้าเท่า การควบคุมค่าใช้จ่ายของ agent ที่ทำงานต่อเนื่อง ครอบคลุมด้านการตรวจสอบ และ การเปรียบเทียบว่า API หรือการสมัครสมาชิกแบบเหมาจ่ายแบบไหนถูกกว่าสำหรับรูปแบบการใช้งานของคุณ เป็นสิ่งที่ควรตัดสินใจก่อนที่คุณจะเสียเวลาเป็นสัปดาห์เพื่อปรับจูนค่าใช้จ่ายต่อ token ซึ่งการสมัครสมาชิกอาจครอบคลุมส่วนนี้ไปแล้ว สำหรับนักพัฒนาคนเดียว เรื่องนี้มักขึ้นอยู่กับว่า Claude Pro ราคา 20 ดอลลาร์ต่อเดือนและขีดจำกัดการใช้งานที่มาพร้อมกัน เพียงพอต่อปริมาณงานที่คุณต้องจ่ายเงินตามจริงหรือไม่ หากคุณพบว่าใช้งานถึงขีดจำกัดกลางคันบ่อยครั้ง การวิเคราะห์ว่าคุณกำลังติดขัดที่ส่วนไหน คือสิ่งแรกที่ต้องทำ เพราะวิธีแก้ไขคือการใช้โมเดลที่เล็กลง, ลดบริบทที่ส่งไป, ซื้อเครดิตการใช้งานเพิ่ม หรือย้ายงานนั้นไปทำบน API ที่คิดเงินตามจริง หากพบว่า API ที่คิดเงินตามจริงเป็นทางเลือกที่ถูกกว่าสำหรับงานนั้น การลดระดับแผนการใช้งานหรือยกเลิก จะไม่ทำให้เดือนที่คุณจ่ายเงินไปแล้วเสียเปล่า ดังนั้นการเปลี่ยนแผนจึงไม่มีต้นทุนแฝง หากแผนที่คุณกำลังเปรียบเทียบกับ Pro คือ ChatGPT แทนที่จะเป็น API แบบคิดเงินตามจริง การเปรียบเทียบราคาการสมัครสมาชิกทั้งสองแบบ จะแสดงให้เห็นว่าแบบไหนคุ้มค่ากว่าสำหรับงานเขียนโค้ด หากคำถามนี้มาจากทีมงานไม่ใช่แค่นักพัฒนาคนเดียว โปรดทราบว่า Claude Enterprise คิดค่าธรรมเนียมต่อที่นั่งควบคู่ไปกับค่า token ตามอัตรา API นี้ ดังนั้นกลไกทุกอย่างในหน้านี้จึงยังคงใช้ได้กับส่วนของค่าใช้จ่ายที่คิดตามจริงในบิลนั้น

FAQ

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

การสร้าง output 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 จึงเป็นเพียงเพดานสูงสุดไม่ใช่การจองพื้นที่ใช้งาน อย่างไรก็ตามค่านี้ยังคงมีความสำคัญเพราะเป็นขีดจำกัดเดียวที่ป้องกันไม่ให้การตอบกลับยาวเกินความจำเป็น ควรตั้งค่าให้สูงกว่าค่า 95th percentile ของ output_tokens ที่คุณสังเกตพบเล็กน้อย จากนั้นให้จัดการกับ stop_reason: "max_tokens" ในโค้ดแทนการปล่อยให้คำตอบถูกตัดทอนโดยไม่แจ้งเตือน

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

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