Claude Opus 4.7 กับ tokenizer ใหม่: พรอมป์ต์จะใช้ token มากขึ้นและแพงขึ้นจริงหรือไม่

กรณีของ Claude Opus 4.7 เป็นตัวอย่างที่ชัดเจนมาก เอกสารของ Anthropic ระบุว่า tokenizer ใหม่อาจใช้ token ราว 1x ถึง 1.35x เมื่อประมวลผลข้อความ เทียบกับโมเดลก่อนหน้า หรือมากขึ้นได้ถึงประมาณ 35% โดยขึ้นกับเนื้อหา และถ้าใช้ /v1/messages/count_tokens กับ input เดียวกัน จำนวน token ของ Claude Opus 4.7 จะต่างจาก Claude Opus 4.6

สรุปก่อน: มีโอกาสแพงขึ้น แต่ไม่ใช่เพิ่ม 35% ทุกกรณี

คำตอบที่รัดกุมที่สุดคือ tokenizer ใหม่สามารถทำให้พรอมป์ต์เดิมมี input tokens มากขึ้นได้ และถ้าราคา input token ต่อหน่วยเท่าเดิม ต้นทุนฝั่ง input ก็มีโอกาสสูงขึ้นตาม แต่ตัวเลขจาก Anthropic คือช่วงประมาณ 1x–1.35x และระบุชัดว่าแตกต่างตามเนื้อหา จึงไม่ควรแปลว่า “ทุกพรอมป์ต์จะแพงขึ้น 35%”

อีกจุดที่ต้องระวังคือ จำนวน token ที่เพิ่มขึ้นไม่เท่ากับบิลรวมเพิ่มขึ้นเท่ากันเสมอไป เอกสาร pricing ของ Anthropic แยก Base Input Tokens, Cache Writes, Cache Hits และ Output Tokens ออกจากกัน ขณะที่ OpenAI และ Gemini ก็มีเอกสารราคา API ของตัวเอง ดังนั้น input token ที่มากขึ้นจะกระทบต้นทุนฝั่ง input แต่ต้นทุนสุดท้ายยังขึ้นกับ output tokens, การใช้ cache, รุ่นโมเดล และรูปแบบ request จริง

ทำไมข้อความเดิมถึงกลายเป็น token คนละจำนวนได้

Token ไม่ใช่จำนวนคำ และไม่ใช่จำนวนตัวอักษรแบบตรงไปตรงมา OpenAI มีคู่มือ tiktoken ที่แสดงว่าต้องใช้ encoding ที่เหมาะกับโมเดลเพื่อคำนวณว่าข้อความหนึ่งจะถูกแบ่งเป็นกี่ token ส่วนเอกสาร Gemini ระบุว่า input และ output ของ Gemini API จะถูก tokenize รวมถึงข้อความและรูปภาพ

เพราะฉะนั้น การกะต้นทุนจากจำนวนคำ จำนวนตัวอักษร หรืออัตราส่วนคร่าว ๆ ใช้ได้แค่สำหรับประมาณงบเบื้องต้นเท่านั้น ถ้าต้องการตัวเลขที่ใช้ตัดสินใจจริง ควรนับ token ด้วยเครื่องมือของโมเดลเป้าหมายโดยตรง กรณี Claude Opus 4.7 กับ Opus 4.6 ที่ count_tokens ให้ตัวเลขต่างกัน สะท้อนชัดว่าเมื่อ tokenizer เปลี่ยน เนื้อหาเดิมก็อาจถูกนับไม่เท่าเดิม

ตัวเลข 35% ควรอ่านอย่างไร

จะประเมินต้นทุนอย่างไร

ถ้าดูเฉพาะ input tokens และสมมติว่าราคา input token ต่อหน่วยไม่เปลี่ยน สามารถคิดแบบง่าย ๆ ได้ว่า

ต้นทุน input ที่เพิ่มขึ้นโดยประมาณ ≈ (input tokens จาก tokenizer ใหม่ − input tokens จาก tokenizer เดิม) × ราคา input-token ต่อหน่วย

แต่สูตรนี้ประเมินเฉพาะฝั่ง input เท่านั้น บิลจริงอาจมี output tokens, cache writes, cache hits หรือรายการราคาอื่น ๆ ตามผลิตภัณฑ์ที่ใช้ เอกสาร Anthropic แยกหมวดเหล่านี้ไว้ชัดเจน และ OpenAI กับ Gemini ก็มี pricing page ของตนเองให้เทียบ

เช็กลิสต์ก่อนย้ายไปใช้โมเดลใหม่

1. ดึง payload จริงทั้งชุด ไม่ใช่แค่ user message

สิ่งที่ส่งเข้าโมเดลจริงอาจมี system prompt, context ยาว ๆ, ข้อมูลจาก tools, ไฟล์, รูปภาพ หรือ input อื่น ๆ รวมอยู่ด้วย เอกสาร Gemini ระบุว่า input และ output ทั้งหมดถูก tokenize และคู่มือ token counting ของ OpenAI ก็มีตัวอย่างการนับ input ที่มีทั้งข้อความและรูปภาพ

2. ใช้ token counter ทางการของโมเดลเป้าหมาย

OpenAI มีเอกสาร responses.input_tokens.count และคู่มือ tiktoken, Gemini มี count_tokens, ส่วน Anthropic ระบุว่า /v1/messages/count_tokens จะให้จำนวน token ของ Claude Opus 4.7 ต่างจาก Opus 4.6

3. สุ่มตัวอย่างตามประเภทงานจริง

อย่าทดสอบแค่พรอมป์ต์สั้น ๆ เพียงรายการเดียว เพราะ Anthropic ระบุว่าการเพิ่มขึ้นของ token ใน Opus 4.7 แตกต่างตามเนื้อหา ควรเลือก payload ที่มีทราฟฟิกสูง, context ยาว, ต้นทุนสูง หรือเป็นกรณีใช้งานที่พบบ่อยที่สุดมาวัดเทียบ

4. นำ token delta ไปคำนวณกับ pricing ทางการ

เริ่มจากเปรียบเทียบ input token count ของโมเดลเดิมกับโมเดลใหม่ จากนั้นค่อยใช้ราคาอย่างเป็นทางการของโมเดลนั้น ๆ คำนวณส่วนต่าง แล้วจึงเติม output, cache และช่องทางต้นทุนอื่นกลับเข้าไปในแบบจำลองต้นทุนรวม เอกสาร pricing ของ Anthropic, OpenAI และ Gemini เป็นแหล่งอ้างอิงหลักสำหรับขั้นตอนนี้

5. ใช้ผลลัพธ์ตัดสินใจว่าจะต้องปรับ prompt หรือไม่

ถ้า token delta เล็กมาก อาจแค่อัปเดตงบประมาณและ monitoring ก็พอ แต่ถ้า payload ที่มีปริมาณใช้งานสูงแพงขึ้นชัดเจน ควรพิจารณาย่อ prompt, ลด context ที่ไม่จำเป็น, ปรับกลยุทธ์ cache หรือคำนวณต้นทุนต่อ request ใหม่ ประเด็นสำคัญไม่ใช่เห็นตัวเลข 35% แล้วตื่นตระหนก แต่คือการวัดผลด้วย counter ทางการและ pricing ทางการ

บรรทัดสุดท้าย

Tokenizer ใหม่สามารถทำให้พรอมป์ต์เดิมใช้ token มากขึ้นได้จริง ในกรณี Claude Opus 4.7 เอกสารทางการระบุว่าเมื่อประมวลผลข้อความ อาจใช้ token ราว 1x–1.35x เทียบกับโมเดลก่อนหน้า หรือสูงสุดประมาณ 35% แต่การเพิ่มขึ้นขึ้นกับเนื้อหา

ดังนั้นคำถามที่ควรถามไม่ใช่แค่ว่า “35% จริงไหม” แต่คือ payload จริงของคุณถูกนับเป็น input tokens เพิ่มขึ้นเท่าไร, output behavior เปลี่ยนหรือไม่, cache ถูกคิดราคาอย่างไร และ pricing ของผู้ให้บริการนำไปใช้กับกรณีของคุณแบบไหน วิธีที่น่าเชื่อถือที่สุดคือรัน token counter ทางการก่อนอัปเกรด แล้วนำผลไปคำนวณกับ pricing ทางการ