เหตุใดเครื่องมือติดตามการทำงานของ LLM จึงเริ่มสร้างเกตเวย์ AI

ในปี 2026 LangSmith, Langfuse, Opik และ Braintrust ต่างเพิ่มเกตเวย์ไว้หน้าผู้ให้บริการโมเดล เหตุผลหลักคือการควบคุม เพราะเครื่องมือติดตามการทำงานทำได้เพียงบันทึกการเรียกใช้โมเดล ส่วนเกตเวย์สามารถหยุดการเรียกใช้ได้

เครื่องมือสองชนิดที่ทำงานแยกกัน

ตลอดสองปีที่ผ่านมา หลายทีมใช้เครื่องมือสองชนิดแยกกันกับแอปพลิเคชันโมเดลภาษาขนาดใหญ่ (LLM) โดยมีเกตเวย์คั่นอยู่ระหว่างแอปพลิเคชันกับผู้ให้บริการโมเดล เกตเวย์เก็บคีย์ API ของผู้ให้บริการ แปลงคำขอระหว่าง API ของผู้ให้บริการแต่ละราย และลองส่งคำขอที่ล้มเหลวอีกครั้ง LiteLLM ซึ่งเป็นพร็อกซีแบบโอเพนซอร์ส กลายเป็นตัวเลือกที่ใช้กันทั่วไปสำหรับงานนี้ ส่วนเครื่องมือติดตามการทำงาน เช่น LangSmith หรือ Langfuse จะอยู่ข้างแอปพลิเคชัน โดยบันทึกการเรียกใช้โมเดล การเรียกใช้เครื่องมือ และขั้นตอนการดึงข้อมูลแต่ละครั้ง เพื่อให้วิศวกรเห็นได้ว่าเอเจนต์ทำอะไรไปบ้าง

การแยกหน้าที่เช่นนี้สมเหตุสมผล เพราะเกตเวย์ต้องทำงานได้รวดเร็วและรองรับ API ของผู้ให้บริการทุกราย ขณะที่เครื่องมือติดตามการทำงานต้องมีอินเทอร์เฟซที่ดี พื้นที่จัดเก็บข้อมูลขนาดใหญ่ และ SDK ที่ครอบโค้ดของแอปพลิเคชันไว้ Langfuse ยังคงอธิบายการตั้งค่าโดยใช้เครื่องมือสองชนิด โดยมีการผสานรวม LiteLLM Proxyที่ส่งทุกคำขอผ่านพร็อกซีไปยัง Langfuse ในปี 2026 ผู้ให้บริการเครื่องมือติดตามการทำงานเริ่มสร้างเกตเวย์ขึ้นเอง

การเปิดตัวสี่ครั้งในหกเดือน

LangChain ประกาศเปิดทดสอบ LangSmith LLM Gateway แบบส่วนตัวในเดือนพฤษภาคม 2026 และเปิดทดสอบแบบสาธารณะในวันที่ 30 กรกฎาคม จากนั้นยังได้ผนวกเกตเวย์นี้เข้ากับการติดตั้งใช้งาน LangSmith แบบนำคลาวด์ของตนเองมาใช้ด้วย Braintrust เลิกใช้พร็อกซี AI รุ่นก่อน และแนะนำให้ผู้ใช้เปลี่ยนไปใช้เกตเวย์รุ่นใหม่ ซึ่งอยู่ในช่วงทดลองใช้งานและไม่มีค่าใช้จ่ายจนกว่าจะเปิดให้ใช้งานทั่วไป ส่วน Comet เปิดตัวOpik LLM Gateway ในรูปแบบปลายทางรุ่นเบตาที่รองรับคำขอในรูปแบบ OpenAI เมื่อวันที่ 4 พฤศจิกายน Langfuse ก็เปิดตัว AI Gateway ในรุ่นเบตาสาธารณะ ทั้งบน Langfuse Cloud และสำหรับการติดตั้งใช้งานที่โฮสต์เอง เกตเวย์นี้ใช้สัญญาอนุญาต MIT และเขียนด้วย Rust

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

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

เหตุใดการควบคุมงบประมาณจึงต้องอยู่ในเส้นทางของคำขอ

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

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

จุดเชื่อมต่อเดียวบันทึกทุกคำขอ

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

Langfuse พัฒนาเกตเวย์โดยยึดแนวคิดนี้เป็นหลัก ตามที่ระบุไว้ในเอกสารประกอบเกตเวย์ คีย์เกตเวย์แต่ละรายการจะผูกกับผู้ใช้หรือบัญชีบริการ และอาจมีข้อมูลเมตา เช่น ทีม หรือศูนย์ต้นทุน มีเพียงเกตเวย์เท่านั้นที่เก็บข้อมูลรับรองของผู้ให้บริการไว้ และผู้ดูแลระบบเป็นผู้อนุมัติว่าแต่ละข้อมูลรับรองจะเรียกใช้โมเดลใดได้บ้าง LangSmith เผยแพร่หน้าคำแนะนำการตั้งค่าสำหรับกำหนดเส้นทาง Claude Code, Codex และ Gemini CLI ผ่านเกตเวย์ของตน เอเจนต์เหล่านี้เรียกใช้โมเดลจากเครื่องของนักพัฒนา โดยอยู่นอกโค้ดติดตามการทำงานของแอปพลิเคชัน

เกตเวย์ของเครื่องมือติดตามการทำงานเพิ่มอะไรให้บ้าง

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

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

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

สิ่งที่เกตเวย์รุ่นเบต้ายังทำไม่ได้

เกตเวย์เหล่านี้ยังอยู่ในช่วงเริ่มต้น และผู้ให้บริการก็ระบุข้อจำกัดของผลิตภัณฑ์ตนเองไว้ด้วย ขณะนี้เกตเวย์ของ Langfuse รองรับเฉพาะ OpenAI และ Anthropic ส่วน Amazon Bedrock, Google Vertex AI และ Google AI Studio อยู่ในแผนพัฒนา ฟังก์ชันสำรองไปใช้ผู้ให้บริการรายอื่นและการกำหนดเพดานค่าใช้จ่ายแบบตายตัวต่อทีม ผู้ใช้ หรือคีย์นั้นอยู่ในแผน แต่ยังไม่ได้เปิดให้ใช้งาน ตอนนี้เกตเวย์มีแดชบอร์ดค่าใช้จ่ายและการแจ้งเตือนเท่านั้น เอกสารของผลิตภัณฑ์ไม่ได้กล่าวถึงการจำกัดอัตราการเรียกใช้หรือการแคชการตอบกลับ

เกตเวย์ของ Langfuse ไม่แปลงรูปแบบ API ระหว่างกัน ดังนั้นไคลเอนต์ OpenAI จึงเรียกใช้ได้เฉพาะโมเดล OpenAI เท่านั้น เวอร์ชันที่โฮสต์ด้วยตนเอง เรียกได้เฉพาะ URL อย่างเป็นทางการของผู้ให้บริการ จึงยังไม่สามารถใช้ Azure OpenAI, Bedrock หรือพร็อกซีภายในองค์กรได้ในขณะนี้ Comet ระบุว่าเกตเวย์ Opik ออกแบบมาสำหรับการพัฒนาและการทดสอบ ส่วน Braintrust ยังไม่ได้ประกาศราคาเกตเวย์ของตน

เกตเวย์ของ LangSmith ทำได้มากกว่าผลิตภัณฑ์อื่น ๆ อยู่แล้ว เอกสารระบุว่าการสลับไปใช้ผู้ให้บริการสำรอง การจำกัดค่าใช้จ่าย การจำกัดอัตราการเรียกใช้ และนโยบายข้อมูลเป็นฟีเจอร์ที่ใช้งานได้ในปัจจุบัน อีกทั้งยังรองรับรูปแบบ OpenAI Chat Completions, OpenAI Responses และ Anthropic Messages การสลับไปใช้ผู้ให้บริการสำรองและการจำกัดอัตราการเรียกใช้เคยถูกระบุว่าเป็นงานในอนาคตเมื่อเดือนพฤษภาคม จึงมีการเพิ่มฟีเจอร์เหล่านี้ระหว่างช่วงเบต้า อย่างไรก็ตาม ผลิตภัณฑ์โดยรวมยังคงระบุสถานะว่าเป็นเบต้า

การทดสอบโหลดเผยให้เห็นข้อจำกัดอีกลักษณะหนึ่ง การทดสอบเปรียบเทียบแบบโฮสต์ด้วยตนเองระหว่างเกตเวย์ Langfuse, LiteLLM และ AcruxCore พบว่าเกตเวย์ Langfuse เพิ่มเวลาแฝงต่อการเรียกใช้น้อยกว่า LiteLLM อย่างไรก็ตาม เมื่อใช้การตั้งค่า Docker เริ่มต้น ระบบล้มเหลวกับสตรีมพร้อมกัน 739 รายการจากทั้งหมด 1,000 รายการ เนื่องจากโปรเซสยังคงใช้ขีดจำกัดจำนวนไฟล์ที่เปิดได้ 1,024 ไฟล์ตามค่าเริ่มต้นของ Docker การเพิ่มบรรทัดเดียวในไฟล์ Compose ของ Langfuse ก็แก้ปัญหานี้ได้

เมื่อเทียบกับผลิตภัณฑ์รุ่นเบต้าเหล่านี้ LiteLLM ซึ่งเป็นเกตเวย์แบบแยกเดี่ยวที่ให้บริการมาหลายปีแล้ว รองรับผู้ให้บริการมากกว่า 100 ราย และมีคีย์เสมือน การติดตามค่าใช้จ่าย มาตรการควบคุมความปลอดภัย การกระจายโหลด และแดชบอร์ดผู้ดูแลระบบมาให้แล้ว นอกจากนี้ LiteLLM กำลังย้ายเส้นทางคำขอจาก Python ไปยัง Rust Rust AI Gateway ของ LiteLLM อยู่ในช่วงเบต้า และทีม LiteLLM คาดว่า คำขอ /v1/messages ในรูปแบบของ Anthropic จะทำงานครบวงจรด้วย Rust ได้ภายในวันที่ 1 ธันวาคม โดยมีเวลาแฝงลดลงประมาณ 20 เท่า แพลตฟอร์มโอเพนซอร์สบางราย เช่น MLflow และ AcruxCore มีทั้งเกตเวย์และระบบติดตามเทรซรวมอยู่ในผลิตภัณฑ์เดียวกันแล้ว

เหตุผลที่ควรแยกทั้งสองระบบออกจากกัน

การรวมเกตเวย์เข้ากับเครื่องมือติดตามเทรซมีต้นทุน และต้นทุนสำคัญที่สุดคือการผูกระบบเข้าด้วยกัน หากใช้เกตเวย์แยกต่างหาก ทีมก็เปลี่ยนผู้ให้บริการระบบติดตามเทรซได้เพียงเปลี่ยนฟังก์ชันเรียกกลับสำหรับบันทึกข้อมูล แต่เมื่อเครื่องมือติดตามเทรซทำหน้าที่เป็นเกตเวย์ด้วย ก็ต้องเปลี่ยน URL พื้นฐาน คีย์ และตัวระบุโมเดลของทุกบริการไปพร้อมกัน ตัวอย่างเช่น Langfuse เขียนตัวระบุโมเดลในรูปแบบ credential:model

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

ผู้ให้บริการด้านความปลอดภัยต่างต้องการมีบทบาทในจุดเดียวกันของเส้นทางคำขอ Palo Alto Networks ดำเนินการซื้อกิจการ Portkey ซึ่งเป็นเกตเวย์แบบแยกเดี่ยวเสร็จสิ้นในเดือนพฤษภาคม 2026 และทำให้ Portkey เป็นเกตเวย์ AI ของแพลตฟอร์ม Prisma AIRS ทีมรักษาความปลอดภัยอาจต้องการให้เกตเวย์อยู่ภายใต้การควบคุมของตนเอง แทนที่จะฝังไว้ในเครื่องมือสังเกตการณ์ระบบ นอกจากนี้ เกตเวย์ยังกลายเป็นเป้าหมายของผู้โจมตี ดังที่แสดงให้เห็นจากเหตุละเมิดห่วงโซ่อุปทานของ LiteLLMในเดือนมีนาคม

แนวทางให้ทีมเลือกใช้

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

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

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

เกตเวย์ส่วนใหญ่เหล่านี้ระบุสถานะว่าเป็นเบต้าหรือเวอร์ชันตัวอย่าง รายการข้อจำกัดจึงน่าจะลดลงอย่างรวดเร็ว คำถามที่ยังเปิดอยู่คือ ใครจะเป็นผู้รับผิดชอบเส้นทางคำขอภายในบริษัททั่วไป—ทีมสังเกตการณ์ระบบ ทีมแพลตฟอร์มที่ดูแลเกตเวย์แบบแยกเดี่ยว หรือทีมรักษาความปลอดภัย ในปีนี้ LangSmith และ Langfuse สร้างเกตเวย์ของตนเอง ขณะที่ Palo Alto Networks ซื้อกิจการเกตเวย์รายหนึ่ง แต่ในระบบของหลายองค์กร เส้นทางคำขอยังคงผ่าน LiteLLM