LFM3-1.7B กับ Gemma 4 26B A4B: สองสูตรสำหรับโทเคนราคาถูก และมีเพียงสูตรเดียวที่ใส่ลงในโทรศัพท์ได้

ในทางทฤษฎี ทั้งสองโมเดลนี้ใช้แนวทางเดียวกันกับปัญหาเดียวกัน LFM3-1.7B ซึ่ง Liquid AI ประกาศเมื่อวันที่ 27 ตุลาคม 2026 และ Gemma 4 26B A4B ซึ่ง Google DeepMind เปิดตัวเมื่อวันที่ 2 เมษายน 2026 ทั้งคู่มีไว้เพื่อตอบคำถามข้อเดียว: จะทำให้โมเดลที่มีความสามารถพอดีกับงบหน่วยความจำที่จำกัดได้อย่างไร? ทั้งสองให้คำตอบที่ตรงกันข้าม Liquid ย่อโมเดลลง Google กลับคงโมเดลให้ใหญ่ไว้ และจ่ายเพียงบางส่วนของโมเดลต่อโทเค็นเท่านั้น ตัวน้ำหนักโมเดลนั้นฟรี ค่าใช้จ่ายจึงขึ้นอยู่กับราคาที่โฮสต์ที่มีความสามารถและถูกที่สุดเรียกเก็บ เราส่งต่อราคาตามรายการของผู้ให้บริการในอัตรามาร์กอัป 0%.

ความแตกต่างนี้ฟังดูเป็นเกร็ดเล็กเกร็ดน้อยทางสถาปัตยกรรม จนกว่าคุณจะประเมินต้นทุนการติดตั้งใช้งาน ถึงจุดนั้นมันจึงเป็นสิ่งเดียวที่สำคัญ Gemma 4 26B A4B เปิดใช้งานพารามิเตอร์ 3.8 พันล้านตัวต่อโทเค็น แต่คุณยังต้องเก็บพารามิเตอร์ 25.2 พันล้านตัวนั้นไว้ที่ไหนสักแห่ง LFM3-1.7B เปิดใช้งานพารามิเตอร์ทั้งหมด 1.73 พันล้านตัว และจัดเก็บไว้จำนวนนั้นพอดี ตัวหนึ่งมีต้นทุนการคำนวณต่ำ อีกตัวมีต้นทุนต่ำในการเป็นเจ้าของ.

สองสูตรสำหรับโทเค็นราคาถูก

Gemma 4 26B A4B เป็นโมเดลแบบ mixture-of-experts: มี routed experts 128 ตัว บวก shared expert หนึ่งตัว, 30 เลเยอร์ โดยมีผู้เชี่ยวชาญประมาณแปดตัวทำงานต่อโทเคน ซึ่งให้ความจุความรู้เทียบเท่าโมเดล dense ขนาด 25.2B และต้นทุนการคำนวณใกล้เคียงกับโมเดลขนาด 4B กรอบการนำเสนอของ Google เองระบุว่ามันทำคะแนน MMLU-Pro ได้ประมาณ 97% ของ Gemma 4 31B แบบ dense โดยใช้ FLOPs เพียงประมาณ 12%

LFM3-1.7B ไปอีกเส้นทางหนึ่ง โมเดลนี้เป็นแบบ fully dense — ทุกพารามิเตอร์ทำงานบนทุกโทเคน — และการประหยัดที่ได้มาจากสถาปัตยกรรมที่ออกแบบใหม่ ไม่ใช่จากการทำให้เบาบาง สแต็กไตรไฮบริดของ Liquid มี 24 เลเยอร์: คอนโวลูชันสั้นแบบเกต 13 เลเยอร์, เลเยอร์แอตเทนชันแบบหน้าต่างเลื่อน 5 เลเยอร์ และเลเยอร์ฟูลแอตเทนชัน 6 เลเยอร์ การจำลองลำดับส่วนใหญ่ทำโดยคอนโวลูชันซึ่งมีต้นทุนต่ำ และฟูลแอตเทนชันปรากฏเพียงหกครั้งเท่านั้น นี่คือวิธีที่โมเดลขนาด 1.73B รองรับบริบท 262,144 โทเคนและคำศัพท์ 128,000 โทเคนได้ โดยที่ KV cache ไม่กินทรัพยากรเครื่องจนเกินไป

• จำนวนพารามิเตอร์ทั้งหมด — 1.73B สำหรับ LFM3-1.7B; 25.2B สำหรับ Gemma 4 26B A4B

• แอ็กทีฟต่อโทเคน — 1.73B เทียบกับประมาณ 3.8B นี่เป็นแถวเดียวที่ทั้งสองอยู่ในระดับเดียวกัน

• หน่วยความจำที่ 4 บิต — ประมาณ 1 GB เทียบกับประมาณ 18 GB นี่คือแถวที่ใช้ตัดสินการนำไปใช้งาน

• บริบท — 262,144 โทเค็นทั้งสองฝั่ง ถือเป็นการเสมอกันจริง ๆ อีกครั้ง

• รูปแบบข้อมูล — ข้อความเท่านั้น เมื่อเทียบกับอินพุตข้อความและรูปภาพ พร้อมการเรียกใช้ฟังก์ชันแบบเนทีฟและโหมดการคิดที่กำหนดค่าได้

• สัญญาอนุญาต — LFM Open License v1.0 ใช้งานฟรีเมื่อรายได้ต่อปีต่ำกว่า 10 ล้านดอลลาร์; Apache 2.0 โดยไม่มีเกณฑ์ขั้นต่ำสำหรับ Gemma 4 26B A4B

ทำไม 3.8B active จึงไม่ได้หมายความว่าจะใช้หน่วยความจำ 3.8B

นี่คือข้อผิดพลาดที่พบบ่อยที่สุดในการอ่านสเปกชีตแบบ mixture-of-experts จึงควรพูดให้ตรง ๆ ว่า พารามิเตอร์ที่ใช้งานอยู่ (active parameters) เป็นตัวกำหนดการประมวลผล และคร่าว ๆ ก็คือความเร็ว แต่ไม่ได้เป็นตัวกำหนดขนาดไฟล์ที่คุณดาวน์โหลดหรือ VRAM ที่คุณจองไว้ Gemma 4 26B A4B จำเป็นต้องมีพารามิเตอร์ทั้ง 25.2 พันล้านตัวอยู่ในหน่วยความจำเพื่อใช้ในการเลือกเส้นทางระหว่าง expert; ที่ 4-bit จะอยู่ที่ประมาณ 18 GB คุณสามารถให้บริการมันบนการ์ด 24 GB เพียงใบเดียวได้ และ Google มีบิลด์ FP8 และ NVFP4 เพื่อทำให้เรื่องนี้ใช้งานได้จริง แต่คุณไม่สามารถใส่มันลงในโทรศัพท์ได้

LFM3-1.7B มีขนาดประมาณ 1 GB ที่ 4-bit — เอกสารสเปกของ Liquid ระบุว่ามันใส่ได้ในโทรศัพท์หรือแล็ปท็อป และด้วยขนาดเท่านี้ ข้อกล่าวอ้างนั้นจึงน่าเชื่อถือมากกว่าจะเป็นการตลาด มันยังใช้ KV cache ขนาด 1.6 GB ที่ 128K โทเค็น ซึ่งเป็นตัวเลขที่กำหนดจริง ๆ ว่าคุณรองรับคำขอแบบบริบทยาวที่ทำงานพร้อมกันได้กี่คำขอ

ผลที่ตามมาในทางปฏิบัติคือ การติดตั้งใช้งาน 26B-A4B เป็นการตัดสินใจระดับเซิร์ฟเวอร์สำหรับการอนุมาน ส่วนการติดตั้งใช้งาน 1.7B เป็นการตัดสินใจระดับการส่งมอบแอปพลิเคชัน สองสิ่งนี้เป็นโปรเจกต์ที่แตกต่างกัน มีทีมต่างกัน และมีโครงสร้างต้นทุนต่างกัน และไม่มีเบนช์มาร์กใดที่ปิดช่องว่างระหว่างทั้งสองได้

สิ่งที่ผู้จำหน่ายแต่ละรายเผยแพร่ และสิ่งนั้นบอกอะไรกับคุณ

Google เผยแพร่ตารางขนาดใหญ่สำหรับ Gemma 4 26B A4B: 82.6 บน MMLU-Pro, 82.3 บน GPQA Diamond, 88.3 บน AIME 2026 โดยไม่ใช้เครื่องมือ, 77.1 บน LiveCodeBench v6, Codeforces Elo 1718, 73.8 บน MMMU-Pro และ 44.1 บน MRCR v2 ที่ 128K ด้วยเข็มแปดเข็ม ทั้งหมดเป็นข้อมูลที่ผู้พัฒนารายงานเอง ไม่มีรายการใดถูกทำซ้ำโดยอิสระ การติดตามโดยบุคคลที่สามระบุว่า Elo บน LMArena อยู่ใกล้ 1438

Liquid ได้เผยแพร่ตารางที่แคบกว่าสำหรับ LFM3-1.7B และตารางนี้เอนเอียงไปทางงานแบบเอเจนต์: 71.39 บน BFCL V4, 80.36 บน ToolSandbox, 68.01 บน τ³-bench, 45.60 บน LiveClaw, 38.42 บน WebArena-Verified นอกจากนี้ยังรายงาน 96.66 บน IFEval, 73.03 บน IFBench, 63.37 บน GPQA Diamond, 73.46 บน LiveCodeBench v6 และ 65.56 บน RULER ที่ 128K Liquid ไม่ได้เผยแพร่ตัวเลข MMLU-Pro สำหรับ LFM3-1.7B และการที่ไม่มีตัวเลขนั้นไม่ใช่ศูนย์ แต่เป็นเพียงแค่ไม่ได้วัดเท่านั้น

มีเพียง LiveCodeBench v6 และ GPQA Diamond เท่านั้นที่ทับซ้อนกันอย่างลงตัว Gemma 4 26B A4B ชนะทั้งสองรายการ ด้วย 3.6 และ 18.9 คะแนนตามลำดับ ในจุดที่ชุดทดสอบของ Liquid เน้นไปทางเอเจนต์ ไม่มีตัวเลขของ Gemma ให้เปรียบเทียบ — Google รายงาน τ²-bench ที่ 68.2 และ τ² ไม่ใช่ τ³ ดังนั้นการนำ 68.01 ไปวางเทียบข้างกันจะเป็นการเปรียบเทียบที่ถูกกุขึ้นและถูกแต่งให้ดูราวกับเป็นการเปรียบเทียบอย่างรอบคอบ

จุดที่ 1.7B คงอยู่ในบทสนทนา

ช่องว่าง 3.6 คะแนนใน LiveCodeBench นั้นเล็กกว่าที่อัตราส่วนพารามิเตอร์ 14 ต่อ 1 จะทำนายไว้ และเหตุผลก็เป็นเรื่องสถาปัตยกรรม การเขียนโปรแกรมเชิงแข่งขันให้รางวัลกับความสามารถในการจดจำรูปแบบและสร้างฟังก์ชันที่ถูกต้อง ซึ่งเป็นทักษะที่ได้ประโยชน์จากสัญญาณการฝึกที่สะอาดมากกว่าความจุดิบ ถ้าคำถามด้านการเขียนโค้ดเป็นงานทั้งหมด 26B จะชนะ และส่วนนี้จะสั้น

สิ่งที่ทำให้ LFM3-1.7B ยังคงมีความเกี่ยวข้องจริง ๆ คือการรวมกันของบริบท 262,144 โทเคนกับขนาดเพียง 1 GB โมเดลที่รองรับเอกสารขนาดใหญ่และทำงานบนอุปกรณ์ที่กำลังอ่านเอกสารนั้นได้ถือเป็นผลิตภัณฑ์ที่แตกต่างจากโมเดลที่รองรับเอกสารเดียวกันได้บนเซิร์ฟเวอร์ Liquid รายงานคะแนน 65.56 บน RULER ที่ 128K ซึ่งไม่ใช่คะแนนบริบทยาวที่โดดเด่น — Gemma 4 26B A4B รายงาน 81.4 บนตระกูลเบนช์มาร์กเดียวกัน — แต่ก็ยังมีการวัดจริง บนอุปกรณ์ ที่ขนาดหนึ่งกิกะไบต์

และในด้านการปฏิบัติตามคำสั่ง โมเดลขนาดเล็กนี้ไม่ได้เป็นรองเลย: 96.66 บน IFEval และ 73.03 บน IFBench ถือเป็นตัวเลขที่แข็งแกร่งสำหรับขนาดระดับนี้ โดยทั้งสองค่าเป็นข้อมูลที่ผู้ขายรายงานเอง สำหรับงานประเภท tool-calling หรือ structured-output ค่านี้ใกล้เคียงกับเมตริกที่สำคัญกว่ามากเมื่อเทียบกับ GPQA Diamond

สิ่งที่เลเยอร์การกำหนดเส้นทางเปลี่ยนแปลงจริง ๆ

Gemma 4 26B A4B อยู่ในแค็ตตาล็อกของ OrcaRouter — API คีย์เดียวก็เข้าถึงโมเดลนี้ได้พร้อมกับโมเดลอื่นอีกกว่า 200 โมเดล โดยราคาตามรายการของผู้ให้บริการถูกส่งต่อโดยบวกกำไร 0% ดังนั้นเมื่อผู้ขายเปลี่ยนราคา การเปลี่ยนแปลงจะมีผลในวันเดียวกัน แทนที่จะต้องรอรอบการปรับราคาใหม่ เรื่องนี้สำคัญในกรณีนี้มากกว่าปกติ เพราะนี่คือโมเดลที่เศรษฐศาสตร์ทั้งหมดขึ้นอยู่กับราคาของผู้ให้บริการ: น้ำหนักโมเดลฟรี ค่าใช้จ่ายจึงเป็นเท่าใดก็ตามที่โฮสต์ที่มีความสามารถและถูกที่สุดเรียกเก็บ และตัวเลขนั้นก็เปลี่ยนแปลงอยู่เสมอ

การ failover อัตโนมัติคืออีกครึ่งหนึ่ง โมเดล mixture-of-experts ขนาด 26B ที่มีบริบท 256K ถือเป็นภาระงานแบบที่ชนกำแพงขีดความสามารถในช่วงพีคพอดี และการกำหนดเส้นทางข้ามผู้ให้บริการหมายความว่าช่วงบ่ายที่แย่ของโฮสต์เดียวไม่ใช่ระบบล่มของคุณ LFM3-1.7B ไม่จำเป็นต้องมีสิ่งใดเหล่านี้เลย เพราะมันทำงานบนฮาร์ดแวร์ที่คุณควบคุมเองและไม่มีผู้ให้บริการให้ต้อง fail over จาก ที่ไม่ใช่ทั้งข้อดีหรือข้อเสียของมัน — มันเป็นผลสืบเนื่องจากการเลือกสูตรอีกแบบหนึ่ง

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

ตัดสินใจในครั้งเดียว

หากเป้าหมายการติดตั้งใช้งานมีหน่วยความจำน้อยกว่า 20 GB — โทรศัพท์ แล็ปท็อป Jetson หรือ AI PC — แสดงว่า Gemma 4 26B A4B ไม่ใช่ตัวเลือก และการเปรียบเทียบก็จบลงเพียงเท่านี้ ให้เลือก LFM3-1.7B วางแผนการดึงข้อมูล (retrieval) โดยคำนึงถึงช่องว่างทางความรู้ที่ Liquid เองชี้ให้เห็น และใช้มันสำหรับการเรียกใช้เครื่องมือ (tool calling) และการสกัดข้อมูลแบบมีโครงสร้าง (structured extraction) ในจุดที่ตัวเลขของมันแข่งขันได้จริง

หากคุณให้บริการจาก GPU และภาระงานนั้นใช้ความรู้เข้มข้น เป็นมัลติโมดัล หรือต้องการระดับการให้เหตุผลแบบ 82.3 GPQA Diamond และ 82.6 MMLU-Pro แล้ว Gemma 4 26B A4B คือโมเดลที่ดีกว่า และ 18 GB คือต้นทุนที่ต้องจ่ายเพื่อเข้าใช้งาน Apache 2.0 ตัดประเด็นเรื่องลิขสิทธิ์ออกไปทั้งหมด ซึ่งสำหรับองค์กรขนาดใหญ่แล้วมีค่ามากกว่าคะแนน benchmark ไม่กี่คะแนน

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

ประเด็นที่ยังไม่มีคำตอบไม่ใช่เรื่องความสามารถ ซึ่งตัดสินไปในทางที่ Google ได้เปรียบแล้ว แต่เป็นเรื่องว่าโมเดลขนาด 1 GB ที่มีบริบท 256K นั้นดีพอสำหรับงานเอเจนต์แบบแคบ ๆ ที่ผลิตภัณฑ์บนอุปกรณ์ส่วนใหญ่ต้องการจริงหรือไม่ การ์ดโมเดลของ Liquid เองก็ตรงไปตรงมาอย่างผิดปกติว่าโมเดลนี้ไม่ใช่โมเดลสำหรับการให้เหตุผล ความตรงไปตรงมานั้นมีค่ามากกว่าช่องว่างของ LiveCodeBench เพราะมันบอกคุณว่าครึ่งใดของภาระงานของคุณควรส่งไปที่ไหน