Snowflake Dynamic Model Routing: เมื่อ Cortex AI Gateway เลือกโมเดลที่คุ้มค่าที่สุดให้แต่ละงาน

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

• ต้นทุน
• คุณภาพของคำตอบ
• ความหน่วงหรือความเร็วในการตอบกลับ
• ข้อกำหนดด้านการกำกับดูแล
• ถิ่นที่อยู่ของข้อมูล

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

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

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

ระบบเลือกโมเดลอย่างไร

Snowflake อธิบายกลไกหลักไว้ 2 รูปแบบ ได้แก่ advisor pattern และการกำหนดเส้นทางด้วย classifier

1. Advisor pattern: เริ่มจากโมเดลเล็ก แล้วค่อยยกระดับ

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

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

2. Classifier: จำแนกคำขอก่อนเลือกโมเดล

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

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

ผลลัพธ์ด้านประสิทธิภาพที่ Snowflake รายงาน

Snowflake ระบุว่า ในการทดสอบภายในกับงานสร้าง data pipeline บน dbt ระบบ Dynamic Model Routing ให้ประสิทธิภาพด้านการใช้โทเคนสูงสุด 3 เท่า เมื่อรักษาคุณภาพใกล้เคียงกับการใช้โมเดลระดับแนวหน้าเพียงอย่างเดียว

ในการทดสอบงานเขียนโค้ดอีกชุดหนึ่ง บริษัทระบุว่าทีมวิศวกรยังคงทำ pull request ได้ในปริมาณใกล้เคียงเดิม ขณะใช้โทเคนน้อยลงประมาณ 25%

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

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

เพิ่ม DeepSeek และ GLM เข้ามาในตัวเลือก

Snowflake กำลังขยายกลุ่มโมเดลที่ให้บริการผ่าน Cortex AI ด้วย DeepSeek-V4-Flash 0731 และ Z.ai GLM-5.3 โดย DeepSeek-V4-Flash 0731 ได้รับการประกาศให้อยู่ใน private preview รวมถึงการใช้งานผ่าน CoCo ส่วน GLM-5.3 จะเข้าสู่ private preview ในเร็ว ๆ นี้ ขึ้นอยู่กับความพร้อมของโมเดล

Snowflake รายงานว่า DeepSeek-V4-Flash ได้คะแนน 74.4% ในการทดสอบ ADE-bench ภายใน โดยใช้ CoCo เป็นโครงสร้างสำหรับรันเอเจนต์ นอกจากนี้ บริษัทยังอ้างถึงผลทดสอบก่อนหน้าของ GLM-5.2 ซึ่งได้คะแนน 66% และใช้โทเคนน้อยที่สุดในเบนช์มาร์กดังกล่าว

ข้อควรระวังคือ ผลลัพธ์ 66% เป็นของ GLM-5.2 ไม่ใช่ GLM-5.3 จึงไม่ควรนำไปตีความว่าเป็นผลการประเมินของ GLM-5.3

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

จุดขายเรื่องข้อมูลที่อยู่ภายใต้การกำกับดูแล

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

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

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

Snowflake ต่างจากแพลตฟอร์ม routing อื่นอย่างไร

แนวคิดการเลือกโมเดลตามงานไม่ใช่เรื่องใหม่ในตลาด ตัวอย่างเช่น Amazon Bedrock มี Intelligent Prompt Routing ซึ่งใช้เอนด์พอยต์แบบ serverless เดียวเพื่อส่งคำขอไปยังโมเดลพื้นฐานหลายตัวภายในตระกูลโมเดลเดียวกัน โดยพยายามคาดการณ์คุณภาพของคำตอบและเลือกเส้นทางที่สมดุลระหว่างคุณภาพกับต้นทุน

Databricks ใช้ Unity AI Gateway เป็นศูนย์กลางสำหรับส่งคำขอไปยังโมเดลและบริการ MCP พร้อมจัดการความจุ ความพร้อมใช้งาน และค่าใช้จ่ายข้ามผู้ให้บริการ

Google Cloud API Gateway มีความสามารถด้าน model routing ในฐานะชั้นจัดการทราฟฟิกสำหรับคำขอที่เข้ากันได้กับ OpenAI โดยสามารถกำหนดเส้นทางไปยังเอนด์พอยต์โมเดลของ Gemini Enterprise Agent Platform ได้

ฝั่ง NVIDIA นำเสนอ NeMo Switchyard เป็น SDK หรือชั้น routing ที่ไม่ผูกกับผู้ให้บริการรายใดรายหนึ่ง ขณะที่ OpenRouter เน้นการรวมโมเดลและผู้ให้บริการหลายราย พร้อม routing ระหว่างผู้ให้บริการเพื่อเพิ่มความพร้อมใช้งาน

ดังนั้น คำถามสำคัญจึงไม่ใช่แค่ว่า “แพลตฟอร์มใดเลือกโมเดลที่ถูกกว่าได้” แต่คือ นโยบายกำกับดูแล ข้อมูล ตรรกะการ routing การรันโมเดล และการมองเห็นค่าใช้จ่าย ถูกจัดการอยู่ที่ใด

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

ก่อนเชื่อว่าประหยัดต้นทุนได้ ต้องวัดอะไรบ้าง

การประเมินระบบ routing ควรเปรียบเทียบกับการใช้โมเดลระดับแนวหน้าคงที่ โดยใช้ชุดงานที่ใกล้เคียงกับการใช้งานจริง และควรติดตามอย่างน้อยรายการต่อไปนี้

• ต้นทุนรวมต่อภารกิจที่ทำสำเร็จ ไม่ใช่แค่ราคาต่อโทเคนของโมเดลที่ถูกเลือก
• ค่าใช้จ่ายของ router หรือ classifier หากมีการเรียกเก็บแยก
• การเรียกโมเดลเพิ่มจากการยกระดับงาน การ fallback การ retry หรือการใช้เครื่องมือที่ล้มเหลว
• ความหน่วงตั้งแต่ต้นจนจบ รวมเวลาสำหรับ routing การดึงข้อมูล การประกอบบริบท และการเรียกโมเดลรอบที่สอง
• อัตราความสำเร็จและคุณภาพของงานแยกตามประเภทคำขอ
• การหลอนข้อมูล การละเมิดนโยบาย และคุณภาพที่ถดถอยจากการใช้โมเดลขนาดเล็ก
• เวลาที่มนุษย์ใช้ตรวจสอบ แก้ไข ยกระดับปัญหา และทำงานซ้ำ
• ข้อจำกัดด้านถิ่นที่อยู่ของข้อมูล การสังเกตการณ์ระบบ ค่า egress และการผูกติดกับผู้ให้บริการ

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

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

สรุป

ประกาศของ Snowflake มี 2 ส่วนสำคัญ ได้แก่ การเลือกโมเดลแบบไดนามิกระหว่างโมเดลที่ได้รับอนุมัติ และการขยายตัวเลือกโมเดลภายใน Cortex AI โดยฟีเจอร์ Dynamic Model Routing คาดว่าจะเปิดให้ใช้งานแบบ private preview ในเร็ว ๆ นี้ ขณะที่ DeepSeek-V4-Flash 0731 อยู่ใน private preview แล้ว และ GLM-5.3 จะตามมาเมื่อพร้อมให้บริการ

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

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