ติดตั้ง LLM แบบ private ในองค์กรของคุณเอง
Private AI คือการติดตั้ง LLM ไว้บนเครื่องที่องค์กรควบคุมเอง คำถามและเอกสารจึงไม่ออกจากเครือข่าย หน้านี้อธิบายว่าการทำแบบนั้นต้องใช้อะไร และต้องตัดสินใจอะไรบ้างระหว่างทาง
เหตุผล
ทำไมองค์กรถึงเลือกติดตั้งเอง
ไม่ใช่ทุกองค์กรควรติดตั้งเอง แต่สำหรับองค์กรที่มีข้อมูลอ่อนไหวและมีผู้ใช้จำนวนมาก เหตุผลสี่ข้อนี้มักเป็นตัวตัดสิน
- ข้อมูลไม่ออกจากเครือข่าย
- เมื่อโมเดลรันบนเครื่องขององค์กร คำถาม เอกสารที่แนบไป และคำตอบทั้งหมดอยู่ภายในเครือข่ายเดียวกับระบบงานอื่น ไม่มีการเรียก API ภายนอกในเส้นทางปกติ จึงไม่มีคำถามว่าผู้ให้บริการรายใดเก็บ prompt ไว้นานเท่าใด
- ข้อกำหนดด้านกฎระเบียบ
- ธนาคาร โรงพยาบาล และหน่วยงานรัฐหลายแห่งมีข้อกำหนดที่ทำให้ส่งข้อมูลบางประเภทออกนอกองค์กรไม่ได้ ไม่ว่าผู้ให้บริการจะน่าเชื่อถือเพียงใด private deployment เป็นทางเดียวที่ทำให้ใช้ AI กับข้อมูลชุดนั้นได้เลย
- ต้นทุนที่คาดการณ์ได้
- ค่าใช้จ่ายของระบบที่ติดตั้งเองไม่ผูกกับปริมาณ token ที่ใช้ เมื่อการใช้งานภายในองค์กรเติบโต ต้นทุนต่อคำขอลดลงแทนที่จะเพิ่มขึ้น ข้อแลกเปลี่ยนคือการลงทุนครั้งแรกและภาระการดูแลระบบ ซึ่งเป็นสิ่งที่เรารับไปทำแทน
- ควบคุมเวอร์ชันของโมเดลได้เอง
- โมเดลที่ให้บริการผ่าน API สาธารณะเปลี่ยนพฤติกรรมได้โดยไม่แจ้งล่วงหน้า ซึ่งเป็นปัญหาเมื่อมีกระบวนการทำงานผูกอยู่กับผลลัพธ์ ระบบที่ติดตั้งเองเปลี่ยนโมเดลเมื่อองค์กรพร้อม และย้อนกลับได้หากผลลัพธ์แย่ลง
การเลือกโมเดล
โมเดลไหน และทำไม
เราไม่ผูกกับโมเดลตัวใดตัวหนึ่ง การเลือกมาจากงานจริงขององค์กรและผลการทดสอบกับเอกสารจริง
- โมเดลเปิดที่รองรับภาษาไทย
- ตระกูลโมเดลเปิดอย่าง Qwen, Llama, Gemma และ DeepSeek รวมถึงโมเดลที่ปรับสำหรับภาษาไทยโดยเฉพาะ มีคุณภาพต่างกันชัดเจนในงานภาษาไทย เราทดสอบกับเอกสารจริงขององค์กรก่อนเลือก ไม่ตัดสินจากคะแนน benchmark ภาษาอังกฤษ
- ขนาดโมเดลกับงานที่ทำ
- งานสรุปเอกสารและถามตอบทั่วไปมักใช้โมเดลขนาดกลางได้ดีพอ ส่วนงานที่ต้องอ่านเอกสารยาวและให้เหตุผลหลายขั้นต้องการโมเดลใหญ่กว่า การใช้โมเดลใหญ่กับทุกงานคือวิธีที่แพงที่สุดในการได้ผลลัพธ์เท่าเดิม
- การใช้หลายโมเดลร่วมกัน
- ระบบส่วนใหญ่ที่เราส่งมอบให้บริการโมเดลมากกว่าหนึ่งตัวบนคลัสเตอร์เดียว โมเดลเล็กรับงานปริมาณมากที่ไม่ซับซ้อน โมเดลใหญ่รับงานที่ต้องการคุณภาพสูง ชั้น model serving เป็นผู้ตัดสินใจว่าคำขอใดไปที่ใด
- Quantization
- การลดความละเอียดของน้ำหนักโมเดลลดความต้องการ VRAM ได้มาก โดยคุณภาพลดลงเพียงเล็กน้อยในงานส่วนใหญ่ ระดับที่เหมาะสมขึ้นกับงานและต้องวัดกับข้อมูลจริง เราทดสอบก่อนเลือก ไม่ตั้งค่าตามค่ามาตรฐาน
- การปรับแต่งกับข้อมูลองค์กร
- ในกรณีส่วนใหญ่ RAG ให้ผลดีกว่าและถูกกว่าการ fine-tune เพราะเอกสารเปลี่ยนได้ทุกวันโดยไม่ต้องเทรนใหม่ การ fine-tune คุ้มเมื่อองค์กรต้องการรูปแบบผลลัพธ์เฉพาะหรือคำศัพท์เฉพาะทางที่โมเดลพื้นฐานตอบได้ไม่ดี
การประเมินขนาด
ต้องใช้เครื่องแค่ไหน
คำตอบขึ้นกับโมเดล ความยาว context และจำนวนผู้ใช้พร้อมกัน เราคำนวณให้จากตัวเลขจริงขององค์กร ไม่เสนอสเปกสำเร็จรูป
- VRAM เป็นข้อจำกัดแรกเสมอ
- น้ำหนักโมเดลต้องอยู่ใน VRAM ทั้งก้อน และยังต้องเหลือที่ให้ KV cache ซึ่งโตตามความยาว context คูณด้วยจำนวนคำขอพร้อมกัน ระบบที่คำนวณเฉพาะขนาดน้ำหนักมักหมด VRAM ทันทีที่มีผู้ใช้จริงหลายคน เราคำนวณรวมทั้งสองส่วนตั้งแต่ขั้นออกแบบ
- จำนวน GPU มาจาก concurrency
- throughput ที่ต้องการมาจากจำนวนคำขอพร้อมกันในช่วงพีคและความยาวคำตอบเฉลี่ย ไม่ใช่จำนวนพนักงานทั้งหมด เราประเมินจากรูปแบบการใช้งานจริงของหน่วยงานที่จะเริ่มใช้ก่อน แล้วเผื่อการขยายไว้ในการออกแบบเครือข่ายและพื้นที่ในตู้
- Storage สำหรับเอกสารและดัชนี
- ต้องเผื่อพื้นที่สำหรับเอกสารต้นฉบับ ข้อความที่ผ่าน OCR แล้ว และ vector index ซึ่งมักโตกว่าที่คาดเมื่อเอกสารมีจำนวนหน้ามาก ความเร็วของ storage มีผลต่อเวลาตอบสนองของการค้นคืนโดยตรง
- เครือข่ายและระบบระบายความร้อน
- เซิร์ฟเวอร์ GPU กินไฟและปล่อยความร้อนมากกว่าเซิร์ฟเวอร์ทั่วไปหลายเท่า ศูนย์ข้อมูลเดิมขององค์กรอาจต้องปรับระบบไฟและระบายความร้อนก่อนติดตั้ง เราตรวจข้อจำกัดนี้ก่อนเสนอสเปก เพราะเป็นสาเหตุที่พบบ่อยของการเลื่อนติดตั้ง
ชั้นซอฟต์แวร์
ประกอบด้วยอะไรบ้าง
ส่วนประกอบทั้งสี่นี้ต้องทำงานร่วมกัน การมีเพียงโมเดลที่รันได้ยังไม่ใช่ระบบที่พนักงานใช้งานจริงได้
- Model serving
- vLLM หรือ TGI ทำ continuous batching เพื่อให้ GPU ทำงานเต็มที่เมื่อมีคำขอเข้ามาพร้อมกัน พร้อมเปิด API รูปแบบมาตรฐานที่ระบบอื่นเรียกใช้ได้โดยไม่ต้องผูกกับผู้ให้บริการรายใด
- ชั้นค้นคืนและฝังเวกเตอร์
- โมเดล embedding ที่รองรับภาษาไทย ฐานข้อมูล vector และกลไกการแบ่งเอกสารเป็นชิ้น คุณภาพของการแบ่งเอกสารมีผลต่อคำตอบมากกว่าการเปลี่ยนโมเดลภาษาในหลายกรณี
- OCR สำหรับเอกสารสแกน
- องค์กรไทยจำนวนมากมีสัญญาและแบบฟอร์มเป็นเอกสารสแกน ซึ่งต้องแปลงเป็นข้อความก่อนจึงจะค้นได้ งานนี้เป็นภาระต่อเนื่องเมื่อมีเอกสารใหม่เข้ามาทุกวัน จึงต้องอยู่ในการประเมินขนาดตั้งแต่แรก
- Mimir Suites
- ชั้นที่ประกอบทุกอย่างข้างต้นให้เป็นระบบเดียวที่พนักงานใช้ได้ พร้อมการควบคุมสิทธิ์ audit log และการเชื่อมต่อกับระบบเดิม โดยไม่ต้องให้ทีม IT ประกอบเครื่องมือหลายตัวเข้าด้วยกันเอง
ภาพรวมของชั้นทั้งหมดและลำดับการออกแบบอยู่ที่ สถาปัตยกรรมอ้างอิง Enterprise AI ส่วนการควบคุมสิทธิ์และการตรวจสอบย้อนหลังอยู่ที่ ความปลอดภัยและธรรมาภิบาล AI
บอกเราว่าองค์กรมีเอกสารแบบไหน ผู้ใช้กี่คน และข้อมูลอ่อนไหวระดับใด เราจะประเมินโมเดลและขนาดของระบบให้
ปรึกษา Enterprise AI Architect