LFM2.5-VL-3B-DSpark กับ UI-Venus 2.9B: ตัวคูณความเร็วเมื่อเทียบกับ GUI Agent

LFM2.5-VL-3B-DSpark และ UI-Venus 2.9B ถูกจัดเข้าหมวดหมู่กว้างๆ เดียวกัน — โมเดลวิชันขนาดเล็ก — แล้วนำมาเปรียบเทียบกัน ซึ่งเป็นความผิดพลาดเชิงหมวดหมู่ที่ควรแก้ก่อนที่มันจะทำให้ใครบางคนต้องเสียเวลาหนึ่งสัปดาห์ไปกับการผสานรวม LFM2.5-VL-3B-DSpark เป็นโมเดลดราฟต์ขนาด 279.5 ล้านพารามิเตอร์ที่เร่งความเร็วให้ LFM2.5-VL-3B ของ Liquid AI ส่วน UI-Venus 2.9B จากแล็บ inclusionAI ของ Ant Group เป็นเอเจนต์ GUI ขนาด 9B ที่อ่านภาพหน้าจอ ตัดสินใจเลือกการกระทำ และลงมือทำในสภาพแวดล้อมมือถือ เว็บ และเดสก์ท็อป ตัวหนึ่งทำให้โมเดลที่มีอยู่เร็วขึ้น อีกตัวคือสิ่งที่ทำงานจริง ถ้าสิ่งที่คุณต้องการคือเอเจนต์ GUI ตัวดราฟต์ไม่ใช่ตัวเลือกที่ถูกกว่า — มันไม่ใช่ตัวเลือกเลยด้วยซ้ำ

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

แต่ละสิ่งคืออะไรกันแน่

เริ่มจากรูปทรงก่อน เพราะมันอธิบายส่วนที่เหลือส่วนใหญ่ได้

• มันคืออะไร — LFM2.5-VL-3B-DSpark เป็นตัวร่างสำหรับการถอดรหัสแบบคาดการณ์ (speculative-decoding drafter); UI-Venus 2.9B เป็นนโยบายเอเจนต์ GUI เอนกประสงค์

• พารามิเตอร์ — 279.5M BF16 สำหรับดราฟเตอร์ เทียบกับ 9B สำหรับ UI-Venus 2.9B ที่เริ่มต้นจาก Qwen3.5-9B

• ความสามารถแบบเดี่ยว — ตัวร่างไม่ได้สร้างสิ่งใดที่ใช้งานได้ด้วยตัวเอง และไม่สามารถวัดประสิทธิภาพแบบแยกโดดเดี่ยวได้; UI-Venus 2.9B ทำงานเป็นเอเจนต์ที่สมบูรณ์

• อินพุต — ผู้ร่างไม่เห็นภาพเองเลย เห็นเพียงสถานะที่ซ่อนอยู่ของโมเดลเป้าหมาย; UI-Venus 2.9B รับภาพหน้าจอโดยตรง และถูกสร้างขึ้นทั้งหมดโดยอิงกับภาพเหล่านั้น

• เอาต์พุต — ดราฟเตอร์เสนอโทเคนเพื่อการตรวจสอบ; UI-Venus 2.9B ส่งการกระทำแบบ grounded พร้อมกรอบล้อมกับอินเทอร์เฟซแบบสด

• ฐาน — โมเดลร่างผูกกับ LiquidAI/LFM2.5-VL-3B ในเมทาดาทาของตัวเอง; UI-Venus 2.9B ต่อยอดจาก Qwen3.5-9B

• บริบท — โมเดลร่างจะสืบทอดทุกสิ่งที่โมเดลเป้าหมายให้มา; UI-Venus 2.9B ถูกให้บริการที่ขีดจำกัดสูงสุด 262,144 โทเคนตามสูตร vLLM ของผู้จำหน่ายเอง

• สัญญาอนุญาต — ทั้งสองยังไม่คลี่คลายในลักษณะที่แตกต่างกัน; Liquid เผยแพร่ภายใต้สัญญาอนุญาต LFM1.0 และการ์ดของ UI-Venus 2.9B ระบุตรง ๆ ว่าสัญญาอนุญาตน้ำหนักของโมเดลยังอยู่ระหว่างรอการยืนยันขั้นสุดท้าย

หัวข้อย่อยสุดท้ายนี่แหละคือจุดที่ต้องชะลอไว้ก่อน การรายงานของเราเองเกี่ยวกับ UI-Venus-2-9B เมื่อปลายเดือนสิงหาคมระบุว่าการเปิดตัวนี้เป็น Apache-2.0 เพราะนั่นคือสิ่งที่เอกสารของโครงการระบุไว้ในตอนนั้น การ์ดโมเดลในวันนี้กลับระบุแตกต่างออกไปและหนักแน่นกว่า นั่นคือ สัญญาอนุญาตน้ำหนักโมเดลยังอยู่ระหว่างรอการยืนยันขั้นสุดท้าย และจะถูกเพิ่มก่อนการเปิดตัวต่อสาธารณะ และการประกาศว่าเป็น Apache-2.0 นั้นจงใจไม่ถูกนำมาสานต่อ เนื่องจากเอกสารต้นทางในปัจจุบันมีข้อความเกี่ยวกับสัญญาอนุญาตที่ขัดแย้งกัน หากคุณกำลังวางแผนนำ UI-Venus 2.9B ไปใช้งานเชิงพาณิชย์ คำถามเรื่องสัญญาอนุญาตยังเปิดอยู่ตามคำยอมรับของผู้ให้บริการเอง และนั่นถือเป็นความเสี่ยงที่มีนัยสำคัญ ไม่ใช่แค่หมายเหตุท้ายบท

ตัวเลขที่แต่ละฝ่ายเผยแพร่จริง

รีโพซิทอรีทั้งสองแห่งวัดสิ่งที่แตกต่างกัน ซึ่งนั่นแหละคือประเด็นสำคัญ Liquid เผยแพร่ปริมาณงานที่ประมวลผลได้ ส่วน Ant Group เผยแพร่อัตราความสำเร็จของงาน

สำหรับตัว drafter ตามฮาร์เนสของ Liquid เอง: ความเร็วในการถอดรหัสเพิ่มขึ้นสูงสุด 2.66 เท่าบน H100 80GB เครื่องเดียวใน BF16 ผ่าน SGLang, สูงสุด 3.13 เท่าด้วย MLX-VLM บน Apple M5 Max และสูงสุด 2.14 เท่าด้วย llama.cpp บน M3 Ultra เมื่อวัดแบบ end-to-end การรันเดียวกันนั้นให้ผลอยู่ระหว่าง 1.30 เท่าถึง 2.62 เท่า ขึ้นอยู่กับสแตกและงาน อัตราการยอมรับ draft อยู่ที่ประมาณ 3.2 ถึง 4.5 โทเคนต่อรอบการตรวจสอบหนึ่งครั้ง ทั้งหมดนี้เป็นค่าที่ผู้ขายวัดเอง โดยไม่มีการทำซ้ำจากภายนอก

สำหรับ UI-Venus 2.9B ตารางของบัตรโมเดลเองรายงานค่า 80.2 บน AndroidWorld, 65.8 บน MobileWorld ที่งบประมาณ 50 สเต็ป, 70.8 บน OSWorld-Verified, 48.0 บน DeskCraft, 90.8 บน WebVoyager จากชุดงาน 595 งานที่รีเฟรชใหม่, 74.0 บน Online-Mind2Web, 73.0 บน ScreenSpot-Pro และ 77.1 บน VenusBench-GD สำหรับ CAPTCHA รายงาน 78.1 บน VenusBench-CAPTCHA และ 75.7 บน MCA-Bench ในด้านความปลอดภัย รายงานอัตราความสำเร็จของการโจมตี 11.3% บน OSHarm เทียบกับ 25.3% สำหรับฐาน Qwen3.5-9B ทั้งหมดนี้เป็นค่าที่ผู้ขายรายงาน เกณฑ์อ้างอิงบางตัวมีเครื่องหมายดอกจันหมายความว่าผู้เขียน UI-Venus เป็นผู้ประเมินภายใต้โปรโตคอลที่ระบุ และบัตรโมเดลเองเตือนว่าการเปรียบเทียบบน OSWorld-Verified ใช้โครงสร้างการดำเนินการเฉพาะของแต่ละโมเดล และควรอ่านเป็นข้อมูลอ้างอิงระดับเบนช์มาร์กมากกว่าการทดลองแบบควบคุมตัวแปร

สังเกตว่าสิ่งใดที่ไม่มีอยู่ในทั้งสองรายการ: สิ่งใดก็ตามที่ถูกวัดโดยบุคคลที่สาม สำหรับดราฟเตอร์ นั่นเป็นเพราะเช็กพอยต์มีอายุหลายวันแล้ว สำหรับ UI-Venus 2.9B นั่นเป็นเพราะเบนช์มาร์ก GUI-agent มีค่าใช้จ่ายสูงในการทำซ้ำ และผลลัพธ์ในสภาพแวดล้อมจริงเปลี่ยนแปลงไปตามสถานะของสภาพแวดล้อมในวันที่ประเมิน — ข้อแม้ที่การ์ดระบุไว้เอง

จุดที่ทั้งสองมาบรรจบกันจริง ๆ

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

UI-Venus 2.9B โจมตีมันด้วยการฝึก: ไปป์ไลน์สามขั้นตอนของการฝึกระดับกลางแบบมัลติโหมดบนสภาพแวดล้อมมือถือ เว็บ และ OS จำลอง, RL ออฟไลน์แบบรายโดเมน, จากนั้นจึงกลั่นแบบ on-policy จากหลายครูเป็นนโยบายเดียว ความสามารถที่เผยแพร่คือผลลัพธ์ โมเดลนี้มีขนาด 9B ซึ่งเล็กสำหรับ GUI agent และใหญ่สำหรับอุปกรณ์ edge และการกำหนดค่าการให้บริการที่ตั้งใจไว้ของการ์ดคือการปรับใช้ vLLM — เอกสารเดียวกันระบุว่าการกำหนดค่านั้นไม่ได้รับการตรวจสอบด้วย live-canary เป็นส่วนหนึ่งของการอัปเดตการ์ด และบอกให้คุณปักหมุดและตรวจสอบเวอร์ชัน vLLM ของคุณสำหรับ Qwen3.5 ก่อนที่จะปรับใช้

LFM2.5-VL-3B-DSpark เข้าจัดการปัญหานี้ด้วยรันไทม์ โดยไม่แตะต้องน้ำหนักของโมเดลเป้าหมาย และแลกความเร็วมาด้วยการร่างและตรวจสอบโทเค็น บนอุปกรณ์ระดับสมาร์ตโฟน การแลกเปลี่ยนนี้เอนเอียงไปทางฝ่ายดราฟเตอร์เพียงฝ่ายเดียว เพราะเอาต์พุตพิสูจน์ได้ว่าเป็นของโมเดลเป้าหมาย และหน่วยความจำที่เพิ่มขึ้นนั้นต่ำกว่าหนึ่งในสิบของโมเดล

ผลที่ตามมาสำหรับใครก็ตามที่เลือก: ลูปเอเจนต์ทำให้มีการเรียกโมเดลหลายครั้งต่อหนึ่งงาน และทุกครั้งที่เรียกต้องจ่ายค่า prefill สำหรับภาพหน้าจอใหม่ การเข้ารหัสภาพและ prefill เป็นขั้นตอนที่การถอดรหัสเชิงคาดการณ์ (speculative decoding) ไม่ได้เร่งให้เร็วขึ้นเลย — ประกาศของ Liquid เองก็ใช้ข้อโต้แย้งนี้คัดค้านการตีความตัวเลขพาดหัวของตนแบบไม่จำกัด ดังนั้น ข้อได้เปรียบของดราฟเตอร์จึงหดหายในภาระงานแบบที่ UI-Venus 2.9B อยู่พอดี ในทางกลับกัน ข้อได้เปรียบของ UI-Venus 2.9B — การทำงานให้สำเร็จจริง — ไม่ใช่สิ่งที่ดราฟเตอร์มอบให้ได้ไม่ว่าจะเร็วแค่ไหน

การรันทั้งสอง

ทั้งสองไม่ใช่ hosted endpoint บน OrcaRouter LFM2.5-VL-3B-DSpark และ UI-Venus 2.9B ต่างก็ต้องให้คุณดึง weights และให้บริการด้วยตัวเอง และเรื่องราวการให้บริการของทั้งคู่ถูกกำหนดรูปร่างโดยบทบาทที่แตกต่างกันอย่างมาก ตัว drafter ต้องใช้ SGLang v0.5.19 หรือใหม่กว่า พร้อมแฟล็กอัลกอริทึม speculative DSPARK และ block size 9 หรือ MLX-VLM v0.7.2 หรือใหม่กว่า โดยส่ง drafter เป็น draft model และบังคับ temperature เป็นศูนย์ หรือ llama.cpp กับ F16 GGUF ขนาด 567 MB ที่จับคู่กับ target แบบ quantized UI-Venus 2.9B ต้องใช้เซิร์ฟเวอร์ vLLM ที่ใหญ่พอสำหรับโมเดล 9B ที่ความยาวสูงสุด 262,144 โทเคน บวกกับ reference prompts และ action parsers จากที่เก็บโค้ดของโปรเจกต์ — การ์ดระบุชัดเจนว่าการเริ่มเซิร์ฟเวอร์เพียงอย่างเดียวไม่ได้ให้ GUI agent แบบ closed-loop ที่ใช้งานได้

ทั้งสองยังคงทิ้งช่องว่างแบบเดียวกันไว้ที่ขอบเขตของสิ่งที่ทำได้ โมเดลวิชัน-ภาษาขนาดเล็กที่จับคู่กับดราฟเตอร์ยังคงพบหน้าจอและงานที่จัดการไม่ได้ และเอเจนต์ GUI ก็ยังล้มเหลวในสภาพแวดล้อมที่อยู่นอกการแจกแจงข้อมูลฝึกของมัน คำค้นที่หลุดรอดไปนั้นตกลงที่ใดที่หนึ่ง และในการออกแบบระบบโปรดักชันส่วนใหญ่ นั่นคือโมเดลอเนกประสงค์ขนาดใหญ่กว่า การส่งคำเหล่านั้นผ่านปลายทางเดียวที่ครอบคลุมโมเดล 200+ ตัวในราคาตามรายการของผู้ให้บริการแต่ละราย พร้อมการสลับไปใช้ระบบสำรองอัตโนมัติเมื่อผู้ให้บริการมีปัญหาช่วยให้เส้นทางสำรองไม่อยู่ในรายการสิ่งที่ต้องผสานรวมที่สำคัญ แทนที่จะกลายเป็นโครงการติดตั้งใช้งานที่สองซึ่งมีคีย์และสัญญาของตัวเอง

วิธีตัดสินใจในหนึ่งนาที

หากคุณต้องการซอฟต์แวร์ที่ใช้งานส่วนติดต่อผู้ใช้ — คลิก พิมพ์ นำทางแอปที่มันไม่เคยเห็น — คุณกำลังซื้อนโยบาย และนั่นคือ UI-Venus 2.9B จัดงบสำหรับการปรับใช้ vLLM ขนาด 9B อ่านคำถามเรื่องใบอนุญาตที่ยังค้างอยู่ก่อนที่คุณจะผูกพันในเชิงพาณิชย์ และมองตารางเกณฑ์มาตรฐานของผู้ขายเป็นสมมติฐานเริ่มต้นที่แข็งแกร่งมากกว่าผลลัพธ์ที่ยุติแล้ว โดยเฉพาะการเปรียบเทียบ OSWorld-Verified ที่การ์ดเองระบุว่าขึ้นอยู่กับโครงสร้างสนับสนุน

หากคุณรัน LFM2.5-VL-3B อยู่แล้ว และต้องการให้มันเร็วขึ้นบนฮาร์ดแวร์ที่คุณเป็นเจ้าของ สิ่งที่คุณกำลังซื้อคือการปรับแต่งรันไทม์ และนั่นก็คือ LFM2.5-VL-3B-DSpark ตรวจสอบสามสิ่งก่อน: ว่าเวิร์กโหลดของคุณเป็นแบบ decode-heavy มากกว่า prefill-heavy ว่าคุณให้บริการที่ 16-bit ไม่ใช่การส่งออกแบบ 4-bit และว่ารันไทม์ของคุณตรงตามเวอร์ชัน หากทั้งสามข้อนี้เป็นจริง ค่าใช้จ่ายด้านหน่วยความจำอยู่ที่ 8.9% และผลลัพธ์จะไม่เปลี่ยนแปลงโดยธรรมชาติของการออกแบบ

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

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