เจดีย์ Voxel, โทเค็นน้อยลง 10% และประโยคเดียวที่ OpenBMB ยืนยันสนับสนุนจริง ๆ

ประโยคที่ถูกอ้างถึงมากที่สุดเกี่ยวกับ MiniCPM-V 4.7 35B-A3B ในสัปดาห์นี้ไม่ได้อยู่ในโมเดลการ์ดของมัน แต่เป็นทวีตที่โพสต์เมื่อวันที่ 13 ตุลาคม 2026 ซึ่งกล่าวว่า "MiniCPM-V 4.7 35B-A3B ไม่ได้ใช้โทเค็นน้อยลงเท่านั้น แต่ยังสร้างเจดีย์ voxel ได้ดีกว่า Qwen 3.6 35B-A3 อีกด้วย" การสาธิตที่ทวีตนี้ชี้ไปคือวิดีโอของโมเดลภาษาสองตัวที่ต่างเขียนโค้ดสำหรับเจดีย์ญี่ปุ่นแบบ voxel 3 มิติ แล้วเรนเดอร์วางเคียงข้างกัน มันเป็นชิ้นงานที่น่าสนใจจริง ๆ — มันแสดงให้เห็นโมเดลภาษา-ภาพจำลองโครงสร้างที่สร้างขึ้นในสามมิติจากพรอมป์รูปภาพ ซึ่งเป็นงานที่ยากกว่าการใส่คำบรรยายให้ภาพหนึ่งภาพ แต่ก็ควรแยกให้ชัดว่าทวีตนั้นคืออะไรและไม่ใช่อะไร เพราะข้ออ้างสามแบบที่แตกต่างกันถูกรวมเข้าเป็นบรรทัดเดียว และทั้งสามมีระดับหลักฐานสนับสนุนต่างกัน MiniCPM-V 4.7 35B-A3B เป็นเช็กพอยต์จริงจาก OpenBMB และมีอายุราวหนึ่งสัปดาห์ ส่วน Qwen3.6-35B-A3B เป็นคู่แข่งน้ำหนักเปิดอายุเก้าเดือน ใช้ Apache-2.0 เช่นกัน และเป็น sparse mixture-of-experts ที่ขนาดหัวเดียวกันเช่นกัน ทุกอย่างด้านล่างนี้ว่าด้วยข้ออ้างเรื่องประสิทธิภาพรอบ ๆ สิ่งเหล่านี้ว่าข้อใดตรวจสอบได้ และข้อใดเป็นเพียง JPEG ของแผนภูมิ

สามข้ออ้างที่สวมอยู่ในประโยคเดียว

ทวีตนี้รวมสามสิ่งที่แยกออกจากกันได้ไว้ด้วยกัน และสิ่งเหล่านั้นสมควรถูกแยกออกจากกัน เพราะมีเพียงหนึ่งในนั้นเท่านั้นที่ถูกบันทึกไว้

• "ใช้โทเค็นน้อยลง" — นี่คือข้อความที่สามารถวัดได้เกี่ยวกับการบริโภคโทเค็นสำหรับงานหนึ่ง ตัวเลขที่แพร่กระจายไปพร้อมกับเดโมคือโทเค็นน้อยกว่า Qwen3.6 35B-A3B 10% ตัวเลขนั้นมาจากผู้สร้างบุคคลที่สามที่ทำการเปรียบเทียบ ไม่ใช่จากการประเมินของ OpenBMB และมันเป็นคู่พรอมต์เดียว ไม่ใช่การทดสอบมาตรฐาน

• "สร้างเจดีย์ voxel ที่ดีกว่า" — นี่เป็นการตัดสินที่ทำขึ้นโดยการดูเจดีย์ที่เรนเดอร์แล้วสององค์ ไม่มีรูบริก ไม่มีฮาร์เนสสำหรับให้คะแนน และไม่มีฝ่ายที่สามที่เป็นอิสระ มันเป็นคำกล่าวอ้างแบบที่มนุษย์ใช้เวลาสามวินาทีก็พูดได้ แต่เบนช์มาร์กพูดไม่ได้เลย เพราะ "เจดีย์ที่ดีกว่า" ไม่มีกราวด์ทรูธ

• "ประสิทธิภาพบวกคุณภาพคือสมรภูมิที่แท้จริง" — ส่วนนั้นคือข้อโต้แย้งหลัก และบังเอิญเป็นข้อที่ OpenBMB โต้แย้งไว้เป็นลายลักษณ์อักษร พร้อมแนบตัวเลข ในโมเดลการ์ด เพียงแต่มันไม่ใช่ประโยคที่ถูกส่งต่อ

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

สิ่งที่ OpenBMB เขียนไว้จริง ๆ และเมื่อใด

เริ่มจากไทม์ไลน์ก่อน เพราะมันถูกบีบอัดจากการเล่าซ้ำ เวตถูกอัปโหลดขึ้นอย่างเงียบ ๆ: openbmb/MiniCPM-V-4.7-1Bถูกสร้างขึ้นเมื่อวันที่ 6 ตุลาคม 2026 เวลา 17:40 UTC,openbmb/MiniCPM-V-4.7-35B-A3Bเมื่อวันที่ 7 ตุลาคม เวลา 07:07 UTC. ตอนนั้นทั้งคู่ไม่มีโมเดลการ์ด แท็กสัญญาอนุญาต หรือเบนช์มาร์กใด ๆ — เรื่องนี้เคยถูกพูดถึงที่นี่ในตอนนั้น และมันเป็นสถานการณ์แปลก ๆ สำหรับการอัปโหลดโมเดลขนาด 35 พันล้านพารามิเตอร์ หกวันต่อมา วันที่ 12 ตุลาคม 2026 OpenBMB ได้คอมมิตเอกสารชุดนั้นในคราวเดียว: โมเดลการ์ด สัญญาอนุญาต Apache-2.0 แผนภูมิการประเมิน README ของรีโพซิทอรีที่เขียนใหม่โดยยกซีรีส์ใหม่ขึ้นนำ และประกาศหนึ่งฉบับ พารามิเตอร์ไม่ได้เปลี่ยนในวันนั้น แต่คำอธิบายต่างหากที่เปลี่ยน

ดังนั้นการวางกรอบอย่างตรงไปตรงมาจึงไม่ใช่ “MiniCPM-V 4.7 35B-A3B เปิดตัวในสัปดาห์นี้” แต่เป็น “MiniCPM-V 4.7 35B-A3B กลายเป็นสิ่งที่อ่านออกในสัปดาห์นี้” ทุกอย่างเกี่ยวกับมันที่ตอนนี้อ้างอิงได้ ล้วนถูกอัปโหลดเมื่อวันที่ 6 และ 7 แต่ไม่มีเอกสารประกอบ หรือไม่ก็ถูกเขียนขึ้นเมื่อวันที่ 12 และเป็นคำกล่าวอ้างของผู้ขาย

ข้อกล่าวอ้างที่การ์ดโมเดลนั้นกล่าวอ้างจริง

นี่คือประโยค ซึ่งยกมาทั้งหมดจากการ์ด และแคบกว่าทวีต: ในโหมด Instruct ตัวแปร 35B-A3B "ทำคะแนนรวมได้สูงกว่า และใช้เวลาในการอนุมานน้อยกว่า Qwen3.6 35B-A3B" มีเพียงเท่านั้น ไม่มีจำนวนโทเคน ไม่มีส่วนต่างคะแนน ไม่มีรายละเอียดแยกตามเบนช์มาร์กในรูปแบบข้อความบรรยาย หลักฐานที่อยู่เบื้องหลังคือกราฟกระจาย — คะแนนการประเมินเฉลี่ยบนแกนตั้ง เวลาในการอนุมานเป็นวินาทีบนสเกลลอการิทึมบนแกนนอน — ซึ่ง MiniCPM-V 4.7 35B-A3B อยู่สูงกว่าและไปทางซ้ายของ Qwen3.6-35B-A3B เชิงอรรถของแผนภูมิเองให้นิยามค่าเฉลี่ยว่าหมายถึงค่ามัชฌิมของห้าเบนช์มาร์ก: MMStar, MMMU-Pro, CharXiv reasoning, BLINK และ MathVista วงกลมแทนโหมด Instruct รูปสี่เหลี่ยมข้าวหลามตัดแทนโหมด Thinking

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

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

ประสิทธิภาพของโทเคนควรจะมาจากไหน

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

• Lookahead Expert Scheduling (LES) — เทคนิคหลักที่นำเสนอ sparse mixture-of-experts เก็บพารามิเตอร์ไว้มากกว่าที่เปิดใช้งานต่อโทเคนอย่างมาก และบนอุปกรณ์ที่ไม่สามารถเก็บผู้เชี่ยวชาญทุกตัวไว้ในหน่วยความจำได้ น้ำหนักจะถูกสลับเข้าและออกเป็นเพจ และการถอดรหัสจะสะดุด LES ใช้การทำนายเส้นทางข้ามเลเยอร์เพื่อโหลดล่วงหน้าผู้เชี่ยวชาญที่มีแนวโน้มจะถูกใช้โดยเลเยอร์ถัดไป และจัดลำดับความสำคัญการคำนวณให้กับผู้เชี่ยวชาญที่เราเตอร์จริงเลือกจริงและบังเอิญโหลดอยู่แล้ว OpenBMB ระบุอย่างระมัดระวังว่าการทำนายมีผลต่อการดึงข้อมูลล่วงหน้าและการจัดตารางเวลาเท่านั้น การจัดเส้นทางระดับโทเคนของโมเดลไม่เปลี่ยนแปลง และผู้เชี่ยวชาญที่ตัวทำนายพลาดยังคงถูกโหลดและประเมิน การ์ดอ้างว่าสิ่งนี้ช่วยให้เร็วขึ้น 5× บนอุปกรณ์จริง โดยไม่สูญเสียความสามารถ

• {{1}}การควอนไทซ์แบบละเอียดทีละเลเยอร์{{/1}} — ลดขนาดพื้นที่จัดเก็บน้ำหนักของ expert และปริมาณการรับส่งข้อมูลหน่วยความจำ ซึ่งเป็นอีกครึ่งหนึ่งของการทำให้รูปแบบการโหลดบนอุปกรณ์พอดี

• DSpark speculative sampling — เส้นทางของโมเดลร่างแบบจับคู่ ซึ่งเผยแพร่แยกต่างหากในชื่อ openbmb/MiniCPM-V-4.7-35B-A3B-DSpark และถูกผสานรวมควบคู่ไปกับงานด้านการจัดตารางเวลาและการควอนไทเซชัน

เมื่อนำมารวมกัน สิ่งเหล่านี้ให้ตัวเลขเด่นของรีลีส: 13 โทเคนต่อวินาทีขึ้นไปโดยใช้หน่วยความจำประมาณ 3 GB บน iPhone 17 Pro Max นั่นเป็นตัวเลขจากผู้ขาย บนฮาร์ดแวร์ของผู้ขาย ด้วยซอฟต์แวร์ของผู้ขาย — แอปที่ OpenBMB เขียนขึ้น มันเป็นคำกล่าวอ้างแบบที่ถ้าไม่ใช่ทั้งหมดของผลิตภัณฑ์ก็ไม่มีอะไรเลย และในปัจจุบันไม่มีทางใดที่คนนอกบริษัทจะตรวจสอบได้ เพราะการทำซ้ำต้องใช้สแตกบนอุปกรณ์ที่ใช้ในเดโมบนโทรศัพท์

ประสิทธิภาพของโทเคนเป็นเรื่องจริง แต่ตรงนี้มันเป็นเมทริกซ์ ไม่ใช่สเกลาร์

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

• MiniCPM-V 4.7 35B-A3B รองรับการบีบอัดโทเค็นภาพแบบผสมทั้ง 4x และ 16x โดยเลือกได้ต่อคำขอ การตั้งค่า 16x จะรวมโทเค็นภาพเพื่อความเร็ว ส่วน 4x จะเก็บไว้มากกว่าเป็นสี่เท่าเพื่อรายละเอียด ค่าดีฟอลต์ของการ์ดคือ 16x และต้องส่งพารามิเตอร์นี้ไปทั้งในเทมเพลตแชตและการเรียก generate มิฉะนั้นจำนวน placeholder กับ vision encoder จะไม่ตรงกัน

• ตารางเปรียบเทียบภาพ–ภาษาของผู้จำหน่ายเองบันทึกการตั้งค่าการบีบอัดที่ใช้สำหรับแถวของแต่ละโมเดล ในตารางนั้น แถว MiniCPM-V 4.7 35B-A3B อยู่ที่ 4x — ซึ่งเป็นการตั้งค่าแบบรักษารายละเอียด คือตัวที่แพง — และแถว Qwen3.6 35B-A3B อยู่ที่ 16x ส่วนแถว Gemma 4 ขนาด 31B ระบุไว้ที่ 9x และแถว Qwen ขนาด 27B สองแถวอยู่ที่ 4x

• เชิงอรรถระบุอย่างชัดเจนว่า MiniCPM-V 4.7 รองรับการตั้งค่าใดการตั้งค่าหนึ่ง ในขณะที่โมเดลอื่น ๆ ในตารางรองรับเฉพาะอัตราส่วนการบีบอัดแบบคงที่เท่านั้น

อ่านสองสิ่งนี้รวมกันแล้วภาพก็เปลี่ยนไป หากแถวของ MiniCPM ดึงคะแนนด้านภาพ-ภาษาของตนจากการตั้งค่าที่กินโทเคนมาก ขณะที่แถวของ Qwen ดึงคะแนนจากการตั้งค่าที่ประหยัดโทเคน สองคอลัมน์นั้นก็กำลังเปรียบเทียบปริมาณรายละเอียดภาพที่ต่างกัน และเรื่องราวด้านประสิทธิภาพก็ไม่ใช่ "อินพุตเดียวกัน ใช้โทเคนน้อยกว่า" — มันคือ "อินพุตปรับได้ และนี่คือคอลัมน์ที่ชนะด้านคุณภาพ" นั่นเป็นคำกล่าวอ้างที่น่าสนใจและซื่อสัตย์กว่าของทวีตนั้น และ OpenBMB กลับเผยแพร่มันไว้ในเชิงอรรถแทนที่จะยกขึ้นมาเป็นประเด็นนำ

นี่ยังหมายความว่าตัวเลขที่คุณสนใจจริง ๆ — จำนวนโทเคนต่อหนึ่งหน่วยของรายละเอียดภาพ — ไม่สามารถอ่านออกจากตารางนี้ได้เลย ซึ่งต้องรันโมเดลทั้งสองด้วยการตั้งค่าเดียวกัน และยังไม่มีใครเผยแพร่สิ่งนั้น

ตาราง พร้อมข้อแม้ที่แนบมาด้วย

การ์ดนี้มาพร้อมตารางของผู้ขายสองตาราง ตารางหนึ่งสำหรับวิชัน-ภาษาและอีกตารางสำหรับภาษา ทั้งสองอยู่ในโหมด Instruct ทั้งสองเทียบกับกลุ่มที่รวมโมเดล Qwen ระดับ 35B-A3B สองตัว, Gemma 31B หนึ่งตัว และ Qwen 27B สองตัว ตัวเลขด้านล่างอ่านมาจากแผนภูมิ PNG ของผู้ขายเอง และข้อควรระวังคือเชิงโครงสร้าง: ตัวเลขมีอยู่เพียงในรูปแบบพิกเซลในแผนภูมินั้น ไม่ใช่ในรูปแบบตาราง ดังนั้นสิ่งที่ตามมาจึงถูกสกัดด้วยการอ่านโดยเครื่อง และอาจมีข้อผิดพลาดในการถอดความเล็กน้อยได้

• OCRBench — MiniCPM-V 4.7 35B-A3B 91.20 เทียบกับ Qwen3.6 35B-A3B ที่ 90.40 ช่องว่าง 0.8 จุด จากการรันของผู้ขายเอง

• OmniDocBench v1.6 — ประมาณ 98.2 สำหรับ MiniCPM เทียบกับประมาณ 93.3 สำหรับโมเดล Qwen ซึ่งเป็นช่องว่างเดี่ยวที่ใหญ่ที่สุดในตาราง และเป็นค่าที่จะสำคัญที่สุดหากผลนี้สามารถทำซ้ำได้ เนื่องจากการแยกวิเคราะห์เอกสารเป็นจุดที่มักใช้งบโทเคนไปเป็นส่วนใหญ่

• MMMU — ประมาณ 80.2 ต่อ 80.0 สูสีกันจนแทบแยกไม่ออกที่ระดับความละเอียดของภาพกราฟ

• MMMU-Pro — ประมาณ 69.7 เทียบกับ 67.7 ในแถวที่ Qwen ขนาด 27B อยู่สูงกว่าทั้งคู่

• ตารางภาษา — รูปร่างเดียวกัน โดยมีช่องที่โดดเด่นกว่าอยู่ที่ด้านการทำตามคำสั่งและโค้ด IFBench ถูกระบุไว้ราว 47.7 เทียบกับ 35.3 และ LiveCodeBench-v6 ราว 97.0 เทียบกับ 54.3 สองค่านี้ต่างกันมากพอที่ควรถือเป็นช่องที่น่าเชื่อถือน้อยที่สุดในการเปิดตัวครั้งนี้ จนกว่าจะมีคนอื่นรันมัน: ช่องว่าง 43 จุดบนเบนช์มาร์กโค้ดระหว่างโมเดล MoE แบบเปิดขนาดใกล้เคียงกันสองโมเดล ซึ่งวัดโดยฝ่ายใดฝ่ายหนึ่งจากสองฝ่าย เป็นข้อกล่าวอ้างที่ต้องมีเครื่องมือที่สองมาวัด

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

สิ่งที่ตัวเลขการนำไปใช้บอก ซึ่งไม่เกี่ยวกับคุณภาพเลย

ตัวเลขหนึ่งตัวในการเปรียบเทียบนี้ไม่มีใครโต้แย้ง และมันไม่ใช่เบนช์มาร์ก ตัวนับจำนวนดาวน์โหลดของ Hugging Face ซึ่งอ่านค่าเมื่อวันที่ 13 ตุลาคม 2026 แสดงตัวเลข 630 สำหรับ openbmb/MiniCPM-V-4.7-35B-A3Bเทียบกับราว 3.6 ล้านสำหรับQwen/Qwen3.6-35B-A3B— รีโพซิทอรีที่สร้างขึ้นเมื่อวันที่ 15 เมษายน 2026 จึงอยู่ในเส้นโค้งการยอมรับนำไปใช้ล่วงหน้าราวเก้าเดือน ช่องว่างนี้วัดกันที่เวลา ไม่ใช่คุณค่า และนี่คือเหตุผลที่คำถามเรื่องประสิทธิภาพถูกตั้งขึ้นในทิศทางนี้ตั้งแต่แรก ผู้มาใหม่จำเป็นต้องโต้แย้งกันในระดับต่อโทเคน ก็เพราะมันยังไม่มีเวลาเก้าเดือนที่จะกลายเป็นตัวเลือกเริ่มต้น

ยังมีความขัดแย้งภายในเล็ก ๆ ในหน้าลิสติงที่ควรตั้งข้อสังเกตอยู่ด้วย รีพอซิทอรีนี้มีแท็ก "On-Device Model" ที่สืบทอดมาจากส่วนที่เหลือของตระกูล และ sparse MoE ขนาด 35.2 พันล้านพารามิเตอร์ในน้ำหนัก BF16 70.4 GB ก็ไม่ใช่ on-device ในความหมายใด ๆ ที่ผู้ดาวน์โหลดจะรู้จัก เรื่องราว on-device นั้นเป็นเรื่องจริง แต่เส้นทางนั้นวิ่งผ่านการควอนไทซ์และการสตรีม expert ที่ซ้อนอยู่บน checkpoint ไม่ใช่ผ่านตัว checkpoint เอง ให้ตั้งงบประมาณโดยอิงกับบิลด์ที่ผ่านการควอนไทซ์และแอป ไม่ใช่กับแท็ก

จะทำอย่างไรกับเรื่องนี้ในสัปดาห์นี้

จุดยืนในทางปฏิบัติแคบและชัดเจน หากคุณต้องการให้ข้ออ้างเรื่องประสิทธิภาพได้รับการตรวจสอบยืนยัน ยังไม่มีอะไรให้ตรวจสอบ — มันเป็นแผนภูมิของผู้ขายรายเดียว และตัวเลขเดียวที่มีตัวเลขต่องานกำกับอยู่ (ใช้โทเคนน้อยลง 10% หนึ่ง pagoda) มาจากเดโมครั้งเดียวของบุคคลที่สาม หากคุณต้องการรันโมเดล น้ำหนักเป็น Apache-2.0 สถาปัตยกรรมได้รับการจัดทำเอกสารไว้ และการตั้งค่าการดาวน์แซมปลิงเป็นสิ่งที่คุณเลือกได้ ซึ่งเป็นคันโยกที่มีอยู่จริงและถูกมองข้าม: 16x เมื่อทรูพุตสำคัญ 4x เมื่อแผนภูมิกำลังแสดงเอกสารให้คุณ

ครึ่งหนึ่งของการเปรียบเทียบนี้สามารถเข้าถึงได้ผ่าน API ที่มีผู้โฮสต์ให้บริการอยู่ในวันนี้ ส่วนอีกครึ่งหนึ่งยังทำไม่ได้ และก็คุ้มค่าที่จะระบุให้ชัดเจนว่าอันไหนเป็นอันไหน qwen/qwen3.6-35b-a3bเป็นโมเดลที่โฮสต์อยู่บน OrcaRouter — มันอยู่ในแคตตาล็อกที่เปิดใช้ด้วยคีย์เดียว ในราคาตามที่ Qwen ประกาศไว้เองโดยไม่มีอะไรบวกเพิ่มโดยส่งต่อไปยังผู้ให้บริการรายใดก็ตามที่ยังทำงานปกติ แทนที่จะเป็นรายที่คุณกำหนดไว้เอง MiniCPM-V 4.7 ไม่ได้โฮสต์โดยเรา แต่เป็นเช็กพอยต์แบบเปิดน้ำหนัก (open-weights) ที่คุณต้องให้บริการเอง ความไม่สมมาตรนี้แหละคือสิ่งที่มีประโยชน์ตรงนี้ คุณสามารถนำฝั่ง Qwen ของการเปรียบเทียบนี้ไปตั้งเป็นเบสไลน์ได้ในบ่ายนี้ รันฮาร์เนสของ OpenBMB กับข้อมูลของคุณเองเทียบกับมัน แล้วให้แผนภูมิของผู้ขายเป็นเพียงสมมติฐานแทนที่จะเป็นคำตอบ

ซึ่งเมื่อพิจารณาว่าการโต้แย้งทั้งหมด是关于ประสิทธิภาพบนฮาร์ดแวร์ของคุณแล้ว นี่คือการวัดเพียงอย่างเดียวที่จะตัดสินเรื่องนี้ได้