Studio · Bench
งานใดควรอยู่บนเครื่องของคุณ — และการตัดสินนั้นอ้างอิงการวัดของใคร
Bench ตอบด้วยการวัดเครื่องที่คุณมีจริง แทนการอ่าน model card แล้วตรึงคำตอบไว้ในโปรไฟล์ที่มีเวอร์ชันและบอกได้เมื่อข้อมูลหมดอายุ
นี่ไม่ใช่ “รันโมเดลในเครื่องแทนคลาวด์”
โมเดล frontier ยังมีบทบาทและคุ้มราคาในงานที่ความผิดพลาดมีต้นทุนสูง — การออกแบบ ดีบักยาก และรีวิว แต่ไม่คุ้มกับงานเชิงกลตรงกลาง เช่น ย้ายแพตเทิร์น สรุป สร้างโครง และงานซ้ำจำนวนมากที่คิดเงินต่อโทเค็น
คำถามไม่ใช่ว่าจะย้ายงานหรือไม่ แต่คือจะย้าย งานใด — ซึ่งขึ้นกับฮาร์ดแวร์เฉพาะของคุณและไม่มีใครบอกล่วงหน้าได้
เราไม่อาจรู้ชุดติดตั้งในเครื่องที่ถูกต้องล่วงหน้า ต้องวัดบนเครื่องจริง และช่องว่างระหว่างการเดากับการวัดใหญ่พอจะเปลี่ยนสิ่งที่คุณซื้อ
วัดจริง ไม่ใช่เดา
สี่โมเดล หนึ่งโหนด unified memory 128 GB และ llama.cpp ผ่าน Vulkan/RADV แม้ GLM-4.5-Air ดูเป็นตัวเลือกเรือธง แต่บนเครื่องนี้สร้างผลลัพธ์ ช้ากว่า 2.1× เทียบกับ gpt-oss-120b — วัดได้ 2.12× สองครั้งและต่างกันไม่ถึงหนึ่งในสิบของส่วนเบี่ยงเบนมาตรฐาน การประมวลผล prompt ก็ช้ากว่าสองเท่า (2.11–2.25) และมีน้ำหนักมากกว่าราว 9 GiB ไม่มี model card ใดบอกเรื่องนี้ เพราะไม่ได้อธิบายเครื่องของคุณ
หนึ่งโหนด สี่โมเดล สามมาตรวัด
โหนด unified memory 128 GB ระดับ Ryzen AI Max+ 395, llama.cpp + Vulkan/RADV, Q4_K_M ยกเว้น gpt-oss-120b ที่เป็น MXFP4 โดยกำเนิด ใช้ llama-bench -p 512 -n 128 -ngl 999 -fa 1 -ctk q8_0 -ctv q8_0 และ f16 KV สำหรับ kimi-linear ที่ quantise ไม่ได้ ทุกพาเนลเรียงตามความเร็วการสร้าง
| โมเดล | pp512 t/s | tg128 t/s | น้ำหนัก GiB | โหลดเย็น s | อุ่น s |
|---|
ตัวเลขเหล่านี้อธิบายเครื่องหนึ่งเครื่องภายใต้ชุด flag หนึ่งชุด เป็นหลักฐานว่าการวัดสำคัญ ไม่ใช่คำทำนายสำหรับฮาร์ดแวร์ของคุณ ขนาดหน่วยความจำเทียบกันได้เพราะไบต์คือไบต์ แต่ throughput เทียบไม่ได้ การสอบเทียบจะสร้างตัวเลขของคุณเอง ก่อนหน้านั้นเราเลือกไม่แสดงอะไรดีกว่าแสดงตัวเลขของคนอื่น
สิ่งที่ model card บอกไม่ได้
ห้าสิ่งที่ปรากฏเมื่อรันจริงเท่านั้น ไม่มีในสเปก และแต่ละข้อเปลี่ยนการตัดสินใจ
Cold load ช้ากว่า warm load ราว 23×
GLM-4.5-Air ใช้ 42.19 วินาทีจากดิสก์ เทียบกับ 1.85 วินาทีแบบ warm — และนี่คือช่องว่างที่ แคบที่สุด ในสี่โมเดล อัตราส่วนนี้ต่างหากที่กำหนดว่าจะรวมงานเป็นชุดหรือสลับกัน เป็นนโยบายคิวที่ซ่อนอยู่ในเวลาโหลด
ความสำเร็จที่จริงแล้วล้มเหลว
เมื่อ token budget น้อยเกินไป โมเดล reasoning ส่ง HTTP 200 พร้อมเนื้อหาว่าง เพราะโทเค็นถูกใช้กับการคิดหมด ไม่มี error และ pipeline บันทึกว่าสำเร็จแล้วเดินต่อ
หนึ่งโมเดล quantise KV cache ไม่ได้เลย
head dimension ของ Kimi-Linear คือ 72 แต่ block size ของ q8_0 คือ 32 นี่เป็นข้อจำกัดตายตัว ไม่ใช่พารามิเตอร์ปรับแต่ง และจะรู้ได้เมื่อรันจริง
ความสามารถมีเพดานที่วัดได้
coder ระดับ 30B ทำงานไฟล์เดียวได้ดีอย่างสม่ำเสมอ แต่ล้มเมื่อเกินกว่านั้น เพดานนี้วัดได้ ไม่ได้คำนวณจากจำนวนพารามิเตอร์บนกล่อง
เครื่องรายงานหน่วยความจำของตัวเองผิด
หน่วยความจำที่ GPU มองเห็นมีค่าเริ่มต้น 60.61 จาก 121.21 GiB — ครึ่งหนึ่งพอดี เพราะ ttm_global_init() ในเคอร์เนลทำ num_pages /= 2 มาตั้งแต่ 6.1 ไม่ใช่ความเสียหายหรือ build ผิด แต่เป็นค่าเริ่มต้นทั่วไป หลังเพิ่ม boot parameter หนึ่งตัว ได้ 112 GiB และโมเดล 120B ที่ว่า “ใส่ไม่ลง” ก็ใส่ได้
สิ่งที่สวนทางความรู้สึกคือคำแนะนำทั่วไปให้เพิ่ม graphics carve-out ใน BIOS กลับเป็นทางเลือกที่ แย่กว่า บน Linux เพราะเพดาน GTT คำนวณจาก RAM หลังหัก carve-out แล้ว ยิ่งกันมากยิ่งลดเพดานที่ต้องการเพิ่ม
28 Jul, BIOS carve-out 64 GiB amdgpu: 65536M of VRAM memory ready amdgpu: 31451M of GTT memory ready. 05 Aug, BIOS carve-out 2 GiB + ttm.pages_limit amdgpu: 2048M of VRAM memory ready amdgpu: 114688M of GTT memory ready.
ตั้ง BIOS เป็น 64 GiB เหลือ GTT 30.71 GiB ลดเป็นค่าต่ำสุดและตั้งเคอร์เนลหนึ่งค่าได้ 112 GiB — มากกว่า 3.6× บนฮาร์ดแวร์เดิม ค่าที่คู่มือส่วนใหญ่ให้เพิ่มคือค่าที่ควรปล่อยไว้
ไม่มีข้อใดอยู่ใน model card ทุกข้อพบจากการรันจริง นั่นคือ Bench
วิธีทำงาน — เห็นคุณค่าก่อนติดตั้ง
คุณรู้ได้ว่าคุ้มทำหรือไม่ก่อนมีใครขอให้ติดตั้ง การวินิจฉัยใช้ฟรีและจะฟรีต่อไป
คำวินิจฉัย ฟรี · ไม่ติดตั้งอะไร
อ่านหน่วยความจำ หน่วยความจำที่ GPU ใช้ได้ เวอร์ชันไดรเวอร์และเคอร์เนล และพื้นที่ดิสก์ แล้วบอกว่าโมเดลระดับใดอยู่ในหน่วยความจำได้ ระดับใดสลับได้ และระดับใดไม่พอดี ทุกค่าระบุไฟล์หรือคำสั่งต้นทาง จึงแยกการวัดออกจากข้อสรุปได้
โปรไฟล์
คำสั่งเดียว ทำซ้ำได้ ตรึง hash ของ llama.cpp เวอร์ชัน proxy เคอร์เนล firmware และ Mesa รวมถึงทุกไฟล์โมเดลด้วย repository ชื่อไฟล์ และ sha256 โปรไฟล์มีเวอร์ชัน ตารางสภาพแวดล้อมที่ทดสอบ และวันหมดอายุ
การสอบเทียบ คุณเป็นผู้รับรอง
รันชุดงานคัดสรรผ่านเส้นทางบริการจริง หากคอมไพล์หรือทดสอบได้ CI เป็นผู้ตัดสิน โมเดลตัดสินเฉพาะสิ่งที่ตรวจเชิงกลไม่ได้ ผลลัพธ์คือ ข้อเสนอ การจัด lane และผ่านประตูเดียวกับเรื่องอื่น การสอบเทียบไม่ใช้ผลของตัวเองอัตโนมัติ
รายงาน
แสดงสัดส่วน local กับ frontier ส่วนต่างค่าใช้จ่าย และ lane ที่คุ้มต่อการอัปเกรดครั้งถัดไป คำนวณจากบันทึกที่รู้ endpoint ซึ่งให้บริการจริง เพราะ proxy อาจใช้ fallback โดยไม่บอก และตัวเลขประหยัดที่เชื่อเจตนาแทนบันทึกไม่มีความหมาย
โปรไฟล์ที่ไม่มีเวอร์ชันและวันหมดอายุคือคำโกหกที่รอเวลา
ในหนึ่งสัปดาห์ upstream เปลี่ยนสามครั้ง: key การตั้งค่าถูกลบกลางงาน กฎ “เคอร์เนลที่รู้ว่าดี” จากเดือนก่อนใช้ไม่ได้ และฟีเจอร์ชั้นบริการย้ายตำแหน่ง ชุดติดตั้งที่ถูกวันจันทร์ผิดอย่างเงียบ ๆ ในวันศุกร์
ทุกโปรไฟล์จึงระบุสิ่งที่ใช้ทดสอบและวันที่เลิกอ้างว่าเป็นปัจจุบัน เมื่อเก่าหรือคุณตั้งใจเบี่ยงเบน ให้ทดสอบและจับคู่ใหม่ นี่คือเส้นทางที่รองรับ ไม่ใช่ภาวะล้มเหลว
$ saphan machine show strix-halo-evo-x2 [current] profile strix-halo-evo-x2 v1.0.0 · expires in 90 days kernel 7.0.0-28-generic · mesa 26.0.3 · vulkan 1.4.341 llama.cpp e031d95 · BIOS EVO-X2 1.12 · GTT 112.00 GiB models: 4 pinned by sha256 · 1 hard constraint recorded $ saphan machine show strix-halo-evo-x2 # ninety-one days later [expired] do not treat the figures below as current → run: saphan machine qualify strix-halo-evo-x2 --reverify
ข้อจำกัดที่คำบรรยายอย่างเดียวไม่พอ: n_embd_head_v % kv_block_size == 0 — 72 กับ block q8_0 ขนาด 32 ทำให้ kimi-linear quantise KV cache ไม่ได้ การทำเฉพาะ K ก็ไม่ช่วย กฎนี้ส่งเป็นข้อมูลพร้อมวิธีทำซ้ำ เครื่องมือจึงปฏิเสธค่าที่เป็นไปไม่ได้ก่อนเวลาโหลด
ตำแหน่งของ Bench
Bench เป็นโมดูลของ Saphan Studio ไม่ใช่ผลิตภัณฑ์แยก lane ที่เสนอคือ lane ที่ routing ใช้อยู่ การรับรองใช้ประตูเดิม และค่าใช้จ่ายมาจากบันทึกเดิม
ส่วนเดียวที่ทำงานแยกคือคำวินิจฉัยฟรี เพราะต้องใช้ได้บนเครื่องที่ยังไม่ได้ติดตั้งอะไร แม้แต่ Saphan
Routing ตัดสินว่างานประเภทหนึ่งควรไปไหน Bench บอกว่าฮาร์ดแวร์ของคุณรับอะไรได้ เพื่อให้ตัดสินจากการวัดแทนสมมติฐาน
เมื่อคนที่สองต้องการหลักประกันเดียวกัน
ทั้งหมดทำงานเหมือนเดิมสำหรับทีม แต่การแบ่งงานเปลี่ยนจากนิสัยส่วนตัวเป็นนโยบาย: การจัด lane เป็นไฟล์ที่มีผู้อนุมัติ และค่าใช้จ่ายระบุที่มาได้เพราะบันทึกรู้ endpoint ที่ให้บริการจริง
นี่คือประตูถัดไป ไม่ใช่ผลิตภัณฑ์ใหม่ เริ่มแบบ Solo และใช้โปรไฟล์เดิมเมื่อเครื่องที่สองเข้ามา
สถานะอย่างตรงไปตรงมา
สิ่งที่จริงวันนี้: deployment อ้างอิงทำงานอยู่ และทุกค่าบนหน้านี้มาจากมัน Verdict เป็น prototype ที่ทำงานได้กับโปรไฟล์ฮาร์ดแวร์อ้างอิงและชุด fixture สังเคราะห์
สิ่งที่ยังไม่จริง: Verdict ยังไม่ยืนยันบนเครื่องจริงเครื่องที่สอง Profile, Calibration และ Report มีข้อกำหนดแล้วแต่ยังไม่สร้าง เมทริกซ์ที่รองรับจงใจแคบและขยายด้วยการตรวจทีละคลาส
เราเลือกพูดว่า “ยังไม่ได้วัด” ดีกว่าเผยแพร่ตัวเลขที่รับรองไม่ได้ นี่คือเหตุผลที่มีส่วนนี้
สอบถามโครงการ design partner
ติดต่อเรา — [email protected]