LLMコスト最適化とは、生成AIシステムの精度・品質を維持しながら、トークン消費・モデル選定・キャッシュ活用の三軸でAPI費用と推論コストを継続的に削減する取り組みである。

本番運用に踏み切った途端、月額コストが想定の数倍に膨らむケースが報告されている。PoC段階では見えなかったトークン（Token）の無駄遣い、過剰なモデルスペックの選択、キャッシュ未活用による重複リクエストが積み重なるためだ。

本記事はLLMを本番運用するエンジニア・アーキテクト・LLM FinOps担当者を対象に、トークン削減・モデル選定・プロンプトキャッシュ・RAG設計の4つの柱を体系的に解説する。精度を落とさずにコストを半減させる実装パターンを、ステップ別に習得できる。

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

มีรายงานว่าหลังจากเริ่มใช้งาน LLM (Large Language Model) ในระดับโปรดักชันได้ไม่นาน ค่าใช้จ่ายรายเดือนมักพุ่งสูงขึ้นกว่าที่คาดการณ์ไว้หลายเท่า หากดำเนินการต่อไปโดยไม่เข้าใจโครงสร้างดังกล่าว ค่าใช้จ่ายที่มองไม่เห็นในขั้นตอน PoC (Proof of Concept) จะยังคงสะสมเพิ่มขึ้นเรื่อยๆ

ปัจจัยหลักที่ทำให้ค่าใช้จ่ายบานปลายสามารถแบ่งออกได้เป็น 3 ระดับ ดังนี้:

① การใช้โทเค็น (Token) อย่างฟุ่มเฟือย

• มีการสะสมคำอธิบายที่ซ้ำซ้อนหรือตัวอย่างที่ไม่จำเป็นไว้ใน System Prompt ทำให้สิ้นเปลืองโทเค็นหลายร้อยถึงหลายพันโทเค็นในทุกคำขอ (Request)
• นำผลลัพธ์การค้นหาจาก RAG (Retrieval-Augmented Generation) ใส่ลงใน Context Window ทั้งหมดโดยไม่คัดกรอง ส่งผลให้มีการส่งเอกสารที่ไม่เกี่ยวข้องไปด้วย
• ในการอนุมานแบบหลายขั้นตอน (Multi-step reasoning) หรือการจัดการ Agent (Agent orchestration) ข้อมูลชุดเดิมจะถูกส่งซ้ำไปมาหลายรอบ

② การเลือกโมเดลที่ไม่มีประสิทธิภาพ

• มีการใช้ Dense Model (โมเดลแบบหนาแน่น) ประสิทธิภาพสูงกับงานทั่วไป เช่น การจำแนกประเภทหรือการสรุปความ ทั้งที่งานเหล่านั้นเป็นงานเบา
• Reasoning Model (โมเดลสำหรับการใช้เหตุผล) จะสร้าง Output Token จำนวนมากผ่าน CoT (Chain of Thought) ทำให้การนำไปใช้กับงานง่ายๆ ไม่คุ้มค่ากับต้นทุน

③ การไม่ใช้ประโยชน์จากแคช (Cache)

• แม้จะมีการส่ง Prompt เดิมหรือคล้ายเดิมซ้ำๆ แต่เนื่องจากไม่ได้ตั้งค่า Prompt Cache ไว้ จึงทำให้เกิดการเรียกเก็บเงินเต็มจำนวนทุกครั้ง

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

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

3 แกนหลักในการจัดโครงสร้าง Trade-off

• ข้อกำหนดด้านความแม่นยำ (Accuracy Requirements): ยอมรับคำตอบที่ผิดได้หรือไม่ และหากยอมรับได้ ต้องไม่เกินกี่เปอร์เซ็นต์
• ข้อกำหนดด้านความหน่วง (Latency Requirements): ขีดจำกัดสูงสุดของเวลาในการตอบสนองที่ไม่ส่งผลกระทบต่อประสบการณ์ของผู้ใช้
• งบประมาณต้นทุน (Cost Budget): ค่าใช้จ่ายสูงสุดที่ตั้งไว้เป็นรายเดือนหรือต่อหนึ่งคำขอ (Request)

หากดำเนินการเพิ่มประสิทธิภาพโดยไม่มีการตกลงใน 3 แกนนี้ก่อน เกณฑ์การประเมินจะขาดความสม่ำเสมอในแต่ละมาตรการ

ตัวอย่างขีดจำกัดที่ยอมรับได้ตามประเภทงาน

Trade-off ที่ยอมรับได้มักจะแตกต่างกันอย่างมากตามลักษณะของงาน

• งานความเสี่ยงต่ำ (Low-risk tasks) เช่น การค้นหา FAQ ภายในองค์กร หรือการจำแนกประเภทงานประจำ: การให้ความสำคัญกับการลดต้นทุนเป็นอันดับแรกถือเป็นเรื่องสมเหตุสมผล แม้จะต้องยอมเสียความแม่นยำไปบ้างเล็กน้อย
• งานความเสี่ยงสูง (High-risk tasks) เช่น การตรวจสอบสัญญา หรือการให้ข้อมูลทางการแพทย์: ต้องให้ความสำคัญกับการรักษาความแม่นยำเป็นอันดับสูงสุด และมีขอบเขตในการลดต้นทุนที่จำกัด
• งานระดับกลาง (Intermediate tasks) เช่น การสรุปความ หรือการแปลภาษา: สามารถปรับเปลี่ยนแบบเป็นขั้นตอนโดยอิงจากตัวชี้วัดการประเมิน (เช่น BLEU score หรือการประเมินโดยมนุษย์)

แนวคิดเรื่อง "regression budget"

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

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

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

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

ก้าวแรกของการปรับปรุงประสิทธิภาพด้านต้นทุน (Cost Optimization) คือการทำความเข้าใจให้ชัดเจนว่า "เรากำลังใช้จ่ายไปกับอะไรและเท่าไหร่" เนื่องจากค่าใช้จ่ายของ LLM (Large Language Model) จะเกิดขึ้นตามจำนวน Token ดังนั้นการติดตามเพียงแค่จำนวน Request จึงไม่สามารถสะท้อนความเป็นจริงได้

ตัวชี้วัดขั้นต่ำที่ควรวัดผล

• จำนวน Input Token: ผลรวมของ Prompt ทั้งหมด (System Prompt + User Message + Context)
• จำนวน Output Token: ความยาวของข้อความที่โมเดลสร้างขึ้น
• จำนวน Cache Hit: จำนวนครั้งที่มีการใช้ Prompt Cache และปริมาณ Token ที่ประหยัดได้
• Model Identifier: ในกรณีที่ใช้หลายโมเดลภายในแอปพลิเคชันเดียวกัน ต้องรวบรวมข้อมูลแยกตามโมเดล

ใน Response ของแต่ละ API จะมี Object ที่ชื่อว่า usage อยู่ เพียงแค่บันทึกค่า prompt_tokens และ completion_tokens ในทุก Request ก็จะได้ข้อมูลพื้นฐานที่จำเป็น การติดตั้ง Middleware ขนาดเล็กเพื่อเขียนค่าเหล่านี้ลงใน Data Store ตั้งแต่เนิ่นๆ จะช่วยให้การปรับแต่ง (Tuning) ในขั้นตอนถัดไปง่ายขึ้นมาก

ทำความเข้าใจคุณสมบัติของ BPE Tokenizer

BPE Tokenizer (Byte-Pair Encoding Tokenizer) มีแนวโน้มที่จะแปลงตัวอักษรมัลติไบต์ (เช่น ภาษาญี่ปุ่น ภาษาจีน) ให้เป็นจำนวน Token ที่มากกว่าภาษาอังกฤษ เนื่องจากต้นทุนจะแตกต่างกันไปตามภาษาแม้จะมีปริมาณข้อมูลเท่ากัน ดังนั้น สำหรับผลิตภัณฑ์ที่รองรับหลายภาษา การรวบรวมข้อมูลแยกตามภาษาจึงเป็นสิ่งที่ขาดไม่ได้

ลำดับความสำคัญในการดำเนินการ

1. บันทึก usage จาก API Response ทุกรายการลงใน Log (ห้ามละทิ้ง)
2. กำหนด Tag สำหรับ Endpoint, User ID และชื่อฟังก์ชัน
3. คำนวณต้นทุนโดยอัตโนมัติเป็นรายวันและรายสัปดาห์ ด้วยสูตร: ราคาต่อ Token × ปริมาณการใช้งาน

เมื่อมีโครงสร้างพื้นฐานในการวัดผลที่พร้อมแล้วเท่านั้น เราจึงจะสามารถตัดสินใจเชิงปริมาณได้ว่า Endpoint ใดที่ "ไม่คุ้มค่ากับต้นทุน" โดย Observability Stack ที่จะแนะนำในส่วนถัดไปจะทำงานโดยวางอยู่บนโครงสร้างพื้นฐานนี้

เมื่อวางรากฐานการวัดต้นทุนเรียบร้อยแล้ว ขั้นตอนถัดไปคือการนำ Observability Stack มาใช้เพื่อแสดงภาพรายละเอียดในระดับคำขอ (Request) โดยมีเกณฑ์ในการเลือกเครื่องมือดังนี้:

• Langfuse: เน้น Open Source และสามารถโฮสต์เองได้ บันทึกจำนวนโทเค็น ความหน่วง (Latency) และต้นทุนในระดับ Trace ซึ่งเหมาะสำหรับการเปรียบเทียบต้นทุนระหว่างทีม
• LangSmith: มีความเข้ากันได้สูงกับระบบนิเวศของ LangChain และสามารถแสดงภาพขั้นตอนการทำงานระดับกลางของ Agent ได้
• Helicone: เป็นรูปแบบ Proxy ทำให้แก้ไขโค้ดที่มีอยู่เดิมน้อยที่สุด แดชบอร์ดใช้งานง่าย เหมาะสำหรับทีมขนาดเล็ก
• OTel GenAI semconv: เป็นมาตรฐานความหมาย (Semantic Conventions) สำหรับ Generative AI ของ OpenTelemetry ช่วยกำหนดมาตรฐาน Attribute ของ Span (เช่น gen_ai.usage.input_tokens) ให้เป็นกลางต่อผู้ให้บริการ ทำให้ง่ายต่อการรวมเข้ากับระบบ Observability ที่มีอยู่ (เช่น Grafana / Datadog)

สิ่งที่มักถูกมองข้ามหลังจากเลือกเครื่องมือแล้วคือ การออกแบบ FinOps Tag หากไม่มีการติด Tag จะไม่สามารถแยกแยะได้ในภายหลังว่าต้นทุนนั้นมาจาก "ทีมไหน, กรณีการใช้งาน (Use Case) ใด, หรือโมเดลใด" ขอแนะนำให้กำหนด Tag อย่างน้อย 4 แกน ดังนี้:

การติด Tag ควรทำโดยการฝังเป็น Metadata ในขณะส่งคำขอ และทำการกรองข้อมูลที่ฝั่งเครื่องมือ Observability การเพิ่ม Tag ในภายหลังจะทำให้ความต่อเนื่องของ Log ขาดหายไป ดังนั้นจึงสำคัญมากที่จะต้องออกแบบตั้งแต่ช่วงเริ่มต้นของโปรเจกต์ เมื่อมีทั้งการแสดงภาพข้อมูล (Visualization) และการติด Tag ที่ครบถ้วนแล้วเท่านั้น จึงจะสามารถวัดผลมาตรการลดจำนวนโทเค็นในขั้นตอนถัดไปได้อย่างแม่นยำ

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

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

System Prompt จะถูกคิดค่าใช้จ่ายเป็น Token ในทุกครั้งที่มีการส่งคำขอไปยัง LLM (Large Language Model) หากปล่อยให้ System Prompt มีความยาวมากเกินไป อาจส่งผลกระทบต่อค่าใช้จ่ายรายเดือนอย่างหลีกเลี่ยงไม่ได้

ขั้นแรก เพื่อให้เข้าใจสถานการณ์ปัจจุบัน ให้ทำการวัดจำนวน Token ของ System Prompt โดยปกติแล้วการใช้ BPE Tokenizer (Byte-Pair Encoding Tokenizer) กับภาษาญี่ปุ่น มักจะใช้ประมาณ 1-2 Token ต่อ 1 ตัวอักษร มีรายงานว่า Prompt ความยาว 500 ตัวอักษรอาจใช้ Token จริงเกินกว่า 700 Token ดังนั้นจึงไม่ควรทำการปรับแต่งโดยปราศจากการวัดผล

4 ขั้นตอนในการจัดโครงสร้าง

• การลบส่วนที่ซ้ำซ้อน: รวมคำสั่งที่มีความหมายซ้ำซ้อนกัน เช่น "โปรดตอบอย่างสุภาพ" และ "โปรดใส่ใจผู้ใช้งาน" ให้เหลือเพียงบรรทัดเดียว
• การเปลี่ยนรูปปฏิเสธเป็นรูปบอกเล่า: การเขียนประโยคใหม่จาก "โปรดอย่า..." เป็นรูปบอกเล่า มักจะช่วยลดจำนวน Token ได้
• การใช้ Markdown Bullet Points: การใช้รายการแบบ Bullet Points มักจะมีประสิทธิภาพด้าน Token สูงกว่าการเขียนเป็นย่อหน้ายาวๆ
• การทำให้การกำหนดบทบาท (Role Definition) เรียบง่ายขึ้น: การกำหนดบทบาทที่ยาวเหยียด เช่น "คุณคือผู้เชี่ยวชาญด้าน... ซึ่งมีภูมิหลังคือ..." ให้ตัดทอนเหลือเพียงใจความสำคัญเท่านั้น

แนวทางของ Before / After

มีรายงานว่า System Prompt ที่เคยเกิน 500 Token ก่อนการปรับปรุง สามารถลดลงมาเหลือเพียง 200-300 Token ได้ด้วยการจัดระเบียบข้างต้น การลดสัดส่วนของ System Prompt ใน Context Window ทั้งหมด ยังมีผลพลอยได้คือช่วยเพิ่มพื้นที่สำหรับ User Turn ได้มากขึ้น

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

ยิ่ง Context Window ยาวขึ้น จำนวน Input Token มักจะเพิ่มขึ้นแบบเกินเชิงเส้น (Super-linear) ส่งผลให้ต้นทุนพุ่งสูงขึ้น ในกรณีการใช้งานที่หลีกเลี่ยงการป้อนข้อมูลยาวๆ ไม่ได้ เช่น การสรุปเอกสาร, การถาม-ตอบจากข้อความยาว (Long-form QA) และการสนทนาแบบหลายรอบ (Multi-turn conversation) การบีบอัดบริบท (Context Compression) จึงเป็นกลยุทธ์ที่มีประสิทธิภาพ

ไลบรารี OSS ที่เป็นตัวแทนหลัก ได้แก่ LLMLingua และ LongLLMLingua โดยมีแนวทางในการเลือกใช้ดังนี้:

• LLMLingua: มุ่งเน้นไปที่ Prompt ขนาดกลางระดับหลายพัน Token โดยจะลบ Token ที่มีคะแนนความสำคัญต่ำออก มีรายงานว่าให้ผลลัพธ์การบีบอัดในระดับหนึ่ง เหมาะสำหรับงานสรุปความหรือการจำแนกประเภทที่มีความยาวระดับสั้นถึงกลาง
• LongLLMLingua: มุ่งเน้นไปที่ข้อความยาวระดับหลายหมื่น Token โดยจะเลือกเก็บเฉพาะ Chunk ที่สำคัญโดยยึดตามความเกี่ยวข้องกับคำถามเป็นหลัก มีประสิทธิภาพเป็นพิเศษในกรณีที่ผลลัพธ์การค้นหาจาก RAG (Retrieval-Augmented Generation) มีจำนวนมาก

อย่างไรก็ตาม การนำไปใช้จำเป็นต้องมีเกณฑ์การตัดสินใจ โดยควรพิจารณานำมาใช้ในกรณีที่ตรงตามเงื่อนไขต่อไปนี้:

1. ส่วนสำคัญของ Input Token ประกอบด้วยวลีที่เป็นแบบแผนหรือคำอธิบายพื้นหลังที่เยิ่นเย้อ
2. มีการกำหนดขอบเขตการลดลงของความแม่นยำในการตอบกลับที่ยอมรับได้ไว้ล่วงหน้า (เชื่อมโยงกับ regression budget ที่จะกล่าวถึงต่อไป)
3. Latency ของกระบวนการบีบอัดอยู่ในเกณฑ์ที่ยอมรับได้

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

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

นอกจากการลดจำนวนโทเค็นแล้ว อีกหนึ่งวิธีที่ช่วยลดต้นทุนได้โดยตรงคือ การเลือกใช้โมเดลให้เหมาะสมกับงาน (Model Selection) หากใช้ LLM (Large Language Model) ที่มีประสิทธิภาพสูงสุดกับทุกคำขอ ต้นทุนจะพุ่งสูงขึ้นอย่างไม่มีที่สิ้นสุด ในทางกลับกัน หากมีการแบ่งระดับโมเดลตามความยากง่ายของงาน ก็จะสามารถลดต้นทุนลงได้อย่างมากโดยที่ยังคงความแม่นยำไว้ได้

ในส่วนนี้จะอธิบายถึงการเลือกโมเดลผ่าน 2 แนวทางหลัก ได้แก่ กลยุทธ์การกำหนดเส้นทาง (Routing Strategy) และการใช้ Local LLM

• การกำหนดเส้นทางไปยังโมเดลขนาดเล็ก (Routing to Lightweight Models): การจัดสรรโมเดลโดยอัตโนมัติตามความซับซ้อนของงาน
• การตัดสินใจด้าน TCO สำหรับโครงสร้างแบบไฮบริด (TCO Assessment for Hybrid Configurations): การประเมินจุดคุ้มทุนระหว่างการใช้งานบนคลาวด์และแบบ On-premise

การส่งคำขอทั้งหมดไปยังโมเดลประสิทธิภาพสูงอย่างต่อเนื่องจะทำให้ค่าใช้จ่ายพุ่งสูงขึ้นอย่างไร้ขีดจำกัด "กลยุทธ์การกำหนดเส้นทาง" (Routing Strategy) ที่คัดแยกโมเดลตามความซับซ้อนของงาน จึงเป็นหัวใจสำคัญของการเพิ่มประสิทธิภาพต้นทุน LLM

แนวคิดพื้นฐานของการกำหนดเส้นทาง (Routing)

• การจำแนกประเภทหรือสรุปความง่ายๆ → ประมวลผลด้วย SLM หรือโมเดลขนาดเล็ก
• การใช้เหตุผลที่ซับซ้อนหรืองานหลายขั้นตอน → ยกระดับไปยังโมเดลประสิทธิภาพสูง
• ตัวกำหนดเส้นทาง (Router) จะเลือกโมเดลแบบไดนามิกในระดับคำขอ (Request)

เกณฑ์การเลือกเครื่องมือหลัก

RouteLLM เป็นเฟรมเวิร์กแบบ OSS ที่คำนวณคะแนนความยากแบบเรียลไทม์ และจะส่งต่อคำขอไปยังโมเดลระดับสูงก็ต่อเมื่อเกินเกณฑ์ที่กำหนดเท่านั้น จุดแข็งคือสามารถปรับสมดุลระหว่างอัตราการลดต้นทุนกับความเสื่อมถอยของคุณภาพได้ด้วยตัวเลข แต่ต้องคำนึงถึงต้นทุนในการตั้งค่าเริ่มต้นเนื่องจากจำเป็นต้องปรับเทียบ (Calibration) ให้เข้ากับรูปแบบการรับส่งข้อมูลของบริษัท

Martian เป็นเราเตอร์ที่ให้บริการในรูปแบบ Cloud API ซึ่งจะจำแนกคุณลักษณะของงานโดยอัตโนมัติเพื่อเลือกโมเดล แม้จะมีขั้นตอนการติดตั้งน้อย แต่จำเป็นต้องพิจารณาเรื่อง Vendor Lock-in และค่าใช้จ่าย API เพิ่มเติม

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

ข้อควรระวังในการใช้งาน

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

การใช้ Local LLM (การโฮสต์ Open-weight model ด้วยตนเอง) แม้จะช่วยหลีกเลี่ยงค่าใช้จ่ายผ่าน API ได้ แต่ก็มีต้นทุนแฝงที่เพิ่มขึ้นจากการจัดหา GPU, การดูแลโครงสร้างพื้นฐาน และการอัปเดตโมเดล หากไม่คำนวณ TCO (Total Cost of Ownership) ให้แม่นยำก่อนเริ่มใช้งาน ก็มีโอกาสสูงที่ค่าใช้จ่ายจะสูงกว่าการใช้ Cloud API

รายการต้นทุนหลักที่ควรพิจารณาในการเปรียบเทียบ TCO

• ฝั่ง Cloud API: ราคาต่อหน่วยของ Input/Output Token × จำนวนคำขอต่อเดือน, ค่าใช้จ่ายในการลองใหม่ (Retry) เมื่อเกิดปัญหา Latency SLA
• ฝั่ง Local LLM: ค่าใช้จ่ายด้าน GPU/Instance (On-premise หรือ Cloud GPU), ค่าแรงในการสร้างและดูแลรักษาโครงสร้างพื้นฐานสำหรับ Serving โมเดล, ค่าใช้จ่ายในการทำ Quantization และการปรับจูนด้วย LoRA
• ส่วนที่เหมือนกัน: การตรวจสอบความปลอดภัย, โครงสร้างพื้นฐานสำหรับการตรวจสอบและบันทึกข้อมูล (Monitoring & Logging), ค่าแรงของวิศวกรที่รับผิดชอบ

สถานการณ์ที่การใช้โครงสร้างแบบ Hybrid มีประสิทธิภาพ

โครงสร้างแบบ Hybrid ที่ผสมผสานระหว่าง Local LLM และ Cloud API มักจะให้ความคุ้มค่าสูงเมื่อเข้าเงื่อนไขต่อไปนี้:

• มีคำขอที่เกี่ยวข้องกับเอกสารภายในหรือข้อมูลส่วนบุคคลจำนวนมาก ซึ่งไม่สามารถส่งข้อมูลออกไปยังคลาวด์ได้
• มีรูปแบบ Prompt ที่ซ้ำกันบ่อยครั้งและมี Throughput ที่สูงและเสถียร (สามารถรักษาอัตราการใช้งาน GPU ให้คุ้มค่าได้)
• งานที่มีน้ำหนักเบาสามารถประมวลผลแบบ Local ด้วย SLM (Small Language Model) และส่งเฉพาะงานที่ต้องใช้การอนุมาน (Inference) ที่ซับซ้อนไปยัง Cloud API

เกณฑ์ในการตัดสินใจ

หากจำนวน Token ต่อเดือนเกินเกณฑ์ที่กำหนดและมีแนวโน้มที่จะสามารถใช้งาน GPU ได้อย่างเต็มประสิทธิภาพตลอดเวลา การใช้โครงสร้างแบบ Local จะให้ความคุ้มค่าด้านต้นทุนได้ง่ายกว่า ในทางกลับกัน หากคำขอมีลักษณะเป็นครั้งคราว (Sporadic) ค่าใช้จ่ายของ GPU ในช่วงที่ไม่ได้ใช้งาน (Idle) จะกลายเป็นภาระหนัก แนวทางที่เหมาะสมคือการทดสอบวัดค่าใช้จ่ายจริงของ Cloud API ในระดับ PoC ก่อน แล้วจึงนำค่านั้นมาเปรียบเทียบกับ TCO ของโครงสร้างแบบ Local เพื่อประกอบการตัดสินใจย้ายระบบ

เมื่อวางรากฐานด้วยการลดโทเค็นและการเลือกโมเดลแล้ว สิ่งที่ควรทำต่อไปคือการลดต้นทุนด้วยการใช้แคช (Cache) การรันการอนุมาน (Inference) เต็มรูปแบบทุกครั้งสำหรับอินพุตเดิมนั้นนำไปสู่การสิ้นเปลืองทรัพยากรคำนวณโดยตรง

แนวทางในการทำ Prompt Cache และการนำผลลัพธ์กลับมาใช้ใหม่มีอยู่ 2 รูปแบบหลัก ได้แก่ ฟีเจอร์แคชแบบเนทีฟ (Native Cache) ที่ผู้ให้บริการจัดเตรียมไว้ให้ และ Semantic Cache ที่ติดตั้งในระดับแอปพลิเคชัน เนื่องจากทั้งสองรูปแบบมีกลไกและสถานการณ์การใช้งานที่แตกต่างกัน การเข้าใจเกณฑ์ในการเลือกใช้จึงเป็นเรื่องสำคัญ

ในหัวข้อ H3 ถัดไป เราจะอธิบายรายละเอียดเกี่ยวกับความแตกต่างของข้อกำหนดด้านแคชของ Anthropic, OpenAI และ Google รวมถึงวิธีรับมือกับความเสี่ยงจากการเกิด False Hit (การดึงแคชผิดพลาด)

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

เปรียบเทียบข้อกำหนดของ 3 ผู้ให้บริการหลัก

※ ข้อมูลข้างต้นเป็นค่าอ้างอิง ณ เวลาที่เขียน โปรดตรวจสอบหน้าเว็บไซต์ราคาล่าสุดอีกครั้ง

ขั้นตอนการตัดสินใจเลือกใช้งาน

1. System Prompt มีขนาดน้อยกว่า 1,024 โทเค็นหรือไม่? → หากใช่ จะไม่ได้รับผลประโยชน์จากการทำแคช ควรให้ความสำคัญกับการลดจำนวนโทเค็นก่อน
2. ความถี่ในการเรียกใช้งานเพียงพอหรือไม่? → ไม่เหมาะกับงานประมวลผลแบบแบตช์ที่มีความถี่ต่ำซึ่งไม่สามารถนำกลับมาใช้ใหม่ได้ภายในระยะเวลา TTL
3. ส่วนต้นของ Prompt เป็นค่าคงที่หรือไม่? → แคชมีเงื่อนไขว่าต้องตรงกับส่วนนำ (Prefix) เท่านั้น จำเป็นต้องออกแบบโดยวางตัวแปรแบบไดนามิกไว้ที่ส่วนท้าย
4. หากใช้ Google Gemini → จำเป็นต้องเรียกใช้ API cachedContent อย่างชัดเจน และต้องระวังเรื่องค่าใช้จ่ายด้านพื้นที่จัดเก็บที่จะเพิ่มเข้ามา

ประเด็นสำคัญในการเลือกใช้งาน

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

นอกจากนี้ ควรคำนึงด้วยว่าแนวคิดการออกแบบนั้นแตกต่างจาก Semantic Cache ซึ่งจะกล่าวถึงในส่วนถัดไป

Semantic Cache คือกลไกที่แปลง Prompt ที่ป้อนเข้ามาให้เป็น Embedding จากนั้นจึงค้นหา Query ที่คล้ายคลึงกันใน Vector Database เพื่อนำคำตอบเดิมกลับมาใช้ใหม่ เนื่องจากสามารถลดการเรียก API ได้โดยตรง จึงคาดหวังว่าจะช่วยลดต้นทุนได้มากกว่า Prompt Cache

ขั้นตอนการใช้งานพื้นฐาน

1. แปลง Input ของผู้ใช้ให้เป็นเวกเตอร์ด้วย Embedding Model
2. คำนวณ Cosine Similarity ใน Vector Database (เช่น Pinecone, Qdrant, Redis VSS เป็นต้น)
3. หากค่าความคล้ายคลึงเกินเกณฑ์ที่กำหนด (เช่น 0.92 ขึ้นไป) ให้ส่งคืนคำตอบที่แคชไว้
4. หากต่ำกว่าเกณฑ์ ให้เรียกใช้งาน LLM และเพิ่มผลลัพธ์ลงในแคช

การตั้งค่าเกณฑ์ (Threshold) จะส่งผลต่อคุณภาพการใช้งาน หากตั้งไว้ต่ำเกินไปจะทำให้เกิด False Positive เพิ่มขึ้น ซึ่งเสี่ยงต่อการส่งคำตอบที่ผิดพลาดให้กับคำถามที่มีความหมายต่างกัน แต่หากตั้งไว้สูงเกินไป อัตราการ Hit ของแคชจะลดลง ทำให้ประสิทธิภาพในการลดต้นทุนน้อยลง

รูปแบบที่มักเกิด False Positive

• Query ที่มีโครงสร้างคล้ายกันแต่คำตอบต่างกัน เช่น "อากาศที่โตเกียวเป็นอย่างไร" กับ "อากาศที่โอซาก้าเป็นอย่างไร"
• กรณีที่ตัวเลขหรือชื่อเฉพาะต่างกันแต่บริบทคล้ายกัน (เช่น "ยอดขายปี 2023" เทียบกับ "ยอดขายปี 2024")
• คำถามที่จำเป็นต้องปรับให้เหมาะสมกับผู้ใช้แต่ละราย (Personalization)

แนวทางการลดความเสี่ยง

• Metadata Filtering: เพิ่ม User ID, Tenant ID หรือวันที่เข้าไปในเงื่อนไขการกรองเพื่อจำกัดขอบเขต
• การตั้งค่า TTL สำหรับ Entry: กำหนดวันหมดอายุให้สั้นลงสำหรับข้อมูลที่ความสดใหม่เป็นสิ่งสำคัญ เพื่อป้องกันการนำคำตอบที่ล้าสมัยกลับมาใช้
• การเก็บ Log ของชั้นแคช: ส่งคู่ Input/Output เมื่อเกิด Hit ไปยังระบบ AI Observability เพื่อตรวจสอบคุณภาพอย่างสม่ำเสมอ

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

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

ยิ่งดำเนินมาตรการเพิ่มประสิทธิภาพด้านต้นทุนมากเท่าไร ความเสี่ยงที่ความแม่นยำจะลดลงก็จะค่อยๆ สะสมเพิ่มขึ้นอย่างเงียบๆ ไม่ใช่เรื่องแปลกที่จะพบกรณีที่หลังจากดีใจว่า "ลดต้นทุนได้แล้ว" ในเดือนถัดมากลับมีข้อร้องเรียนจากผู้ใช้เพิ่มขึ้นอย่างรวดเร็ว การจัดการความเสี่ยงดังกล่าวเชิงปริมาณทำได้โดยการออกแบบชุดข้อมูลประเมินผล (Evaluation Dataset) และ regression budget (กรอบการยอมรับความเสื่อมถอย)

หลักการจัดทำชุดข้อมูลประเมินผล

• Golden Set: คู่ข้อมูลอินพุตและเอาต์พุตที่เป็นตัวแทนซึ่งสกัดมาจากบันทึกการใช้งานจริง (Production Log) โดยควรรวบรวมไว้อย่างน้อย 100–300 รายการ
• Edge Case Set: รวมกรณีที่เคยมีรายงานว่าตอบผิดและเงื่อนไขขอบเขต (Boundary Conditions) เข้าไปโดยเจตนา
• การแบ่งตามประเภทงาน: แยกตัวชี้วัดการประเมินตามประเภทของงาน เช่น การสรุปความ การจำแนกประเภท และการสร้างเนื้อหา (ตัวอย่าง: ใช้ F1 สำหรับการจำแนกประเภท และ BERTScore สำหรับการสรุปความ)

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

วิธีการออกแบบ regression budget

regression budget คือกรอบที่กำหนดไว้ล่วงหน้าว่า "จะยอมรับการลดลงของความแม่นยำได้มากน้อยเพียงใดจากการดำเนินมาตรการเพิ่มประสิทธิภาพนี้"

• ตัวอย่าง: ควบคุมอัตราความถูกต้องของงานหลักไม่ให้ลดลงเกิน ±2%, อัตราการเกิดอาการประสาทหลอน (Hallucination) ต้องไม่แย่ลงกว่าเดิม เป็นต้น
• ควรบริหารจัดการโดยใช้แนวคิดการใช้ budget ในแต่ละมาตรการ และควรมีกลไกที่สั่งการย้อนกลับ (Rollback) โดยอัตโนมัติหากมีการใช้เกินกรอบที่กำหนด

การรวมเข้ากับ CI/CD

ควรนำการประเมินผลไปรวมไว้ในไปป์ไลน์การปรับใช้ (Deployment Pipeline) และดำเนินการโดยอัตโนมัติทุกครั้งที่มีการดำเนินมาตรการ หากเชื่อมต่อกับเครื่องมือ AI Observability (เช่น Langfuse) จะสามารถเชื่อมโยงบันทึกการทำงานจริง (Production Trace) เข้ากับคะแนนการประเมินเพื่อเฝ้าระวังอย่างต่อเนื่องได้ การที่สามารถตรวจสอบผลลัพธ์ของการลดต้นทุนและการเปลี่ยนแปลงของความแม่นยำได้บนแดชบอร์ดเดียวกัน คือรูปแบบในอุดมคติของ LLM FinOps

ในการเพิ่มประสิทธิภาพด้านต้นทุนของ LLM มีรายงานว่ามักเกิดข้อผิดพลาดเดิมๆ ซ้ำอยู่บ่อยครั้ง ต่อไปนี้คือการสรุป Anti-pattern ที่พบบ่อย

Q1. "พอเปลี่ยนไปใช้โมเดลที่ถูกลง ความแม่นยำก็ลดลง"

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

Q2. "เปิดใช้งาน Prompt Caching แล้ว แต่ต้นทุนไม่ลดลง"

สาเหตุที่พบบ่อยมี 3 ประการดังนี้:

• Prefix ที่ต้องการทำแคชมีการเปลี่ยนแปลงในทุกการสนทนา
• มีการแทรก Timestamp หรือตัวแปรแบบไดนามิกไว้ที่ท้าย System Prompt
• Prompt สั้นเกินกว่าจำนวนโทเค็นขั้นต่ำ (Anthropic กำหนดไว้ที่ 1,024 โทเค็น)

หลักการพื้นฐานคือการรวบรวมองค์ประกอบที่เป็นไดนามิกไว้ที่ท้าย Prompt และคงส่วนที่เป็น Static ไว้ที่ส่วนต้นให้คงที่

Q3. "ได้คำตอบที่ผิดพลาดจาก Semantic Cache"

หากตั้งค่าความคล้ายคลึง (Similarity Threshold) ต่ำเกินไป จะทำให้เกิดการจับคู่ผิด (False Hit) โดยการนำคำตอบเก่ามาใช้กับคำถามที่มีความหมายต่างกัน แนะนำให้เริ่มตั้งค่า Threshold ไว้ที่ประมาณ 0.95 แล้วปรับจูนตามลักษณะคำศัพท์เฉพาะทางของโดเมนนั้นๆ

Q4. "พอใส่มาตรการลดต้นทุนเข้าไป ตัวเลขกลับไม่ตรงกับรายงานประจำเดือน"

มักเกิดจากการออกแบบ FinOps Tag ที่ไม่เพียงพอ ทำให้ต้นทุนของแต่ละโมเดลและแต่ละฟังก์ชันปะปนกัน หากไม่กำหนดโครงสร้าง Tag ตั้งแต่เริ่มโปรเจกต์ การแยกข้อมูลในภายหลังมักจะทำได้ยาก

บทเรียนร่วม: การเพิ่มประสิทธิภาพโดยไม่มีการวัดผลมักนำไปสู่ผลลัพธ์ที่แย่ลง การเปลี่ยนแปลงควรทำทีละอย่าง และต้องสร้างนิสัยในการตรวจสอบผลลัพธ์ด้วย A/B Testing เสมอ

การเพิ่มประสิทธิภาพต้นทุน LLM ไม่ใช่มาตรการที่ทำครั้งเดียวจบ แต่สิ่งสำคัญคือวงจรการปรับปรุงอย่างต่อเนื่องโดยผสมผสาน 4 เสาหลัก ได้แก่ การลดจำนวนโทเค็น (Token), การเลือกโมเดล, การทำ Prompt Caching และการออกแบบ RAG

เมื่อสรุปแนวทางที่อธิบายในบทความนี้ จะเห็นลำดับความสำคัญดังต่อไปนี้:

• เริ่มจากการมองเห็นภาพรวม (Visualization): การเพิ่มประสิทธิภาพไม่สามารถเริ่มต้นได้หากไม่มีฐานการวัดต้นทุน การทำความเข้าใจพื้นฐานของการใช้โทเค็นด้วยเครื่องมือ AI Observability คือจุดเริ่มต้น
• ตามด้วยการลดจำนวนโทเค็น: การจัดโครงสร้าง System Prompt และการบีบอัดบริบท (Context Compression) เป็นวิธีที่เห็นผลทันทีโดยไม่ต้องใช้โครงสร้างพื้นฐานเพิ่มเติม
• การออกแบบลำดับชั้นของโมเดล (Model Tiering): ไม่ควรกระจุกคำขอทั้งหมดไว้ที่โมเดลประสิทธิภาพสูง แต่ควรจัดเส้นทาง (Routing) ไปยัง SLM หรือ Local LLM ตามความซับซ้อนของงาน
• การขจัดความซ้ำซ้อนด้วยแคช: การใช้ Prompt Caching ร่วมกับ Semantic Caching จะช่วยลดต้นทุนการประมวลผลซ้ำๆ ได้อย่างมหาศาล

ความแม่นยำและต้นทุนไม่ใช่สิ่งที่ต้องแลกเปลี่ยนกันเสมอไป แต่สามารถทำให้ควบคู่กันไปได้ขึ้นอยู่กับการออกแบบ การจัดเตรียมชุดข้อมูลประเมินผล (Evaluation Dataset) และงบประมาณสำหรับการตรวจสอบการถดถอย (Regression Budget) เป็นสิ่งจำเป็นในการสร้างระบบเพื่อติดตามเชิงปริมาณว่าการลดต้นทุนไม่ได้ทำให้คุณภาพลดลง

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