Lightning เปิดให้ใช้งานในรูปแบบ BF16 และ NVFP4 ขณะที่ข้อมูลทางเทคนิคระบุถึงสถาปัตยกรรมแบบไฮบริดที่ผสานการประมวลผลสไตล์ State Space หรือ Mamba เข้ากับ Attention และระบบ Routed Experts การออกแบบนี้ต้องการรักษาความจุของโมเดลขนาดใหญ่ไว้ โดยไม่ต้องเปิดใช้งานเครือข่ายทั้งหมดกับทุกโทเคน

ตัวเลข “30B” และ “3B active” จึงหมายถึงคนละเรื่องกัน

• 30B พารามิเตอร์รวม: กลุ่มพารามิเตอร์ที่โมเดลเรียนรู้ไว้ทั้งหมด
• ประมาณ 3B พารามิเตอร์ที่ทำงาน: ส่วนที่ถูกเรียกใช้ในแต่ละขั้นตอนของการสร้างโทเคน

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

ทำไมจึงเหมาะกับ “execution layer”

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

รูปแบบที่ Lightning เหมาะจะรับผิดชอบ ได้แก่

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

โครงสร้างการทำงานแบบสองระดับอาจเป็นดังนี้

1. โมเดลเหตุผลขนาดใหญ่ตีความเป้าหมายและสร้างแผน
2. Lightning ดำเนินขั้นตอนประจำกับเครื่องมือ เอกสาร หรือข้อมูลแบบมีโครงสร้าง
3. ระบบเรียกโมเดลขนาดใหญ่อีกครั้งเมื่อพบความไม่แน่นอน ข้อยกเว้น หรือการตัดสินใจที่ต้องใช้เหตุผลซับซ้อน

NVIDIA วาง Nemotron 3 Ultra ซึ่งเป็นโมเดล MoE ที่มีพารามิเตอร์รวม 550B และพารามิเตอร์ที่ทำงาน 55B ไว้สำหรับการใช้เหตุผลระดับแนวหน้าและการควบคุมลำดับงานของ Agent เมื่อเทียบกันแล้ว Lightning จึงมีบทบาทเป็นชั้นประมวลผลความถี่สูง ไม่ใช่ผู้ควบคุมงานทั้งหมด

NeMo Switchyard ช่วยเลือกโมเดลให้เหมาะกับแต่ละงาน

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

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

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

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

บริบทขนาดใหญ่และทางเลือกในการติดตั้ง

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

ไฟล์ NVFP4 ถูกจัดทำขึ้นสำหรับการนำไปใช้งานด้าน Inference และอาศัยเคอร์เนลเฉพาะของ NVIDIA บน GPU รุ่นที่รองรับ โดย NVIDIA ระบุช่องทางการติดตั้งตั้งแต่โครงสร้างพื้นฐานภายในองค์กร เวิร์กสเตชัน ดาต้าเซ็นเตอร์ ไปจนถึงระบบคลาวด์ นอกจากนี้ยังมีโมเดลผ่าน Hugging Face และบริการโฮสต์ต่าง ๆ

สำหรับผู้ใช้ AWS โมเดลดังกล่าวมีให้ใช้งานผ่าน Amazon SageMaker JumpStart ซึ่งสามารถติดตั้งจากคอนโซล SageMaker หรือใช้ Python SDK ได้ ส่วนเอกสาร NVIDIA NIM มีแนวทางติดตั้งแบบคอนเทนเนอร์แยกต่างหาก และระบุข้อกำหนดด้านระบบปฏิบัติการ CUDA ไดรเวอร์ และ Docker ไว้อย่างชัดเจน

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

ตัวเลขความเร็วต้องอ่านควบคู่กับเงื่อนไขการทดสอบ

NVIDIA และ AWS ระบุว่า Lightning อาจให้ Throughput สูงขึ้นได้ถึง 4 เท่า และทำให้การทำงานเสร็จเร็วขึ้นสูงสุด 30% สำหรับเวิร์กโหลดของ Agent ที่อยู่ในกลุ่มเป้าหมาย

ตัวเลขดังกล่าวไม่ใช่การวัดความฉลาดของโมเดลในทุกสถานการณ์ และไม่ใช่การรับประกันประสิทธิภาพในการใช้งานจริง เพราะผลลัพธ์อาจเปลี่ยนไปตามปัจจัยต่าง ๆ เช่น

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

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

ราคาโฮสต์ขึ้นอยู่กับผู้ให้บริการ

การให้บริการผ่าน API อาจทำให้ Lightning น่าสนใจสำหรับงาน Inference ปริมาณมาก โดย DeepInfra ระบุราคาไว้ที่ 0.05 ดอลลาร์สหรัฐต่อโทเคนขาเข้า 1 ล้านโทเคน และ 0.20 ดอลลาร์สหรัฐต่อโทเคนขาออก 1 ล้านโทเคน เป็นการคิดค่าบริการตามการใช้งานโดยไม่ต้องบริหาร GPU เอง

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

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

สรุป: โมเดลทำงานเร็ว ไม่ใช่โมเดลคิดแทนทุกอย่าง

Nemotron 3.5 Lightning เหมาะกับการเป็น โมเดลผู้ปฏิบัติงานที่เร็วและปรับแต่งได้ สำหรับระบบ AI Agent โดยเฉพาะแอปพลิเคชันที่ต้องสร้างคำขอจำนวนมากซึ่งมีรูปแบบคล้ายกัน และสามารถกำหนดขอบเขตงานหรือฝึกต่อให้เหมาะกับโดเมนเฉพาะได้

จุดเด่นของโมเดลคือพารามิเตอร์รวม 30B แต่เปิดใช้งานราว 3B ต่อขั้นตอน สถาปัตยกรรมแบบไฮบริด วัสดุโมเดลแบบเปิด ตัวเลือกการประมวลผล NVFP4 บริบทขนาดใหญ่ และช่องทางติดตั้งที่ครอบคลุมทั้งระบบภายในองค์กรและคลาวด์

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

บทสรุปเชิงปฏิบัติจึงค่อนข้างชัดเจน: Lightning มีเหตุผลที่สุดเมื่อถูกวางไว้เป็น Execution Tier ที่ตอบสนองเร็วในระบบ Agent แบบหลายโมเดล ให้โมเดลใหญ่คิดและตัดสินใจในจุดสำคัญ ขณะที่ Lightning รับงานประจำที่ต้องทำซ้ำจำนวนมาก ความเร็วและต้นทุนที่ NVIDIA ระบุไว้น่าสนใจ แต่ควรทดสอบกับเวิร์กโฟลว์จริงก่อนนำผลไปสรุปเป็นประสิทธิภาพระดับ Production

Lightning เปิดให้ใช้งานในรูปแบบ BF16 และ NVFP4 ขณะที่ข้อมูลทางเทคนิคระบุถึงสถาปัตยกรรมแบบไฮบริดที่ผสานการประมวลผลสไตล์ State Space หรือ Mamba เข้ากับ Attention และระบบ Routed Experts การออกแบบนี้ต้องการรักษาความจุของโมเดลขนาดใหญ่ไว้ โดยไม่ต้องเปิดใช้งานเครือข่ายทั้งหมดกับทุกโทเคน

ตัวเลข “30B” และ “3B active” จึงหมายถึงคนละเรื่องกัน

• 30B พารามิเตอร์รวม: กลุ่มพารามิเตอร์ที่โมเดลเรียนรู้ไว้ทั้งหมด
• ประมาณ 3B พารามิเตอร์ที่ทำงาน: ส่วนที่ถูกเรียกใช้ในแต่ละขั้นตอนของการสร้างโทเคน

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

ทำไมจึงเหมาะกับ “execution layer”

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

รูปแบบที่ Lightning เหมาะจะรับผิดชอบ ได้แก่

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

โครงสร้างการทำงานแบบสองระดับอาจเป็นดังนี้

1. โมเดลเหตุผลขนาดใหญ่ตีความเป้าหมายและสร้างแผน
2. Lightning ดำเนินขั้นตอนประจำกับเครื่องมือ เอกสาร หรือข้อมูลแบบมีโครงสร้าง
3. ระบบเรียกโมเดลขนาดใหญ่อีกครั้งเมื่อพบความไม่แน่นอน ข้อยกเว้น หรือการตัดสินใจที่ต้องใช้เหตุผลซับซ้อน

NVIDIA วาง Nemotron 3 Ultra ซึ่งเป็นโมเดล MoE ที่มีพารามิเตอร์รวม 550B และพารามิเตอร์ที่ทำงาน 55B ไว้สำหรับการใช้เหตุผลระดับแนวหน้าและการควบคุมลำดับงานของ Agent เมื่อเทียบกันแล้ว Lightning จึงมีบทบาทเป็นชั้นประมวลผลความถี่สูง ไม่ใช่ผู้ควบคุมงานทั้งหมด

NeMo Switchyard ช่วยเลือกโมเดลให้เหมาะกับแต่ละงาน

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

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

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

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

บริบทขนาดใหญ่และทางเลือกในการติดตั้ง

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

ไฟล์ NVFP4 ถูกจัดทำขึ้นสำหรับการนำไปใช้งานด้าน Inference และอาศัยเคอร์เนลเฉพาะของ NVIDIA บน GPU รุ่นที่รองรับ โดย NVIDIA ระบุช่องทางการติดตั้งตั้งแต่โครงสร้างพื้นฐานภายในองค์กร เวิร์กสเตชัน ดาต้าเซ็นเตอร์ ไปจนถึงระบบคลาวด์ นอกจากนี้ยังมีโมเดลผ่าน Hugging Face และบริการโฮสต์ต่าง ๆ

สำหรับผู้ใช้ AWS โมเดลดังกล่าวมีให้ใช้งานผ่าน Amazon SageMaker JumpStart ซึ่งสามารถติดตั้งจากคอนโซล SageMaker หรือใช้ Python SDK ได้ ส่วนเอกสาร NVIDIA NIM มีแนวทางติดตั้งแบบคอนเทนเนอร์แยกต่างหาก และระบุข้อกำหนดด้านระบบปฏิบัติการ CUDA ไดรเวอร์ และ Docker ไว้อย่างชัดเจน

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

ตัวเลขความเร็วต้องอ่านควบคู่กับเงื่อนไขการทดสอบ

NVIDIA และ AWS ระบุว่า Lightning อาจให้ Throughput สูงขึ้นได้ถึง 4 เท่า และทำให้การทำงานเสร็จเร็วขึ้นสูงสุด 30% สำหรับเวิร์กโหลดของ Agent ที่อยู่ในกลุ่มเป้าหมาย

ตัวเลขดังกล่าวไม่ใช่การวัดความฉลาดของโมเดลในทุกสถานการณ์ และไม่ใช่การรับประกันประสิทธิภาพในการใช้งานจริง เพราะผลลัพธ์อาจเปลี่ยนไปตามปัจจัยต่าง ๆ เช่น

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

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

ราคาโฮสต์ขึ้นอยู่กับผู้ให้บริการ

การให้บริการผ่าน API อาจทำให้ Lightning น่าสนใจสำหรับงาน Inference ปริมาณมาก โดย DeepInfra ระบุราคาไว้ที่ 0.05 ดอลลาร์สหรัฐต่อโทเคนขาเข้า 1 ล้านโทเคน และ 0.20 ดอลลาร์สหรัฐต่อโทเคนขาออก 1 ล้านโทเคน เป็นการคิดค่าบริการตามการใช้งานโดยไม่ต้องบริหาร GPU เอง

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

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

สรุป: โมเดลทำงานเร็ว ไม่ใช่โมเดลคิดแทนทุกอย่าง

Nemotron 3.5 Lightning เหมาะกับการเป็น โมเดลผู้ปฏิบัติงานที่เร็วและปรับแต่งได้ สำหรับระบบ AI Agent โดยเฉพาะแอปพลิเคชันที่ต้องสร้างคำขอจำนวนมากซึ่งมีรูปแบบคล้ายกัน และสามารถกำหนดขอบเขตงานหรือฝึกต่อให้เหมาะกับโดเมนเฉพาะได้

จุดเด่นของโมเดลคือพารามิเตอร์รวม 30B แต่เปิดใช้งานราว 3B ต่อขั้นตอน สถาปัตยกรรมแบบไฮบริด วัสดุโมเดลแบบเปิด ตัวเลือกการประมวลผล NVFP4 บริบทขนาดใหญ่ และช่องทางติดตั้งที่ครอบคลุมทั้งระบบภายในองค์กรและคลาวด์

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

บทสรุปเชิงปฏิบัติจึงค่อนข้างชัดเจน: Lightning มีเหตุผลที่สุดเมื่อถูกวางไว้เป็น Execution Tier ที่ตอบสนองเร็วในระบบ Agent แบบหลายโมเดล ให้โมเดลใหญ่คิดและตัดสินใจในจุดสำคัญ ขณะที่ Lightning รับงานประจำที่ต้องทำซ้ำจำนวนมาก ความเร็วและต้นทุนที่ NVIDIA ระบุไว้น่าสนใจ แต่ควรทดสอบกับเวิร์กโฟลว์จริงก่อนนำผลไปสรุปเป็นประสิทธิภาพระดับ Production