- สรุปคำถามและคำตอบจากโพสต์ใน Reddit /r/ollama
- ในฐานะ ผู้ดูแลระบบ ของสำนักงานกฎหมายที่มีพนักงานราว 300 คน ต้องการมอบ เครื่องมือเขียนและตรวจแก้เอกสารด้วย AI คล้าย ChatGPT ให้กับพนักงานทุกคน
- เพื่อ ปกป้องข้อมูลอ่อนไหว เช่น PII จึงกำลังพิจารณา โฮสต์ LLM บนเซิร์ฟเวอร์ภายในองค์กรโดยตรง แทนการใช้บริการภายนอก (พร้อมการควบคุมการเข้าถึง เช่น ล็อกอิน, 2FA, VPN)
- คำถามหลัก
- เซิร์ฟเวอร์ LLM ที่สร้างและดูแลเองจะรองรับ ผู้ใช้มากกว่า 300 คน ได้จริงหรือไม่?
- เดิมคิดว่าน่าจะใช้ PC+GPU ไม่กี่เครื่อง ก็พอ แต่ในความเป็นจริงประเมินต่ำไปหรือไม่?
- การสร้าง/จัดการผู้ใช้ จะกลายเป็นภาระใหญ่หรือไม่?
- มี ประเด็นสำคัญอะไรที่อาจมองข้ามไป หรือไม่?
- ผู้ถามไม่ใช่ผู้เชี่ยวชาญด้าน LLM จึงต้องการคำแนะนำเชิงปฏิบัติเกี่ยวกับ การขยายระบบ ภาระการดูแล และความเป็นไปได้จริง
สรุปคำตอบหลัก
1. ข้อจำกัดด้านฮาร์ดแวร์ ประสิทธิภาพ และต้นทุน
- หากคาดหวังคุณภาพระดับ โมเดลเชิงพาณิชย์ (เช่น ChatGPT) จะต้องใช้ คลัสเตอร์ GPU ราคาสูงมาก ระดับหลายแสนดอลลาร์ (ประเมินไว้ที่ $200,000~$1,000,000+)
- หากลดระดับลงมาใช้ โมเดลโอเพนซอร์ส (ระดับ 30B~70B พารามิเตอร์) ก็ต้องยอมรับประสิทธิภาพที่ลดลง (ทั้งความหน่วงและคุณภาพผลลัพธ์) และอาจรองรับการใช้งานพร้อมกันได้เพียง 10~40 คน
- แนะนำให้ตั้งสมมติฐานว่ามีผู้ใช้พร้อมกันไม่เกิน 10 คน แล้วค่อย ๆ ขยายแบบเพิ่มเซิร์ฟเวอร์ทีละขั้น
- การเช่า GPU บนคลาวด์อาจ คุ้มค่าและยืดหยุ่นกว่า การติดตั้งในสภาพแวดล้อมภายในองค์กร
2. แนะนำ PoC (โครงการนำร่อง) และการค่อย ๆ ขยาย
- แนะนำให้สร้าง PoC (โครงการนำร่อง) ด้วยเซิร์ฟเวอร์ 1 เครื่อง + GPU 1 ใบ แล้ววัดภาระงานและสถานการณ์ใช้งานจริงก่อนขยายต่อ
- เมื่อมีคำขอพร้อมกันจำนวนมาก ระบบคิว เป็นสิ่งจำเป็น และจำนวนผู้ใช้พร้อมกันจริงอาจไม่ใช่ 300 คน แต่อยู่ที่ราว 10~30 คน
- ในระยะสั้นสามารถทดลองได้ด้วย โมเดลขนาดเล็ก (3B~13B พารามิเตอร์) ร่วมกับเวิร์กสเตชัน
3. คลาวด์ / ไฮบริด / ทางเลือกอื่น
- มีข้อเสนอให้ใช้ LLM บนคลาวด์ (API, VPS, Azure, AWS Bedrock เป็นต้น) เชื่อมกับโครงสร้างภายใน เพื่อออกแบบเป็นสถาปัตยกรรมแบบไฮบริดที่ตอบโจทย์ด้านความปลอดภัย
- หากโฮสต์เอง ภาระด้านความปลอดภัย ประสิทธิภาพ และต้นทุนจะสูงมาก ดังนั้นในทางปฏิบัติ ChatGPT Enterprise/Teams, Microsoft Copilot Studio และโซลูชันเชิงพาณิชย์อื่น ๆ อาจมีประสิทธิภาพกว่ามาก
- ต้องตรวจสอบข้อกำหนดด้านความปลอดภัยสำหรับข้อมูลกฎหมายและการจัดการ PII อย่างรอบคอบ
4. ประเด็นด้านปฏิบัติการ การจัดการ และเทคนิคอื่น ๆ
- การจัดการผู้ใช้/การยืนยันตัวตน: สามารถทำให้ง่ายขึ้นได้ด้วยการเชื่อมต่อ AD, OAuth หรือระบบยืนยันตัวตนของตนเอง
- การเลือก/ปรับแต่งโมเดล: ควรทดสอบโมเดลโอเพนซอร์สขนาดเล็กถึงกลางที่เหมาะกับงานจริง (เช่น การตรวจแก้เอกสาร) เช่น LLama, Deepseek, Gemma, Qwen
- ควรพิจารณาความเป็นไปได้ในการเพิ่มโซลูชันเสริม เช่น RAG, แคช, การกระจายโหลด
- จำเป็นต้องกำหนด สถานการณ์การใช้งานจริง และตรวจสอบงบประมาณ/ROI ที่เหมาะสมผ่าน PoC
สรุปคำตอบเด่น
ithkuil
- เมื่อเทียบกับโมเดลเชิงพาณิชย์ โมเดลโอเพนซอร์สยังมี ช่องว่างด้านประสิทธิภาพ มาก และหากเป็นระดับ 300 คน อาจต้องใช้ ฮาร์ดแวร์มูลค่าหลายแสนดอลลาร์
- อย่างไรก็ตาม ยังพอคาดหวังได้ว่า ฮาร์ดแวร์และโมเดลเปิดจะพัฒนาไปมากภายใน 2 ปี
SlimeQ
- แนะนำให้เริ่มจาก อินสแตนซ์เดียว+ระบบคิว สำหรับขนาดเล็ก แล้วจึงค่อย ๆ ขยายเมื่อปริมาณการใช้งานเพิ่มขึ้น
- ไม่สามารถให้ผู้ใช้ครบ 300 คนใช้งานพร้อมกันได้ และควรวัดการใช้งานจริงก่อนตัดสินใจขยาย
Ok-Internal9317
- ผู้ใช้พร้อมกันจริงอาจมีไม่ถึง 10 คน และ GPU 4~5 ใบ อาจเพียงพอ
- ในระยะยาว ค่าใช้ API อาจคุ้มกว่าการลงทุนฮาร์ดแวร์เอง
dyoh777
- สามารถทำเดโมได้ง่ายด้วย Ollama+WebUI แต่คุณภาพของโมเดลคือประเด็นสำคัญ
careful-monkey
- สามารถรันโมเดลขนาดเล็กได้ด้วย Mac Studio + RAM ขนาดใหญ่ ที่ความเร็วประมาณ 20token/sec
tshawkins
- แนะนำโซลูชันแบบ SaaS เช่น Microsoft Copilot Studio ซึ่งผสานรวมใน Power Platform
roman_fyseek, Cergorach, Space__Whiskey
- ข้อจำกัดของ VRAM ของโมเดล: 1 เซสชัน = 1 GPU ดังนั้นหากประมวลผลพร้อมกัน 300 คนจะต้องใช้ GPU 300 ใบ
- ในทางปฏิบัติจำเป็นต้องมี การจำกัดการเชื่อมต่อพร้อมกัน แคช และสถาปัตยกรรมแบบไฮบริด
Siderox, SandboChang, unrulywind
- แนะนำให้ เริ่มทดลองด้วยเซิร์ฟเวอร์ขนาดเล็กผ่าน PoC (เช่น 1~2 คน/โมเดล และตรวจสอบว่านำไปใช้กับงานจริงได้หรือไม่) แล้วจึงค่อยขยาย
- หลังจากกำหนดสถานการณ์จริงและทำ benchmarking แล้ว จึงประเมินงบประมาณและ ROI
Little_Marzipan_2087, morosis1982, Daemonero
- การเช่า GPU บนคลาวด์ มีราคาถูกกว่าและขยายระบบได้ดีกว่า เป็นแนวทางที่ถูกใช้อยู่บ่อย
- เมื่อคำนึงถึงภาระด้านปฏิบัติการและการบำรุงรักษาแล้ว แนะนำให้ใช้คลาวด์มากกว่าลงทุนฮาร์ดแวร์เอง
CtiPath, alew3, faldore, Wheynelau
- แนะนำเฟรมเวิร์กเซิร์ฟเวอร์ LLM โอเพนซอร์สประสิทธิภาพสูง เช่น vLLM, OpenWebUI, TGI, sglang
- แนะนำสถาปัตยกรรมแบบ คิว+โหลดบาลานเซอร์
อื่น ๆ
- ประเด็นด้านความปลอดภัย/กฎหมาย: แม้จะใช้คลาวด์ก็ยังต้องตรวจสอบ ตำแหน่งจัดเก็บข้อมูล การเข้ารหัส และการปฏิบัติตามข้อกำหนด อย่างละเอียด
- มีการกล่าวถึงตัวเลือกฮาร์ดแวร์หลายแบบ เช่น Mac Studio, RTX 6000 Pro, 4090
- สามารถลดภาระงานได้บางส่วนด้วย แคช, RAG, การจำกัด context, offload
สรุปข้อสรุป
- สำหรับ เซิร์ฟเวอร์ LLM แบบโฮสต์เอง แนวทางที่สมจริงที่สุดคือเริ่มจากโครงการนำร่องขนาดเล็ก (PoC) แล้วค่อยตรวจสอบ ขนาดผู้ใช้จริง ความต้องการ ประสิทธิภาพ และต้นทุน เป็นลำดับ
- การรองรับผู้ใช้พร้อมกัน 300 คนมีภาระด้าน ฮาร์ดแวร์และต้นทุนการปฏิบัติการ สูงมาก และขึ้นอยู่กับลักษณะงานและงบประมาณว่า คลาวด์, ไฮบริด หรือโซลูชันเชิงพาณิชย์ จะเหมาะสมกว่าหรือไม่
- สุดท้ายควรพิจารณาองค์ประกอบหลายด้านร่วมกัน เช่น ความปลอดภัย ต้นทุน ประสบการณ์ผู้ใช้ และการบำรุงรักษา
6 ความคิดเห็น
ดูเหมือนว่าคุณตั้งเกณฑ์ความสามารถในการให้เหตุผลที่ใช้กับงานของผู้ใช้ 300 คนไว้กว้างเกินไปหน่อยครับ ถ้าต้องการครอบคลุมตั้งแต่ความรู้สามัญทั่วไปไปจนถึงงานวิจัยหรือหัวข้อขั้นสูง การออกแบบแบบนี้ก็อาจจะถูกต้อง แต่ถ้ามองจากระดับของงานที่ต้องประมวลผลจริง ๆ รุ่นระดับประมาณ 30b ที่พ่วง RAG ก็น่าจะรองรับงานส่วนใหญ่ได้แล้ว ไม่ใช่ว่าขนาดมันใหญ่เกินไปเพราะพยายามยกระดับน้ำหนักทั้งหมดของโอเพนซอร์สโมเดลพื้นฐานและพึ่งพาความสามารถในการคิดวิเคราะห์ขั้นสูงกับฟังก์ชันต่าง ๆ มากเกินไปหรือเปล่าครับ?? แล้วก็งานที่สามารถประมวลผลได้ทันที กับการค้นหาและสำรวจเอกสาร ก็น่าจะแยกออกเป็นฟังก์ชันคนละส่วนจะเหมาะกว่าครับ
ส่วนช่วงโทเค็นของ KV cache สำหรับรองรับผู้ใช้พร้อมกัน 300 คน ถ้าคิดเป็นค่า quantized ประมาณคนละ 20000 โทเค็น ก็น่าจะใช้งานได้แบบเหลือ ๆ ตรงนี้ก็อาจตั้งไว้สูงเกินไปเหมือนกัน... ??
ถ้าผู้ใช้ทั้ง 300 คนไม่ใช่นักวิจัยระดับปริญญาเอกที่ทำงานเขียน论文กันจริง ๆ ผมว่าตั้งระดับการให้เหตุผลไว้ประมาณนักเรียนมัธยมปลาย (14~30b) แล้วจัดการให้ค้นหาเอกสารภายในองค์กรหลากหลายชุดผ่านตรรกะ RAG พร้อม CoT ที่เหมาะสม ก็น่าจะทำให้โปรเจกต์ทดลองใช้งานออกมาอยู่ในงบที่รับได้อย่างราบรื่นนะครับ
ผมเองก็เพราะความจำเป็นเลยกำลังทำโซลูชัน RAG โดยใช้ GPU H100 ที่ว่ากันว่าหายากถึง 4 ใบอยู่เหมือนกัน แต่พอคิดรวมไม่ใช่แค่เงินลงทุนฮาร์ดแวร์โดยตรง ยังมีค่าไฟกับค่าโซลูชันระบายความร้อนอื่น ๆ ด้วย ก็ยิ่งรู้สึกเรื่อย ๆ ว่าการเรียกใช้ API ไปเลยน่าจะดีกว่ามาก
ตอนแรกผมก็เริ่มทดสอบด้วย Ollama เหมือนกัน แล้วพอเห็นว่ารองรับผู้ใช้พร้อมกัน 3 คนยังแทบไม่ไหว ก็ขยับไปใช้ vLLM ทันทีแล้วก็จัดองค์ประกอบโซลูชัน RAG ไปแบบทุลักทุเล แต่แค่นี้ก็ต้องใช้ GPU H100 เกือบเต็ม 2 ใบแล้ว (สมมติว่ามีผู้ใช้พร้อมกัน 10 คน) งาน embedding กับงานค้นหาก็เปิดผ่าน vLLM ใช้เหมือนกัน ทำให้ H100 4 ใบนี่ตึงมากจริง ๆ ครับ ทั้งที่ VRAM ต่อใบก็ราว ๆ 90GB แล้วนะ
แน่นอนว่าผมเองก็ไม่ได้รู้เรื่อง AI มากนัก แค่พยายามทำสิ่งที่แผนกต้องการพร้อมกับปรับให้เข้ากับข้อกำหนดความปลอดภัยภายในบริษัทไปเรื่อย ๆ ก็เลยเหมือนลองทำแบบลุย ๆ ไปก่อน... เลยอดคิดไม่ได้ว่านี่มันถูกทางไหม ChatGPT Enterprise ใช่ไหมนะ? ผมว่าราคาคุ้มมากจริง ๆ ครับ
ถ้ามีเครื่องแรง ๆ ที่คุ้มราคาสักเครื่องก็น่าจะพอ? บริษัทกฎหมายที่โหด ๆ ก็คงซื้อมาใช้กันแหละ แต่ก็ต้องเปิดเครื่องเหมือนเดินเครื่องจักรในโรงงาน 24 ชั่วโมงเลย 555
คนหนึ่งที่คิดแค่ราคารถ Porsche แต่ไม่ได้คิดเรื่องค่าบำรุงรักษา ค่าน้ำมัน ประกัน ฯลฯ เลยแม้แต่นิดเดียว
บริการอย่างแชตบอตที่ต้องมีฟีเจอร์สตรีมมิง พอประมวลผลพร้อมกัน งาน Prefill จะส่งผลไปถึง decode ด้วย เลยทำให้ถึง VRAM จะเหลือเยอะ แต่ในมุมผู้ใช้กลับดูเหมือนประสิทธิภาพลดลงมากครับ
ผมลองใช้ทั้งออปชันที่เกี่ยวกับ chunk prefill และฟีเจอร์ Disaggregated Prefilling ที่ vLLM มีให้แบบทดลองแล้ว แต่พอมีคำขอใหม่เข้ามา ก็ยังเกิดอาการที่คำตอบซึ่งกำลังสร้างอยู่เดิมสะดุดเป็นช่วง ๆ อยู่ดี เลยอยากทราบว่าในมุมของนักพัฒนามือใหม่ นอกจากวิธีเพิ่ม GPU หรือเพิ่มโหนดแล้ว ยังมีวิธีที่มีประสิทธิภาพที่สุดอีกไหมครับ
สรุปคือ~แล้วแต่กรณี!