MiniCPM-V-4.7-1B-DSpark: โมเดลร่างขนาด 213M ที่เปิดตัวโดยไม่มีการประกาศ

MiniCPM-V-4.7-1B-DSpark เป็นเช็คพอยต์ที่มีพารามิเตอร์ 213,547,777 ตัว ซึ่งไม่สามารถตอบคำถามได้ มันไม่อ่านภาพ มันไม่สนทนา และเมื่อให้บริการด้วยตัวเอง มันก็ไม่สร้างอะไรที่คุ้มค่าจะอ่าน หน้าที่ทั้งหมดของมันคือการนั่งอยู่หน้าโมเดลหนึ่งตัว — MiniCPM-V-4.7-1B — และคาดเดาโทเค็นสิบห้าตัวถัดไป เพื่อให้โมเดลภาษาภาพขนาดเล็กระดับโทรศัพท์สามารถตรวจสอบบล็อกของโทเค็นเหล่านั้นได้ใน forward pass เพียงครั้งเดียว แทนที่จะสร้างทีละตัว

ไฟล์มีขนาด 0.85 GB ภายใต้ Apache-2.0 และปรากฏบน Hugging Face เมื่อเวลา 04:26 UTC ของวันที่ 8 ตุลาคม 2026 ในชุดเดียวกับฉบับร่างสำหรับโมเดลพี่น้อง 35B-A3B ที่ใหญ่กว่า สี่วันต่อมา การ์ดของโมเดลหลักยังคงถือว่ามันเป็นเพียงเชิงอรรถ: ฉบับร่างปรากฏเพียงครั้งเดียว ในฐานะแถวหนึ่งในตารางเวต และอยู่หลังปุ่มสลับ “Speculative decoding (DSpark)” ที่ถูกย่อไว้ ไม่มีโพสต์บล็อกของ OpenBMB เกี่ยวกับมัน ไม่มีรายงานทางเทคนิค และไม่มีรายการในเอกสาร GitHub ของโครงการเอง

ความเงียบนั้นคือส่วนที่น่าสนใจ เพราะสิ่งที่ไฟล์นี้โดยเฉพาะทำให้เป็นไปได้ มันเป็นชิ้นงานแรกในตระกูล MiniCPM-V 4.7 ที่ข้อกล่าวอ้างหลัก — ว่าโมเดลวิชันขนาด 1B ทำงานบนโทรศัพท์ได้อย่างยอมรับได้ — สามารถถูกตรวจสอบโดยคนนอก OpenBMB ทุกอย่างด้านล่างแยกสองกองออกจากกัน: อะไรคือไฟล์บนดิสก์ที่คุณเปิดได้ และอะไรคือตัวเลขที่ผู้ขายพิมพ์ไว้ข้าง ๆ มัน

จริงๆ แล้วมีอะไรอยู่ในรีโพซิทอรี

สี่ไฟล์ เท่านั้นเอง ทั้งหมด: .gitattributes, README.md, config.json และ model.safetensors เพียงไฟล์เดียวที่บรรจุน้ำหนัก BF16 ขนาด 854,204,052 ไบต์ ไม่มีโทเคไนเซอร์ในรีโพซิทอรี เพราะไม่จำเป็นต้องมี — ดราฟต์ยืมของเป้าหมาย และคำศัพท์ในคอนฟิกของมันก็คือ 248,094 โทเคนของพาเรนต์อย่างแม่นยำทุกประการ ดราฟเตอร์ที่มีโทเคนไม่แมปแบบหนึ่งต่อหนึ่งกับของเป้าหมาย ไม่สามารถเสนออะไรที่เป้าหมายจะยอมรับได้ ดังนั้นการแชร์คำศัพท์จึงเป็นข้อกำหนด มากกว่าความสะดวก

Hub API บันทึกที่เก็บนี้ว่าถูกสร้างเมื่อ 2026-10-08T04:26:19Z และแก้ไขล่าสุดเมื่อ 2026-10-12T14:29:57Z ติดแท็กสำหรับภาษาอังกฤษและภาษาจีน ได้รับสัญญาอนุญาต Apache-2.0 มีไลก์สามครั้งและดาวน์โหลดหนึ่งครั้ง ณ เวลาที่เขียน ตัวเลขสุดท้ายนี่แหละที่ควรจดจำไว้ ดาวน์โหลดหนึ่งครั้ง หลังผ่านไปสี่วัน บนไฟล์ที่เล็กพอจะดึงผ่านการเชื่อมต่อโทรศัพท์ได้

ฟิลด์ architecture ระบุเป็น Qwen3DSparkModel โดยมี model_type เป็น qwen3 ซึ่งสอดคล้องกันมากกว่าแปลกประหลาด เพราะโครงกระดูกหลักด้านภาษาของ MiniCPM-V 4.7 สืบทอดมาจากสาย Qwen3 ดังนั้นสตับห้าเลเยอร์ที่ตัดมาจากตระกูลเดียวกันจึงเป็นสิ่งที่คาดได้อยู่แล้ว สิ่งที่ไม่ใช่สำเนาขนาดย่อมของตัวแม่ก็คือวิธีที่สตับสื่อสารกับมัน คอนฟิกนี้ติดตั้ง dflash_config พร้อมกับ projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" และ markov_rank: 256 ส่วน confidence head นั้นคือส่วนที่ยกมาจากวิธี DSpark: มันเป็นกลไกสำหรับประเมินว่าบล็อกที่เสนอมาควรค่าแก่การตรวจสอบมากน้อยเพียงใด ซึ่งเป็นเหตุผลทั้งหมดที่คอนฟิกการให้บริการเปิดสวิตช์ให้ปิดการตรวจสอบแบบปรับเปลี่ยนได้

ข้อมูลจำเพาะ และเหตุผลว่าทำไมตัวเลขแต่ละตัวจึงอยู่ตรงนั้น

ฝั่ง Draft จากทั้งการ์ดและการตั้งค่า ซึ่งทั้งสองอย่างตรงกัน:

• พารามิเตอร์ของดราฟต์ — 213,547,777 ทั้งหมดเป็น BF16 ในเช็กพอยต์ไฟล์เดียวขนาด 0.85 GB

• ความลึกของ Draft — 5 เลเยอร์, ใช้ full attention ทุกเลเยอร์, ขนาด hidden 1,024, ขนาด intermediate 3,584, การเปิดใช้งาน SiLU

• เรขาคณิตของ attention — 8 query head เทียบกับ 2 key/value head, มิติ head 256, attention แบบ grouped-query

• โทเค็นต่อ forward pass — 15 ซึ่งระบุไว้ใน config เป็น block_size: 15

• ช่วงตำแหน่ง — RoPE theta 10,000,000 พร้อมการฝังแบบโรตารีขนาด 256 มิติ และ max_position_embeddings ตั้งค่าเป็น 262,144 ซึ่งตรงกับหน้าต่าง 256K ของพาเรนต์

• แตะเลเยอร์ — [3, 7, 11, 15, 19] จากทั้งหมด 24 ของเลเยอร์แม่ (num_target_layers: 24)

• คำศัพท์ — 248,094 ซึ่งผูกกับโทเคไนเซอร์ของเป้าหมาย โดยมีโทเคนมาสก์เฉพาะที่ 248,076 สำหรับขั้นตอนการร่างแบบกึ่งออโตเรเกรสซีฟ

สองในบรรทัดเหล่านั้นคุ้มค่ามากกว่าการกวาดตามองผ่าน ๆ อย่างแรกคือ tap layers ดราฟต์ไม่ได้อ่านเลเยอร์สุดท้ายของโมเดลแม่ แต่จะอ่าน hidden states จากห้าเลเยอร์ที่กระจายอยู่ทั่วความลึกของโมเดลแม่ แล้วฉายผ่านโปรเจกเตอร์ dspark สเตตที่อยู่กลางเครือข่ายจับคู่ให้ตรงกันได้ถูกกว่า และยังคงมีข้อมูลที่เลเยอร์สุดท้ายได้บีบยุบไปเป็น logits ของโทเคนถัดไปแล้ว อย่างที่สองคือมิติหัว (head dimension) ขนาด 256 เทียบกับขนาด hidden 1,024 นั่นคือหัวที่กว้างอย่างจงใจบนโมเดลที่แคบ และคอนฟิกตั้งค่า tie_word_embeddings: false — เมทริกซ์ embedding ถูกเก็บแยกไว้ต่างหากแทนที่จะแชร์กับการฉายเอาต์พุต ดังนั้นจำนวนพารามิเตอร์จึงนับรวมทั้งสองส่วน

สรุปความก็คือดราฟเตอร์ที่มีขนาดราวหนึ่งในห้าของขนาดเป้าหมาย แต่มีรูปร่างแตกต่างไปโดยสิ้นเชิง เพื่อเปรียบเทียบ ดราฟต์ของรุ่นพี่น้อง 35B-A3B มีพารามิเตอร์ 389,223,169 ตัว และแตะเลเยอร์ [3, 11, 19, 27, 35] จาก 40 สองดราฟต์ หนึ่งตัวต่อเป้าหมายหนึ่งตัว เพราะดราฟต์จะใช้ได้เฉพาะกับคำศัพท์และการแทนค่าระดับกลางที่มันถูกฝึกมาด้วยเท่านั้น

ตารางการยอมรับเป็นการ์ดโมเดล ไม่ใช่การวัด

นี่คือข้อมูลเชิงตัวเลขทั้งหมดที่ OpenBMB เผยแพร่เกี่ยวกับประสิทธิภาพของคู่นี้ โดยแสดงเป็นจำนวนโทเคนที่ยอมรับต่อขั้นตอนการตรวจสอบยืนยัน ซึ่งวัดจากการสิ้นสุดแบบ EOS ตามธรรมชาติและmax_new_tokens=8192:

• Vision, MMMU — 3.452 โทเค็นที่ยอมรับต่อขั้นตอน

• Vision, MathVista — 4.333

• การมองเห็น, การให้เหตุผล CharXiv (การตรวจสอบ) — 4.452

• Vision, OCRBench — 4.752

• ข้อความ, คณิตศาสตร์ — 5.891

ข้อความ, โค้ด — 5.347

• ข้อความ ทั่วไป — 3.370

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

ข้อควรระวังสามข้อนั้นควรอยู่ในตารางนั้น และการ์ดไม่ได้บอกข้อใดในนั้นเลย

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

ความยาวการยอมรับเป็นคุณสมบัติของคู่ ไม่ใช่คุณสมบัติของโมเดล เป้าหมายที่พูดซ้ำตัวเองย่อมมอบชัยชนะง่าย ๆ ให้ดราฟเตอร์ของมัน ดังนั้นตัวเลขที่สูงขึ้นตรงนี้จึงไม่ใช่หลักฐานว่า MiniCPM-V 4.7-1B เก่งเรื่องอะไรสักอย่าง มันเป็นหลักฐานว่าผลลัพธ์ของมันคาดเดาได้แค่ไหน ซึ่งเป็นคนละคำถามกับคนละคำตอบ

และมันไม่ใช่การเร่งความเร็ว ดราฟเตอร์ที่เสนอ 15 โทเคนและได้รับการตรวจยืนยัน 3.4 โทเคนก็ยังคงเดินหน้าไปหลายโทเคนต่อการทำ forward pass ของโมเดลเป้าหมายหนึ่งครั้ง แต่การตรวจยืนยันบล็อกขนาด 15 โทเคนมีต้นทุนสูงกว่าการสร้างโทเคนเพียงหนึ่งตัว และทุกข้อเสนอที่ถูกปฏิเสธล้วนต้องจ่ายไปแล้วถูกทิ้ง การแปลงความยาวที่ได้รับการยอมรับให้เป็นตัวเลขเวลาจริงต้องอาศัยต้นทุนการตรวจยืนยัน ขนาดแบตช์ และฮาร์ดแวร์ ซึ่งการ์ดไม่ได้ให้ข้อมูลเหล่านี้เลย สูตรการให้บริการสูตรเดียวที่มันให้มานั้นตั้งค่าเป็น--max-num-seqs 1 ซึ่งเป็นคอนฟิกูเรชันที่ปรับมาเพื่อให้ทำงานได้ มากกว่าที่จะปรับมาให้เร็ว

เมื่ออ่านเทียบกับรุ่นพี่น้อง ตารางนี้จะมีประโยชน์มากขึ้น ดราฟต์ 35B-A3B ทำคะแนนได้ 7.387 บนโค้ด และ 5.098 บน MMMU; ดราฟต์ 1B นี้ทำได้ 5.347 และ 3.452 เป้าหมายที่เล็กลงพร้อมดราฟต์เตอร์ที่เล็กลงจะรับโทเค็นต่อสเต็ปน้อยลงอย่างเห็นได้ชัด ซึ่งเป็นรายละเอียดข้ามตระกูลแบบที่การ์ดใบเดียวแสดงไม่ได้ แต่การ์ดสองใบแสดงได้

การฝึกอบรม และรายละเอียดที่อธิบายการออกแบบทั้งหมด

สูตรนี้มีสี่บรรทัด: ลำดับการฝึกสองล้านลำดับ หกรอบการเรียนรู้ AdamW และฟังก์ชันวัตถุประสงค์รวมที่ประกอบด้วย cross-entropy พจน์ L1 และค่าความสูญเสียความเชื่อมั่น บรรทัดที่สำคัญคือบรรทัดที่ว่าข้อมูลการฝึกมาจากไหน — การตอบกลับถูกสร้างขึ้นโดย MiniCPM-V-4.7-1B เอง จากส่วนผสมของพรอมป์ต์ภาพและข้อความ

นั่นคือการกลั่นตัวเอง (self-distillation) และมันกำหนดต้นทุนขั้นต่ำในการสร้างดราฟเตอร์แบบนี้ คุณไม่สามารถเทรนมันได้หากไม่รันโมเดลเป้าหมายในปริมาณมากก่อน ครอบคลุมทั้งสองโมดัลลิตี ซึ่งหมายความว่าอาร์ติแฟกต์ขนาด 0.85 GB ที่คุณดาวน์โหลดได้นั้นเป็นเศษที่ราคาถูกจากกระบวนการที่แพง มันยังอธิบายด้วยว่าทำไมดราฟเตอร์จึงถูกจับคู่แบบหนึ่งต่อหนึ่งแทนที่จะแชร์กัน: พฤติกรรมที่มันเลียนแบบคือพฤติกรรมของโมเดลนี้ และเอาต์พุตของเป้าหมายอื่นจะเทรนดราฟเตอร์ที่แตกต่างออกไป

บทความของวิธีนี้เอง arXiv 2607.05147 ไม่ใช่ของ OpenBMB เป็นบทความที่มีผู้เขียน 33 คน ส่งเมื่อวันที่ 6 กรกฎาคม 2026 ซึ่งอธิบาย DSpark ว่าเป็นกรอบงานถอดรหัสแบบคาดการณ์ที่จับคู่แบ็กโบนแบบขนานกับโมดูลลำดับน้ำหนักเบา และกำหนดความยาวการตรวจสอบจากความน่าจะเป็นของการอยู่รอดของพรีฟิกซ์ที่ประเมินไว้ บทความรายงานการนำไปใช้งานภายในระบบให้บริการ DeepSeek-V4 ใช้เบสไลน์การผลิตที่เรียกว่า MTP-1 และอ้างว่าการสร้างผลลัพธ์ต่อผู้ใช้เร็วขึ้น 60 ถึง 85 เปอร์เซ็นต์ที่ทรูพุตเท่ากัน ข้ออ้างเหล่านั้นเป็นของบทความและของการนำไปใช้งานนั้น ไม่มีสิ่งใดที่ได้รับการเผยแพร่เชื่อมโยงข้ออ้างเหล่านั้นกับดราฟต์ 5 ชั้นขนาด 213M บนโมเดลวิชัน 1B และตารางการยอมรับข้างต้นคือสะพานเดียวที่เคยมีใครเสนอ

ทำไมไฟล์นี้จึงสำคัญมากกว่าที่ขนาดของมันบ่งบอก

ข้อกล่าวอ้างหลักของตระกูล MiniCPM-V 4.7 คือการทำงานบนอุปกรณ์ การ์ด 1B มาพร้อมกับแผนภูมิเปรียบเทียบประสิทธิภาพกับเวลาการอนุมาน แผนภูมิประสิทธิภาพโดยรวมสำหรับบิลด์ 1B instruct การบันทึกหน้าจอที่ไม่ผ่านการตัดต่อซึ่งบันทึกบน iPhone 17 Pro Max และประโยคเชิงคุณภาพที่กล่าวว่าตัวแปร 1B มีประสิทธิภาพเหนือกว่า Qwen3.5 0.8B อย่างมากทั้งในคะแนนโดยรวมและประสิทธิภาพการอนุมาน นอกจากนี้ยังระบุตระกูลการควอนไทเซชัน — int4, AWQ, GPTQ, GGUF รวมถึงการรองรับ FP8 — และเป้าหมายฮาร์ดแวร์ในวันแรกที่ครอบคลุม iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD และ Arm

ทุกข้อในนั้นเป็นคำกล่าวอ้างของผู้จำหน่ายโดยไม่มีตัวเลขจากภายนอกมาประกอบ และหนึ่งในนั้นก็ไม่สอดคล้องกันเองภายใน: ข้อความบนการ์ดเรียกมันว่าโมเดล 1B ขณะที่แถบด้านข้างของ Hub รายงานขนาดโมเดลว่า 2B พารามิเตอร์ เช็กพอยต์ DSpark แตกต่างในเชิงชนิดจากทั้งหมดนั้น มันมีขนาด 0.85 GB ใช้สัญญาอนุญาต Apache-2.0 และมาพร้อมคำสั่งสำหรับให้บริการ ซึ่งหมายความว่าบุคคลภายนอกที่มี GPU สำหรับผู้ใช้ทั่วไปสามารถรันมันได้ภายในสัปดาห์นี้ และสร้างตัวเลขที่วัดจากภายนอกเป็นครั้งแรกของตระกูลนี้ ไม่ใช่คะแนนเบนช์มาร์ก แต่เป็นสิ่งที่เกือบมีประโยชน์พอ ๆ กัน: ความยาวการยอมรับที่ทำซ้ำได้

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

การรันมัน และค่าใช้จ่ายในการลอง

การ์ดนี้มาพร้อมสูตรสำเร็จหนึ่งสูตร และมันคือการเรียกใช้ vllm serve ไม่ใช่แค่การพูดลอย ๆ มันโหลดโมเดลเป้าหมาย openbmb/MiniCPM-V-4.7-1B ให้บริการภายใต้ชื่อ MiniCPM-V-4.7-1B ตั้งค่า --max-model-len 40960 และ --max-num-batched-tokens 40960 ตรึง --attention-backend FLASH_ATTN และ --mm-encoder-attn-backend FLASH_ATTN ส่ง kwarg ของตัวประมวลผลแบบหลายรูปแบบ (multimodal processor) เป็น {"downsample_mode": "4x"} เชื่อถือ kwarg แบบหลายรูปแบบต่อคำขอ และชี้การกำหนดค่า speculative ไปที่เช็กพอยต์ DSpark ด้วย "method": "dspark", "num_speculative_tokens": 15 และปิดการตรวจสอบแบบปรับตัวไว้ ค่า kwarg เริ่มต้นของเทมเพลตแชตทำให้การคิดถูกปิดไว้

รายละเอียดสองอย่างในบรรทัดนั้นน่าอ่านซ้ำอีกครั้ง --max-num-seqs 1หมายความว่าการตั้งค่าที่เผยแพร่นั้นให้บริการทีละลำดับ ดังนั้นสูตรนี้จึงอธิบายการกำหนดค่าความหน่วงแบบสตรีมเดียว ไม่ใช่การกำหนดค่าเพื่อปริมาณงาน และโหมดดาวน์แซมเปิลภาพ 4x เป็นแบบที่ประหยัดกว่าจากสองแบบที่การ์ดแมโฆษณาไว้ — การ์ดเดียวกันยังมีรูปแบบผสม 4x/16x ที่แลกรายละเอียดเพื่อความเร็ว และสูตรนี้เลือกฝั่งของข้อแลกเปลี่ยนนั้นที่ให้น้ำหนักกับความเร็ว

ขอบเขตฮาร์ดแวร์อยู่ตรงกันข้ามกับการตลาดของตระกูลนี้ เป้าหมายขนาด 1B ใช้พื้นที่ประมาณ 2 GB ใน BF16 บวกกับ KV cache และดราฟต์เพิ่มอีก 0.85 GB ทับลงไป ดังนั้นนี่จึงเป็นงานบน GPU เดียว — การ์ดระดับผู้บริโภค หรือเวิร์กสเตชันที่มีหน่วยความจำรวมเพียงพอ — ไม่ใช่งานบนมือถือ ส่วนเส้นทางบนอุปกรณ์ในเอกสารของโมเดลแม่ต้องผ่านบิลด์แบบควอนไทซ์และเฟรมเวิร์กที่ไม่มีในสูตรนี้ และเช็กพอยต์ DSpark ตามที่เผยแพร่เป็นอาร์ติแฟกต์ฝั่งเซิร์ฟเวอร์แบบ BF16

นั่นทิ้งช่องว่างที่ทีมส่วนใหญ่จะเจอ: เวอร์ชันที่น่าสนใจของ MiniCPM-V 4.7-1B คือเวอร์ชันบนอุปกรณ์ และเวอร์ชันที่คุณรันได้วันนี้โดยไม่ต้องมีชุดเครื่องมือสำหรับมือถือคือเวอร์ชันฝั่งเซิร์ฟเวอร์ หากสิ่งที่คุณต้องการจริง ๆ ตอนนี้คือการอินเฟอเรนซ์แบบมัลติโมดัลขนาดเล็ก ตัวเลือกที่โฮสต์ไว้ซึ่งใกล้เคียงที่สุดคือโมเดลอื่น — Qwen3 VL 8B Instruct อยู่บน OrcaRouter ในราคา $0.18 ต่อล้านโทเคนอินพุต และ $0.70 ต่อล้านโทเคนเอาต์พุต โดยมีหน้าต่างบริบท 128K และรับข้อความ รูปภาพ และวิดีโอเป็นอินพุต ไม่มีเวตในเครื่องและไม่มีสูตรการเสิร์ฟที่ต้องคอยดูแลให้ทำงาน MiniCPM-V 4.7 ไม่ใช่โมเดลโฮสต์บน OrcaRouter และบทความนี้จะไม่แสร้งทำเป็นอย่างอื่น กรอบที่ซื่อตรงคือสิ่งเหล่านี้เป็นสองวิธีในการทำงานเดียวกัน และมีเพียงวิธีเดียวเท่านั้นที่วัดผลได้จากแค็ตตาล็อกในบ่ายวันนี้

จุดที่สิ่งอย่าง DSpark คุ้มค่าที่จะใช้คือกรณีของโมเดลที่ยังไม่ผ่านการพิสูจน์ และนั่นเป็นคำถามเรื่อง routing มากกว่าคำถามเรื่องโมเดล drafter ที่ยังไม่มีใครทำซ้ำได้สำเร็จนั้นเป็นองค์ประกอบแบบที่คุณอยากวางไว้หลัง endpoint ที่คุณถอยกลับไปพึ่งได้พอดี การรันโมเดล 200+ ตัวไว้หลังคีย์เดียว ราคาตามรายการของผู้ให้บริการส่งผ่านตรงโดยบวกเพิ่ม 0% พร้อม failover อัตโนมัติเมื่อเส้นทางใดเส้นทางหนึ่งเสื่อมประสิทธิภาพ หมายความว่าการทดลองให้บริการที่ผิดพลาดทำให้คุณเสียแค่การลองใหม่ ไม่ใช่ระบบล่ม — และเนื่องจากไม่มีการบวกกำไรใด ๆ การเปลี่ยนแปลงราคาของผู้ขายบนโมเดลใดก็ตามในแคตตาล็อกจึงมีผลทันทีในวันเดียวกัน ไม่ใช่รอถึงรอบบิลถัดไป

อะไรจะทำให้สิ่งนี้ตรวจสอบได้

มีสามสิ่งที่ขาดหายไป และมีเพียงหนึ่งในนั้นเท่านั้นที่ต้องใช้ OpenBMB

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

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

และคำถามเรื่องคุณภาพก็ยังไม่ถูกแตะต้องเลย ไม่มีคะแนน MMMU ไม่มีผลลัพธ์ OCRBench ไม่มีตัวเลขความเข้าใจเอกสาร และไม่มีตัวเลข grounding สำหรับ MiniCPM-V 4.7-1B ที่ใดเลยในรีลีส — ตาราง acceptance เป็นตารางเกี่ยวกับ decoding และการอ่านค่า acceptance length ที่สูงเป็นสัญญาณของคุณภาพก็คือข้อผิดพลาดที่ตัวเลขเหล่านั้นชักชวนให้เกิดนั่นเอง

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