เวลาประเมินต้นทุนหลังอัปเกรดโมเดล อย่าดูแค่ราคาต่อ 1 ล้าน token แล้วสรุปทันทีว่าแพงหรือถูกกว่าเดิม เพราะจำนวน token เองก็อาจเปลี่ยนได้ Tokenizer คือกติกาที่แบ่งข้อความให้เป็น token ก่อนส่งเข้าโมเดล และ token count เป็นหน่วยสำคัญที่เอกสาร pricing ของผู้ให้บริการ LLM API หลายรายใช้คำนวณต้นทุน ^{[20][12][32][2]}

กรณีของ 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 ^[34]

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

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

อีกจุดที่ต้องระวังคือ จำนวน token ที่เพิ่มขึ้นไม่เท่ากับบิลรวมเพิ่มขึ้นเท่ากันเสมอไป เอกสาร pricing ของ Anthropic แยก

Base Input Tokens

Cache Writes

Cache Hits

Output Tokens

[12]

[32]

[2]

[12]

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

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

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

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

คำพูดที่มักได้ยิน	วิธีอ่านที่แม่นกว่า
Claude Opus 4.7 ทำให้พรอมป์ต์แพงขึ้น 35% ทุกครั้ง	สรุปเกินไป เอกสารทางการพูดถึง token ราว 1x–1.35x และขึ้นกับเนื้อหา [34]
ข้อความเดิมอาจถูกนับเป็น token มากขึ้น	ถูกต้อง Anthropic ระบุว่า tokenizer ใหม่ของ Opus 4.7 อาจใช้ token มากขึ้น และ token count จะต่างจาก Opus 4.6 [34]
tokenizer กระทบแค่ context limit ไม่เกี่ยวกับต้นทุน	ไม่ครบถ้วน เพราะ API pricing คิดตามช่องทางการใช้ token เช่น input, output และ cache การนับ token ที่เปลี่ยนจึงกระทบต้นทุนได้ [12][32][2]
ทางที่ดีที่สุดคือทดสอบด้วย counter ทางการ	ถูกต้อง OpenAI มีเอกสาร input token counting และ tiktoken, Gemini มี count_tokens, Anthropic ก็ระบุการใช้ /v1/messages/count_tokens ในบริบทของ Opus 4.7 [33][20][1][34]

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

ถ้าดูเฉพาะ 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 ของตนเองให้เทียบ ^[12][32][2]

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

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

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

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 ^{[33][20][1][34]}

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

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

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

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

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

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

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

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

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