SubQ Snap 1.1 vs Granite 4.2 3B: ราคาต่อโทเคนคือใบเรียกเก็บเงินที่ผิด

ของ IBMGranite 4.2 3B มีราคาอยู่ที่ $0.03 ต่อหนึ่งล้านโทเค็นอินพุต SubQ Snap 1.1 มีราคาอยู่ที่ $0.04 หากอัตราต่อโทเค็นคือยอดที่ต้องจ่าย โมเดล Apache-2.0 ขนาด 3 พันล้านพารามิเตอร์ก็จะเอาชนะโมเดลตัดสินใจที่ได้อันดับหนึ่งร่วมบน Artificial Analysis Decision Index v1.0 และบทความนี้ก็จะสั้น แต่ราคาต่อโทเค็นไม่ใช่ยอดที่ต้องจ่าย เมื่อคุณคิดราคาเป็นการตัดสินใจหนึ่งครั้งแทนที่จะเป็นโทเค็น — รวมถึงสิ่งที่แต่ละโมเดลต้องส่งออกเพื่อสร้างการตัดสินใจหนึ่งครั้ง — อันดับก็พลิก แล้วพลิกกลับ ขึ้นอยู่กับการตั้งค่าคอนฟิกเพียงรายการเดียว และไปจบลงตรงจุดที่ไม่มีผู้ขายรายใดโฆษณาไว้

Granite 4.2 3B เป็นโมเดลการให้เหตุผลแบบ dense ขนาดเล็กของ IBM เปิดตัวเมื่อวันที่ 25 สิงหาคม 2026 พร้อมกับรุ่นพี่น้อง 8B และ 30B โดยแทบไม่มีกระแสประชาสัมพันธ์เลย — เป็นเพียงโพสต์บล็อกทางเทคนิคแทนที่จะเป็นงานเปิดตัว Snap 1.1 เป็นโมเดลตัดสินใจของ Subquadratic ที่ใช้งานจริงตั้งแต่ 22 ตุลาคม 2026 ซึ่งจะคืนค่าตัวเลือกหนึ่งจากชุดคำตอบที่กำหนดไว้แทนการสร้างข้อความ ทั้งสองโมเดลทับซ้อนกันในงานเพียงหนึ่งประเภทเท่านั้น: การนำข้อความบางส่วนมาตัดสินใจว่ามันคืออะไร ส่วนเรื่องอื่น ๆ นั้นแตกต่างกันทั้งหมด รวมถึงความหมายของคำว่า "ราคาถูก" ด้วย

ก่อนอื่น สองโมเดลนี้คืออะไรกันแน่

Granite 4.2 3B เป็นตัวถอดรหัสแบบ dense ที่มีพารามิเตอร์สามพันล้านตัว สร้างบนพื้นฐานของ Granite-4.1-3B-Base เป็นโมเดลเชิงเหตุผลที่มีสามโหมด ได้แก่ โหมดคิดที่สร้างสายการคิด โหมดความพยายามต่ำ และโหมดไม่คิดที่ตอบโดยตรง IBM รายงานว่า AIME 2025 อยู่ที่ 78.33, GPQA อยู่ที่ 54.80, LiveCodeBench v6 อยู่ที่ 69.71, MMLU-Pro อยู่ที่ 67.84, IFBench อยู่ที่ 74.3 และ τ³-Bench อยู่ที่ 45.8 — ทั้งหมดเป็นตัวเลขจากผู้จำหน่าย ไม่มีตัวเลขใดได้รับการทำซ้ำอย่างอิสระ ในบริบทแบบยาว มีรายงานค่า RULER ที่ 67.52 ที่ 64K และ 55.30 ที่ 128K Artificial Analysis จัดให้ Intelligence Index อยู่ที่ 9 ซึ่งไม่โดดเด่นเมื่อเทียบในเชิงสัมบูรณ์ และสูงกว่าค่ามัธยฐานของกลุ่มขนาดเดียวกัน

เรื่องฮาร์ดแวร์คือส่วนที่น่าสนใจ มันทำงานที่หน่วยความจำ 6 ถึง 8 กิกะไบต์ใน bf16 และต่ำกว่า 2 กิกะไบต์เมื่อควอนไทซ์ ซึ่งหมายความว่ามันใช้งานได้บนแล็ปท็อป, GPU สำหรับผู้บริโภคตัวเดียว หรือ CPU ที่มี RAM เพียงพอ มันรองรับเฉพาะข้อความ ครอบคลุม 12 ภาษา รองรับการเรียกใช้เครื่องมือที่เข้ากันได้กับ OpenAI และมีให้ใช้งานใน vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX และ Ollama หากข้อจำกัดของคุณคือ "ต้องรันในที่ที่ฉันควบคุมได้" โมเดลนี้ผ่านเกณฑ์นั้น

SubQ Snap 1.1 เป็นผลิตภัณฑ์ที่อยู่ตรงข้ามในแทบทุกมิติ มันไม่มีเวต รันผ่าน API ของ Subquadratic เท่านั้น รองรับข้อความและรูปภาพได้สูงสุด 384K tokens พร้อมชุดคำตอบที่มีทางเลือกตั้งแต่ 2 ถึง 255 ทางเลือก และส่งคืนผลการเลือกหนึ่งรายการพร้อมความน่าจะเป็นที่ปรับเทียบแล้ว มันไม่สามารถเขียนประโยคได้ ซึ่งนั่นคือจุดสำคัญ: ไม่มีเอาต์พุตให้แยกวิเคราะห์ และไม่มีเอาต์พุตให้ต้องจ่ายเงิน

กับดักโทเค็นเอาต์พุต

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

• Granite 4.2 3B ในโหมดไม่คิด — โทเค็นอินพุต 6B ที่ $0.03/M คิดเป็น $180 บวกโทเค็นเอาต์พุตประมาณห้าโทเค็นต่อการตัดสินใจ หรือโทเค็นเอาต์พุต 5M ที่ $0.12/M คิดเป็น $0.60 รวม: ประมาณ $180.60

Granite 4.2 3B ในโหมดคิด — อินพุต 6B ที่ $180 บวกกับโทเคนการให้เหตุผลอีกประมาณ 800 โทเคนต่อการตัดสินใจ หรือโทเคนเอาต์พุต 800M ที่ $0.12/M เป็นเงิน $96 รวม: ประมาณ $276

• SubQ Snap 1.1 — 6B โทเค็นอินพุตที่ $0.04/M คิดเป็น $240 และไม่มีบรรทัดเอาต์พุตเลย

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

นี่ไม่ใช่ความเสี่ยงเชิงทฤษฎี โปรไฟล์อิสระของ Granite 4.2 3B จาก Artificial Analysis เรียกโมเดลนี้ว่า “ละเอียดเกินจำเป็นมาก” และบันทึกว่าโมเดลสร้างโทเคนเอาต์พุต 92 ล้านโทเคนระหว่างได้รับการประเมินบน Intelligence Index เทียบกับค่ามัธยฐานที่ 67 ล้านโทเคนสำหรับโมเดลที่เทียบเคียงได้ ความละเอียดเกินจำเป็นนี้เป็นคุณสมบัติที่วัดได้ของโมเดลในโหมดการให้เหตุผล และเป็นคุณสมบัติที่ตัดสินว่าข้อได้เปรียบด้านราคาต่อโทเคนจะยังคงอยู่เมื่อเผชิญกับภาระงานการจัดเส้นทางหรือไม่

นั่นยังอธิบายตัวเลขที่ดูผิดตั้งแต่แรกได้ด้วย Artificial Analysis ระบุว่า Snap 1.1 อยู่ที่ประมาณ $30 ต่อล้านงาน เทียบกับ $8.4 สำหรับ Elephant 9B สามสิบดอลลาร์ต่อล้านงานบ่งชี้ว่างานเฉลี่ยสั้นมาก อยู่ในระดับไม่กี่พันโทเค็น ชุดเบนช์มาร์กของ Decision Index นั้นสั้น ทิกเก็ต สัญญา และบันทึกของคุณไม่สั้น และต้นทุนจะเพิ่มขึ้นเชิงเส้นตามความยาวอินพุตจากจุดนั้น ให้ถือว่าตัวเลขต่องานเป็นคุณสมบัติของเบนช์มาร์ก ไม่ใช่ราคาที่เสนอ

จุดที่ 3B ชนะอย่างแท้จริง

โทเค็นที่ราคาถูกกว่านั้นเป็นเรื่องเล็กที่สุด Granite 4.2 3B สามารถโฮสต์เองได้ภายใต้ Apache 2.0 ซึ่งหมายความว่าเมื่อจ่ายค่าฮาร์ดแวร์แล้ว จะไม่มีค่าใช้จ่ายต่อการเรียกใช้งานเลย ข้อมูลไม่ต้องออกจากเครือข่ายของคุณ ไม่มีข้อจำกัดอัตราการใช้งาน และไม่มีผู้ขายรายใดที่สามารถเปลี่ยนราคาหรือเปลี่ยนโมเดลใต้ตัวคุณได้ สำหรับเวิร์กโฟลว์ที่ต้องปฏิบัติตามข้อกำหนด นี่ไม่ใช่ตัวเลือกเสริม แต่เป็นข้อกำหนด และ Snap 1.1 ไม่สามารถก้าวเข้าสู่พื้นที่นั้นได้เลย

นอกจากนี้ยังทำได้มากกว่านั้นอีก โดยจะเขียนสรุปหลังจากตัดสินใจจัดเส้นทางแล้ว รองรับการเรียกเครื่องมือด้วยสคีมา และรองรับการขยายบริบทแบบเลือกเปิดใช้ไปถึง 512K ซึ่งเพิ่มเข้ามาในระยะก่อนฝึกที่ห้า ในทางทฤษฎีแล้วยาวกว่า 384K ของ Snap — แม้ว่าคะแนน RULER ที่ลดลงจาก 67.52 ที่ 64K เหลือ 55.30 ที่ 128K จะเป็นคำเตือนที่ตรงไปตรงมาว่าใช้ประโยชน์จากหน้าต่างบริบทนั้นได้มากเพียงใด และมีขนาดเล็กพอที่จะรันที่ edge ในคอนเทนเนอร์ข้างแอปพลิเคชันของคุณ โดยไม่ต้องกระโดดผ่านเครือข่ายระหว่างการตัดสินใจกับการลงมือทำ

จุดที่ Snap 1.1 ชนะอย่างแท้จริง

สามสิ่งที่โมเดลเชิงกำเนิดขนาด 3B ทำได้ไม่ดีโดยโครงสร้าง

การสอบเทียบคือสิ่งแรก Snap 1.1 รายงานค่าความคลาดเคลื่อนในการสอบเทียบที่คาดหวังไว้ที่ 0.014 ลดลงจาก 0.108 ในพรีวิว และอัตราการไม่ตอบที่ 86% สำหรับคำถามที่ไม่สามารถตอบได้ — เทียบกับคะแนนการไม่ฮัลลูซิเนต 0.7% ของรุ่น 1.0 ของตัวเองบนพร็อกซีของผู้ขาย ตัวเลขเหล่านี้เป็นตัวเลขจากผู้ขายและควรอ่านในฐานะนั้น แต่ตัวเลขเหล่านี้อธิบายโมเดลที่ถูกฝึกโดยมีการไม่ตอบเป็นวัตถุประสงค์ที่ชัดเจน โมเดลการให้เหตุผลขนาด 3B ไม่มีเป้าหมายเช่นนั้น ถามมันว่าทิกเก็ตหนึ่งตอบได้หรือไม่ และมันจะสร้างประโยคที่ฟังดูสมเหตุสมผลไม่ว่าจะกรณีใด

พฤติกรรมแบบ single-pass บนบริบทยาวเป็นประเด็นที่สอง Snap ประมวลผล 384K โทเคนใน forward pass ครั้งเดียวด้วยปริมาณการคำนวณต่อโทเคนคงที่ ซึ่งเป็นเหตุผลรองรับทั้งหมดของ Subquadratic Sparse Attention การลดลงของ RULER ใน Granite เป็นพฤติกรรมปกติของโมเดลแบบ dense ที่ความยาวสิบเท่าของความยาวที่โมเดลทำงานได้สบาย หากการตัดสินใจของคุณขึ้นอยู่กับบางสิ่งที่ถูกฝังอยู่ที่ตำแหน่ง 200,000 ในชุดล็อก ความแตกต่างทางสถาปัตยกรรมก็ไม่ใช่เรื่องทางวิชาการ

ความแน่นอนของรูปแบบผลลัพธ์เป็นข้อที่สาม และเป็นสิ่งที่ถูกมองข้าม Snap จะคืนค่าเป็นตัวเลขหนึ่งค่าจากรายการตัวเลือกของคุณ Granite คืนข้อความที่คุณต้องนำไปแยกวิเคราะห์ในภายหลัง และทุก parser คือจุดที่คำตอบซึ่งผิดรูปแบบสามารถกลายเป็นเหตุระบบล่มได้ การถอดรหัสแบบมีข้อจำกัด (constrained decoding) ปิดช่องว่างนั้นได้เกือบทั้งหมด ซึ่งเป็นเรื่องที่ควรพูดถึง — มันไม่ใช่ข้อได้เปรียบเชิงพื้นฐาน แต่เป็นความแตกต่างในปริมาณ scaffolding ที่คุณต้องเขียน

คำถามเกี่ยวกับการตั้งค่าที่ไม่มีใครถาม

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

กลไกควบคุมที่เทียบเท่ากันของ Snap กลับตรงกันข้าม: คุณต้องให้ตัวเลือกที่น้อยลงแต่คมชัดขึ้น API ของมันจำกัดคำถามไว้ที่ 16 ข้อ และตัวเลือกไว้ที่ 255 ตัวต่อคำถาม และความแม่นยำบน Decision Index อยู่ที่ 20% — ต่ำกว่า 32% ของ d1-ultra — โดยคะแนนดัชนีได้มาจากการงดตอบเป็นหลัก เมื่อจำกัดชุดคำตอบ ปัญหาความแม่นยำก็ลดลง หากให้มันตัดสินใจแบบปลายเปิด มันจะปฏิเสธที่จะตอบอย่างถูกต้องและบ่อยครั้ง

สิ่งที่ฉันจะสร้างจริง ๆ

สำหรับไปป์ไลน์งานสนับสนุนหรือเอกสารในปริมาณที่มีนัยสำคัญ การออกแบบที่ประหยัดที่สุดและมีเหตุผลรองรับได้คือแบบสองขั้นตอน Granite 4.2 3B ทำงานในโหมด non-thinking เป็นตัวจำแนกด่านแรกสำหรับส่วนใหญ่ที่ง่าย — ตั๋วที่เป็นเรื่องขอคืนเงินชัด ๆ เหตุขัดข้องชัด ๆ สแปมชัด ๆ — ซึ่งโมเดล 3B ให้ความแม่นยำและมีต้นทุนส่วนเพิ่มเป็นศูนย์ Snap 1.1 รับส่วนที่เหลือ: เธรดยาว ๆ กรณีกำกวม กรณีที่คำตอบที่ถูกอาจเป็น "ส่งต่อ" และการเดาอย่างมั่นใจนั้นแย่กว่าการปฏิเสธ คุณจ่าย $0.04 ต่อล้านโทเค็นเฉพาะสัดส่วนที่จำเป็นเท่านั้น และคุณได้ความน่าจะเป็นที่ปรับเทียบแล้วในจุดตัดสินใจที่การปรับเทียบมีความสำคัญพอดี

ไม่มีผู้ขายรายใดขายดีไซน์นั้น เพราะแต่ละรายต้องการเป็นทั้งเลเยอร์ Granite 4.2 3B ไม่ได้อยู่ในแคตตาล็อกของ OrcaRouter — มันเป็น Apache 2.0 ดังนั้นการโฮสต์เองจึงเป็นเส้นทางปกติ และยังมีผู้ให้บริการ inference หลายรายให้บริการอยู่ด้วย Snap 1.1 ก็ไม่ใช่ของเราเช่นกัน; มันทำงานผ่าน API ของ Subquadratic เอง สิ่งที่ OrcaRouter มีส่วนช่วยในดีไซน์แบบนี้คือชั้นการสร้างที่อยู่เบื้องหลัง: โมเดล 200+ รายการภายใต้คีย์เดียว ราคาตามรายการของผู้ให้บริการส่งต่อโดยไม่มีส่วนเพิ่ม 0% และการสลับเมื่อล้มเหลวอัตโนมัติ ดังนั้นโมเดลที่เขียนสรุปการยกระดับจึงไม่ใช่ dependency เดียวกับโมเดลที่ตัดสินใจยกระดับ

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