ก่อนซื้อ AI หรือ GPU ให้ตอบ 5 คำถามนี้: จาก Human-in-the-loop ถึงฮาร์ดแวร์

จุดเริ่มที่ถูกต้องไม่ใช่ AI แต่คือการตัดสินใจที่ต้องดีขึ้น

คำว่า “อยากใช้ AI” กว้างเกินกว่าจะออกแบบระบบได้ มันอาจหมายถึงอยากลดเวลาตอบลูกค้า อยากจัดลำดับเอกสาร อยากค้นความรู้ในองค์กร อยากตรวจความผิดปกติ หรือเพียงอยากแสดงว่าบริษัทไม่ตกกระแส แต่แต่ละเป้าหมายต้องใช้ข้อมูล วิธีวัด ความเสี่ยง และฮาร์ดแวร์ต่างกัน

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

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

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

กรอบ NIST AI Risk Management Framework ให้เหตุผลในทิศเดียวกัน ฟังก์ชัน Map เริ่มจากบริบท เป้าหมาย คุณค่า ขอบเขต ผู้มีส่วนได้เสีย และผลกระทบ ก่อนเข้าสู่การวัดและจัดการความเสี่ยง ที่สำคัญ NIST ระบุด้วยว่าความรู้เรื่องบริบทควรเพียงพอสำหรับการตัดสินใจ Go/No-Go เบื้องต้น กล่าวอีกอย่างคือ การหยุดโครงการเมื่อโจทย์ไม่เหมาะก็เป็นผลลัพธ์ที่มีคุณค่า ไม่ใช่ความล้มเหลว

โมเดลเก่งไม่ได้แปลว่าระบบจะใช้ได้ เพราะโมเดลเป็นเพียงชิ้นส่วนหนึ่ง

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

งานวิจัย Hidden Technical Debt in Machine Learning Systems จาก Google อธิบายว่าระบบ Machine Learning สร้างหนี้ทางเทคนิคจากการพึ่งพาข้อมูล ความเชื่อมโยงระหว่างส่วนประกอบ Feedback Loop และโค้ดเชื่อมระบบจำนวนมาก โมเดลอาจเป็นกล่องเล็กเมื่อเทียบกับโครงสร้างทั้งหมด แต่การเปลี่ยนข้อมูลหนึ่งช่องหรือ Workflow หนึ่งขั้นสามารถกระทบพฤติกรรมปลายทางได้

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

ในทางกลับกัน หากโมเดลพอดีกับหน่วยความจำและทำงานเป็น Batch กลางคืน CPU อาจเพียงพอ หากต้องตอบคำขอพร้อมกันจำนวนมากภายในเวลาเข้มงวด GPU อาจคุ้มค่า หากข้อมูลอยู่ใน Storage ช้า ต่อให้ GPU เร็วเพียงใดก็ต้องรอ และหากคนต้องตรวจทุกคำตอบ ต้นทุนแรงงานอาจสูงกว่าค่าเครื่องมาก

จึงควรคิดเป็นสมการเชิงระบบ ไม่ใช่สมการราคาเครื่อง:

คำถามที่ 1: การตัดสินใจใดต้องดีขึ้น และใครรับผลจากมัน

คำถามแรกทำหน้าที่เปลี่ยนความต้องการกว้าง ๆ ให้เป็นหน่วยงานที่ออกแบบและทดสอบได้ วิธีง่ายที่สุดคือเขียนหกช่อง ได้แก่ Actor, Decision, Input, Constraint, Outcome และ Harm จากนั้นอ่านเป็นเรื่องเดียวกัน ไม่ใช่กรอกแบบฟอร์มแล้วแยกเก็บคนละเอกสาร

เมื่อเขียนครบหกช่อง ลองทดสอบด้วยประโยคเดียว: “ระบบช่วยใครทำอะไรจากข้อมูลใด ภายใต้เงื่อนไขอะไร เพื่อให้ผลลัพธ์ใดดีขึ้น โดยต้องไม่สร้างความเสียหายแบบใด” หากประโยคยังยาวจนมีหลายงานปนกัน ให้แยกเป็น Use Case ย่อย เพราะหนึ่ง Pilot ควรพิสูจน์สมมติฐานสำคัญไม่กี่ข้อ ไม่ใช่แก้ทั้งองค์กรในครั้งเดียว

คำถามที่ 2: งานส่วนใดควรเป็นกฎ งานส่วนใดควรเป็น AI และส่วนใดไม่ควรทำอัตโนมัติ

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

คำถามที่ดีไม่ใช่ “กฎหรือ AI อย่างใดอย่างหนึ่ง” แต่คือ “ขอบเขตไหนควรแน่นอน ขอบเขตไหนต้องยืดหยุ่น และจุดไหนต้องให้คนใช้วิจารณญาณ” ระบบที่ดีจึงมักเป็น Hybrid กฎคุมสิทธิ์และเงื่อนไขตายตัว AI ช่วยจัดการความหลากหลาย ส่วนมนุษย์รับงานที่ต้องตีความผลกระทบหรือรับผิดชอบต่อการตัดสินใจ

Rules of Machine Learning ของ Google เริ่มด้วยคำแนะนำตรงไปตรงมาว่าอย่ากลัวที่จะเปิดผลิตภัณฑ์โดยไม่มี Machine Learning และให้สร้าง Metric ก่อน การเริ่มจาก Heuristic หรือกฎง่ายช่วยให้ทีมมี Baseline เก็บข้อมูล และเห็นว่าปัญหายากจริงตรงไหน ก่อนรับภาระของระบบ ML เต็มรูปแบบ

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

คำถามที่ 3: มนุษย์อยู่ตรงไหน และมีอำนาจเปลี่ยนผลได้จริงหรือไม่

คำว่า Human-in-the-loop ฟังแล้วอุ่นใจ แต่การมีปุ่ม “ยืนยัน” ไม่ได้แปลว่าคนกำกับระบบได้ หากหน้าจอไม่แสดงหลักฐาน คนไม่มีเวลาตรวจ ไม่มีสิทธิ์แก้ หรือการกดปฏิเสธสร้างงานเพิ่มจนทุกคนเลือกผ่าน ระบบนั้นมีเพียง Human-in-the-click คนอยู่ในภาพแต่ไม่ได้ควบคุมความเสี่ยง

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

งาน Guidelines for Human-AI Interaction ของ Microsoft Research เสนอแนวทาง 18 ข้อที่ผ่านการประเมินหลายรอบ เช่น ทำให้ผู้ใช้รู้ว่าระบบทำอะไรได้และทำได้ดีเพียงใด สนับสนุนการแก้ไขเมื่อระบบผิด ให้การควบคุมที่เหมาะสม และเรียนรู้จากพฤติกรรมผู้ใช้ แนวคิดเหล่านี้เตือนว่า Human Oversight เกิดจากการออกแบบปฏิสัมพันธ์ ไม่ใช่เพียงใส่ชื่อคนลงในแผนผัง

คนต้องเห็นอะไรจึงจะตรวจได้

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

คนต้องทำอะไรได้มากกว่ากดยอมรับ

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

เวลาและภาระของคนต้องถูกนับเป็นต้นทุน

หาก Pilot รายงานว่าโมเดลแม่น 95% แต่คนต้องอ่านทุกเคสตั้งแต่ต้นจนจบ ประโยชน์อาจต่ำกว่าที่เห็น ต้องวัดเวลาตรวจต่อเคส อัตราการแก้ ความเหนื่อยล้า ความแตกต่างระหว่างผู้ตรวจ และจำนวนกรณีที่ Escalate การทำให้คนตรวจทุกอย่างอาจเหมาะในช่วงเก็บหลักฐาน แต่ไม่ควรถูกซ่อนจาก TCO

Feedback ต้องกลับไปเปลี่ยนระบบ

การบันทึกว่าคนแก้อะไรโดยไม่วิเคราะห์ต่อเป็นเพียงการสะสม Log ทีมต้องทบทวนรูปแบบความผิดพลาด แยกข้อผิดพลาดของข้อมูล Prompt, Retrieval, Model, UI และนโยบาย แล้วกำหนดเจ้าของการแก้แต่ละชนิด บางปัญหาต้องปรับกฎ บางปัญหาต้องเพิ่มข้อมูล บางปัญหาต้องลดขอบเขต และบางปัญหาชี้ว่าไม่ควรใช้ AI ในจุดนั้นเลย

คำถามที่ 4: คุณค่าที่พิสูจน์ได้มากกว่าต้นทุนและความเสี่ยงทั้งวงจรหรือไม่

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

เริ่มจาก Baseline ที่ตรงกับงานจริง

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

Baseline ควรมีทั้งคุณภาพ เวลา ต้นทุน และความเสียหาย ไม่ใช่เลือก Metric เดียว เช่น ระบบตอบคำถามอาจวัดเวลาหาคำตอบ ความถูกต้องของหลักฐาน อัตราการส่งต่อ จำนวนคำตอบที่ต้องแก้ และความพึงพอใจของพนักงาน หาก AI เร็วขึ้นแต่ทำให้คนไม่เชื่อถือและตรวจซ้ำทุกครั้ง คุณค่าจริงอาจไม่เพิ่ม

แยก Metric ของโมเดลออกจาก Outcome ขององค์กร

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

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

นับ Total Cost of Ownership ให้ครบวงจร

TCO หรือ Total Cost of Ownership ไม่ได้มีแค่ค่าซื้อเครื่องหรือค่าเรียกโมเดล ให้รวมการเตรียมข้อมูล การติดป้าย การจัดสิทธิ์ การพัฒนา Integration, Storage, Network, Monitoring, Logging, Security, การฝึกผู้ใช้ การตรวจของคน การรับ Incident, การอัปเดตโมเดล และแผนย้ายออกจากผู้ให้บริการ หากเป็นเครื่องภายในยังมีไฟฟ้า ความเย็น พื้นที่ อะไหล่ ประกัน และเวลาของผู้ดูแลระบบ

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

กำหนด Go/No-Go และ Stop Rule ก่อนเห็นผล

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

Stop Rule ไม่ได้ทำให้ทีมกลัวทดลอง ตรงกันข้าม มันสร้างพื้นที่ให้ทดลองอย่างปลอดภัย เพราะทุกคนรู้ว่าขอบเขตอยู่ตรงไหน การหยุดเร็วช่วยรักษางบและความเชื่อมั่นสำหรับทางเลือกที่ดีกว่า

คำถามที่ 5: ข้อมูลไหลผ่านระบบอย่างไร และทรัพยากรใดเป็นคอขวดจริง

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

เส้นทางพื้นฐานมักเป็น Input → Storage → Network → RAM → CPU/GPU → RAM/VRAM → Output → Application → ผู้ใช้ แต่ระบบจริงอาจมี OCR, Database, Vector Search, Cache, Queue, API Gateway, Guardrail และ Logging แทรกอยู่ ทุกจุดใช้เวลา หน่วยความจำ และ Bandwidth ของตัวเอง หากวัดเฉพาะช่วงรันโมเดล เราอาจปรับส่วนที่ไม่ใช่คอขวด

เริ่มด้วยขนาดงาน ไม่ใช่ชื่อชิป

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

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

Capacity บอกว่าใส่ได้แค่ไหน

โมเดล น้ำหนัก พื้นที่ทำงาน Cache และข้อมูลระหว่างคำนวณต้องอยู่ในหน่วยความจำที่เหมาะสม หาก Working Set ไม่พอใน VRAM ระบบอาจย้ายข้อมูลไปมาระหว่าง RAM กับ GPU หรือไม่สามารถรันตามการตั้งค่าที่ต้องการได้ การถามว่า “GPU กี่ GB” จึงต้องตามด้วย “สำหรับโมเดล Precision, Context, Batch และจำนวนผู้ใช้แบบใด”

ตัวเลขขนาดไฟล์โมเดลไม่ใช่ Working Set ทั้งหมด ระหว่าง Inference ยังมี KV Cache, Activation บางส่วน ไลบรารี และพื้นที่ของ Runtime ขณะที่การ Fine-tune หรือ Training ต้องเก็บ Gradient, Optimizer State และ Activation มากขึ้น การประมาณจากชื่อโมเดลอย่างเดียวจึงเสี่ยงซื้อขาดหรือเกิน

Bandwidth บอกว่าขนข้อมูลได้เร็วแค่ไหน

GPU ทำงานได้ต่อเมื่อข้อมูลมาถึง หาก Storage อ่านช้า Network อิ่ม หรือการส่งระหว่าง CPU กับ GPU เป็นคอขวด หน่วยคำนวณจะว่างรอ Memory Bandwidth สำคัญกับงานที่ต้องอ่านน้ำหนักและข้อมูลจำนวนมากซ้ำ ๆ ส่วน Interconnect สำคัญเมื่อโมเดลหรือ Batch กระจายหลาย GPU แต่ Bandwidth สูงจะไม่มีประโยชน์หาก Software ไม่ใช้เส้นทางนั้นอย่างมีประสิทธิภาพ

นี่คือเหตุผลที่สเปกควรถูกอ่านเป็นระบบ ตัวเลข VRAM, Memory Bandwidth, NVLink หรือ PCIe ไม่ใช่คะแนนรวม แต่เป็นคำตอบของข้อจำกัดคนละชนิด การซื้อเครื่องที่มี Compute สูงมากแต่ Storage และ Network ไม่สมดุลคล้ายสร้างครัวใหญ่ที่ประตูส่งวัตถุดิบแคบ เชฟเก่งเพียงใดก็ต้องยืนรอ

Compute บอกว่าคำนวณได้มากแค่ไหน แต่ชนิดตัวเลขมีผล

ผู้ผลิตมักแสดงสมรรถนะหลายรูปแบบ เช่น FP32, TF32, FP16, BF16, FP8 หรือ Integer แต่ตัวเลขเหล่านี้ใช้แทนกันไม่ได้ โมเดลและ Framework ต้องรองรับ Precision นั้น คุณภาพต้องยังผ่านเกณฑ์ และลักษณะงานต้องใช้หน่วยคำนวณได้จริง จึงไม่ควรนำค่าสูงสุดคนละ Precision มาเปรียบเหมือนเป็นคะแนนเดียว

การ Quantization ลดความละเอียดตัวเลขเพื่อประหยัดหน่วยความจำและเพิ่มความเร็วได้ แต่ต้องวัดคุณภาพกับงานจริง บางงานเสียคุณภาพน้อย บางงานไวต่อความเปลี่ยนแปลง และบาง Runtime รองรับเฉพาะรูปแบบจำกัด คำถามที่ถูกต้องคือ “การตั้งค่าใดให้ Outcome ผ่านด้วยต้นทุนต่ำสุด” ไม่ใช่ “รูปแบบใดเร็วที่สุดในตาราง”

Utilization บอกว่าเครื่องแพงถูกใช้งานจริงหรือไม่

GPU Utilization ต่ำไม่ได้แปลว่า GPU เสีย อาจหมายถึงระบบรอข้อมูล Batch เล็กเกิน มี Preprocessing บน CPU มาก หรือจำนวนคำขอไม่พอ บางทีมซื้อเครื่องเพื่อรองรับพีกแต่เวลาส่วนใหญ่ไม่มีงาน หากภาระงานเป็นช่วง ๆ Cloud หรือคิวรวมอาจคุ้มกว่าเครื่องเฉพาะ หากข้อมูลอ่อนไหวและงานสม่ำเสมอ ระบบภายในอาจได้เปรียบ การตัดสินใจนี้ต้องใช้ข้อมูลการใช้งาน ไม่ใช่ความรู้สึก

อ่านสเปก GPU อย่างไรโดยไม่หลงกับตัวเลขที่ใหญ่ที่สุด

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

ภาพ Grace Hopper ด้านล่างช่วยให้เห็นสิ่งที่ตารางสเปกมักซ่อนอยู่ ชิปไม่ได้ลอยเดี่ยว มันอยู่บนบอร์ด เชื่อมกับหน่วยความจำ ระบบระบายความร้อน Power, Storage และ Network ในข่าวของ NASA เมื่อเดือนมีนาคม 2025 การเพิ่ม Grace Hopper ให้ Cabeus เกิดหลังทีมทดสอบ Portability และ Benchmark งานจริงก่อนการจัดซื้อครั้งใหญ่ นี่เป็นลำดับที่ควรเรียนรู้: ทดลองโค้ดและข้อมูลของตนเอง แล้วค่อยขยายฮาร์ดแวร์

เอกสาร NVIDIA DGX H100/H200 User Guide แสดงตัวอย่างว่าระบบหลาย GPU ต้องคิดรวมหน่วยความจำทั้งหมด การเชื่อมต่อระหว่าง GPU, Storage, Network, CPU และพลังงาน ตัวเลขระดับระบบมีความหมายต่อเมื่อ Software กระจายงานได้และ Workload ต้องการ Scale นั้น การนำสเปกของระบบศูนย์ข้อมูลมาใช้เป็นเป้าหมายสำหรับ Pilot เล็กโดยไม่วัดจึงอาจสร้างทั้งค่าใช้จ่ายและความซับซ้อนที่ไม่จำเป็น

Cloud, เครื่องภายใน หรือ Hybrid ไม่มีคำตอบเดียว

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

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

ซื้อ สร้าง หรือเช่าบริการ ต้องคิดถึง Exit ตั้งแต่ต้น

หากใช้ API ภายนอก ให้ทดสอบการ Export ข้อมูล Log และ Prompt, ข้อจำกัด Rate Limit, เวอร์ชันโมเดล การเปลี่ยนราคา และเงื่อนไขการเก็บข้อมูล หากสร้างเอง ให้ประเมินคนที่ต้องดูแล Model Serving, Patch, Security และ Incident หากซื้อโซลูชันสำเร็จรูป ให้ตรวจว่าผู้ขายอธิบายขอบเขต ข้อมูล และการทดสอบได้หรือไม่

Exit Plan ไม่ได้หมายความว่าต้องย้ายออก แต่ช่วยให้เห็นว่าการตัดสินใจย้อนกลับยากเพียงใด ทีมควรรู้ว่าจะปิดระบบอย่างไร ส่งงานกลับ Manual ได้หรือไม่ เก็บหลักฐานอะไร และย้ายข้อมูลไปทางเลือกอื่นอย่างไร ระบบที่พิสูจน์คุณค่าได้แต่ถอนตัวไม่ได้ยังมีความเสี่ยงเชิงกลยุทธ์

สามกรณีศึกษา: กรอบเดียวกันให้คำตอบฮาร์ดแวร์ต่างกัน

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

กรณีที่ 1: ระบบช่วยคัดแยกคำร้องลูกค้า

Decision: เสนอหมวดและลำดับความเร่งด่วนให้เจ้าหน้าที่ ไม่ตัดสินปิดเคสเอง Rule vs AI: กฎดักเหตุฉุกเฉินและเงื่อนไขตามนโยบาย ส่วนโมเดลช่วยจัดหมวดภาษาที่หลากหลาย Human: เจ้าหน้าที่แก้หมวด ส่งต่อ และระบุเหตุผลได้ Value: ลดเวลารอโดย Recall ของกรณีสำคัญไม่ลด Hardware: เริ่มจากโมเดลเล็กบนทรัพยากรเดิมหรือ Cloud แล้ววัดปริมาณข้อความจริง

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

Metric ที่ควรเก็บ ได้แก่ เวลาเฉลี่ยและเปอร์เซ็นไทล์สูง จำนวนเคสต่อชั่วโมง Recall ของหมวดเสี่ยง อัตรา Override เวลาตรวจ และ Cost per Case ต้องแยกตามภาษา ช่องทาง และประเภทลูกค้า เพราะค่าเฉลี่ยรวมอาจซ่อนกลุ่มที่ระบบทำงานไม่ดี

กรณีที่ 2: ผู้ช่วยค้นนโยบายภายในองค์กร

Decision: ช่วยพนักงานค้นคำตอบพร้อมหลักฐาน ไม่อนุมัติสิทธิ์หรือข้อยกเว้น Rule vs AI: กฎคุมสิทธิ์และเวอร์ชันเอกสาร Retrieval ค้นเนื้อหา โมเดลสรุปเป็นภาษาธรรมชาติ Human: เจ้าของนโยบายรับคำถามที่หลักฐานไม่พอและแก้เอกสารต้นทาง Value: ลดเวลาค้นโดยไม่เพิ่มคำตอบที่อ้างอิงผิด Hardware: แยกวัดเวลา Search, Rerank และ Generation

โครงการนี้มักหลงซื้อโมเดลใหญ่เพื่อให้คำตอบดูดี ทั้งที่ปัญหาจริงคือเอกสารซ้ำ ชื่อไฟล์ไม่สื่อความหมาย สิทธิ์ไม่ตรง หรือไม่มีเจ้าของเวอร์ชัน โมเดลที่เก่งขึ้นไม่สามารถสร้าง Source of Truth ที่องค์กรยังไม่มี หาก Retrieval ส่งเอกสารผิด คำตอบที่เขียนสวยยิ่งทำให้ความผิดน่าเชื่อถือขึ้น

Pilot ควรสร้างชุดคำถามจากงานจริง ครอบคลุมคำถามที่ตอบได้ ตอบไม่ได้ เอกสารขัดกัน และข้อมูลที่ผู้ถามไม่มีสิทธิ์ วัด Citation correctness, Answer groundedness, อัตราปฏิเสธที่เหมาะสม และเวลาที่เจ้าของนโยบายใช้ตรวจ ฮาร์ดแวร์จึงถูกเลือกหลังเห็นสัดส่วนเวลาของแต่ละขั้น

กรณีที่ 3: ตรวจตำหนิจากภาพในสายการผลิต

Decision: แจ้งเตือนชิ้นงานที่ควรตรวจซ้ำ ไม่ทิ้งสินค้าทันที Rule vs AI: Sensor และกฎตรวจค่ากายภาพชัดเจน ส่วน Vision Model จับรูปแบบตำหนิที่หลากหลาย Human: ผู้ตรวจยืนยันชนิดตำหนิและหยุดสายการผลิตเมื่อมีความเสี่ยง Value: ลดของเสียและเวลาตรวจโดยไม่เพิ่ม False Negative เกินเกณฑ์ Hardware: Latency ใกล้กล้องและปริมาณภาพอาจทำให้ Edge GPU เหมาะกว่า Cloud

กรณีนี้ต่างจากงานข้อความ เพราะข้อมูลภาพมีขนาดใหญ่และต้องตอบทันจังหวะสายการผลิต Network ไป Cloud อาจเพิ่ม Latency และความเสี่ยงเมื่อการเชื่อมต่อขาด แต่การติด GPU ทุกจุดก็เพิ่มต้นทุนดูแล ทีมควรวัด Frame Rate, Resolution, Preprocessing, Model Latency, จำนวนกล้อง และความสามารถในการ Buffer เมื่อระบบช้า

การทดสอบต้องรวมสภาพแสง ฝุ่น มุมกล้อง รุ่นสินค้า และตำหนิหายาก ไม่ใช่ภาพคัดสะอาดจากวันเดียว หาก Distribution เปลี่ยนหลังเปลี่ยนวัตถุดิบหรือกล้อง ระบบต้องมี Monitoring และแผน Revalidation นี่คือตัวอย่างที่ฮาร์ดแวร์สัมพันธ์กับบริบทหน้างานอย่างชัดเจน แต่ยังต้องเริ่มจาก Outcome และความเสียหายก่อน

ออกแบบ Pilot ให้ตอบคำถาม ไม่ใช่ทำ Demo ให้ดูน่าประทับใจ

Demo แสดงว่าสิ่งหนึ่งทำได้ภายใต้เงื่อนไขที่เลือก ส่วน Pilot ต้องบอกว่าสิ่งนั้นเหมาะกับระบบจริงหรือไม่ ความต่างอยู่ที่การตั้งสมมติฐาน กลุ่มข้อมูล เงื่อนไขโหลด Baseline และเกณฑ์หยุด Pilot ที่ดีไม่ต้องใหญ่ แต่ต้องทำให้การตัดสินใจครั้งถัดไปมีหลักฐานมากขึ้น

ขั้นที่ 1 เขียนสมมติฐานที่ล้มได้

ตัวอย่าง “ระบบช่วยจัดหมวดจะลดเวลารวมต่อเคสอย่างน้อย 20% โดย Recall ของกรณีความเสี่ยงสูงไม่ต่ำกว่า Baseline และภาระตรวจเฉลี่ยไม่เกินหนึ่งนาที” ประโยคนี้ดีกว่า “ทดสอบว่า AI ใช้ได้หรือไม่” เพราะระบุสิ่งที่ต้องวัดและเปิดโอกาสให้ผลไม่ผ่าน

ขั้นที่ 2 ล็อก Baseline และชุดทดสอบก่อนปรับโมเดล

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

ขั้นที่ 3 เริ่มด้วยทางเลือกที่ง่ายที่สุด

ลองกฎ การค้นคำ โมเดลเล็ก หรือบริการที่มีอยู่ก่อน เพื่อสร้าง Baseline ทางเทคนิค หากวิธีง่ายผ่าน Outcome ไม่มีเหตุผลต้องเพิ่มโมเดลใหญ่ หากไม่ผ่าน ให้ใช้ข้อผิดพลาดระบุว่าความซับซ้อนใหม่แก้ปัญหาใด วิธีนี้สอดคล้องกับคำแนะนำของ Google ที่ให้เริ่มจาก Pipeline ที่เชื่อถือได้และโมเดลง่าย

ขั้นที่ 4 วัดทั้งคุณภาพ ระบบ คน และต้นทุนในรอบเดียวกัน

Dashboard ของ Pilot ควรมีอย่างน้อยสี่กลุ่ม Metric กลุ่มแรกคือคุณภาพผลลัพธ์ กลุ่มสองคือ Latency, Throughput, Error Rate และ Resource Use กลุ่มสามคือเวลา Override และภาระของคน กลุ่มสี่คือ Cost per Case และ Incident อย่าเก็บคนละช่วงเพราะจะเชื่อมเหตุและผลยาก

ขั้นที่ 5 ทดสอบภายใต้โหลดและ Failure Mode

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

ขั้นที่ 6 ให้กลุ่มใช้งานจริงทดลองภายใต้ขอบเขตปลอดภัย

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

ขั้นที่ 7 ตัดสินใจด้วยเกณฑ์เดิม

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

สัญญาณเตือนว่าโครงการกำลังวิ่งนำปัญหา

อีกสัญญาณหนึ่งคือการอ้าง Accuracy ค่าเดียวโดยไม่บอก Distribution, Test Set และ Error Cost ค่ารวม 95% อาจซ่อนว่าระบบพลาดครึ่งหนึ่งของกลุ่มที่สำคัญ หรือดีเพียงกับข้อมูลจากสาขาที่ใช้สร้างโมเดล SHIRO จะถามเสมอว่า “วัดในเงื่อนไขเดียวกับโลกจริงหรือไม่ และข้อผิดพลาดชนิดใดเปลี่ยนการตัดสินใจ”

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

Checklist ก่อนอนุมัติ Pilot และก่อนอนุมัติซื้อฮาร์ดแวร์

Checklist นี้ไม่ควรถูกใช้เป็นพิธีเซ็นเอกสาร ทุกข้อควรมีหลักฐาน เจ้าของ และวันที่ทบทวน หากข้อใดตอบว่า “ยังไม่รู้” ให้ระบุว่าต้องทดลองอย่างไร แทนการเดาคำตอบให้ครบ

1. เขียน Actor, Decision, Input, Constraint, Outcome และ Harm เป็นเรื่องเดียวกันได้
2. แยกผู้ใช้ ผู้ตัดสินใจ ผู้ได้รับผล และเจ้าของความเสี่ยงชัดเจน
3. มีเหตุผลว่าทำไมกฎ Software เดิม หรือการปรับ Workflow จึงยังไม่พอ
4. กำหนดส่วนที่ต้องแน่นอน ส่วนที่ให้ AI ประมาณ และส่วนที่ต้องให้คนตัดสิน
5. ผู้ตรวจเห็นหลักฐาน ความไม่แน่นอน และข้อจำกัดที่จำเป็นต่อการตัดสินใจ
6. ผู้ตรวจมีเวลา สิทธิ์ Override, Escalate, หยุด และบันทึกเหตุผล
7. ผู้ได้รับผลมีช่องทางแก้ไขหรืออุทธรณ์เมื่อบริบทของงานต้องการ
8. Baseline และ Pilot ใช้วิธีวัด ช่วงเวลา และกลุ่มข้อมูลที่เปรียบเทียบกันได้
9. Metric ของโมเดลเชื่อมกับ Outcome งานจริง ไม่ได้รายงานแยกจากกัน
10. ชุดทดสอบมีกรณีปกติ กรณีขอบเขต กลุ่มสำคัญ และเหตุการณ์เสียหายสูง
11. แยก False Positive กับ False Negative และคำนวณต้นทุนต่างกัน
12. วัดเวลา Review, Override, Escalation และงานแก้ซ้ำของมนุษย์
13. TCO รวมข้อมูล Integration, Security, Monitoring, Incident, Training และ Exit
14. กำหนด Go/No-Go, Stop Rule และ Rollback ก่อนเริ่ม Pilot
15. วาด Data Path ตั้งแต่ Input, Storage, Network, CPU/GPU ถึงผู้ใช้ครบ
16. รู้ Working Set, Context, Batch, Concurrency และ Peak Load ที่ต้องรองรับ
17. วัด Latency แบบ End-to-end ไม่ใช่เฉพาะเวลารันโมเดล
18. ใช้ Profiler หรือ Telemetry ระบุคอขวด แทนการเดาจาก Utilization ค่าเดียว
19. เปรียบเทียบ CPU, GPU, Cloud และโมเดลเล็กด้วย Outcome และ Cost per Case
20. ทดสอบ Failure Mode เช่นข้อมูลหาย Network ช้า โมเดลล่ม และ Provider ไม่พร้อม
21. ระบบล้มอย่างปลอดภัยและกลับสู่ Manual Workflow ได้
22. มีเจ้าของข้อมูล โมเดล Application, Monitoring, Security และ Incident
23. บันทึกเวอร์ชัน Dataset, Prompt, Model, Runtime และการตั้งค่าที่ใช้ทดสอบ
24. กำหนดรอบ Revalidation เมื่อข้อมูล นโยบาย ผู้ใช้ หรือโมเดลเปลี่ยน
25. ตรวจสิทธิ์ข้อมูล ความเป็นส่วนตัว สัญญา และข้อกำกับที่เกี่ยวข้องแล้ว
26. ผู้มีส่วนได้เสียที่ได้รับผลได้รับฟัง ไม่ใช่มีเฉพาะทีมพัฒนาและผู้ซื้อ
27. มี Exit Plan สำหรับข้อมูล Workflow และสัญญาผู้ให้บริการ
28. ฮาร์ดแวร์ที่เสนอผูกกับค่าที่วัดได้ ไม่ใช่เพียงเผื่ออนาคตแบบไม่มีขอบเขต
29. แผนขยายระบบระบุ Trigger เช่นผู้ใช้ ปริมาณงาน หรือ Latency ไม่ใช่วันที่ตามปฏิทินอย่างเดียว
30. ผู้อนุมัติสามารถอธิบายได้ว่าเหตุใดการไม่ทำ การทำแบบง่าย และทางเลือก AI ต่างกันอย่างไร

สรุป: ซื้อเครื่องเมื่อรู้แล้วว่าระบบต้องพิสูจน์อะไร

กลับมาที่ห้องประชุมเช้าวันจันทร์ คราวนี้คำถามแรกไม่ใช่ “จะซื้อ GPU รุ่นใด” แต่คือ “การตัดสินใจใดต้องดีขึ้น ใครได้รับผล และเราจะรู้ได้อย่างไรว่าดีขึ้นจริง” เมื่อทีมตอบคำถามนี้ได้ การคุยเรื่องกฎหรือ AI บทบาทมนุษย์ ข้อมูล Pilot และฮาร์ดแวร์จะต่อกันเป็นเส้นเดียว แทนที่จะเป็นรายการเทคโนโลยีที่แต่ละฝ่ายมองคนละทิศ

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