นำโดย GPT OSS ที่ OpenAI เผยแพร่ภายใต้ลิขสิทธิ์ Apache 2.0 โมเดลภาษาแบบ open-weight เริ่มบันทึกคะแนน benchmark ที่เทียบเคียงได้กับ cloud API ในงานเฉพาะทางบางประเภท โดยเฉพาะอย่างยิ่ง SLM (Small Language Model) กำลังแสดงให้เห็นถึงช่องว่างด้านความแม่นยำที่แคบลงเมื่อเทียบกับ cloud API ในงานประจำรูปแบบ เช่น การจำแนกประเภท การสรุปความ และการดึงข้อมูลเชิงโครงสร้าง จึงได้รับความสนใจในฐานะทางเลือกที่สามารถบรรลุทั้ง data sovereignty และการเพิ่มประสิทธิภาพด้านต้นทุนไปพร้อมกัน บทความนี้มุ่งเป้าไปยังผู้รับผิดชอบด้านระบบสารสนเทศและความมั่นคงปลอดภัยในภาคการเงิน การแพทย์ และการผลิต ซึ่งมีข้อจำกัดในการส่งข้อมูลขึ้น cloud โดยจะเปรียบเทียบ trade-off ระหว่าง local LLM / SLM รวมถึง GPT OSS กับ cloud API ใน 3 มิติ ได้แก่ ข้อกำหนด GPU ความแม่นยำแยกตามประเภทงาน และ TCO เมื่ออ่านจบ คุณจะมีข้อมูลเพียงพอสำหรับการตัดสินใจเลือก architecture และการผสมผสานโมเดลที่เหมาะสมที่สุดสำหรับองค์กรของคุณ

วิธีการนำ language model ของ AI มาใช้ในงานแบ่งออกเป็น 3 แนวทางหลัก ได้แก่ Cloud API, Local LLM และ SLM ทั้ง 3 แนวทางนี้สามารถจัดระเบียบได้ด้วยแกน 2 แกน คือ "สถานที่รันโมเดล" และ "ขนาดของโมเดล"

Cloud API คือวิธีการส่ง HTTP request ไปยังโมเดลที่โฮสต์ไว้แล้วโดย OpenAI, Anthropic และ Google ข้อดีคือไม่ต้องจัดการโครงสร้างพื้นฐานเอง แต่ข้อมูลอินพุตจะต้องผ่านเซิร์ฟเวอร์ของผู้ให้บริการ

Local LLM หมายถึงแนวทางการรันโมเดลภาษาขนาดใหญ่บนเซิร์ฟเวอร์หรือเวิร์กสเตชันของตนเอง โมเดลขนาดใหญ่ที่อยู่ในกลุ่มนี้ ได้แก่ Llama 4 Maverick (พารามิเตอร์รวม 400B, active 17B) และ GPT OSS 120B (พารามิเตอร์รวม 117B, active 5.1B) โมเดลขนาดใหญ่ในยุคหลังนำสถาปัตยกรรม MoE (Mixture of Experts) มาใช้ ซึ่งช่วยลด active parameter ลงอย่างมากเมื่อเทียบกับจำนวนพารามิเตอร์รวม ทำให้สามารถรันได้ด้วย GPU น้อยกว่าเดิม

SLM (Small Language Model) คือโมเดลขนาดเบาที่จำกัดจำนวนพารามิเตอร์ไว้ที่ระดับหลายพันล้านหรือน้อยกว่า ตัวอย่างที่เป็นตัวแทนของกลุ่มนี้ ได้แก่ GPT OSS 20B (พารามิเตอร์รวม 21B, active 3.6B), Phi-4 (14B), Gemma 3 (4B / 12B / 27B), Qwen 3 (7B) และ Llama 4 Scout (พารามิเตอร์รวม 109B, active 17B) จุดเด่นคือ "ขนาดเล็ก ≠ ประสิทธิภาพต่ำ" เนื่องจากการฝึกด้วย MoE และข้อมูลคุณภาพสูงช่วยให้ความแม่นยำในงานเฉพาะทางเทียบเคียงได้กับโมเดลขนาดใหญ่

โดยเฉพาะอย่างยิ่ง GPT OSS คือตระกูลโมเดล open-weight ชุดแรกที่ OpenAI เผยแพร่ภายใต้ Apache 2.0 license โดยมียอดดาวน์โหลดบน HuggingFace ทะลุ 9 ล้านครั้งภายในเวลาเพียงไม่กี่สัปดาห์หลังเปิดตัว โมเดลนี้ใช้ tokenizer ตัวเดียวกับ GPT series บน Cloud API และรองรับทั้ง tool calling และการอนุมานแบบ Chain-of-Thought จึงมีอุปสรรคในการย้ายระบบจาก workflow ที่ใช้ GPT เป็นฐานอยู่ต่ำมาก

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

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

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

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

รูปแบบที่ 1: การจำแนกและสรุปข้อมูลที่เป็นความลับ (การเงิน). ต้องการใช้ AI สรุปเอกสารการพิจารณาสินเชื่อ แต่ไม่สามารถส่งข้อมูลทางการเงินของลูกค้าขึ้น Cloud ได้ หากติดตั้ง SLM บนเซิร์ฟเวอร์ภายในองค์กร จะสามารถทำให้การสรุปเอกสารการพิจารณาเป็นแบบอัตโนมัติโดยที่ข้อมูลไม่รั่วไหลออกสู่ภายนอก ระดับการประหยัดเวลาเมื่อเทียบกับการทำด้วยมือนั้นขึ้นอยู่กับความซับซ้อนของเอกสารและการปรับแต่งความแม่นยำของโมเดล

รูปแบบที่ 2: การวิเคราะห์ Log ของสายการผลิต (การผลิต). ให้ SLM วิเคราะห์ Log ของอุปกรณ์บน Edge Server ในโรงงานเพื่อตรวจจับรูปแบบความผิดปกติ การใช้งานผ่าน Cloud API จะมีความหน่วงจากการรับส่งข้อมูลผ่านเครือข่าย แต่การประมวลผลแบบ Local สามารถลดส่วนนั้นได้ อย่างไรก็ตาม การ Inference ของ SLM เองก็ใช้เวลาหลายสิบถึงหลายร้อยมิลลิวินาที ดังนั้นนิยามของ "Real-time" จึงต้องได้รับการตรวจสอบให้สอดคล้องกับข้อกำหนดทางธุรกิจ

รูปแบบที่ 3: การจัดโครงสร้างเวชระเบียนอิเล็กทรอนิกส์ (การแพทย์). สามารถพิจารณาแนวทางการใช้ SLM แปลงบันทึกการรักษาแบบอิสระให้เป็นรูปแบบ SOAP ได้ เนื่องจากข้อมูลผู้ป่วยไม่ออกจากเครือข่ายภายในโรงพยาบาล จึงง่ายต่อการรักษาความสอดคล้องกับกฎหมายคุ้มครองข้อมูลส่วนบุคคลและแนวปฏิบัติด้านข้อมูลทางการแพทย์ อย่างไรก็ตาม เนื่องจากโดเมนการแพทย์จัดอยู่ในประเภท YMYL (Your Money or Your Life) การมีระบบตรวจสอบผลลัพธ์โดยมนุษย์จึงเป็นสิ่งที่ขาดไม่ได้

ในทางกลับกัน หากตรงกับเงื่อนไขต่อไปนี้ Cloud API ถือเป็นตัวเลือกที่สมเหตุสมผลกว่า

• ข้อมูลที่ประมวลผลไม่มีข้อมูลที่เป็นความลับ (เช่น การสรุปข้อมูลสาธารณะ การสร้าง FAQ ภายในองค์กร)
• ปริมาณ token ต่อเดือนไม่มาก (ดูจุดคุ้มทุนที่จะกล่าวถึงในภายหลัง)
• ต้องการประสิทธิภาพของโมเดลล่าสุดอยู่เสมอ (Cloud API จะอัปเดตโมเดลโดยอัตโนมัติ)
• ไม่มีระบบบริหารจัดการโครงสร้างพื้นฐาน GPU (ไม่มี ML Engineer ที่รับผิดชอบโดยตรง)

เมื่อมีทั้ง "ข้อมูลที่ไม่สามารถส่งขึ้น Cloud ได้" และ "ปริมาณ token ต่อเดือนในระดับหนึ่ง" การลงทุนเพื่อรันแบบ local จึงจะคุ้มค่าในแง่ของผลตอบแทนต่อการลงทุน

ปัญหาแรกที่มักเจอในการรันโมเดลบนเครื่องตัวเองคือ "จะใช้โมเดลไหน กับฮาร์ดแวร์แบบไหน" การแพร่หลายของสถาปัตยกรรม MoE ทำให้ไม่สามารถประเมินหน่วยความจำที่ต้องการได้จากจำนวนพารามิเตอร์ทั้งหมดเพียงอย่างเดียวอีกต่อไป บทความนี้จะช่วยให้คุณคำนวณย้อนกลับจากจำนวน active parameter และระดับการ quantization เพื่อเลือกโมเดลให้เหมาะสมกับงบประมาณที่มี

ตารางด้านล่างนี้จัดเรียงโมเดลแบบ open-weight หลักๆ ตามความต้องการหน่วยความจำ GPU โปรดสังเกตว่าโมเดล MoE แม้จะมีจำนวนพารามิเตอร์รวมมาก แต่ต้องการหน่วยความจำน้อยกว่า เนื่องจากมี active parameter จำนวนน้อย

เปรียบเทียบสเปค GPU (NVIDIA อย่างเป็นทางการ): RTX 5090 มี GDDR7 32GB · แบนด์วิดท์ 1,792 GB/s (สถาปัตยกรรม Blackwell) H200 มี HBM3e 141GB · แบนด์วิดท์ 4.8 TB/s B200 มี HBM3e 192GB · แบนด์วิดท์ 8 TB/s แบนด์วิดท์เป็นตัวชี้วัดที่สำคัญอย่างยิ่งสำหรับการ inference ของ LLM ที่ถูก memory-bound

วิธีอ่านตาราง: ค่า "VRAM Q4 โดยประมาณ" ของโมเดล MoE รวมน้ำหนักของ expert ทั้งหมดไว้แล้ว แม้ว่า active parameter จะมีจำนวนน้อย แต่ก็ยังจำเป็นต้องโหลด expert ทั้งหมดลงในหน่วยความจำ

สิ่งที่น่าสนใจคือประสิทธิภาพของ GPT OSS 20B พารามิเตอร์รวม 21B แต่ active เพียง 3.6B เท่านั้น ด้วยการ quantize แบบ MXFP4 ใช้พื้นที่ประมาณ 13GB จึงทำงานได้อย่างสบายบน RTX 5090 ที่มี 32GB (และยังทำงานได้บน RTX 4090 ที่มี 24GB ด้วย) แม้จะเป็นเช่นนั้น โมเดลนี้ยังทำคะแนนใน benchmark อย่างเป็นทางการได้เทียบเท่า OpenAI o3-mini

หากต้องการความแม่นยำสูงสุดด้วย RTX 5090 เพียงใบเดียว GPT OSS 20B (MXFP4) คือตัวเลือกอันดับแรก เนื่องจากแบนด์วิดท์เพิ่มขึ้น 78% เมื่อเทียบกับ RTX 4090 จึงคาดหวัง throughput การ inference ที่ดีขึ้นได้ด้วย นอกจากนี้ VRAM 32GB ที่มีอยู่อย่างเหลือเฟือยังทำให้ Gemma 3 27B (Q4, 16GB) ทำงานได้อย่างลื่นไหลเช่นกัน

สำหรับ H200 ใบเดียว ทั้ง GPT OSS 120B และ Llama 4 Scout ต่างเป็นตัวเลือกที่เป็นไปได้ GPT OSS 120B ใช้พื้นที่ประมาณ 61GB ด้วย MXFP4 ส่วน Llama 4 Scout ใช้ประมาณ 55GB ด้วย int4 บวกกับ KV cache VRAM 141GB ทำให้มีพื้นที่เหลือสำหรับ KV cache แม้ใช้ context ยาว (128K token) หากเน้น text inference ให้เลือก GPT OSS 120B แต่หากต้องการ multimodal (การเข้าใจภาพ) ให้เลือก Llama 4 Scout

สำหรับ B200 Llama 4 Maverick (พารามิเตอร์รวม 400B) อยู่ในขอบเขตที่ทำได้ ด้วย HBM3e 192GB และแบนด์วิดท์ 8 TB/s ทำให้สามารถ inference ด้วย GPU ใบเดียวโดยใช้การ quantize แบบ Q4 ได้ โดย NVIDIA อ้างว่าประสิทธิภาพการ inference สูงกว่า H100 ถึง 15 เท่า (ตามข้อมูลอย่างเป็นทางการของ NVIDIA)

การควอนไทซ์ (Quantization) คือเทคนิคการบีบอัดน้ำหนักของโมเดลให้เป็นบิตต่ำ (4bit / 8bit) ซึ่งสามารถลด VRAM ที่จำเป็นลงได้มากกว่าครึ่งหนึ่ง นับตั้งแต่การเปิดตัว GPT OSS นอกเหนือจากรูปแบบการควอนไทซ์แบบดั้งเดิมแล้ว MXFP4 ยังได้กลายมาเป็นตัวเลือกใหม่อีกด้วย

เกี่ยวกับความสัมพันธ์ระหว่างระดับการควอนไทซ์และความแม่นยำนั้น มีรายงานการตรวจสอบจากชุมชนสะสมอยู่มากมาย แนวโน้มทั่วไปคือ Q8 (8bit) แทบไม่พบการลดลงของความแม่นยำเมื่อเทียบกับ FP16, Q4 (4bit) อาจพบการเสื่อมคุณภาพเล็กน้อยขึ้นอยู่กับงาน และ Q2 (2bit) มีรายงานว่าคุณภาพลดลงอย่างชัดเจน อย่างไรก็ตาม เนื่องจากระดับการเสื่อมคุณภาพแตกต่างกันไปตามโมเดล งาน และภาษา การตรวจสอบในกรณีการใช้งานจริงขององค์กรจึงเป็นสิ่งที่ขาดไม่ได้

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

MXFP4 คือรูปแบบการควอนไทซ์ที่ OpenAI นำมาใช้ใน GPT OSS โดยนำไปใช้กับน้ำหนักเอ็กซ์เพิร์ตของ MoE อย่างเลือกสรร ให้ประสิทธิภาพสูงสุดบนสถาปัตยกรรม Blackwell (B200 / RTX 5090) และสถาปัตยกรรม Hopper (H100 / H200)

ประโยชน์ของการควอนไทซ์ไม่ได้จำกัดอยู่แค่การลด VRAM เท่านั้น แบนด์วิดท์หน่วยความจำของ RTX 5090 ที่ 1,792 GB/s, H200 ที่ 4.8 TB/s และ B200 ที่ 8 TB/s นั้นแสดงผลเสริมฤทธิ์กันกับการลดขนาดน้ำหนักจากการควอนไทซ์ แม้จะเป็นโมเดลเดียวกัน การใช้ Q4 จะลดปริมาณการถ่ายโอนน้ำหนักลงครึ่งหนึ่ง ช่วยบรรเทาคอขวดของแบนด์วิดท์และเพิ่มความเร็วในการสร้างโทเค็น

การดาวน์โหลดไฟล์ weights ของโมเดลเพียงอย่างเดียวไม่เพียงพอสำหรับการ inference (การสร้างข้อความ) กระบวนการต่างๆ ที่จำเป็น ได้แก่ การโหลดโมเดลลง GPU การใช้งาน tokenizer การจัดการ KV cache และการ sampling output token ล้วนเป็นหน้าที่ของ inference framework การเลือก framework ไม่ส่งผลต่อความแม่นยำของโมเดล แต่ส่งผลโดยตรงต่อความเร็วในการ inference จำนวนการประมวลผลพร้อมกัน และความสะดวกในการดำเนินงาน

llama.cpp คือ inference engine ที่พัฒนาด้วย C/C++ รองรับตั้งแต่ CPU only จนถึง GPU ได้อย่างหลากหลาย จุดเด่นคือสามารถโหลดโมเดลในรูปแบบ GGUF ได้โดยตรง และมี dependency น้อย นอกเหนือจาก Python environment และ CUDA driver GPT OSS ก็มีเวอร์ชันที่แปลงเป็น GGUF เผยแพร่ไว้เช่นกัน และสามารถเริ่มต้นใช้งานได้ด้วยคำสั่ง llama-server -hf ggml-org/gpt-oss-120b-GGUF เหมาะสำหรับการติดตั้งในสภาพแวดล้อมที่การสร้าง Python environment เป็นเรื่องยาก เช่น Windows PC หรืออุปกรณ์ edge

vLLM มีจุดเด่นด้านการจัดการหน่วยความจำที่มีประสิทธิภาพสูงด้วย PagedAttention ในการ inference ทั่วไป KV cache จะจองหน่วยความจำแบบต่อเนื่องสำหรับแต่ละ request ทำให้ VRAM ตึงตัวเมื่อจำนวน request พร้อมกันเพิ่มขึ้น vLLM จัดการสิ่งนี้ในระดับ page เพื่อป้องกัน memory fragmentation ทำให้สามารถประมวลผล request ได้มากขึ้นพร้อมกันด้วย VRAM เท่าเดิม GPT OSS รองรับ vLLM อย่างเป็นทางการ และสามารถเปิดให้บริการได้ด้วยคำสั่ง vllm serve openai/gpt-oss-120b --tensor-parallel-size 2 ถือเป็นตัวเลือกอันดับแรกสำหรับการให้บริการในฐานะ API server ภายในองค์กรแก่หลายแผนก

Ollama คือ CLI tool ที่ wrap llama.cpp ไว้ สามารถดาวน์โหลดและเริ่มต้นโมเดลได้ครบในคำสั่งเดียวอย่าง ollama run phi4 การจัดการโมเดล (การสลับเวอร์ชัน การลบ) ก็ทำได้ครบผ่าน CLI จึงเหมาะอย่างยิ่งสำหรับขั้นตอน "ลองรันดูก่อน" ใน PoC หรือ prototyping อย่างไรก็ตาม เนื่องจากไม่มีกลไก request queuing หรือ monitoring ในตัว จึงจำเป็นต้องย้ายไปใช้ vLLM หรือเครื่องมืออื่นสำหรับ production environment

"เข้าใจแล้วว่ามันทำงานได้บน local แต่ความแม่นยำนั้นโอเคไหม?" — นี่คือคำถามที่พบบ่อยที่สุดในการพิจารณานำไปใช้งาน การเปิดตัว GPT OSS ได้เปลี่ยนแปลงคำตอบของคำถามนี้ไปอย่างมาก

ต่อไปนี้คือการเปรียบเทียบคะแนนสาธารณะระหว่างโมเดลในเครื่อง (local model) และ cloud API ในเบนช์มาร์กหลัก โดย MMLU, HumanEval และ MATH อ้างอิงจากค่าที่ประกาศอย่างเป็นทางการของแต่ละโมเดล หรือการตรวจสอบซ้ำโดยบุคคลที่สาม

หมายเหตุ: คะแนนเบนช์มาร์กรายงานของ GPT OSS 20B ถูกสรุปในโมเดลการ์ดทางการว่า "เทียบเท่า o3-mini" แต่คะแนนรายละเอียดแยกตามงานบางส่วนยังไม่ได้เปิดเผย "เทียบเท่า o3-mini" ข้างต้นอ้างอิงจากการเปรียบเทียบอย่างเป็นทางการของ OpenAI

สำหรับการจำแนกข้อความ, การสรุปข้อความสั้น, การดึงข้อมูลเชิงโครงสร้าง และการแปลหลายภาษานั้น ยังไม่มีเบนช์มาร์กสาธารณะมาตรฐานที่ยอมรับกันทั่วไป การเปรียบเทียบความแม่นยำระหว่างโมเดลจึงจำเป็นต้องตรวจสอบด้วยข้อมูลของตนเอง แนวโน้มทั่วไปคือ งานที่มี input/output สั้นและเป็นรูปแบบตายตัว (เช่น การจำแนกและการดึงข้อมูล) จะมีช่องว่างด้านประสิทธิภาพระหว่าง SLM กับ cloud API น้อยกว่า ในขณะที่งานที่ต้องการ context ยาวหรือการอนุมานที่ซับซ้อนนั้น cloud API มักมีความได้เปรียบมากกว่า

การปรากฏตัวของ GPT OSS ทำให้ขอบเขตที่ local model สามารถเทียบเคียง cloud API บน public benchmark ขยายกว้างขึ้น

ด้าน benchmark ที่ local model มีความโดดเด่น ได้แก่ การสร้างโค้ด (HumanEval) และการเรียกใช้ tool (TauBench) โดย GPT OSS 120B ทำคะแนนใน TauBench สูงกว่า o3-mini และเทียบเท่า o4-mini (จาก OpenAI official blog) ส่วน GPT OSS 20B ก็ถูกประเมินว่าอยู่ในระดับเดียวกับ o3-mini

ด้านที่ cloud API ยังคงมีความได้เปรียบ คือ การอนุมานที่ซับซ้อนและคณิตศาสตร์ (MATH benchmark) รวมถึงงานหลายภาษา แม้แต่ "deep mode" ของ GPT OSS 120B (โหมดที่ใช้เวลาในการอนุมานมากขึ้น) ก็ยังมีช่องว่างกับ cloud model ขนาดใหญ่อยู่

อย่างไรก็ตาม คะแนน benchmark และความแม่นยำในงานจริงไม่จำเป็นต้องสอดคล้องกันเสมอไป benchmark วัดผลด้วย prompt และเกณฑ์การประเมินที่เป็นมาตรฐาน แต่ในงานจริงนั้น คุณภาพของข้อมูล input คำศัพท์เฉพาะทาง และข้อกำหนดด้านรูปแบบ output ล้วนแตกต่างกัน ดังนั้นในการตัดสินใจนำไปใช้งาน จึงควรอ้างอิง benchmark เป็นแนวทาง พร้อมกับการทำ PoC โดยใช้ข้อมูลขององค์กรเองด้วย

หากความแม่นยำในระดับทั่วไปยังไม่เพียงพอ สามารถเพิ่มความแม่นยำได้โดยใช้ PEFT (Parameter-Efficient Fine-Tuning) เพื่อปรับแต่งโมเดลให้เชี่ยวชาญเฉพาะด้านกับข้อมูลขององค์กร

ในแง่ของสิทธิ์การใช้งาน GPT OSS ใช้สัญญาอนุญาต Apache 2.0 จึงไม่มีข้อจำกัดสำหรับการไฟน์จูนนิ่งหรือการใช้งานเชิงพาณิชย์ ในทางกลับกัน Llama 4 Scout ใช้ Llama 4 Community License ซึ่งองค์กรที่มีผู้ใช้งานที่ใช้งานต่อเดือนเกิน 700 ล้านคนจะต้องขอรับสิทธิ์การใช้งานแยกต่างหาก สำหรับองค์กรส่วนใหญ่แล้วข้อจำกัดนี้แทบไม่มีผลในทางปฏิบัติ แต่ควรตระหนักว่าเงื่อนไขแตกต่างจาก Apache 2.0

ในบรรดาเทคนิค PEFT ที่ใช้งานจริงมากที่สุดในภาคปฏิบัติคือ LoRA และ QLoRA

LoRA เป็นเทคนิคที่เพิ่มเมทริกซ์อัปเดตแบบ low-rank เข้าไปในเมทริกซ์น้ำหนักของโมเดล โดยเรียนรู้เฉพาะพารามิเตอร์เพิ่มเติมประมาณ 0.1–1% ของพารามิเตอร์ทั้งหมด สามารถทำการไฟน์จูนนิ่ง LoRA บนโมเดล Phi-4 14B ได้ด้วย RTX 4090 เพียงหนึ่งใบ

QLoRA เป็นเทคนิคที่ผสมผสาน LoRA เข้ากับการ Quantization เพื่อลด VRAM ที่จำเป็นลงอีกครึ่งหนึ่ง เนื่องจากสามารถไฟน์จูนโมเดลขนาด 14B ได้แม้บน GPU ระดับ 16GB จึงเป็นตัวเลือกที่น่าสนใจสำหรับผู้ที่ต้องการลดการลงทุนเริ่มต้น

ขั้นตอนทั่วไปสำหรับการปรับแต่งโมเดลมีดังนี้

1. เลือก Base Model: เลือกโมเดลที่เหมาะกับฮาร์ดแวร์จากตารางการเลือกข้างต้น
2. เตรียมข้อมูล: สร้างข้อมูลสำหรับการเรียนรู้จำนวน 500–5,000 รายการจากข้อมูลงาน (คู่ input–output)
3. ไฟน์จูนด้วย QLoRA: เวลาในการเรียนรู้ขึ้นอยู่กับปริมาณข้อมูล LoRA rank และจำนวน epoch โดยประมาณการณ์ว่าสำหรับเงื่อนไข 1,000 รายการ rank 16 และ 3 epoch บน RTX 4090 จะใช้เวลาหลายชั่วโมง
4. ประเมินผล: ตรวจสอบความแม่นยำด้วยชุดทดสอบภายในองค์กร และยืนยันความแตกต่างจาก Base Model
5. Deploy: นำโมเดลที่ merge แล้วไปติดตั้งบน llama.cpp / vLLM

ขอบเขตของการเพิ่มความแม่นยำจากการไฟน์จูนเฉพาะโดเมนนั้นขึ้นอยู่กับประสิทธิภาพทั่วไปของ Base Model คุณภาพและปริมาณของข้อมูลการเรียนรู้ รวมถึงลักษณะของงานเป็นอย่างมาก แนะนำให้ยืนยันผลลัพธ์ด้วยการทดสอบขนาดเล็ก (100–200 รายการ) ก่อน แล้วจึงดำเนินการจัดเตรียมข้อมูลอย่างจริงจัง

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

หมายเหตุ: ราคาฮาร์ดแวร์อาจเปลี่ยนแปลงได้อย่างมากตามสภาวะตลาด มีรายงานว่า RTX 5090 ถูกซื้อขายในราคาสูงกว่า MSRP ($1,999) อย่างมีนัยสำคัญ เนื่องจากผลกระทบจากการขาดแคลน DRAM ควรตรวจสอบราคาตลาดล่าสุดก่อนพิจารณานำไปใช้งาน

ความคุ้มค่าของ RTX 5090 กำลังได้รับความสนใจ การที่ GPT OSS 20B (เทียบเท่า o3-mini ตาม Benchmark อย่างเป็นทางการ) สามารถทำงานบน GPU สำหรับผู้บริโภคขนาด 32GB ได้นั้น เป็นปัจจัยที่ช่วยลดจุดคุ้มทุนของ Local AI ลง

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

สำหรับเซิร์ฟเวอร์ RTX 5090 (สมมติการลงทุนเริ่มต้น 800,000–1,000,000 เยน, ค่าดำเนินการรายเดือน 30,000–50,000 เยน, ราคาเป็นค่าอ้างอิง) จุดคุ้มทุนเมื่อเทียบกับ Cloud API ขึ้นอยู่กับปริมาณ Token ต่อเดือน RTX 5090 มี VRAM เพิ่มขึ้นจาก 24GB เป็น 32GB เมื่อเทียบกับ RTX 4090 และ Memory Bandwidth ดีขึ้น 78% จึงสามารถรัน MoE Model อย่าง GPT OSS 20B ได้อย่างราบรื่นยิ่งขึ้น

สิ่งสำคัญที่ควรทราบเป็นข้อสมมติฐานของการประมาณการนี้คือ ต้นทุนดำเนินการรายเดือนของ Local SLM แทบไม่แปรผันตามปริมาณการประมวลผล เนื่องจาก GPU Server เป็นโมเดลต้นทุนคงที่ ยิ่งประมวลผลมากขึ้น ราคาต่อ Token ยิ่งลดลง ในทางกลับกัน หากใช้งานเบาโดยมีปริมาณ Token ต่อเดือนน้อย ค่าใช้จ่ายแบบ Pay-as-you-go ของ Cloud API จะถูกกว่า

แม้ RTX 5090 จะมีการลงทุนเริ่มต้นสูงกว่า RTX 4090 แต่ด้วย VRAM 32GB ทำให้ Gemma 3 27B (Q4, 16GB) ทำงานได้อย่างสบาย และขยายตัวเลือก Model ให้กว้างขึ้น การพิจารณาว่าคุ้มค่ากับส่วนต่างของเงินลงทุนหรือไม่ ควรตัดสินจากขนาด Model ที่ต้องการและปริมาณการประมวลผล

จุดคุ้มทุนที่แท้จริงจะแตกต่างกันอย่างมากตาม Model, โครงสร้างราคา และเงื่อนไขสัญญาของ Cloud API ที่ใช้งาน เมื่อพิจารณานำเข้าใช้งาน แนะนำให้วัดปริมาณ Token ต่อเดือนของตนเองเป็นเวลา 1–2 สัปดาห์ก่อน จากนั้นจึงเปรียบเทียบใบเสนอราคาของ Cloud API กับต้นทุนคงที่ของการรันแบบ Local

รูปแบบความล้มเหลวที่พบซ้ำๆ ในการนำ Local LLM / SLM มาใช้งานมี 3 รูปแบบ แต่ละรูปแบบสามารถแก้ไขได้ในเชิงเทคนิค อย่างไรก็ตาม หากรู้ไว้ล่วงหน้าจะช่วยหลีกเลี่ยงการเสียเวลาโดยไม่จำเป็นได้

มีกรณีที่พยายามรันโมเดล 70B อย่างฝืนใจ แล้วลดคุณภาพลงด้วยการ Quantization ที่มากเกินไป (Q2) ในหลายกรณี การรันโมเดล 14B ด้วย Q4 ให้ความแม่นยำสูงกว่าการรันโมเดล 70B ด้วย Q2 การใช้โมเดลที่มีขนาดเหมาะสมกับฮาร์ดแวร์ในระดับ Q4 ขึ้นไป จะช่วยให้ได้ผลลัพธ์ที่เหมาะสมทั้งในแง่ความแม่นยำและต้นทุน

ให้ย้อนกลับไปดูตารางการเลือกโมเดลตามข้อกำหนด GPU ที่กล่าวถึงก่อนหน้า แล้วเลือก "โมเดลที่ใหญ่ที่สุดที่สามารถรันด้วย Q4 ขึ้นไป" ภายใต้ GPU Memory ของบริษัทตนเอง นั่นคือคำตอบที่ถูกต้องในเชิงปฏิบัติ

อีกสิ่งหนึ่งที่มักถูกมองข้ามคือการใช้หน่วยความจำจาก KV cache ในระหว่างการ inference แม้ว่าตัวโมเดลจะใช้เพียง 8GB แต่หากประมวลผล prompt ที่ยาว (เกิน 4,000 token) KV cache จะกินหน่วยความจำเพิ่มอีก 2〜4GB แม้แต่ RTX 4090 ที่มี VRAM 24GB ก็อาจถูกใช้จนเต็มที่ 18〜20GB จากการรวมกันของโมเดล 14B (Q4, 8GB) + KV cache + OS

มีวิธีแก้ปัญหาอยู่ 2 แนวทาง ได้แก่ การจำกัด context length ให้เหลือเพียงเท่าที่จำเป็นสำหรับการใช้งานจริง (หากใช้แค่ 4,096 ก็ไม่จำเป็นต้องตั้งเป็น 8,192) และอีกแนวทางหนึ่งคือการใช้ PagedAttention ของ vLLM เพื่อจัดการ KV cache ได้อย่างมีประสิทธิภาพ

แม้ว่า PoC ในช่วงเริ่มต้นจะประสบความสำเร็จ แต่ก็มีกรณีที่ถูกละเลยในช่วงการดำเนินงานจริง โมเดล Open-weight จะมีการเผยแพร่เวอร์ชันใหม่ทุกๆ หลายเดือน เช่น Phi-3 → Phi-4 หรือ Gemma 2 → Gemma 3 ซึ่งเมื่อเปลี่ยนรุ่น ความแม่นยำจะดีขึ้นอย่างมีนัยสำคัญแม้จะใช้จำนวน parameter เท่าเดิม

สำหรับโครงสร้างการดำเนินงานขั้นต่ำ แนะนำให้รวมการประเมินการอัปเดตโมเดลทุกไตรมาส รวมถึงการติดตามตรวจสอบความเร็วในการ inference และอัตราข้อผิดพลาดอย่างสม่ำเสมอ แม้จะไม่มี ML engineer ประจำ งานเหล่านี้ก็อยู่ในระดับที่เจ้าหน้าที่ฝ่าย IT สามารถทำให้เป็นระบบอัตโนมัติได้ด้วย script

หากสามารถนำข้อมูลออกสู่ภายนอกได้ Cloud API จะสะดวกกว่า ควรเลือกใช้ GPT OSS ในกรณีที่มีข้อจำกัดด้าน data sovereignty ต้องการแปลงต้นทุน API ให้เป็นค่าใช้จ่ายคงที่ หรือต้องการรันในสภาพแวดล้อมแบบออฟไลน์ จากเกณฑ์มาตรฐานอย่างเป็นทางการของ OpenAI พบว่า GPT OSS 20B บันทึกคะแนนที่เทียบเท่า o3-mini ในการทดสอบ MMLU, HumanEval, TauBench และอื่นๆ ในขณะที่ 120B บันทึกคะแนนที่เทียบเท่า o4-mini อย่างไรก็ตาม เนื่องจากคะแนน benchmark ไม่ได้รับประกันความแม่นยำในงานจริง การตรวจสอบด้วย PoC บนงานของบริษัทเองจึงเป็นสิ่งจำเป็น

ใช้ได้ RAG (Retrieval-Augmented Generation) เป็นเทคนิคที่ฝังเอกสารที่ดึงมาจากการค้นหาลงในพรอมต์ จึงไม่ขึ้นอยู่กับขนาดของโมเดล การผสมผสานระหว่าง GPT OSS 20B หรือ Phi-4 กับ vector DB (เช่น Qdrant, pgvector เป็นต้น) ช่วยให้สามารถสร้าง pipeline สำหรับการค้นหาเอกสารภายในองค์กรและการสร้างคำตอบได้ เนื่องจาก GPT OSS มี context length ถึง 128K และ Llama 4 Scout มีสูงสุดถึง 10M token จึงมีความยืดหยุ่นเพียงพอในการออกแบบ chunk size สำหรับ RAG ด้วย

ขึ้นอยู่กับฮาร์ดแวร์ที่ใช้งาน แต่ในบางกรณี การประมวลผลแบบ local อาจมี latency ต่อ request เดียวที่ต่ำกว่า เนื่องจาก cloud API มี overhead จากการรับส่งข้อมูลผ่านเครือข่ายและการรอคิว (queue) เพิ่มเติม สำหรับ GPT OSS 20B บน RTX 4090 นั้น เนื่องจาก active parameter ของ MoE มีเพียง 3.6B ซึ่งน้อยกว่า จึงมีความเป็นไปได้ที่จะเริ่มสร้าง token ได้เร็วกว่าโมเดลแบบ Dense 14B อย่างไรก็ตาม เมื่อจำนวน request พร้อมกันเพิ่มขึ้น GPU จะกลายเป็น bottleneck ดังนั้นจึงจำเป็นต้องออกแบบระบบโดยใช้ batch inference framework อย่าง vLLM เพื่อรองรับ throughput ที่เพียงพอ เนื่องจาก latency จริงจะแปรผันอย่างมากตามโมเดล, การ quantization, ความยาวของ prompt และ batch size จึงแนะนำให้วัดผลในสภาพแวดล้อมของตนเองแทนการอ้างอิงค่า benchmark

ผลลัพธ์จากการใช้งานจริงในระดับ Production กำลังเพิ่มขึ้นเรื่อยๆ จากรายงานกรณีศึกษาของชุมชน Open Source และผู้ให้บริการ Cloud ข้อควรระวังหลักในการนำ SLM ที่ Fine-tuning ด้วย QLoRA ไปใช้งานจริงมีอยู่ 2 ประการ ประการแรกคือการควบคุมคุณภาพของข้อมูลการเรียนรู้ หากเรียนรู้จากข้อมูลที่มีสัญญาณรบกวนมาก อาจเกิดปรากฏการณ์ที่เรียกว่า "Catastrophic Forgetting" ซึ่งทำให้ประสิทธิภาพทั่วไปเสื่อมถอยลง ประการที่สองคือการจัดการเวอร์ชันของ LoRA Adapter เมื่อมีการอัปเดต Base Model จะต้องทำการเรียนรู้ Adapter ใหม่อีกครั้ง รายละเอียดทางเทคนิคของ Fine-tuning อธิบายไว้ในบทความแนะนำ PEFT

การตัดสินใจนำ Local LLM / SLM มาใช้งานนั้นขึ้นอยู่กับปัจจัย 3 ประการ ได้แก่ "ข้อกำหนดด้านอธิปไตยของข้อมูล (Data Sovereignty)" "ปริมาณ Token ต่อเดือน" และ "ความซับซ้อนของงาน" การเกิดขึ้นของ GPT OSS ทำให้การตัดสินใจนี้ง่ายขึ้นอีกขั้น หากมีข้อจำกัดที่ไม่สามารถส่งข้อมูลขึ้น Cloud ได้ และต้องประมวลผลมากกว่า 5 ล้าน Token ต่อเดือน ก็สามารถใช้ GPT OSS 20B (RTX 4090) หรือ GPT OSS 120B (H100) เพื่อให้ได้ความแม่นยำเทียบเท่า o3-mini / o4-mini ของ Cloud API ได้ในระดับ Local

แนวทางที่แนะนำคือ เริ่มต้นทดสอบในขนาดเล็กด้วย Ollama + GPT OSS 20B ก่อน หากพอใจกับความแม่นยำแล้วจึงใช้ QLoRA เพื่อ Fine-tune กับข้อมูลขององค์กร จากนั้นนำไปให้บริการด้วย vLLM การดำเนินการตามขั้นตอนนี้จะช่วยให้สามารถบรรลุทั้งอธิปไตยของข้อมูลและการเพิ่มประสิทธิภาพด้านต้นทุน ในขณะที่ยังคงลงทุนเริ่มต้นให้น้อยที่สุด