Drex Max จับตาโมเดลการตัดสินใจ — และกำหนดราคาทุกคลิกที่ $0.06

เอเจนต์ที่ใช้คอมพิวเตอร์ไม่ได้เป็นการตัดสินใจครั้งเดียวจริง ๆ การจองเที่ยวบินหนึ่งครั้งประกอบด้วยการตัดสินใจถึงสามสิบครั้ง: จะคลิกช่องไหน จะเปิดผลลัพธ์รายการใด วิดเจ็ตปฏิทินเรนเดอร์เสร็จแล้วหรือยัง และค่าโดยสารที่กำลังดูอยู่คือรายการที่ต้องการหรือไม่ แต่ละอย่างล้วนเป็นการส่งภาพหน้าจอไปกลับหนึ่งรอบ และหากโมเดลที่อยู่อีกฝั่งเป็นโมเดลแชตระดับฟรอนเทียร์ แต่ละรอบก็กินเวลาหลายวินาทีและมีค่าใช้จ่ายในระดับฟรอนเทียร์Drex Max ซึ่ง Nace.AI เปิดให้ใช้งานทั่วไปเมื่อวันที่ 19 ตุลาคม 2026 เป็นความพยายามที่จะยุบการคำนวณนั้นลง เป็นโมเดลสำหรับการตัดสินใจ ไม่ใช่โมเดลแชต — คุณป้อนหน้าจอและชุดตัวเลือกที่กำหนดชนิดไว้ให้มัน และการประมวลผลไปข้างหน้าหนึ่งครั้งจะคืนค่าความน่าจะเป็นของแต่ละตัวเลือก Nace ระบุราคาไว้ที่ 0.06 ดอลลาร์ต่อโทเคนอินพุตหนึ่งล้านโทเคน ความหน่วงมัธยฐาน 183 มิลลิวินาที และไม่มีค่าใช้จ่ายสำหรับเอาต์พุตเลย เพราะมันไม่เขียนอะไรออกมา ความล้มเหลวของ AI และเหตุการณ์เกี่ยวกับเอเจนต์ที่มีการบันทึกไว้ ซึ่งอยู่เบื้องหลังการเปิดตัวลักษณะนี้ ถูกรวบรวมไว้ใน OrcaRouter AI Incident Archive โดยแต่ละรายการมีแหล่งอ้างอิง ระดับความรุนแรง เกรดความเชื่อมั่น และสถานะข้อโต้แย้งของตัวเอง

การเปรียบเทียบที่ Nace วางถัดจากนั้นคือ TypeSafe J​ev 1.14 ซึ่งเป็นโมเดลการตัดสินใจที่กำหนดรูปแบบคำขอของหมวดหมู่นี้ และโมเดลชายแดนอเนกประสงค์ที่เอเจนต์ใช้กันในปัจจุบัน ในตารางที่ Nace เผยแพร่เอง นั่นคือ $10.17 ต่อการตัดสินใจหนึ่งพันครั้งสำหรับ Claude Opus 5.5 และประมาณ 3.5 วินาทีต่อการตัดสินใจ เทียบกับ $0.06 และ 174 มิลลิวินาทีสำหรับ Drex Max บนคำถามจากภาพหน้าจอชุดเดียวกันจำนวน 243 ข้อ ตัวเลขของผู้ขาย รันเอง ไม่มีใครนอก Nace ตรวจสอบ — แต่ประเด็นอยู่ที่ความต่างระดับขนาด และนี่คือเหตุผลที่รีลีสนี้สำคัญกว่าที่แถวผลเบนช์มาร์กของมันจะบ่งชี้

สิ่งที่ส่งมอบจริง

Drex Max เป็นรุ่นแรกในสาย Drex ที่มีตัวเข้ารหัสภาพ Drex 2.0 และ Drex 1.5 เป็นแบบรับข้อความเป็นอินพุตและให้ค่าความน่าจะเป็นเป็นเอาต์พุต ส่วน Max อ่านภาพหน้าจอ สกรีนแคสต์ เอกสารที่สแกน แผนภูมิ ภาพถ่าย และเฟรมวิดีโอ และตอบคำถามสามประเภทเดียวกับรุ่นก่อนๆ

• รหัสโมเดล — drex-max, ปักหมุดไว้ ไม่มีเวทแบบเปิด โฮสต์ผ่าน API ของ Nace เอง โดยไม่มีเช็กพอยต์ให้ดาวน์โหลด

• รูปแบบอินพุต — state สตริง พร้อมด้วย questions ออบเจ็กต์ และ images อาร์เรย์ของภาพได้สูงสุด 8 ภาพต่อคำขอ ปลายทางคือ POST /v1/systemone ซึ่งเป็นพาธเดียวกับที่ J​ev ใช้

• ประเภทคำถาม — choice (ตัวเลือกที่มีชื่อ คืนค่าความน่าจะเป็นต่อตัวเลือก), noul (คำถามใช่/ไม่ใช่ คืนค่า P(true)), score (ระดับที่เรียงลำดับ คืนค่าระดับที่คาดหมายและการกระจาย) คำถามหลายข้อเกี่ยวกับสถานะเดียวกันจะใช้การประมวลผลรอบเดียวร่วมกัน

• บริบท — 131,072 โทเคนต่อคำถาม รวมถึงโทเคนของภาพ ตามคู่มือ API โพสต์เปิดตัวระบุแยกต่างหากว่า "หน้าต่างบริบทขนาด 262K โทเคน" ตัวเลขสองตัวนี้ไม่ตรงกัน และเป็นสิ่งแรกที่ต้องหาข้อสรุปก่อนคุณจะกำหนดขนาดบัฟเฟอร์ภาพหน้าจอ

• ราคา — $0.06 ต่อโทเค็นอินพุตหนึ่งล้านโทเค็น; เอาต์พุตไม่ถูกเรียกเก็บค่าบริการ Nace อ้างอิงตัวเลขเดียวกันที่ $0.06 ต่อการตัดสินใจหนึ่งพันครั้ง ซึ่งบ่งบอกถึงประมาณหนึ่งพันโทเค็นต่อการเรียกหนึ่งครั้ง

• รุ่นก่อนหน้า — Drex 2.0 (ขนาดรวม 35B, ใช้งานจริงประมาณ 3B, สร้างบน Qwen3.6-35B-A3B, น้ำหนักแบบเปิด) ในราคา $0.06 ต่อพันการตัดสินใจ และ Drex 1.5 (9B, ข้อความเท่านั้น) ในราคา $0.04

• การติดตั้งใช้งาน — บริหารจัดการบน GPU ของ Nace แบบเฉพาะหรือภายในบัญชี AWS หรือ Azure ของลูกค้า หรือแบบแยกสภาพแวดล้อมโดยสมบูรณ์ (air-gapped) ทั้งหมดภายใต้สัญญาการเรียกใช้ (request contract) เดียวกัน การไม่มี weights หมายความว่าไม่สามารถโฮสต์เองได้ แต่ไม่ได้หมายความว่ามีเฉพาะรูปแบบ SaaS เท่านั้น

ไม่มีอะไรแปลกพิเศษในอินเทอร์เฟซ นี่เป็นเจตนา: Nace สร้าง Drex Max ให้เข้ากันได้ในระดับ wire กับ J​ev SDK ของ TypeSafe ดังนั้น @typesafe-ai/sdkจึงยังใช้งานได้เมื่อเปลี่ยน base URL คีย์ และโมเดลเริ่มต้น ความเข้ากันได้นี้ไม่ใช่การเอาใจคู่แข่ง แต่เป็นวิธีที่ผู้เล่นรายใหม่จะได้รับการลองใช้ — การย้ายระบบที่ถูกที่สุดคือการย้ายที่เป็นเพียงค่าคอนฟิกค่าเดียว

ส่วนที่แตกต่างอย่างแท้จริง: การแจกแจงแทนที่จะเป็นประโยค

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

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

อย่างแรกคือการตั้งเกณฑ์ (thresholding) การแจกแจงความน่าจะเป็นช่วยให้คุณเขียนกฎที่ต้องการได้จริง: ลงมือเมื่อตัวเลือกอันดับต้นมีค่าถึง 0.9 และยกระดับไปยังโมเดลที่ช้ากว่าหรือมนุษย์เมื่อไม่ถึง ส่วนโมเดลเชิงสร้างให้ประโยคหนึ่งมาและให้ฟิลด์ความเชื่อมั่นที่มีความหมาย完全不同 — โดยปกติคือการกระจายของโทเคนมีความแหลมแค่ไหน ไม่ใช่ความน่าจะเป็นที่คำตอบจะถูกต้อง

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

ประการที่สามคือเศรษฐศาสตร์ เพราะไม่มี output tokens ต้นทุนในการให้คะแนนตัวเลือกสิบตัวจึงเท่ากับการให้คะแนนสองตัว กรอบความคิดของ Nace คือสิ่งนี้ทำให้มันมีต้นทุนต่ำพอที่จะเรียกใช้ได้ในทุกขั้นตอน และที่ $0.06 ต่อหนึ่งพันครั้ง การคำนวณก็ยังลงตัว: แม้แต่งานสามสิบขั้นตอนที่ทำหละหลวมก็มีต้นทุนในส่วนของการตัดสินใจต่ำกว่าสองในสิบของหนึ่งเซนต์ งานเดียวกันเมื่อเทียบกับ Opus 5.5 โดยใช้ตัวเลขต่อการตัดสินใจของ Nace จะอยู่ที่ประมาณสามสิบเซนต์ — ไม่ถึงขั้นร้ายแรง แต่ก็เป็นราคาที่สูงเป็นสามสิบเท่าของสิ่งที่มันกำลังทำอยู่

ตาราง benchmark และตัวเลขเหล่านี้เป็นของใคร

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

พาดหัวข่าวคือ Decision Index สาธารณะที่ 67.6 เทียบกับ 61.3 สำหรับ Drex 2.0, 58.1 สำหรับ Drex 1.5, 60.7 สำหรับ J​ev 1.14 และ 47.8 สำหรับ GPT-6 Luna Decisions ใน Vision Index ควบคู่กัน — ตัวเลขที่สำคัญสำหรับโมเดลที่มีจุดขายด้านการมองเห็น — Drex Max ได้ 74.5 เทียบกับ 63.9 ของ Luna

• Mind2Web — 88.6 เทียบกับ 81.2 สำหรับ GPT-6 Luna Decisions ซึ่งเป็นแถวที่เกี่ยวข้องโดยตรงที่สุดสำหรับเอเจนต์เบราว์เซอร์

• OSWorld-Verified — 0.780 เทียบกับ 0.756 สำหรับ GPT-6 Sol และ 0.790 สำหรับ Claude Opus 5.5 โดย Drex Max เอาชนะตัวแรกและพ่ายแพ้อย่างหวุดหวิดต่อตัวที่สอง

• OSWorld-V2 — 0.737 เทียบกับ 0.744 สำหรับ Sol และ 0.761 สำหรับ Opus 5.5 เรื่องเดิม แต่ช่องว่างกว้างขึ้นเล็กน้อย

• BFCL tool calling — 98.2 นำหน้า J​ev 1.14 ที่ 96.4 และ Claude Opus 5.5 ที่ 97.3 เป็นรองเพียง GPT-6 Sol

• DecideBench — 98.5 สำหรับ items และ 97.0 สำหรับ pairs ซึ่งทั้งสองค่าสูงกว่า J​ev 1.14

• การตัดสินใจทางธุรกิจเทียบกับ J​ev 1.14 — FinEntity 92.3 เทียบกับ 81.9, BANKING77 90.0 เทียบกับ 79.7, ContractNLI 75.9 เทียบกับ 57.7

แถวข้อมูล OSWorld ควรมีข้อควรระวังที่ตารางของ Nace ไม่ได้ระบุไว้อย่างชัดเจน คะแนนเหล่านั้นอธิบายถึงสแต็กระบบอัตโนมัติแบบเต็มรูปแบบ และไม่มีการบันทึกไว้ว่าในลูปโดยรอบ Drex Max มีส่วนใดที่เป็นฮาร์เนสของ Nace เองด้วย แบบจำลองการตัดสินใจที่เลือกการกระทำถัดไปได้ดีนั้นยังต้องพึ่งพาสิ่งที่ทำหน้าที่จับภาพหน้าจอ รอให้การเรนเดอร์เสร็จ และตัดสินใจว่างานเสร็จเมื่อใด อ่าน 0.780 เป็นหลักฐานว่าการตัดสินใจไม่ใช่คอขวด ไม่ใช่เป็นคำสัญญาเกี่ยวกับเอเจนต์ของคุณ

ในจุดที่มันด้อยกว่า ซึ่งเป็นครึ่งหนึ่งของตารางที่มีประโยชน์มากกว่า

ความสูญเสียเหล่านี้ไม่ได้ถูกซ่อนไว้ แต่เป็นเรื่องง่ายที่จะมองข้ามไป และสองรายการนั้นอธิบายถึงขีดจำกัดที่แท้จริง ไม่ใช่ความคลาดเคลื่อนจากการปัดเศษ

ในด้านความรู้ทั่วไปและการให้เหตุผลโจทย์ยาก โมเดลสำหรับการตัดสินใจไม่สามารถแข่งขันกับโมเดลแชตระดับแนวหน้าได้เลย และ Drex Max ก็ไม่ได้เปลี่ยนเรื่องนี้ MMLU-Pro อยู่ที่ 72.5 ตามหลัง J​ev 1.14 ที่ 82.1, Sol ที่ 93.0 และ Opus 5.5 ที่ 94.0 HLE อยู่ที่ 19.0 เทียบกับ 19.4 ของ J​ev ซึ่งไม่ว่าจะมองแบบไหนก็เป็นการเสมอกันที่ปลายล่างของช่วง เป็นเรื่องที่คาดไว้สำหรับโมเดลที่มีหน้าที่เลือกจากรายการสั้น ๆ เมื่อมีหน้าจอให้ และนี่คือเหตุผลที่โมเดลสำหรับการตัดสินใจเป็นเพียงองค์ประกอบหนึ่งในเอเจนต์ ไม่ใช่สิ่งทดแทนโมเดลที่ทำหน้าที่วางแผน

สิ่งที่น่าสนใจกว่าคือการถดถอยเมื่อเทียบกับรุ่นก่อนหน้าของตัวเอง บน When2Call ซึ่งถามว่าโดยรวมแล้วควรเรียกใช้เครื่องมือหรือไม่ Drex Max ได้ 85.2 ขณะที่ Drex 2.0 ทำได้ 86.5 และ Drex 1.5 รุ่นเก่ากว่าที่ราคาถูกกว่าทำได้ 89.7 โมเดล Drex ที่ใหม่ที่สุดและแพงที่สุดกลับแย่ที่สุดในสามรุ่นในการรู้ว่าเมื่อใดไม่ควรลงมือ หากเวิร์กโฟลว์ของคุณพึ่งพาการยับยั้งชั่งใจ — เช่นเอเจนต์สนับสนุนที่ควรเงียบไว้แทนที่จะเรียกใช้เครื่องมือขอคืนเงิน — ความสามารถด้านภาพไม่ได้ให้สิ่งนั้นกับคุณ และโมเดลข้อความที่ราคาถูกกว่าอาจยังเป็นตัวเลือกที่เหมาะสม

รูปแบบเดียวกันนี้ปรากฏในสองแถวด้าน vision ที่ไปในทิศทางตรงกันข้าม KIE ซึ่งเป็นการสกัดข้อมูลสำคัญจากแบบฟอร์มที่สแกน ได้ 95.5 เทียบกับ 97.5 ของ Luna การกลั่นกรอง Hateful Memes ได้ 70.6 เทียบกับ 71.2 ช่องว่างทั้งสองไม่ใหญ่ และทั้งคู่อยู่ในโดเมนที่ข้อได้เปรียบของ Drex Max ในด้านอื่นกว้างถึงสามสิบจุด ซึ่งบ่งชี้ว่า vision encoder ถูกฝึกให้เน้นเลย์เอาต์หน้าจอและแผนภูมิ มากกว่าแบบฟอร์มที่พิมพ์หรือมีม

Latency ก็ถอยหลังลงเช่นกัน ค่ากลาง 183 ms ของ Drex Max ช้ากว่า Drex 2.0 อยู่ 32 ms และช้ากว่า Drex 1.5 อยู่ 38 ms ในลูปที่รันสามสิบครั้งต่องาน นั่นเท่ากับเพิ่มเวลาประมาณหนึ่งวินาทีต่องาน เมื่อเทียบกับหลายวินาทีที่ประหยัดได้ต่อขั้นตอนเมื่อเทียบกับโมเดลระดับแนวหน้า ยังเป็นการแลกที่คุ้มค่า แต่ก็ควรรู้ว่าตัวเข้ารหัสภาพไม่ได้มาฟรี

มีตัวเลขหนึ่งตัวที่ต้องแยกให้ชัดก่อนมันจะถูกยกมาอ้างใส่คุณ 174 ms ในย่อหน้าเปิดคือการวัดเฉพาะภาพหน้าจอของ Nace — คำถามภาพ 243 ข้อ ทีละคำขอ เทียบกับ 253 ms ของ J​ev 1.14 บนชุดเดียวกัน 183 ms คือค่ามัธยฐานจากชุด benchmark ทั้งหมดในตารางเปิดตัว ทั้งสองค่าเป็นของ Nace; เป็นการวัดที่แตกต่างกัน และค่าที่ดูดีกว่าคือค่าที่แคบกว่า

สองกับดักใน API ก่อนที่คุณจะเชื่อมต่ออะไรทั้งนั้น

เอกสารมีรายละเอียดอยู่จุดหนึ่งที่ถ้าใครอ่านผ่าน ๆ จะต้องเสียเวลาทั้งบ่ายไปกับมัน drex-latestไม่ได้ชี้ไปที่ Drex Max แต่เป็น checkpoint ที่ถูกปักหมุดไว้ และ alias นี้ไป resolve เป็นอย่างอื่นแทน ใครก็ตามที่ทำตาม quickstart แล้วเอา key ของตัวเองมาใส่และตั้งค่า TYPESAFE_DEFAULT_MODEL=drex-latest ซึ่งเป็นสิ่งที่คำแนะนำเรื่องความเข้ากันได้กับ J​ev บอกให้ทำเป๊ะ ๆ นั้น จะกลายเป็นเรียกใช้โมเดลแบบข้อความล้วน แล้วก็สงสัยว่าทำไมภาพหน้าจอของตัวเองถึงถูกมองข้ามไป

กับดักที่สองคือขนาด คู่มือ API กำหนดเพดานคำขอไว้ที่แปดภาพและ 131,072 โทเคนต่อคำถาม โดยรวมโทเคนของภาพเข้าไปด้วย ขณะที่โพสต์เปิดตัวโฆษณาไว้ที่ 262K จนกว่า Nace จะทำให้ทั้งสองสอดคล้องกัน ให้ยึดตามตัวเลขที่น้อยกว่า ไม่มีการเผยแพร่ต้นทุนโทเคนต่อภาพ ซึ่งทำให้ยากที่จะคาดเดาเพดานล่วงหน้าได้: ภาพหน้าจอความละเอียดเต็มไม่ได้มีจำนวนโทเคนคงที่ และเอกสารก็ไม่ได้ระบุว่าภาพถูกปรับขนาดหรือแบ่งเป็นไทล์อย่างไร

สิ่งหนึ่งที่ทำได้ง่ายกว่าคู่แข่งรายเดิม: Drex Max รองรับภาพหน้าจอทุกขนาด ส่วน API ของ Jev 1.14 จะปฏิเสธรูปภาพที่มีด้านใดด้านหนึ่งต่ำกว่า 280 px หรือเกิน 1,568 px ซึ่งเป็นข้อจำกัดแบบที่มักโผล่มาเป็นความล้มเหลวเงียบ ๆ ในลูปรีทรายตอนตีสอง

สิ่งนี้ส่งผลอย่างไรต่อการตัดสินใจด้านการกำหนดเส้นทาง

คำถามในทางปฏิบัติไม่ใช่ว่า Drex Max ดีกว่าโมเดลระดับแนวหน้าหรือไม่ มันไม่ใช่ และมันก็ไม่ได้พยายามจะเป็นเช่นนั้น คำถามคือการตัดสินใจสามสิบรายการในงานหนึ่ง รายการใดสมควรได้รับโมเดลระดับแนวหน้า และรายการใดสมควรได้รับการแจกแจงความน่าจะเป็นที่ใช้เวลา 174 ms และนั่นคือปัญหาการกำหนดเส้นทางก่อนที่จะเป็นปัญหาของโมเดล

Drex Max ไม่ได้อยู่ในรายการเส้นทางของเรา แคตตาล็อก OrcaRouter ไม่มีให้บริการ และไม่ควรตีความสิ่งใดที่นี่ว่าเป็นการยืนยันความพร้อมใช้งานจากเรา — Nace ขายผ่าน API และคอนโซลของตัวเอง สิ่งที่เรามีคือรุ่นที่เป็นตัวเปรียบเทียบหลักTypeSafe Jev 1.13 เป็นเส้นทางที่อยู่ในรายการ ในราคา $0.042 ต่อหนึ่งล้านโทเค็นอินพุต ภายใต้บริบท 65,536 โทเค็น ให้บริการผ่านPOST /v1/systemone body เดียวกัน ดังนั้นการทดสอบ A/B ระหว่างโมเดลตัดสินใจกับลูป screenshot-to-frontier ปัจจุบันของคุณจึงเป็นเพียงการเปลี่ยนสตริงโมเดล ไม่ใช่การเขียนใหม่ วิธีที่ประหยัดที่สุดในการหาคำตอบคือเก็บการเรียกตัดสินใจแบบข้อความล้วนไว้ที่เดิม เพิ่มขั้นตอนการอ่านหน้าจอไว้ข้าง ๆ สำหรับงานที่ต้องใช้ตา และวัดทั้งสองอย่างเทียบกับบันทึกของคุณเอง ไม่ใช่คำขอที่ให้คะแนนแล้ว 140,178 รายการของ Nace

การแยกแบบนั้นจะได้ผลก็ต่อเมื่อทุกชิ้นส่วนเข้าถึงได้จากจุดเดียว คีย์เดียวครอบคลุมโมเดลกว่า 200 รุ่น ราคาตามรายการของผู้ให้บริการถูกส่งผ่านโดยไม่มีการบวกเพิ่มต่อโทเคน และ การสลับไปใช้ผู้ให้บริการรายอื่นโดยอัตโนมัติเมื่อระบบล้มเหลว คือสิ่งที่ป้องกันไม่ให้การทดลองเสื่อมกลายเป็นสาขาที่ล้าสมัยเมื่อคนที่ตั้งมันขึ้นมาเปลี่ยนทีม สิ่งนี้ยังสำคัญในที่นี้ด้วยเหตุผลเฉพาะ: Drex Max เป็นของใหม่ ยังไม่ผ่านการตรวจสอบ และให้บริการผ่าน API เท่านั้น และวิธีที่ปลอดภัยในการนำส่วนประกอบที่ยังไม่ผ่านการพิสูจน์มาใช้คือวางไว้เบื้องหลังสิ่งที่สามารถถอยกลับไปใช้โมเดลที่รู้จักได้เมื่อระดับความมั่นใจลดลงหรือปลายทางทำงานผิดปกติ ส่งการตัดสินใจที่มีความมั่นใจไปยังโมเดลราคาถูก และให้กลไกสำรองอัตโนมัติจัดการส่วนที่เหลือ

อะไรจะทำให้การอ่านนี้เปลี่ยนไป

การรัน Decision Index แบบอิสระคือสิ่งแรกที่ต้องทำ ชุดทดสอบนี้เป็นสาธารณะ Nace กล่าวว่าการประเมินสามารถทำซ้ำได้ และจนกว่าจะมีคนนอกบริษัทนำ Drex Max ไปรันบนชุดนี้ ตัวเลข 67.6 ก็ยังเป็นตัวเลขจากผู้ขาย ช่องที่ต้องจับตาดูเมื่อสิ่งนั้นเกิดขึ้นคือช่องที่ชี้ไปในทิศทางตรงกันข้าม: การนำอยู่ 30 จุดบน Mind2Web ถัดจากภาวะถดถอยบน When2Call ไม่ใช่เส้นโค้งความสามารถที่ราบรื่น แต่บ่งบอกถึงโมเดลที่ถูกฝึกหนักกับคำถาม "ในบรรดาตัวเลือกเหล่านี้ อันไหนคือคลิกถัดไป" และฝึกหนักน้อยกว่ากับคำถาม "ฉันควรคลิกอะไรสักอย่างหรือไม่" หากสิ่งนี้ยังคงเป็นจริง นั่นคือข้อเท็จจริงที่สำคัญที่สุดในเชิงปฏิบัติการเกี่ยวกับ Drex Max และมันไม่ได้อยู่ในส่วนไฮไลต์

ความหน่วงในโปรดักชันภายใต้ภาวะทำงานพร้อมกันคือประเด็นที่สอง ตัวเลขทรูพุตที่ Nace ระบุเอง — ประมาณ 25 คำขอต่อวินาทีบน H100 หนึ่งรีพลิกา โดยไม่มีข้อผิดพลาดเมื่อมีคำขอระหว่างดำเนินการสูงถึง 64 รายการ — เป็นของ Drex โดยทั่วไป ไม่ใช่ของ Max โดยเฉพาะ จุดขายทั้งหมดของการออกแบบนี้คือมันอยู่ในฮอตพาธในทุกขั้นตอน ซึ่งทำให้ p95 ภายใต้โหลดมีความเกี่ยวข้องมากกว่าค่ามัธยฐาน 183 มิลลิวินาทีอย่างมาก และไม่มีข้อมูลที่เผยแพร่ใดกล่าวถึงเรื่องนี้

ประการที่สาม ราคาควรมีตัวอย่างที่คำนวณให้ดูจริงพร้อมรูปภาพประกอบ ราคา 0.06 ดอลลาร์ต่อโทเค็นอินพุตหนึ่งล้านโทเค็นจะมีประโยชน์ก็ต่อเมื่อคุณรู้ว่าภาพหน้าจอหนึ่งภาพใช้โทเค็นเท่าไร และยังไม่มีตัวเลขที่เผยแพร่ที่ไหนทำแบบนั้นไว้ ทีมที่ตั้งงบสำหรับลูป 30 ขั้นโดยมีหน้าจอ 1440p ต่อขั้นจะได้แต่เดาไปเรื่อย ๆ จนกว่า Nace จะเผยแพร่การคิดต้นทุนภาพหรือมีคนวัดมันออกมา

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