นักพัฒนาที่ใช้งานโมเดลภาษาขนาดใหญ่ (LLM) แบบ local พบว่าเซิร์ฟเวอร์ Multi-Channel-Protocol (MCP) เพียงตัวเดียวสามารถกินพื้นที่ context window ไปจนหมดก่อนที่ผู้ใช้จะพิมพ์ prompt เสียอีก พวกเขาต้องเลือกระหว่างคำอธิบายเครื่องมือ (tool descriptions) ที่ไม่สมบูรณ์ หรือลำดับการสนทนาที่ติดขัด

ทำไมปัญหา token บวมถึงสำคัญสำหรับ local LLM

MCP ช่วยให้ LLM สามารถเรียกใช้เครื่องมือภายนอก เช่น API, สคริปต์ หรือยูทิลิตี้ระบบไฟล์ ได้โดยการป้อนคำอธิบายของแต่ละเครื่องมือให้แก่โมเดล โมเดลที่โฮสต์บนคลาวด์ซึ่งมี context window ขนาด 128k token สามารถรองรับคำนิยามของเครื่องมือจำนวนมากและยังเหลือพื้นที่สำหรับการสนทนากับผู้ใช้ แต่โมเดลขนาด 7 พันล้านพารามิเตอร์ที่รันแบบ local ด้วย context window ขนาด 8k token จะพบว่าพื้นที่เต็มหลังจากโหลดเครื่องมือเพียงไม่กี่อย่างเท่านั้น ทางเลือกที่ต้องแลกมานั้นชัดเจนมาก: คำอธิบายที่สั้นและประหยัด token อาจทำให้การเรียกใช้งานผิดพลาด ส่วนคำอธิบายที่ยาวและละเอียดก็จะกินโควตาที่จำเป็นสำหรับการแชท

ลำดับเหตุการณ์ที่นำมาสู่ปัญหานี้

MCP ถูกสร้างขึ้นเพื่อแทนที่โค้ดการเชื่อมต่อแบบกำหนดเอง (custom integration code) ด้วยอินเทอร์เฟซที่ขับเคลื่อนด้วยโมเดลเพียงหนึ่งเดียวเพื่อเข้าถึงแหล่งข้อมูลที่หลากหลาย เซิร์ฟเวอร์ MCP ส่วนใหญ่ทำหน้าที่เป็นเพียง wrapper รอบ REST endpoints ที่ออกแบบมาสำหรับมนุษย์ ไม่ใช่เครื่องจักร เมื่อ wrapper เหล่านี้ถูกนำมาใช้ในเซสชันของ local LLM โมเดลจะต้องอ่านทั้งชื่อ พารามิเตอร์ และหมายเหตุการใช้งานของทุกเครื่องมือก่อนที่จะตัดสินใจได้ว่าจะเรียกใช้เครื่องมือใด Context window ที่มีขนาดเล็กมากจึงเปลี่ยน "ภาระด้านคำอธิบาย" (description overhead) นี้ให้กลายเป็นคอขวดเชิงโครงสร้าง

ใครได้ประโยชน์ ใครเสียประโยชน์

  • นักพัฒนาที่สร้างผู้ช่วยบนอุปกรณ์ (on-device assistants) เสียความยืดหยุ่น พวกเขาต้องเลือกระหว่างการตัดรายการเครื่องมือออกซึ่งเสี่ยงต่อความล้มเหลวบ่อยครั้ง หรือยอมรับ prompt ที่บวมจนทำให้ข้อมูลนำเข้าของผู้ใช้ถูกตัดทอน
  • ผู้ใช้งานทั่วไป จะพบกับพฤติกรรมที่ไม่เสถียร เมื่อผู้ช่วยเลือกเครื่องมือผิดหรือปฏิเสธที่จะทำงานเนื่องจาก context เต็ม
  • ผู้ให้บริการเครื่องมือ ได้รับจุดเชื่อมต่อที่เป็นมาตรฐานเดียวกัน

ต้นทุนที่เกิดขึ้นไม่ใช่แค่ประสบการณ์ที่แย่ลงเท่านั้น แต่ยังเพิ่มความกังวลด้านความปลอดภัย เมื่อ agent ของ MCP สามารถอ่านไฟล์ในเครื่องได้ทุกไฟล์ โมเดลการอนุญาตสิทธิ์ (permission model) จะกลายเป็นแบบ "ได้ทั้งหมดหรือไม่ได้เลย" (all-or-nothing) หากไม่มี sandbox เครื่องมือที่ตั้งค่าผิดพลาดอาจเปิดเผยไฟล์ทั้งระบบได้

สิ่งที่นักพัฒกำลังทำเพื่อแก้ไขปัญหานี้

มีวิธีแก้ปัญหาชั่วคราวสามวิธีที่กำลังเป็นที่นิยมในชุมชน:

  • การตัดทอนคำอธิบาย (Trim descriptions) – ตัด metadata ของเครื่องมือให้เหลือเพียงขั้นต่ำที่สุด วิธีนี้ช่วยคืนพื้นที่ token แต่เพิ่มโอกาสที่โมเดลจะเลือก endpoint ผิด นำไปสู่ข้อผิดพลาดที่นักพัฒนาต้องคอยดักจับและสั่งให้ทำงานใหม่
  • การโหลดแบบไดนามิก (Dynamic loading) – โหลดเฉพาะชุดเครื่องมือที่เกี่ยวข้องกับการสนทนาในปัจจุบัน โดยมีตัวกระจายงาน (dispatcher) น้ำหนักเบาทำหน้าที่ตัดสินใจตามเจตนาของผู้ใช้ว่าจะฉีด (inject) ชุดเครื่องมือใด วิธีนี้ช่วยลดการใช้ token โดยไม่จำเป็น แต่เพิ่มความหน่วง (latency) และความซับซ้อนของโค้ด
  • การจำกัดเซิร์ฟเวอร์ที่ใช้งานอยู่ (Limit active servers) – จำกัดจำนวนเซิร์ฟเวอร์ MCP ต่อหนึ่งเซสชัน บังคับให้นักพัฒนาต้องจัดลำดับความสำคัญของการเชื่อมต่อที่จำเป็นที่สุด วิธีนี้ช่วยให้ขนาดของ prompt อยู่ในระดับที่จัดการได้ แต่ต้องแลกด้วยความสามารถที่ลดลง

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

ความเสี่ยงด้านความปลอดภัยที่มาพร้อมกับปัญหา token

Local agent มักทำงานด้วยสิทธิ์การเข้าถึงระบบไฟล์แบบไม่จำกัด โปรโตคอล MCP ไม่มีการแบ่งระดับความละเอียด (granularity) ระหว่าง "อ่านโฟลเดอร์นี้" กับ "อ่านทุกอย่าง" บางทีมจึงสร้างเลเยอร์เกตเวย์ (gateway layers) ขึ้นมาเพื่อแก้ปัญหาการเข้าถึงแบบเต็มรูปแบบ ซึ่งช่วยบรรเทาปัญหา "การควบคุมทั้งหมด" (full-control) ได้ แต่ก็ทำให้ฐานโค้ด (code base) ซับซ้อนขึ้นด้วย

การออกแบบเครื่องมือสำหรับโมเดลขนาดเล็ก

โมเดลบนคลาวด์ขนาดใหญ่สามารถกู้คืนจากคำอธิบายที่แย่ได้ นักพัฒนาจึงมักมองข้ามความจำเป็นในการกำหนดเครื่องมือที่แม่นยำ สำหรับโมเดลแบบ local ควรปฏิบัติตามหลักการดังนี้:

  • ฟังก์ชันการทำงานที่เฉพาะเจาะจง (Narrow functionality) – เครื่องมือแต่ละอย่างควรทำหน้าที่เพียงอย่างเดียว เครื่องมือ "ค้นหา" (search) ที่สามารถเขียนไฟล์ได้ด้วย จะทำให้โมเดลที่จัดการความรับผิดชอบที่ทับซ้อนกันไม่ได้เกิดความสับสน
  • การตั้งชื่อที่ชัดเจนไม่คลุมเครือ (Unambiguous naming) – หลีกเลี่ยงชื่อทั่วไปอย่าง "process" หรือ "handle" ชื่อควรสื่อถึงการทำงานที่แน่นอน เพื่อลดภาระทางความคิด (mental load) ของโมเดล
  • คำอธิบายที่ชัดเจนและกระชับ (Clear, concise descriptions) – ใส่เฉพาะพารามิเตอร์ที่โมเดลจำเป็นต้องใช้ในการตัดสินใจจริงๆ และใช้รูปแบบที่สม่ำเสมอเพื่อให้โมเดลสามารถจดจำรูปแบบได้อย่างรวดเร็ว

มุมมองแย้ง: โปรโตคอลนี้ยังมีคุณค่าอยู่

แม้จะมีอุปสรรค แต่ MCP ยังคงมีความน่าดึงดูดเพราะช่วยลดความยุ่งยากของโค้ดพื้นฐาน (boilerplate code) อินเทอร์เฟซที่ขับเคลื่อนด้วยโมเดลเพียงหนึ่งเดียวสามารถเชื่อมต่อกับบริการต่างๆ ได้มากมายโดยไม่ต้องเขียนตัวปรับแต่ง (adapters) เฉพาะสำหรับแต่ละบริการ ทีมที่สามารถใช้โมเดลระดับคลาวด์ได้จะมองว่าปัญหา token บวมไม่ใช่เรื่องใหญ่ และความสะดวกสบายนั้นก็คุ้มค่ากับภาระที่เพิ่มขึ้น ความท้าทายคือการนำความสะดวกสบายนั้นมาปรับใช้กับโลกที่มีข้อจำกัดของ on-device LLMs

บทสรุป

If you’re building an on-device assistant, treat MCP tool descriptions as a scarce resource. Trim, load dynamically, and design narrowly scoped tools to keep the context window alive for the actual conversation. At the same time, guard against the implicit “full-access” security model by inserting a permission layer, even if it costs a few extra tokens. The balance you strike will decide whether your local LLM feels like a helpful companion or a broken chatbot.