Agent ทำงานบนเครื่องหรือบนคลาวด์? อ่าน AgBench ผ่านงานสำเร็จและต้นทุนรวม

HYBRID MIND | Business Explainer ระดับ 2

Agent ทำงานบนเครื่องหรือบนคลาวด์? อ่าน AgBench ผ่านงานสำเร็จและต้นทุนรวม

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

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

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

ตำแหน่งที่โมเดลคิด เปลี่ยนทั้งผู้จ่ายและงานที่ทำสำเร็จ

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

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

1. LO — Local-Only: โมเดลในเครื่องเป็นผู้คิดและจัดการลำดับงาน พร้อมเรียกใช้เครื่องมือในเครื่อง
2. CO — Cloud inference: โมเดลคลาวด์ทำหน้าที่อนุมาน ส่วนการทำงานของเครื่องมือยังอยู่บนอุปกรณ์
3. HCL — Cloud-led: โมเดลคลาวด์เป็นผู้นำและมอบหมายงานให้การประมวลผลในเครื่องตามการออกแบบการทดลอง
4. HLL — Local-led, cloud-assisted: โมเดลในเครื่องเป็นผู้นำและปรึกษาโมเดลคลาวด์ในบางช่วง

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

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

สิ่งที่ AgBench วัดได้ และสิ่งที่ยังสรุปแทนธุรกิจไม่ได้

REPORTED_RESEARCH_RESULT: ผู้เขียนทดสอบ 60 งานใน 8 หมวด บน 2 อุปกรณ์ ด้วย 4 สถาปัตยกรรมและ concurrency 4 ระดับ รวม 32 การกำหนดค่า และการรันงานหลัก 1,920 ครั้ง ตัวเลข 162.07 ล้านในบทความหมายถึงระเบียนดิบจากการรันและการวัด ไม่ใช่จำนวนงานอิสระ 162 ล้านงาน และไม่ใช่จำนวนบริษัทหรือผู้ใช้

ตัวอย่างที่อ่านได้ตรงไปตรงมาคือผลบน RTX 5090 ที่ concurrency 1: LO สำเร็จ 35 จาก 60 งาน, CO 50, HCL 39 และ HLL 44 เมื่อเพิ่ม concurrency เป็น 8 ผู้วิจัยรายงาน LO 12 จาก 60 และ CO 48 จาก 60 จำนวนสำเร็จเหล่านี้เป็นผลในชุดทดสอบ ไม่ใช่อัตราสำเร็จที่รับประกันกับงานของผู้อ่าน เมทริกซ์ชุดหลักรันหนึ่งรอบ; การทำซ้ำที่มีจำกัดบน RTX 5090 ที่ concurrency 1 และ 8 พบว่าจำนวนงานสำเร็จแกว่งได้ถึง 6 จาก 60

ความเร็วเป็นอีกมิติหนึ่ง: การจบชุดงานเร็วขึ้นไม่ได้แปลว่าสัดส่วนงานที่ผ่านเกณฑ์สูงขึ้น หากนับงานสำเร็จต่อชั่วโมง อัตราที่คำนวณจากตารางของผู้เขียนสำหรับ LO เพิ่มจากประมาณ 2.10 ที่ concurrency 1 เป็น 4.58 ที่ concurrency 8 (35÷16.66 และ 12÷2.62 งานต่อชั่วโมง) แต่ต้องอ่านคู่กับจำนวนงานสำเร็จที่ลดจาก 35 เป็น 12 จากชุด 60 งานเดิม จึงควรวัดทั้ง goodput และอัตราผ่าน ไม่ใช้เวลา batch สั้นเป็นตัวแทนคุณภาพ

อุปกรณ์ที่ทดสอบเป็น RTX 5090 เดสก์ท็อป VRAM 32 GB และ Max+ 395 ที่มี unified memory 128 GB โดยจัดสรร GPU 96 GB ไม่ใช่ตัวแทนของโน้ตบุ๊กสำนักงานทั่วไป ที่สำคัญ โมเดลในเครื่องคือ Qwen3.8-27B 6-bit ส่วนฝั่งคลาวด์คือ DeepSeek V4 Flash ที่ตั้ง reasoning effort ระดับ high พร้อมข้อจำกัด context และ output ต่างกัน จึงแยกผลของ “ตำแหน่งประมวลผล” ออกจาก “ตัวโมเดลและขีดจำกัด” ไม่ได้อย่างสะอาด

ผลทั้งหมดในส่วนนี้ติดป้าย REPORTED_RESEARCH_RESULT หมายถึงผลที่ผู้เขียนรายงาน ไม่ใช่การทำซ้ำโดย HYBRID MIND หรืองานทดลองในกิจการไทย

ตลาดและการพึ่งพาไม่ได้หายไปเมื่อย้ายโมเดล

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

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

หากอยากอ่านประเด็นประกอบ ดู การรันโมเดลเอเจนต์ในเครื่องและเงื่อนไขที่ควรอ่าน และ ต้นทุน sandbox ที่ยังเกิดแม้ระบบว่าง

แยกค่า API ออกจากต้นทุนต่อผลสำเร็จ

ต้นทุน API ที่บทความ AgBench ประเมินครอบคลุมรายการ input/output แบบ cached และ uncached ตามวิธีของงาน ไม่ใช่ต้นทุนรวมการเป็นเจ้าของระบบ (TCO) ตัวเลขดังกล่าวไม่รวมการวัดจริงของฮาร์ดแวร์ ค่าไฟ การติดตั้ง บำรุงรักษา หรือเวลาตรวจงาน และผลของรูปแบบ hybrid ก็ไม่ได้ต่ำกว่าทุกแบบ การใช้ราคาจากช่วงเวลาของบทความเป็นราคาปัจจุบันจึงไม่เหมาะสม

HYBRID MIND ANALYSIS: เพื่อเปรียบเทียบอย่างเป็นธรรม ให้กำหนดขอบเขตต้นทุนเดียวกันสำหรับแต่ละทางเลือก เช่น แรงงานตรวจและแก้งาน ค่าเครื่องและการจัดสรรอายุใช้งาน ค่าเชื่อมต่อและบำรุงรักษา ค่า API หรือพลังงานตามที่เกี่ยวข้อง แล้วหารด้วยจำนวนงานที่ผ่านเกณฑ์จริง ไม่ควรนับค่าใช้จ่ายคงที่ซ้ำในต้นทุนต่อครั้ง และไม่ควรตีความเวลาคนที่ลดลงเป็นเงินสดที่ประหยัดได้โดยอัตโนมัติ

SCENARIO_SIMULATION_NOT_PAPER_RESULT: Lab ที่จะฝังตรงนี้เป็นสถานการณ์จำลองรายเดือนในหน่วยบาทไทยสมมติ ไม่ใช่ราคาตลาด ไม่ใช่ข้อมูลจาก AgBench และไม่ใช่ผลลัพธ์ของกิจการใด สูตรคือ ต้นทุนรวม = F + N×k + N×r×w/60; จำนวนงานสำเร็จ = N×p/100; ต้นทุนต่อความสำเร็จ = ต้นทุนรวม ÷ จำนวนงานสำเร็จ โดยเมื่อ p เป็นศูนย์ ค่าต่อความสำเร็จไม่มีนิยาม

กำหนด N เป็นจำนวนครั้งที่พยายามต่อเดือน, p เป็นเปอร์เซ็นต์งานที่ตรวจแล้วว่าผ่าน, F เป็นต้นทุนคงที่รายเดือนที่เกี่ยวข้องรวมการปันส่วนค่าเสื่อม/ติดตั้ง/ดูแล, k เป็นต้นทุนเครื่องหรือ API แปรผันต่อครั้ง, r เป็นนาทีตรวจหรือแก้งานต่อครั้ง และ w เป็นค่าแรงที่จัดสรรต่อชั่วโมง ค่านี้เป็นต้นทุนทางเศรษฐศาสตร์ที่ใช้เทียบทางเลือก ไม่ใช่คำทำนายกระแสเงินสดหรือผลตอบแทน

ตัวอย่างค่าเริ่มต้นและชุด Conservative, Base, Optimistic ใน Lab เป็นสมมติฐานที่ปรับได้เท่านั้น ควรแทนด้วยบันทึกเวลางานและต้นทุนของตนเอง รวมทั้งระบุแหล่งข้อมูลและช่วงความไม่แน่นอนให้ชัด

สำหรับมุมมองแยกผลิตภาพ ต้นทุนรวม และ ROI อ่าน บทความเรื่องงานบริการลูกค้า SME ซึ่งเป็นคนละกรณีและไม่ใช่หลักฐานยืนยันผลจาก AgBench

เทียบมือ สคริปต์ AI ช่วยคน และเอเจนต์ด้วยเกณฑ์เดียวกัน

HYBRID MIND ANALYSIS: การเลือกควรเริ่มจากงานและเกณฑ์รับมอบ ไม่ใช่ตั้งสมมติฐานว่าเทคโนโลยีใหม่ต้องชนะทุกทางเลือก กำหนดชุดงานเดียวกัน ตัวอย่างข้อมูลเดียวกัน มาตรฐานคุณภาพเดียวกัน และนับเวลาตั้งแต่เริ่มจนได้ผลลัพธ์ที่ตรวจผ่าน รวมเวลาคนแก้ไขและการจัดการข้อผิดพลาดด้วย

• ทำด้วยมือ: ใช้เป็นเส้นฐานของคุณภาพ เวลา และต้นทุนแรงงาน รวมความแปรปรวนระหว่างผู้ปฏิบัติงาน
• สคริปต์กำหนดกฎ: เหมาะเป็นตัวเปรียบเทียบเมื่องานซ้ำและกติกาคงที่ บันทึกกรณีที่กฎครอบคลุมไม่ได้
• AI ช่วยคน: ให้คนตรวจและอนุมัติด้วยเกณฑ์เดียวกัน วัดทั้งเวลาที่ประหยัดและเวลาที่เพิ่มจากการตรวจ/แก้
• เอเจนต์: รวมการวางแผน เรียกเครื่องมือ และจัดการความล้มเหลวไว้ในการวัด นับเฉพาะงานที่ผ่านเกณฑ์ปลายทาง

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

ตัวชี้วัดข้อมูลที่ส่งให้โมเดล ไม่ใช่การตรวจเครือข่ายหรือใบรับรอง

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

บน RTX 5090 ที่ concurrency 1 งานรายงาน exposure ของ LO 0%, CO 76%, HCL 71% และ HLL 22% ตามนิยามของการศึกษา ค่า 0% ของ HLL ที่ concurrency 8 อาจเกิดจากงานล้มเหลวก่อนถึงขั้นส่งข้อมูล ไม่ควรตีความว่าเป็นการปกป้องข้อมูลได้สมบูรณ์ ส่วน LO หมายถึงไม่มีการอนุมานของโมเดลบนคลาวด์ในรูปแบบนั้น ไม่ได้แปลว่าออฟไลน์หรือไม่มีเครื่องมือภายนอก

สำหรับการประเมินของกิจการ ให้ทำรายการข้อมูลที่แต่ละขั้นอ่าน สร้าง และส่งออก ตรวจ log และการตั้งค่าจริง แยกข้อมูลระบุตัวบุคคล/ลูกค้าออกจากข้อมูลทดสอบเมื่อทำได้ กำหนดสิทธิ์ การเก็บรักษา และการลบตามนโยบายองค์กร การวัดเช่นนี้เป็นการตรวจสอบการไหลของข้อมูล ไม่ใช่ข้อพิสูจน์การปฏิบัติตาม PDPA และบทความนี้ไม่ใช่คำแนะนำทางกฎหมาย

ออกแบบ pilot แบบจำกัดขอบเขตก่อนพิจารณาใช้งานจริง

HYBRID MIND ANALYSIS: เริ่มด้วยการออกแบบการทดลองบนข้อมูลจำลองหรือข้อมูลที่ได้รับอนุญาตอย่างเหมาะสม โดยยังไม่ให้ระบบทำธุรกรรม ส่งข้อความหาลูกค้า หรือเปลี่ยนข้อมูลจริง

1. เลือกงานที่มีขอบเขตชัดและความเสี่ยงต่ำ ระบุเจ้าของงานและเกณฑ์ผ่านที่ตรวจได้
2. สร้างชุดตัวอย่างที่ครอบคลุมกรณีปกติ ข้อมูลขาด และกรณีผิดพลาด โดยเก็บข้อมูลอ่อนไหวให้น้อยที่สุด
3. เปรียบเทียบมือ สคริปต์ AI ช่วยคน และเอเจนต์ด้วยเกณฑ์คุณภาพและช่วงเวลาที่เท่ากัน
4. บันทึกความสำเร็จ เวลารวม เวลาตรวจ/แก้ ต้นทุนที่เกี่ยวข้อง และข้อมูลที่ต้องส่งออก พร้อมระบุว่าค่ามาจากการวัดหรือสมมติฐาน
5. กำหนดเงื่อนไขหยุดและจุดส่งต่อให้คนไว้ล่วงหน้า จากนั้นทบทวนผลและข้อผิดพลาดก่อนตัดสินใจว่าจะทดลองขั้นต่อไปหรือไม่

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

ข้อจำกัดที่ต้องถือไว้พร้อมกับตัวเลข

• เป็น preprint ที่ผู้เขียนรายงานเอง; การค้นหาที่กำหนดขอบเขตใน brief ไม่พบการทำซ้ำอิสระ และไม่ใช่การทดลองกำไรหรือธุรกิจ SME ไทย
• เมทริกซ์หลักรันหนึ่งรอบ การทำซ้ำมีจำกัดและผลสำเร็จแกว่งได้ถึง 6 ใน 60 งาน
• ทดสอบอุปกรณ์สองแบบที่มีกำลังสูง ไม่ใช่ตัวแทนอุปกรณ์สำนักงานทั่วไป
• โมเดล local และ cloud รวมทั้ง context/output limits ต่างกัน จึงสรุปเหตุเชิงสถาปัตยกรรมอย่างเดียวไม่ได้
• ไม่มีการวัด TCO จริงของฮาร์ดแวร์ ไฟฟ้า บำรุงรักษา และการตรวจงาน ไม่มี ROI หรือกระแสเงินสดของกิจการ
• ตัวเลข exposure เป็นเมตริกของการศึกษา ไม่ใช่การตรวจเครือข่าย การตรวจเหตุละเมิด หรือการรับรองความปลอดภัย/กฎหมาย

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

คำถามที่พบบ่อย

ถ้าใช้ local แล้วค่า API เป็นศูนย์ แปลว่าถูกที่สุดหรือไม่?

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

CO หมายถึงส่งเครื่องมือและข้อมูลทั้งหมดไปคลาวด์หรือไม่?

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

Goodput ต่างจากจำนวนงานที่ระบบเริ่มทำอย่างไร?

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

162.07 ล้านหมายถึงมีการทดลอง 162 ล้านงานหรือไม่?

ไม่ใช่ เป็นจำนวนระเบียนดิบจากการรันและการวัดตามที่ผู้เขียนรายงาน ชุดงานมี 60 งาน และการรันงานหลัก 1,920 ครั้งตามเมทริกซ์ที่อธิบายไว้

ผลจาก Lab ใช้แทนต้นทุนหรือ ROI ของบริษัทได้หรือไม่?

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

แหล่งอ้างอิง

• Yizhou Han, Di Wu, Dhananjay Saikumar และ Blesson Varghese, AgBench: Agentic AI Benchmarks for Personal AI Devices, preprint รุ่น v1, 29 กันยายน 2026. อ้างอิงตัวเลขผลที่ผู้เขียนรายงานและนิยามวิธีทดลองจากบทความต้นฉบับ
• หน้าระเบียน AgBench บน arXiv