วิธีประเมินจำนวน Token ก่อนเริ่มใช้งาน AI — ขั้นตอนการคำนวณต้นทุนล่วงหน้า

ปริมาณ token ที่ AI Agent หรือ Chatbot ใช้งาน สามารถคำนวณได้ก่อนเริ่มทำ PoC หากทราบปริมาณข้อความในสถานการณ์การใช้งานจริงและราคาต่อหน่วยของโมเดล บทความนี้จัดทำขึ้นสำหรับผู้ดูแลระบบหรือผู้รับผิดชอบด้านการวางแผนที่ได้รับมอบหมายให้คำนวณต้นทุนการนำ AI มาใช้งานล่วงหน้า โดยจะแสดงขั้นตอนตั้งแต่การตรวจสอบเงื่อนไขเบื้องต้น ไปจนถึง Step 1 (การคาดการณ์ปริมาณข้อความขาเข้าและขาออก), Step 2 (การแปลงเป็นจำนวน Token), Step 3 (การคำนวณปริมาณการใช้งานต่อ 1 คำขอ) และ Step 4 (การคำนวณต้นทุนรายเดือน) เมื่ออ่านจบ คุณจะสามารถคำนวณต้นทุนรายเดือนจากสถานการณ์การใช้งานที่คาดการณ์ไว้ของบริษัทด้วยตนเอง และนำไปใช้ประกอบการตัดสินใจด้านงบประมาณสำหรับ PoC ได้

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

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

• ชื่อโมเดลที่จะใช้ (รวมถึงเวอร์ชัน เนื่องจากอาจมีการประกาศยกเลิกหรือเปลี่ยนผ่านไปยังโมเดลรุ่นถัดไป จึงควรระบุโมเดลที่ใช้ ณ เวลาที่เลือกให้ชัดเจน)
• ราคาต่อหน่วยของอินพุตโทเค็นและเอาต์พุตโทเค็น (แพลตฟอร์มส่วนใหญ่มักแสดงราคาเป็น "ต่อ 1M (หนึ่งล้าน) โทเค็น")
• การมีอยู่ของส่วนลดราคาเมื่อมีการนำบริบทเดิมกลับมาใช้ใหม่ เช่น Prompt Caching
• การมีอยู่ของส่วนต่างราคาตามภูมิภาคหรือรูปแบบสัญญา

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

การออกแบบหน่วยของปริมาณการประมวลผลเริ่มต้นจากการนับข้อความทั้งหมดที่รวมอยู่ใน 1 คำขอ ในการโต้ตอบรูปแบบแชท ข้อความทั้งหมดที่ถูกส่งจะถูกคิดค่าบริการเป็นโทเค็น ไม่ว่าจะเป็น system prompt, ข้อความของผู้ใช้, ประวัติการสนทนาที่ผ่านมา, RAG ที่แทรกเข้ามาในรูปแบบของส่วนเนื้อหา (document chunks) ที่ค้นหาได้ ไปจนถึงคำนิยามของการเรียกใช้เครื่องมือ (tool calls) คุณจำเป็นต้องระบุองค์ประกอบเหล่านี้สำหรับแต่ละสถานการณ์การใช้งานและกำหนด "ข้อความทั้งหมดที่ส่งใน 1 คำขอ" ให้ชัดเจน

โดยเฉพาะอย่างยิ่ง ให้จัดระเบียบสถานการณ์การใช้งานโดยแบ่งออกเป็นหน่วยดังนี้:

• แชทบอทแบบถาม-ตอบทั่วไป: system prompt + ข้อความของผู้ใช้ + ผลลัพธ์ที่ได้เท่านั้น
• รูปแบบที่ใช้การค้นหาร่วมกับ RAG: เพิ่มเติมจากข้างต้นคือส่วนเนื้อหาที่ค้นหา (จำนวน Top-K และขนาดของส่วนเนื้อหา)
• รูปแบบที่มีการยกตัวอย่างแบบ few-shot: เพิ่มเติมจากข้างต้นคือปริมาณโทเค็นของข้อความตัวอย่าง
• รูปแบบเอเจนต์ที่รองรับหลายเทิร์น (multi-turn): เพิ่มเติมจากข้างต้นคือผลรวมของประวัติการสนทนาที่ผ่านมา

หากกำหนดหน่วยผิดพลาดในขั้นตอนนี้ การคำนวณต่อ 1 คำขอในขั้นตอนที่ 3 หรือการคำนวณค่าใช้จ่ายรายเดือนในขั้นตอนที่ 4 จะคลาดเคลื่อนทั้งหมด หากใช้ RAG ควรตัดสินใจขนาดของส่วนเนื้อหาและจำนวน Top-K ไว้ล่วงหน้า และหากใช้ few-shot ควรระบุจำนวนของข้อความตัวอย่างให้แน่ชัด เพื่อให้การคำนวณจำนวนโทเค็นในขั้นตอนถัดไปเป็นไปอย่างราบรื่น หากมีหลายสถานการณ์การใช้งาน จำเป็นต้องแบ่งหน่วยตามสถานการณ์และประเมินแยกกันเป็นรายกรณี

1 การใช้โทเค็นต่อหนึ่งคำขอจะถูกกำหนดโดยปริมาณตัวอักษรทั้งในส่วนที่ส่งไปและส่วนที่ได้รับกลับมา คุณจำเป็นต้องระบุตัวเลขสำหรับแต่ละสถานการณ์การใช้งาน โดยแบ่งเป็นฝั่งอินพุต (จำนวนตัวอักษรของ System Prompt และข้อความของผู้ใช้) และฝั่งเอาต์พุต (ความยาวของคำตอบที่คาดหวัง)

การประมาณจำนวนตัวอักษรของ System Prompt ให้เริ่มจากการแยกนับระหว่างข้อความคงที่และข้อความที่เปลี่ยนแปลงได้ เนื่องจาก System Prompt จะถูกแนบไปกับทุกคำขอด้วยเนื้อหาเดิมตลอดการสนทนา จึงจำเป็นต้องนับจำนวนตัวอักษรเพียงครั้งเดียว แต่สำหรับข้อความของผู้ใช้ (User Input) ความยาวจะเปลี่ยนไปตามเนื้อหาของคำถาม ดังนั้นจึงต้องคำนวณจำนวนตัวอักษรที่คาดการณ์ไว้ทั้งในกรณีที่เป็นข้อความสั้นและข้อความยาว

โดยเฉพาะอย่างยิ่ง ให้แยกคำนวณตัวเลขของ 3 ส่วนต่อไปนี้ออกจากกัน:

• จำนวนตัวอักษรคงที่ของ System Prompt (รวมถึงเนื้อหาทั้งหมด เช่น การกำหนดบทบาท, คำสั่งรูปแบบการแสดงผล, และข้อห้ามต่างๆ)
• จำนวนตัวอักษรของคำนิยามเครื่องมือ (Tool Definition) ในกรณีที่ใช้การเรียกใช้เครื่องมือ (รวมถึงชื่อฟังก์ชันและคำอธิบายอาร์กิวเมนต์)
• จำนวนตัวอักษรที่คาดการณ์ไว้ของข้อความผู้ใช้ (แบ่งตามข้อความสอบถามที่คาดว่าจะสั้นที่สุด ยาวที่สุด และโดยเฉลี่ย)

ในสถานการณ์ที่ใช้ RAG ในขั้นตอนนี้ยังไม่ต้องนับจำนวนตัวอักษรของตัว Chunk เอง แต่ให้บันทึกไว้เพียงว่ามีช่องสำหรับแทรกผลลัพธ์การค้นหาอยู่เท่านั้น เนื่องจากขนาดของ Chunk และจำนวนรายการเป็นสิ่งที่ต้องนำไปบวกเพิ่มใน Step 3 หากนับซ้ำในขั้นตอนนี้จะทำให้การคำนวณในขั้นตอนถัดไปซ้ำซ้อนกัน หากมีการใช้ตัวอย่างแบบ few-shot ให้ถือว่าข้อความตัวอย่างเป็นข้อความคงที่และนับรวมไปด้วยเช่นกัน

ในการนับจำนวนตัวอักษร ความแม่นยำจะเพิ่มขึ้นหากเตรียมรูปแบบข้อความสอบถามจริงไว้หลายรูปแบบ แล้วนับจำนวนตัวอักษรแยกตาม 3 รูปแบบ คือ สั้นที่สุด ยาวที่สุด และโดยเฉลี่ย สำหรับ System Prompt นั้น หากมีแผนที่จะเปลี่ยนแปลงคำสั่งรูปแบบการแสดงผลหรือข้อห้ามต่างๆ จะต้องนับจำนวนตัวอักษรใหม่ด้วยข้อความหลังการแก้ไข ในขั้นตอนนี้ยังไม่ต้องแปลงเป็นจำนวน Token แต่ให้รวบรวมผลรวมของจำนวนตัวอักษรให้เสร็จสิ้นก่อน ซึ่งจะช่วยให้การทำงานในขั้นตอนการแปลงที่ Step 2 เป็นระเบียบมากขึ้น

การประมาณการจำนวนโทเค็นของคำตอบ (Response tokens) จำเป็นต้องแยกจัดการต่างหากจากการนับจำนวนตัวอักษรของฝั่งอินพุต เนื่องจากความยาวของคำตอบจะแปรผันอย่างมากตามโมเดลและคำสั่งใน Prompt จึงไม่ควรนับเป็นจำนวนตัวอักษรที่คงที่ แต่ควรแบ่งช่วงที่คาดการณ์ไว้ตามประเภทของคำถาม

โดยเฉพาะอย่างยิ่ง ให้แบ่งและบันทึกความยาวของคำตอบออกเป็น 3 รูปแบบ ดังนี้:

• การตั้งค่าที่ให้คำตอบสั้นๆ แบบถาม-ตอบ (เช่น การตอบคำถาม FAQ หรือการตอบกลับตามรูปแบบมาตรฐาน)
• คำตอบระดับกลางที่มีคำอธิบายหรือสรุปความ (เช่น การอธิบายขั้นตอนหรือการตอบกลับที่มีการระบุรายการหลายหัวข้อ)
• คำตอบที่เกี่ยวข้องกับการสร้างเนื้อหาขนาดยาว (เช่น การช่วยร่างเอกสารหรือการสร้างรายงาน)

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

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

จำนวนตัวอักษรและจำนวนโทเค็นไม่ได้มีความสัมพันธ์แบบ 1 ต่อ 1 โดยอัตราส่วนการแปลงจะเปลี่ยนไปตามภาษาและประเภทของตัวอักษร หากนำเกณฑ์มาตรฐานของภาษาอังกฤษที่ว่า 1 โทเค็น ≒ 4 ตัวอักษร มาใช้กับภาษาญี่ปุ่นโดยตรงจะทำให้เกิดความคลาดเคลื่อนสูง จึงจำเป็นต้องมีการวัดผลจริงโดยใช้ BPE tokenizer

ภาษาญี่ปุ่นและภาษาอังกฤษมีจำนวนโทเค็นที่แตกต่างกันแม้จะมีจำนวนตัวอักษรเท่ากันก็ตาม ภาษาอังกฤษใช้ตัวอักษรละตินเป็นหลัก โดยมักจะถือว่าคำหรือส่วนหนึ่งของคำเป็นโทเค็นโดยตรง ทำให้จำนวนตัวอักษรต่อ 1 โทเค็นค่อนข้างสูง ในขณะที่ภาษาที่ไม่ใช่ภาษาละติน เช่น ภาษาญี่ปุ่น ภาษาจีน และภาษาเกาหลี มีแนวโน้มที่จำนวนตัวอักษรต่อ 1 โทเค็นจะน้อยกว่า ทำให้มีโครงสร้างที่จำนวนโทเค็นเพิ่มขึ้นได้ง่ายแม้จะมีจำนวนตัวอักษรเท่ากัน

เหตุผลที่ทำให้เกิดความแตกต่างนี้ขึ้นอยู่กับว่าคลังข้อมูล (Corpus) ของภาษาใดเป็นศูนย์กลางในการสร้างคำศัพท์ของ Tokenizer โดย BPE Tokenizer จะลงทะเบียนชุดตัวอักษรที่ปรากฏบ่อยครั้งไว้เป็นคำศัพท์ ยิ่งข้อมูลที่ใช้เรียนรู้มีความถี่ของภาษาอังกฤษสูงเท่าใด คำหรือส่วนประกอบของคำในภาษาอังกฤษก็จะถูกรวมเป็น 1 โทเค็นได้ง่ายขึ้นเท่านั้น เนื่องจากฮิรางานะ คาตาคานะ และคันจิในภาษาญี่ปุ่นมีรูปแบบการผสมตัวอักษรที่หลากหลาย แม้จะมีขนาดคำศัพท์เท่ากัน แต่ก็มักจะถูกแบ่งในระดับใกล้เคียงกับ 1 ตัวอักษร ส่งผลให้มีการใช้โทเค็นมากขึ้น

ความแตกต่างนี้ยังเปลี่ยนแปลงไปตามการเข้ารหัส (Encoding) ที่ใช้ (เช่น cl100k_base หรือ o200k_base เป็นต้น) ดังนั้นจึงควรหลีกเลี่ยงการคำนวณโดยใช้สัดส่วนการแปลงที่ตายตัว หากคาดการณ์ว่าจะมีการสอบถามเป็นภาษาญี่ปุ่นเป็นหลัก ไม่ควรนำเกณฑ์มาตรฐานของภาษาอังกฤษที่ว่า 1 โทเค็น ≒ 4 ตัวอักษรมาใช้โดยตรง แต่จำเป็นต้องตรวจสอบจำนวนโทเค็นหลังจากแปลงแล้วจากข้อความที่สอบถามจริง

สำหรับการวัดจำนวนโทเค็นจริง ให้ใช้วิธีเรียกใช้งาน BPE tokenizer โดยตรงแทนการคาดคะเนจากอัตราส่วนการแปลง หากเป็นโมเดลของ OpenAI ให้ใช้ไลบรารี tiktoken และหากเป็นโมเดลในกลุ่ม Hugging Face ให้ใช้ไลบรารี tokenizers ซึ่งจะทำให้ได้จำนวนโทเค็นที่แม่นยำตามการเข้ารหัส (encoding) ของโมเดลนั้นๆ

ขั้นตอนการวัดจริงมีดังนี้:

1. ตรวจสอบชื่อ encoding ที่ตรงกับโมเดลเป้าหมาย (เช่น o200k_base หรือ cl100k_base)
2. เตรียมข้อมูลจำนวนตัวอักษรที่รวบรวมไว้ใน Step 1 (ข้อความคงที่ของ System Prompt, รูปแบบข้อความผู้ใช้ทั้งสั้นที่สุด ยาวที่สุด และค่าเฉลี่ย, ตัวอย่างการตอบกลับ)
3. ส่งข้อความไปยัง tokenizer และบันทึกจำนวนโทเค็นที่ได้รับกลับมาในแต่ละรูปแบบ

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

ควรเก็บตารางเปรียบเทียบนี้แยกตามรูปแบบของข้อความคำถาม และเมื่อมีการเปลี่ยนแปลงเนื้อหาใน System Prompt ให้ใช้วิธีการเดียวกันนี้ในการวัดค่าใหม่ เพื่อป้องกันไม่ให้สมมติฐานในการประเมินคลาดเคลื่อน

1 ปริมาณการใช้โทเค็นของคำขอ (Request) คือผลรวมของ system prompt, ข้อความของผู้ใช้, RAG chunk, ตัวอย่าง few-shot และโทเค็นที่สร้างขึ้นทั้งหมด เนื่องจากวิธีการสะสมโทเค็นของการถาม-ตอบแบบครั้งเดียวและการสนทนาแบบหลายรอบ (Multi-turn) ที่มีการเก็บประวัติมีความแตกต่างกัน จึงจำเป็นต้องคำนวณแยกกัน

ในคำขอที่รวม RAG เข้าไปด้วย นอกจาก system prompt และข้อความของผู้ใช้แล้ว จะมีการเพิ่ม chunk ที่ได้จากการค้นหาเข้าไปใน input token โดยตรง ปริมาณที่เพิ่มขึ้นจะถูกกำหนดโดย "ขนาดของ chunk × จำนวน Top-K" ดังนั้นหากเพิ่มขนาดของ chunk จำนวน token ต่อรายการก็จะเพิ่มขึ้น และหากเพิ่มค่า Top-K จำนวน token ก็จะเพิ่มขึ้นตามสัดส่วน ตัวแปรทั้งสองนี้เป็นจุดแลกเปลี่ยน (trade-off) ระหว่างความแม่นยำและต้นทุน หากจำกัดค่า Top-K มากเกินไปอาจทำให้พลาดเอกสารที่เกี่ยวข้อง แต่หากเพิ่มมากเกินไป input token จะบวมขึ้นและส่งผลกระทบต่อค่าใช้จ่ายรายเดือน

ตัวอย่างการคำนวณ: หากขนาดของ chunk คือ 300 token และ Top-K คือ 5 รายการ ปริมาณที่เพิ่มขึ้นจาก RAG จะเท่ากับ 300 × 5 = 1,500 token เมื่อนำค่านี้ไปรวมกับจำนวน token ของ system prompt และข้อความของผู้ใช้ จะได้เป็นจำนวน input token รวมทั้งหมดเมื่อกำหนดค่าคอนฟิกแบบ RAG

ในกรณีที่ใช้ few-shot ร่วมด้วย จะมีการบวกจำนวน token ของประโยคตัวอย่างเพิ่มเข้าไปในส่วนที่เพิ่มขึ้นนี้อีก หาก chunk มีขนาดใกล้เคียงกับขีดจำกัดของ context window จำเป็นต้องออกแบบโดยการจำกัดปริมาณการแทรกข้อมูลผ่านการสรุปหรือการกรองด้วยความเกี่ยวข้อง (relevance filter) การเพิ่มประสิทธิภาพของการออกแบบ chunk ได้รับการกล่าวถึงใน Adaptive RAG คืออะไร? วิธีสร้างสมดุลระหว่างต้นทุนและความแม่นยำด้วยการค้นหาแบบไดนามิกที่ขับเคลื่อนด้วยคิวรี

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

ตัวอย่างการคำนวณ: หากกำหนดให้ system prompt มี 200 Token, คำพูดของผู้ใช้ 50 Token ต่อเทิร์น และคำตอบ 150 Token ต่อเทิร์น ในคำขอเทิร์นที่ 3 จำนวน Token ขาเข้าจะสะสมเป็น "system 200 + (50+150) × ประวัติ 2 เทิร์น + คำพูดของผู้ใช้ในเทิร์นที่ 3 อีก 50" ยิ่งจำนวนเทิร์นเพิ่มขึ้น ประวัติส่วนนี้ก็จะเพิ่มขึ้นเป็นเส้นตรง และเมื่อใกล้ถึงขีดจำกัดของ Context Window จำเป็นต้องตัดสินใจว่าจะใช้วิธีสรุปประวัติเก่าหรือใช้วิธี Sliding Window ที่เก็บเฉพาะ N รายการล่าสุดแทน

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

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

ค่าใช้จ่ายรายเดือนคำนวณจาก 「ปริมาณการใช้โทเค็นต่อ 1 คำขอ × จำนวนคำขอต่อเดือน × ราคาต่อหน่วย」 เนื่องจากโทเค็นขาเข้า (Input Token) และโทเค็นขาออก (Output Token) มีราคาต่อหน่วยที่แตกต่างกัน จุดสำคัญของการคำนวณคือต้องแยกคำนวณทีละส่วนก่อนแล้วจึงนำมารวมกัน

ตัวอย่างการคำนวณ: สมมติว่าโทเค็นขาเข้าอยู่ที่ 1,800 โทเค็นต่อครั้ง (system prompt + ข้อความผู้ใช้ + ส่วนที่เพิ่มจาก RAG chunk) โทเค็นขาออกอยู่ที่ 300 โทเค็นต่อครั้ง และจำนวนคำขอต่อเดือนอยู่ที่ 50,000 ครั้ง ในกรณีนี้ ต้นทุนขาเข้าจะคำนวณจากสูตร 「จำนวนโทเค็นขาเข้า (1,800) × จำนวนคำขอต่อเดือน (50,000) ÷ 1,000,000 × ราคาต่อหน่วยขาเข้า」 และต้นทุนขาออกจะคำนวณจากสูตร 「จำนวนโทเค็นขาออก (300) × จำนวนคำขอต่อเดือน (50,000) ÷ 1,000,000 × ราคาต่อหน่วยขาออก」 จากนั้นนำทั้งสองส่วนมารวมกันจะได้เป็นค่าใช้จ่ายรายเดือน สำหรับราคาต่อหน่วย โปรดอ้างอิงจากหน้าอัตราค่าบริการอย่างเป็นทางการของโมเดลที่ใช้งาน

ในกรณีที่เป็นการออกแบบแบบ Multi-turn ให้คำนวณจากปริมาณโทเค็นสะสมต่อ 1 เซสชันคูณด้วยจำนวนเซสชันก่อนที่จะดำเนินการคำนวณราคาต่อหน่วย ในระบบที่มีทั้งแบบ Single-turn และ Multi-turn ผสมกัน การแยกคำนวณค่าใช้จ่ายรายเดือนตามสถานการณ์ (Scenario) แล้วนำมารวมกันในตอนท้ายจะช่วยให้ติดตามรายละเอียดได้ง่ายขึ้น

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

การคำนวณต้นทุนรายเดือนจะใช้จำนวนคำขอเฉลี่ย แต่การเข้าใช้งานจริงจะมีความผันผวนสูงตามช่วงเวลา หากจัดทำงบประมาณโดยอิงจาก RPS (จำนวนคำขอต่อวินาที) ในช่วงเวลาปกติเพียงอย่างเดียว อาจทำให้มองข้ามช่วงเวลาที่มีการเข้าใช้งานหนาแน่นในช่วงเวลาทำการหรือช่วงที่มีกิจกรรมพิเศษ ซึ่งอาจส่งผลให้ติดข้อจำกัดด้านอัตรา (Rate Limit) ของฝั่ง API หรือมีต้นทุนส่วนเกินจากการใช้งานแบบ Burst ที่เกินงบประมาณที่คาดการณ์ไว้

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

ตัวอย่างการคำนวณ: สมมติว่าช่วงเวลาปกติมี 2,000 คำขอต่อชั่วโมง และช่วงเวลาที่มีการใช้งานสูงสุด (2 ชั่วโมงต่อวัน) มี 8,000 คำขอต่อชั่วโมง จำนวนคำขอต่อวันคือ 44,000 คำขอจากช่วงเวลาปกติ 22 ชั่วโมง และ 16,000 คำขอจากช่วงเวลาที่มีการใช้งานสูงสุด 2 ชั่วโมง รวมเป็น 60,000 คำขอ การคำนวณต้นทุนรายเดือนจากยอดรวมนี้ และนำเฉพาะช่วงเวลาที่มีการใช้งานสูงสุด 2 ชั่วโมงมาคำนวณราคาต่อหน่วย จะช่วยให้ทราบว่าช่วงเวลาที่มีการใช้งานสูงสุดคิดเป็นสัดส่วนเท่าใดของต้นทุนรายเดือนทั้งหมด

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

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

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

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

ขั้นตอนเพื่อป้องกันการมองข้ามคือ ตั้งแต่ขั้นตอนการนับจำนวนตัวอักษรใน Step 1 ให้แยก System Prompt และคำจำกัดความของเครื่องมือออกมาเป็นรายการต่างหาก และกำหนดให้เป็นมาตรฐานในการนำไปรวมคำนวณใน Step 3 สำหรับการคำนวณต่อ 1 คำขอเสมอ นอกจากนี้ หากมีการเปลี่ยนแปลงเนื้อหาหรือการกำหนดค่าเครื่องมือ การกำหนดขั้นตอนให้ทำการนับจำนวนโทเค็นใหม่ทุกครั้งจะช่วยให้สมมติฐานในการประมาณการไม่คลาดเคลื่อนได้ง่ายขึ้น

ความผิดพลาดในการไม่รวม Prompt Cache ไว้ในการประเมินราคา มักเกิดขึ้นในกรณีที่มีการคำนวณส่วนที่คงที่อย่าง System Prompt ในราคาเต็มทุกครั้ง ในการตั้งค่าที่มีการส่ง Context เดิมซ้ำๆ แพลตฟอร์มต่างๆ จะมีกลไกที่ใช้ราคาต่อหน่วยที่ต่ำกว่าปกติสำหรับ Input ที่ถูกแคชไว้ ซึ่งหากละเลยส่วนลดนี้ไป จะทำให้การประเมินค่าใช้จ่ายรายเดือนสูงกว่าความเป็นจริง ส่วนที่เป็น System Prompt คงที่, คำนิยามของ Tool หรือการตั้งค่าที่อ้างอิงเอกสารเดิมซ้ำๆ ใน RAG มักเป็นส่วนที่สามารถนำไปแคชได้ง่าย

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

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

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

หากผลการเปรียบเทียบพบว่าค่าที่วัดได้จริงสูงกว่าค่าที่คาดการณ์ไว้อย่างมาก ให้ระบุสาเหตุว่าเกิดจากส่วนใด ไม่ว่าจะเป็นการขยายตัวของ System Prompt, การออกแบบ Chunk ของ RAG หรือการสะสมของประวัติการสนทนาแบบ Multi-turn จากนั้นจึงปรับเปลี่ยนตัวแปรการออกแบบที่เกี่ยวข้องแล้วคำนวณใหม่ ในการทำ PoC ที่เปรียบเทียบหลายโมเดล ให้เปรียบเทียบค่าใช้จ่ายรายเดือนโดยรวมที่รวมทั้งราคาต่อหน่วยและจำนวนโทเค็นที่วัดได้จริง เพื่อตัดสินว่าโมเดลใดมีความได้เปรียบด้านต้นทุนรวม

การรวมค่าใช้จ่ายรายเดือนที่สะท้อนถึง RPS ในช่วงเวลาที่มีการใช้งานสูงสุด (Peak) ไว้ในงบประมาณของ PoC จะช่วยป้องกันสถานการณ์ที่แผนงานต้องหยุดชะงักเนื่องจากข้อจำกัดด้านอัตราการใช้งาน (Rate Limit) หรือค่าใช้จ่ายที่เกินงบเมื่อเปลี่ยนผ่านสู่ระบบจริง ควรบันทึกเงื่อนไขเบื้องต้นที่ใช้ในการประเมิน (โมเดล, ราคาต่อหน่วย, การออกแบบหน่วย) ไว้ในรายงาน PoC เพื่อให้สามารถติดตามส่วนต่างได้เมื่อมีการวัดผลใหม่ด้วยข้อมูลจริงในอนาคต

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

มีเครื่องมือสำหรับวัดจำนวน Token ได้อย่างแม่นยำ โดย OpenAI Tokenizer แบบออนไลน์ช่วยให้คุณตรวจสอบได้อย่างรวดเร็วเพียงแค่วางข้อความลงไป และหากมีจำนวนมาก การใช้ไลบรารี tiktoken เพื่อประมวลผลแบบกลุ่มจะเป็นวิธีที่ใช้งานได้จริง นอกจากนี้ ไลบรารี tokenizers ของ Hugging Face ยังสามารถนำมาใช้ตรวจวัดจริงได้หากเป็นการเข้ารหัส (encoding) ที่รองรับกับโมเดลเป้าหมาย ทั้งหมดนี้มีจุดร่วมที่เหมือนกันคือ ไม่ใช่การคาดคะเนจากจำนวนตัวอักษร แต่เป็นการวัดผลโดยตรงด้วยการเข้ารหัสของโมเดลนั้นๆ

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

การประเมินปริมาณโทเค็นจะเริ่มต้นจากการกำหนดเงื่อนไขเบื้องต้น โดยดำเนินการตามลำดับขั้นตอนดังนี้: ขั้นตอนที่ 1 คาดการณ์ปริมาณข้อความขาเข้าและขาออก, ขั้นตอนที่ 2 แปลงจำนวนตัวอักษรเป็นจำนวนโทเค็น, ขั้นตอนที่ 3 คำนวณปริมาณการใช้งานต่อ 1 คำขอ และขั้นตอนที่ 4 คำนวณค่าใช้จ่ายรายเดือนจากจำนวนครั้งที่คาดว่าจะใช้งาน ในกระบวนการนี้ สาเหตุหลักของความคลาดเคลื่อนมักเกิดจากการนับจำนวน System Prompt หรือคำนิยามของเครื่องมือ (Tool definition) ตกหล่น รวมถึงการมองข้ามผลของการลดปริมาณข้อมูลด้วยการทำ Cache หรือการบีบอัด ดังนั้น นิสัยในการแยกบันทึกส่วนที่เป็นค่าคงที่และส่วนที่เป็นค่าแปรผันจึงเป็นปัจจัยสำคัญต่อความแม่นยำ

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