หลักการทำงานของ LLM Live
ทุกผลการประเมินบนเว็บไซต์นี้มาจากกฎที่คุณอ่านได้ที่นี่ ไม่มีผู้ให้บริการรายใดจ่ายเงินเพื่อโปรโมต และตัวเลขด้านล่างนี้ก็เป็นค่าเดียวกับที่ระบบใช้จริงในการประมวลผล
สถานะ
สรุปผลลัพธ์เดียวจาก 4 สัญญาณ โดยยึดตามค่าที่แย่ที่สุด
- การตรวจสอบของเรา
- สำหรับบริการที่เรามี API key ตัว worker จะส่งคำขอสตรีมมิงขนาดเล็ก (นับ 1 ถึง 20 ไม่เกิน 80 โทเคน) ไปยัง API ของผู้ให้บริการโดยตรงทุก 60–120 วินาที พร้อมบันทึกเวลาจนถึงโทเคนแรก (TTFT) และจำนวนโทเคนต่อวินาที หากการตรวจสอบล้มเหลวจะลองใหม่ 2 ครั้ง เว้นช่วงละ 20 วินาที โดยไม่นับรวมข้อผิดพลาดจาก rate limit หรือปัญหาในระบบของเราเอง แต่ละหน้าบริการจะระบุไว้ชัดเจนว่ามีการตรวจสอบของเราทำงานอยู่หรือไม่
- เกณฑ์การตัดสิน
- ตรวจสอบล้มเหลวติดต่อกัน 3 ครั้งล่าสุด → ระบบล่มรุนแรง (Major outage) ตรวจสอบล้มเหลวอย่างน้อยครึ่งหนึ่งในรอบ 10 นาที → ระบบล่มบางส่วน (Partial outage) ตรวจสอบล้มเหลวอย่างน้อย 20% หรือค่ามัธยฐานเวลาจนถึงโทเคนแรกเกิน 3 วินาทีและช้ากว่ามัธยฐาน 24 ชั่วโมงถึง 3 เท่า → ประสิทธิภาพลดลง (Degraded)
- หน้าสถานะทางการ
- ดึงข้อมูลอัปเดตทุกนาที ข้อมูลสถานะที่เก่าเกิน 15 นาทีจะถูกละเว้น เพื่อไม่ให้หน้าสถานะทางการที่ค้างทำให้ระบบแสดงสถานะเขียวหรือแดงผิดจากความเป็นจริง
- ผ่าน OpenRouter
- OpenRouter เผยแพร่อัตราความสำเร็จของคำขอสำหรับผู้ให้บริการทุกรายของแต่ละโมเดล หากมีโมเดลบนเอนด์พอยต์ของผู้ให้บริการเองอย่างน้อย 2 โมเดลและคิดเป็นอย่างน้อยครึ่งหนึ่ง มีอัตราสำเร็จต่ำกว่า 80% ในรอบ 30 นาที และต่ำกว่าระดับ 24 ชั่วโมงลงไป 10 จุด → ประสิทธิภาพลดลง; หากเฉลี่ยต่ำกว่า 50% → ระบบล่มบางส่วน แต่หากมีผู้ให้บริการล้มเหลวพร้อมกันตั้งแต่ 3 รายขึ้นไป จะถือว่าเป็นปัญหาของ OpenRouter เองและระบบจะละเว้นสัญญาณนี้
- รายงานจากผู้ใช้
- มีรายงานปัญหาเข้ามาอย่างน้อย 10 ครั้งในรอบ 15 นาที และสูงกว่าอัตราปกติอย่างน้อย 4 เท่า → ประสิทธิภาพลดลง รายงานจากผู้ใช้อย่างเดียวจะไม่ถูกนำมาตัดสินว่าระบบล่มโดยสิ้นเชิง
- การคืนสู่สภาพปกติและการแจ้งเตือน
- สถานะจะถูกประเมินใหม่ทุก 30 วินาที บริการจะกลับสู่สถานะใช้งานได้ปกติ (Operational) ก็ต่อเมื่อไม่มีปัญหาต่อเนื่องกันเป็นเวลา 3 นาที เพื่อป้องกันปัญหาแจ้งเตือนรัวจาก API ที่ติดๆ ดับๆ การแจ้งเตือนจะส่งออกไปเมื่อเริ่มเกิดปัญหา เมื่อปัญหารุนแรงขึ้น และเมื่อปัญหาสิ้นสุดลง
- แท่งสถานะ
- แต่ละแท่งแทนช่วงเวลา 30 นาที และแสดงสีตามสถานะที่แย่ที่สุดในช่วงเวลานั้น สีเทาหมายถึงไม่มีข้อมูล ส่วน Uptime คือสัดส่วนของแท่งที่ไม่มีปัญหา
โมเดลและราคา
ทุกราคาดึงมาจาก API สาธารณะและตรวจสอบทุก 5 นาที
- แหล่งข้อมูล
- แคตตาล็อกโมเดล ราคา และขนาด context window นำมาจาก API สาธารณะของ OpenRouter โดยราคาแสดงต่อ 1M โทเคนตามที่ OpenRouter ระบุ ซึ่งส่วนใหญ่มักจะตรงกับราคาของผู้ให้บริการเอง แต่อาจมีข้อยกเว้นในบางกรณี
- ประวัติราคา
- เราบันทึกสแนปช็อตข้อมูลไว้ทุก 5 นาทีและเก็บประวัติทุกความเปลี่ยนแปลง ทำให้การลดราคา การเปิดตัวโมเดลใหม่ หรือการยกเลิกโมเดลจะปรากฏในฟีดข่าวสารภายในไม่กี่นาที
- ช่องทางการเรียกใช้งาน
- จำนวนผู้ให้บริการจริงที่ให้บริการโมเดลดังกล่าวบน OpenRouter โดยไม่นับรวมแพ็กเกจระดับ flex, batch, priority และ spot เนื่องจากมักไม่พร้อมให้บริการตลอดเวลาโดยโครงสร้างของระบบ
สังเวียนหมากรุก
โมเดลลงแข่งกันเอง โดยมีเอนจินหมากรุกคอยตัดสินแต้มอย่างโปร่งใส
- การเดินหมาก
- โมเดลจะได้รับตำแหน่งหมาก (FEN) และประวัติการเดิน จากนั้นต้องตอบกลับด้วยตาเดินและความคิดเห็นสั้นๆ ความถูกต้องตามกฎจะตรวจสอบด้วย chess.js หากเดินผิดกฎ โมเดลจะได้รับรายการตาเดินที่ถูกต้องและให้โอกาสลองใหม่ การเดินผิดกฎครั้งที่ 3 จะถือว่าแพ้ทันที และหากตอบกลับโดยไม่ระบุตาเดินติดต่อกัน 3 ครั้งจะถือว่าแพ้เวลากำหนด
- งบการประมวลผล
- การคิดเชิงเหตุผล (reasoning) ถูกจำกัดไว้ที่ไม่เกิน 1024 โทเคนต่อตา เพื่อควบคุมค่าใช้จ่ายต่อเกมให้อยู่ในระดับไม่กี่เซนต์ แม้สิ่งนี้จะทำให้โมเดลสายเหตุผลแสดงศักยภาพได้ไม่เต็มที่ แต่สังเวียนนี้ออกแบบมาเพื่อเปรียบเทียบโมเดลภายใต้งบประมาณที่จำกัดเท่ากัน ไม่ใช่การวัดที่จุดสูงสุดของแต่ละโมเดล
- คะแนนเรตติง
- ใช้ระบบ Glicko-2 ซึ่งคำนึงถึงระดับความไม่แน่นอนของคะแนน ตารางอันดับจะเรียงตามเรตติงลบด้วยค่าเบี่ยงเบน 2 เท่า ซึ่งเป็นการประเมินแบบระมัดระวัง โมเดลจะมีสถานะชั่วคราว (provisional) จนกว่าจะแข่งครบ 10 เกม การจับคู่จะให้ความสำคัญกับโมเดลที่ยังมีจำนวนเกมแข่งน้อยและมีเรตติงใกล้เคียงกันก่อน
- ความแม่นยำ
- Stockfish จะประเมินทุกตำแหน่งหมากที่ระดับความลึก 14 หากโอกาสชนะลดลง 5, 10 หรือ 15 จุด จะถือว่าเป็น inaccuracy, mistake หรือ blunder ตามลำดับ โดยคำนวณความแม่นยำตามสูตรของ Lichess
- เกมที่ไม่มีการคิดคะแนน
- เกมที่ต้องหยุดลงเนื่องจากข้อผิดพลาดของ API จากผู้ให้บริการจะไม่นำมาคิดคะแนน นอกจากนี้เกมอาจถูกยกเลิกด้วยตนเองได้หากมีเหตุจำเป็น พร้อมแสดงเหตุผลอย่างเปิดเผย
การโหวตจากผู้ใช้
คุณเลือกคำตอบที่ดีกว่าจาก 2 ตัวเลือกที่ไม่ระบุชื่อ แล้วโมเดล Bradley–Terry จะเปลี่ยนผลโหวตให้เป็นคะแนนเรตติง
- การประลอง
- พรอมต์ของคุณจะถูกส่งไปยัง 2 โมเดลที่สุ่มเลือกมาจากกลุ่มโมเดลปัจจุบันประมาณ 20 ตัวจากผู้พัฒนาชั้นนำนับสิบแห่ง มีการสลับฝั่งและซ่อนชื่อโมเดลจนกว่าคุณจะโหวต โมเดลและคู่ประลองที่มีผลโหวตน้อยจะถูกสุ่มบ่อยขึ้น ส่วนโมเดลเรือธงราคาแพงจะถูกสุ่มน้อยลง คำตอบแต่ละอันจำกัดไว้ที่ไม่เกิน 1024 โทเคนโดยปิดระบบ reasoning หรือจำกัดไว้ที่ 512 โทเคนหากปิดไม่ได้ เพื่อเปรียบเทียบคำตอบที่รวดเร็วในชีวิตประจำวัน ไม่ใช่การวัดพลังสูงสุดของแต่ละโมเดล
- การลงคะแนน
- คุณจะโหวตได้ก็ต่อเมื่อทั้งสองฝั่งตอบเสร็จสมบูรณ์ และโหวตได้เพียงครั้งเดียวต่อหนึ่งการประลอง การโหวตเลือก A หรือ B นับเป็นชัยชนะของโมเดลนั้น ส่วนผลเสมอและ "แย่ทั้งคู่" จะนับเป็นครึ่งแต้มของแต่ละฝั่ง เช่นเดียวกับระบบของ LMArena การประลองที่โมเดลใดโมเดลหนึ่งไม่สามารถตอบได้จะไม่ถูกนำมานับผล
- คะแนนเรตติง
- โมเดล Bradley–Terry จะประมวลผลผลโหวตทั้งหมดพร้อมกันในคราวเดียว ดังนั้นลำดับก่อนหลังของการโหวตจึงไม่มีผล ต่างจากระบบ Elo เรตติงจะแสดงผลในสเกล Elo โดยคะแนนที่ต่างกัน 400 จุดหมายถึงโอกาสถูกเลือก 10:1 และตั้งค่าโมเดลมัธยฐานไว้ที่ 1000 มีการใช้ weak prior (ผลเสมอย้อนหลัง 1 ครั้งต่อโมเดล) เพื่อป้องกันไม่ให้คะแนนพุ่งไม่จำกัดสำหรับโมเดลที่ยังไม่เคยแพ้
- ช่วงความเชื่อมั่น
- ช่วงความเชื่อมั่น 95% มาจากการสุ่มซ้ำแบบ bootstrap จำนวน 100 รอบจากผลโหวต อันดับจะคำนวณจาก 1 บวกด้วยจำนวนโมเดลที่ช่วงความเชื่อมั่นทั้งหมดอยู่เหนือกว่าโมเดลนี้ ทำให้โมเดลที่มีช่วงคะแนนทับซ้อนกันได้อันดับร่วมกัน โมเดลที่มีผลโหวตน้อยกว่า 20 ครั้งจะแสดงไว้ต่อท้ายตาราง ข้อมูลทั้งหมดประมวลผลใหม่ทุก 10 นาที
- หมวดหมู่
- โมเดลภาษาขนาดเล็กจะช่วยแยกหมวดหมู่ของพรอมต์ที่โหวตแล้วออกเป็น: การเขียนโค้ด, คณิตศาสตร์, การเขียนเชิงสร้างสรรค์, คำแนะนำและวิธีทำ, ความรู้และข้อเท็จจริง หรืออื่นๆ พร้อมระบุภาษา โดยตารางพรอมต์ภาษารัสเซียจะใช้เฉพาะพรอมต์ภาษารัสเซียเท่านั้น โมเดลจะปรากฏในหมวดหมู่เมื่อมีผลโหวตในหมวดนั้นครบอย่างน้อย 20 ครั้ง
- ข้อจำกัด
- ทุกคนสามารถร่วมโหวตได้โดยไม่ต้องระบุตัวตน มีการจำกัดการใช้งานต่อผู้เข้าชม (8 การประลองต่อชั่วโมง, 40 ครั้งต่อวัน โดยคำนวณจาก salted hash ของ IP address) และจำกัดงบประมาณรายวันเพื่อทำให้การปั่นคะแนนทำได้ยาก แต่ก็ไม่อาจกันได้สมบูรณ์ ผู้คนมักตัดสินจากสไตล์พอๆ กับเนื้อหา คำตอบที่ยาวและจัดรูปแบบสวยงามจึงมีแนวโน้มที่จะชนะมากกว่า พรอมต์จะถูกจัดเก็บเพื่อใช้จัดหมวดหมู่และอาจเผยแพร่ในภาพรวม แต่จะไม่มีการจัดเก็บ IP address ดิบอย่างเด็ดขาด
โต้วาที
สองโมเดลประชันญัตติกัน 3 ยก กรรมการ AI ให้คะแนนสองรอบ ก่อนเปิดให้ผู้ชมร่วมโหวต
- ญัตติ
- ญัตติคัดสรรประมาณ 40 หัวข้อใน 5 หมวด: เทคโนโลยีและ AI, สังคม, วิทยาศาสตร์, จริยธรรม และเรื่องทั่วไปในชีวิตประจำวัน ทุกหัวข้อมีทั้งภาษาอังกฤษและรัสเซีย เราไม่นำหัวข้อเกี่ยวกับการเลือกตั้งและผู้สมัครรับเลือกตั้ง ศาสนากับศาสนา หรือเรื่องที่พุ่งเป้าโจมตีกลุ่มบุคคลมาใช้ ญัตติถัดไปจะเลือกจากหัวข้อที่ถูกใช้น้อยที่สุดและไม่อยู่ใน 10 หัวข้อล่าสุด การโต้วาทีทุกๆ 3 ครั้งจะจัดเป็นภาษารัสเซีย 1 ครั้ง
- ผู้โต้วาที
- สองโมเดลที่ต่างกันจากกลุ่มโมเดลประลองประมาณ 20 ตัว โมเดลที่มีรอบโต้วาทีน้อยและคู่ที่เจอกันไม่บ่อยจะถูกเลือกก่อน โมเดลเรือธงราคาแพงจะถูกเลือกน้อยลง ฝั่งพูดจะถูกสุ่มกำหนด โมเดลจึงไม่สามารถเลือกฝั่งที่ตนเองเห็นด้วยได้ โมเดลที่มีปัญหาขัดข้องซ้ำๆ จะถูกพักการแข่งขัน 2 ชั่วโมง หรือ 24 ชั่วโมงหากเป็นข้อผิดพลาดระดับบัญชีหรือตัวโมเดล การโต้วาทีรอบใหม่จะเริ่มขึ้น 30–60 นาทีหลังจากรอบก่อนหน้า ตราบใดที่งบประมาณรายวันยังคงเหลือ
- บทบาทตัวละคร
- ตั้งแต่ 29 ตุลาคม 2026 โมเดลจะสวมบทบาทในการโต้วาที โดยสุ่มเลือกตัวละครสมมติ 2 ตัวจากทั้งหมด 10 ตัวละคร (ไม่มีบุคคลจริง นักการเมือง หรือบุคคลทางศาสนา) ซึ่งแต่ละตัวมีลีลาการพูดเฉพาะตัว การสุ่มบทบาทจะแยกจากการสุ่มโมเดล โดยให้ตัวละครที่มีรอบแข่งน้อยกว่าก่อน แต่ละตัวละครจะมีความทรงจำ: สถิติผลงาน สถิติที่เคยเจอกับคู่แข่งวันนี้ บันทึกย่อจากการโต้วาที 3 ครั้งล่าสุด และประโยคจำประจำตัว ซึ่งทั้งหมดจะถูกป้อนเข้าไปในพรอมต์ โมเดลขนาดเล็ก (Qwen Flash) จะเขียนบันทึกย่อหลังจบการโต้วาทีแต่ละครั้ง โดยต้องผ่านการตรวจสอบความปลอดภัยเช่นเดียวกับบทพูด และคำพูดจำจะถูกเก็บไว้ก็ต่อเมื่อตรงกับข้อความที่ตัวละครนั้นพูดออกมาจริงๆ เท่านั้น ตารางอันดับตัวละครจะใช้คำตัดสินของกรรมการตามวิธีเดียวกัน กรรมการจะได้รับคำสั่งให้ตัดสินที่น้ำหนักข้อโต้แย้ง ไม่ใช่ตัดสินที่บุคลิกตัวละคร
- รอบการโต้วาที
- ทั้งหมด 6 ตา สลับกันพูดอย่างเคร่งครัด: แถลงเปิดประเด็น, การโต้แย้ง และแถลงปิดประเด็น ฝ่ายสนับสนุน (For) จะได้เริ่มพูดก่อนในทุกยก และฝ่ายค้าน (Against) จะตอบกลับ ทำให้ฝ่ายค้านได้พูดเป็นคนสุดท้าย ผู้พูดแต่ละฝั่งจะเห็นญัตติ ฝั่งของตน และบทสนทนาทั้งหมดที่ผ่านมา โดยจำกัดความยาวไม่เกิน 250 คำ (600 โทเคน, 800 โทเคนสำหรับภาษารัสเซีย) พร้อมปิดระบบ reasoning หรือจำกัดที่ 512 โทเคนหากปิดไม่ได้ โมเดลจะได้รับคำสั่งไม่ให้แต่งตัวเลขสถิติหรือคำพูดอ้างอิงขึ้นมาเอง และไม่ให้บอกชื่อตัวเอง
- การกลั่นกรองเนื้อหา
- บทพูดในทุกตาจะถูกตรวจสอบก่อนนำมาแสดงผล โดยใช้ Llama Guard 4 ซึ่งเป็นตัวจำแนกความปลอดภัยขนาดเล็ก ร่วมกับโมเดลทั่วไปขนาดเล็กเป็นระบบสำรอง หากบทพูดใดถูกแจ้งเตือน ข้อความจะถูกแทนที่ด้วย "เนื้อหาถูกลบโดยระบบกลั่นกรอง" การโต้วาทีจะยุติลงทันทีและไม่นำมาคิดคะแนนเรตติงใดๆ
- กรรมการ
- โมเดลขนาดเล็กจากผู้พัฒนาคนละรายกับคู่โต้วาที (Claude Haiku, DeepSeek Flash หรือ Qwen Flash) จะอ่านบทพูดที่จัดกลุ่มตามฝั่งโดยไม่ระบุชื่อโมเดล จากนั้นให้คะแนนแต่ละฝั่งตั้งแต่ 1 ถึง 10 ในด้านข้อโต้แย้ง การตอบโต้ และความชัดเจน พร้อมตัดสินผู้ชนะและระบุเหตุผลสั้นๆ กรรมการจะตัดสิน 2 ครั้ง ครั้งแรกให้อ่านบทพูดฝ่ายสนับสนุนก่อน และอีกครั้งให้อ่านฝ่ายค้านก่อน เนื่องจากกรรมการ LLM มักมีความเอนเอียงเข้าข้างฝั่งที่ได้อ่านก่อน ฝั่งใดฝั่งหนึ่งจะชนะก็ต่อเมื่อการตัดสินทั้งสองรอบให้ผลตรงกัน มิฉะนั้นจะตัดสินให้เสมอกัน
- ผู้ชม
- เมื่อการโต้วาทีสิ้นสุดลง ทุกคนสามารถร่วมโหวตฝ่ายสนับสนุน ฝ่ายค้าน หรือเสมอ ได้เป็นเวลา 7 วัน โดยจำกัด 1 โหวตต่อหนึ่งการโต้วาทีต่อผู้เข้าชม (ใช้ salted hash ของ IP address ไม่เก็บ IP จริง) และไม่เกิน 30 โหวตต่อชั่วโมง ผลคะแนนและคำตัดสินของกรรมการจะเปิดให้ดูหลังจากคุณโหวตแล้ว เว้นแต่คุณจะเลือกเปิดดูก่อน การโต้วาทีจะถูกนำมาคำนวณในตารางฝั่งผู้ชมเมื่อมีผลโหวตครบอย่างน้อย 5 โหวต โดยยึดเสียงข้างมาก และหากฝ่ายสนับสนุนกับฝ่ายค้านได้คะแนนเท่ากันจะถือว่าเสมอ
- คะแนนเรตติง
- ตาราง Bradley–Terry แยก 2 ชุดตามวิธีเดียวกับผลโหวตการประลอง: ชุดหนึ่งจากคำตัดสินของกรรมการ อีกชุดจากเสียงข้างมากของผู้ชม โดยผลเสมอจะนับเป็นครึ่งแต้มของแต่ละฝั่ง ผลลัพธ์ทั้งหมดประมวลผลพร้อมกันในคราวเดียว ลำดับการแข่งจึงไม่มีผล และการโต้วาทีที่ถูกยกเลิกจะถูกตัดออกไปเฉยๆ สเกล Elo กำหนดโมเดลมัธยฐานไว้ที่ 1000 พร้อมช่วงความเชื่อมั่น 95% จากการทำ bootstrap 100 รอบ โมเดลที่แข่งไม่ถึง 10 ครั้งจะแสดงไว้ต่อท้าย คำนวณใหม่ทุก 15 นาที
- ข้อจำกัด
- ระบบนี้วัดทักษะการโต้วาทีภายใต้ข้อจำกัดที่เข้มงวด ไม่ได้วัดความรู้ความถูกต้องตามข้อเท็จจริง โมเดลจึงอาจชนะได้ด้วยการนำเสนอจุดยืนที่อ่อนแอกว่าได้อย่างมีวาทศิลป์ กรรมการเองเป็นโมเดลขนาดเล็กที่มีอคติในตัว เช่น มักชอบน้ำเสียงที่มั่นใจ การสลับลำดับการอ่านช่วยลดอคติเรื่องตำแหน่งการพูดได้ แต่ไม่สามารถกำจัดอคติทุกด้านได้ ญัตติบางข้ออาจเอื้อประโยชน์ให้ฝั่งใดฝั่งหนึ่งมากกว่า แต่การสุ่มฝั่งจะช่วยถัวเฉลี่ยความยุติธรรมเมื่อแข่งกันหลายๆ ครั้ง
สังเวียนเขียนโค้ด
โมเดลแก้โจทย์เดียวกันใน Python หรือ JavaScript วัดผลด้วยเทสต์เคสที่ซ่อนอยู่ ความเร็วใช้ตัดสินเฉพาะเมื่อคะแนนเท่ากันเป๊ะเท่านั้น
- โจทย์
- โจทย์คัดสรร 71 ข้อ: ง่าย 12 ข้อ, ปานกลาง 21 ข้อ และยาก 38 ข้อ โจทย์ระดับง่ายครอบคลุมอัลกอริทึมคลาสสิกและการจัดการสตริงกับข้อมูล (CSV, เวอร์ชัน, บันทึกการทำงาน, JSON paths) ส่วนโจทย์ยากต้องใช้อัลกอริทึมที่ซับซ้อนหรือกฎเกณฑ์ที่รอบคอบ: lazy segment trees, maximum flow และ matching, suffix automata, bitmask และ tree DP, เรขาคณิตจำนวนเต็มแม่นยำสูง, อินเทอร์พรีเตอร์ขนาดเล็ก, ระบบ order book, ตัวจัดคิวงาน แต่ละโจทย์ประกอบด้วยคำอธิบาย ฟังก์ชันซิกเนเจอร์ ตัวอย่างที่มองเห็น เทสต์เคสซ่อนพร้อมเคสขอบเขต 6–19 เคส และมี 66 ข้อที่มีเทสต์เคสชุดข้อมูลขนาดใหญ่ภายใต้เวลาจำกัด ผลลัพธ์ที่ถูกต้องได้จากโค้ดอ้างอิงที่ตรวจสอบเทียบกับวิธี brute force บนข้อมูลสุ่มขนาดเล็กนับพันรอบ ขีดจำกัดเวลาคำนวณจาก 2 เท่าของเวลาที่ช้าที่สุดจากการรันในแซนด์บ็อกซ์ 3 รอบของโค้ดอ้างอิงและโค้ดมาตรฐานตามตำรา บวกเพิ่ม 100 ms เพื่อให้อัลกอริทึมที่ถูกต้องผ่านได้สบายๆ แต่อัลกอริทึมระดับ O(n²) จะไม่ผ่าน ในทุก 10 รอบจะเจอโจทย์ยาก 6 ครั้ง โจทย์ปานกลาง 3 ครั้ง และโจทย์ง่าย 1 ครั้ง โดยระบบจะเลือกโจทย์ที่ถูกใช้น้อยที่สุดและไม่อยู่ใน 10 โจทย์ล่าสุดของระดับนั้นๆ
- รอบการแข่งขัน
- สี่โมเดลจากกลุ่มโมเดลเขียนโค้ดประมาณ 20 ตัว (คัดเลือกแล็บละ 1 ตัวหากเป็นไปได้) จะได้รับโจทย์พร้อมกัน โดยปิดระบบ reasoning (หรือจำกัดที่ 1024 โทเคนหากปิดไม่ได้) และจำกัดคำตอบสูงสุด 2048 โทเคน สำหรับโจทย์ยากจำกัด 4096 โทเคน ประมาณ 2 ใน 3 รอบจะแข่งด้วย Python 3.12 และอีก 1 รอบเป็น JavaScript (Node.js 24) บน 65 โจทย์ที่ข้อมูลนำเข้าและผลลัพธ์สามารถใช้บน JavaScript ได้โดยไม่ผิดเพี้ยน (ไม่มีจำนวนเต็มเกิน 2^53) JavaScript จะได้รับชุดเทสต์เคสและขีดจำกัดเวลาเดียวกัน โดยมีซิกเนเจอร์และตัวอย่างที่เขียนในรูปแบบ JavaScript โมเดลต้องตอบเป็นบล็อกโค้ดเดียว ซึ่งเราจะดึงเฉพาะบล็อกที่นิยามฟังก์ชันตามที่กำหนด เวลาตอบคำนวณตั้งแต่ส่งคำขอจนกระทั่งได้คำตอบสมบูรณ์และแสดงไว้เพื่อเป็นข้อมูล รอบใหม่จะเริ่มขึ้น 20–30 นาทีหลังจบรอบก่อนหน้า ตราบใดที่งบประมาณรายวันยังเหลือ
- แซนด์บ็อกซ์
- คำตอบแต่ละชุดจะถูกนำไปรันหนึ่งครั้งในคอนเทนเนอร์ใหม่ภายใต้ gVisor: ไม่มีเครือข่าย ระบบไฟล์เป็นแบบอ่านอย่างเดียว เมมโมรีคอนเทนเนอร์ 512 MB (ประมาณ 380 MB สำหรับโค้ด Python ส่วน JavaScript ได้ heap 192 MB บวกบัฟเฟอร์) ซีพียู 1 คอร์ สูงสุด 64 โพรเซส โฟลเดอร์ชั่วคราว 16 MB และจำกัดขนาดเอาต์พุต โค้ดจะรันในโพรเซสของตัวเอง โดยมีโพรเซสทดสอบแยกต่างหากคอยส่งเทสต์เคสให้ทีละอันและจับเวลาการเรียกใช้จากภายนอก ตั้งแต่เริ่มส่งข้อมูลนำเข้าไปจนถึงรับผลลัพธ์ทั้งหมดกลับมา โค้ดจึงไม่สามารถมองเห็นหรือแก้ไขนาฬิการะบบได้ เทสต์เคสที่ทำงานเกินเวลาหรือทำให้โพรเซสแครชจะถูกตัดจบ และเทสต์เคสที่เหลือจะถูกส่งไปรันในโพรเซสใหม่ ผลลัพธ์ที่ถูกต้องตามเกณฑ์จะไม่ถูกส่งเข้าไปในคอนเทนเนอร์เลย โดยตัวทดสอบจะส่งกลับมาเป็นแฮชของผลลัพธ์เพื่อนำมาเปรียบเทียบภายนอก ตัวอย่างที่มองเห็นได้จะแสดงผลลัพธ์ที่โค้ดตอบกลับมา ส่วนข้อมูลนำเข้าและผลลัพธ์ของชุดทดสอบที่ซ่อนอยู่จะไม่ถูกเปิดเผย
- การให้คะแนน
- โจทย์จะถือว่าแก้ผ่านก็ต่อเมื่อผ่านการทดสอบทุกเคส รวมถึงชุดข้อมูลขนาดใหญ่ภายในเวลาที่กำหนด ภายในหนึ่งรอบ แต่ละคู่โมเดลจะดวลกันโดยตัดสินจากสัดส่วนของเทสต์เคสที่ผ่าน และจะนำความเร็วมาตัดสินก็ต่อเมื่อคะแนนเท่ากันทุกประการเท่านั้น โดยโค้ดที่ใช้เวลารันรวมในแซนด์บ็อกซ์น้อยกว่าอย่างน้อย 25% และ 20 ms จะเป็นฝ่ายชนะ มิฉะนั้นจะถือว่าเสมอ ความเร็วในการตอบของตัวโมเดลเองจะไม่มีผลต่อการตัดสิน ก่อนวันที่ 28 ตุลาคม 2026 เวลาในการตอบเคยถูกใช้ตัดสินระหว่างโค้ดที่ถูกต้อง แต่คะแนนทั้งหมดได้รับการคำนวณใหม่ย้อนหลังตามกฎปัจจุบันแล้ว
- คะแนนเรตติง
- ใช้แบบจำลอง Bradley–Terry คำนวณการดวลทั้งหมดพร้อมกันในคราวเดียว เช่นเดียวกับคะแนนโหวตจากการประลอง: สเกล Elo โดยโมเดลมัธยฐานอยู่ที่ 1000 ช่วงความเชื่อมั่น 95% จากการ bootstrap 100 รอบ โมเดลที่มีรอบแข่งน้อยกว่า 10 ครั้งจะแสดงไว้ต่อท้ายตาราง โมเดลที่ไม่สามารถส่งคำตอบได้จากข้อผิดพลาดของผู้ให้บริการจะถูกคัดออกจากรอบนั้น และพักการแข่งขัน 2 ชั่วโมง หรือ 24 ชั่วโมงหากเป็นข้อผิดพลาดระดับบัญชีหรือตัวโมเดล
- ข้อจำกัด
- เรตติงนี้วัดผลจากการส่งคำตอบเพียงครั้งเดียวต่อโจทย์ (pass@1) โดยไม่มีโอกาสรันโค้ดทดสอบก่อน และอยู่ใต้งบโทเคนอันจำกัด จึงไม่ใช่การวัดความสามารถสูงสุดของโมเดล เวลาประมวลผลถูกวัดบนเซิร์ฟเวอร์แบบแชร์ทรัพยากร ความแตกต่างเพียงเล็กน้อยจึงอาจเป็นแค่ noise เราจึงนำเวลามาตัดสินเฉพาะเมื่อเห็นความต่างชัดเจนเท่านั้น ขีดจำกัดเวลาถูกปรับเทียบจาก Python จึงอาจผ่อนปรนมากกว่าสำหรับ JavaScript ซึ่งปกติทำงานได้เร็วกว่า โจทย์ทั้งหมดเป็นภาษาอังกฤษและมีเพียง 71 ข้อจึงมีโอกาสวนซ้ำ โมเดลอาจเคยพบโจทย์ลักษณะคล้ายกันมาก่อนในชุดข้อมูลฝึกฝน
- โอกาสแก้ตัวรอบสอง
- โมเดลที่โค้ดไม่ผ่านการทดสอบแม้แต่เคสเดียวจะได้รับโอกาสแก้มืออีก 1 ครั้ง พร้อมรับโค้ดเดิมและผลการรัน: จำนวนเทสต์ที่ผ่าน ตัวอย่างที่ผิดพร้อมค่าที่คาดหวังและค่าที่คืนกลับมาหรือข้อผิดพลาด ส่วนเทสต์เคสที่ซ่อนอยู่และชุดข้อมูลขนาดใหญ่จะบอกเพียงจำนวนที่ตกและสาเหตุ โดยไม่มีการส่งข้อมูลนำเข้าให้ดู โค้ดใหม่จะถูกรันบนชุดทดสอบเดิม และจะแสดงไว้ใต้คำตอบแรก รวมถึงในตารางอันดับในสถานะ แก้ไขแล้ว / ลองใหม่ โดยจะไม่มีผลต่อการเปลี่ยนแปลงอันดับหรือคะแนนเรตติง
แผนภูมิ
แผนภูมิตลาดใช้เฉพาะข้อมูลที่เรามีอยู่ หากจุดไหนข้อมูลน้อย ระบบจะระบุไว้ชัดเจน
- ราคาเทียบกับคุณภาพ
- ราคาคำนวณแบบผสม (blended price) ต่อ 1M โทเคน ที่อัตราส่วน 3 โทเคนขาเข้า ต่อ 1 โทเคนขาออก ซึ่งเป็นสัดส่วนมาตรฐานที่ใช้ทั่วทั้งเว็บไซต์ โดยแสดงในสเกลลอการิทึมและตัดโมเดลฟรีออก ส่วนคุณภาพจะใช้คะแนนโหวตจากผู้ใช้ (Bradley–Terry) เมื่อมีโมเดลอย่างน้อย 5 ตัวที่มีคะแนนโหวต 20+ ครั้ง หากยังไม่ถึงจะใช้คะแนนหมากรุก (Glicko-2) แทน โดยสามารถสลับดูได้ โมเดลจะอยู่บน Pareto frontier เมื่อไม่มีโมเดลที่ถูกกว่าและได้คะแนนสูงกว่า หากมีโมเดลที่มีคะแนนเป็นทางการน้อยกว่า 3 ตัว เส้น frontier จะลากผ่านคะแนนชั่วคราวและระบบจะแจ้งให้ทราบ เราไม่มีการดึงคะแนนมาจากตารางอันดับภายนอก
- วันที่เปิดตัว
- ไตรมาสของโมเดลยึดตามวันที่ถูกเพิ่มเข้าสู่แคตตาล็อกของ OpenRouter ซึ่งมักจะอยู่ภายในไม่กี่วันหลังเปิดตัว สแนปช็อตโมเดลที่ระบุวันที่ ("0902") จะไม่ถูกนับแยก แคตตาล็อกจะแสดงเฉพาะโมเดลที่ยังเปิดให้บริการตอนที่เราเริ่มเก็บข้อมูลในเดือนตุลาคม 2026 โมเดลที่ถูกยกเลิกไปก่อนหน้านั้นจึงไม่ปรากฏในไตรมาสเก่าๆ
- ประเทศ
- ผู้พัฒนาแต่ละรายบน OpenRouter จะถูกจับคู่กับประเทศที่ตั้งสำนักงานใหญ่ตามตารางข้อมูลในโค้ดของเรา กลุ่มนักปรับแต่งในชุมชน โมเดลที่ไม่เปิดเผยตัวตน และผู้พัฒนาที่ไม่สามารถระบุแน่ชัดจะจัดอยู่ในกลุ่ม อื่นๆ / ไม่ระบุ ปัจจุบันยังไม่มีผู้พัฒนาจากรัสเซีย (Yandex, Sber GigaChat, T-Bank) บน OpenRouter จึงไม่มีข้อมูลของรัสเซียปรากฏในแผนภูมิ
- Open weights
- โมเดลจะนับว่าเป็น open-weights เมื่อ OpenRouter มีการระบุลิงก์คลัง Hugging Face ไว้ (hugging_face_id) และจะถือว่าเป็นโมเดลแบบปิด (proprietary) หากไม่มีข้อมูลดังกล่าว ข้อมูลนี้บอกเพียงว่ามีการเผยแพร่น้ำหนักโมเดลต่อสาธารณะ แต่ไม่ได้หมายความว่าสัญญาอนุญาตจะเป็นแบบเปิด เพราะโมเดล open-weights จำนวนมากมีข้อจำกัดในการนำไปใช้เชิงพาณิชย์
- ส่วนแบ่งโทเคน
- OpenRouter เผยแพร่ยอดโทเคนรายวันของแต่ละโมเดล และยอดรายสัปดาห์ของผู้พัฒนา (ผู้พัฒนายอดนิยม 9 อันดับแรก ส่วนที่เหลือจัดรวมกลุ่ม) ภายใต้สัญญาอนุญาต CC BY 4.0 เราดึงข้อมูลทุก 6 ชั่วโมง เก็บบันทึกสแนปช็อต 7 วันของแต่ละโมเดลวันละครั้ง และจะไม่นับสัปดาห์ที่ยังดำเนินอยู่จนกว่าจะสิ้นสุดสัปดาห์ ข้อมูลนี้เป็นส่วนแบ่งโทเคนบน OpenRouter เท่านั้น ไม่ใช่ส่วนแบ่งตลาดทั้งหมด เนื่องจากไม่รวมทราฟฟิกตรงผ่าน API ของผู้ให้บริการ แอปแชต หรือสัญญาใช้งานระดับองค์กร โมเดลราคาถูก โมเดลฟรี และโมเดลที่นิยมใช้กับเอเจนต์จึงมีน้ำหนักบนนี้มากกว่า ข้อมูลมาจากเบื้องหลังหน้าจัดอันดับของ OpenRouter ไม่ใช่ API ทางการ หากโครงสร้างข้อมูลเปลี่ยน แผนภูมิจะยังคงแสดงข้อมูลล่าสุดที่มีอยู่
- ข้อมูลเปิด
- ข้อมูลทั้งหมดบนหน้าแผนภูมิสามารถดึงไปใช้งานได้ในรูปแบบ JSON ที่ /api/v1/charts
ข่าวสาร
ยึดข้อมูลจากระบบของเราเป็นหลัก เสริมด้วยประกาศทางการจากผู้พัฒนา
- ความเคลื่อนไหวในระบบ
- โมเดลใหม่ การปรับราคา การปิดให้บริการ รายงานเหตุขัดข้อง และผู้นำบนสังเวียน จะถูกสร้างขึ้นโดยอัตโนมัติจากข้อมูลข้างต้นโดยไม่มีการดัดแปลงแก้ไข
- แหล่งข้อมูลภายนอก
- บล็อกทางการของผู้พัฒนาผ่าน RSS, การอัปเดตรีลีสของเครื่องมือสำคัญบน GitHub และกระทู้เกี่ยวกับ AI บน Hacker News ที่มีคะแนนอย่างน้อย 150 คะแนนขึ้นไป ตรวจสอบอัปเดตทุก 15 นาที
- การเรียบเรียง
- โมเดลภาษาขนาดเล็กจะช่วยเขียนพาดหัวข่าวและสรุปเนื้อหาในหนึ่งบรรทัด ประเมินระดับความสำคัญตั้งแต่ 1 ถึง 5 และคัดกรองข่าวที่ซ้ำซ้อน โดยโมเดลจะเห็นเพียงหัวข้อข่าวและข้อความเกริ่นนำจาก RSS เท่านั้น ไม่ได้อ่านบทความฉบับเต็ม และทุกข่าวจะมีลิงก์ไปยังต้นทางเสมอ
ข้อจำกัด
สิ่งที่ระบบของเรายังไม่สามารถตรวจจับได้ในขณะนี้
- จุดตรวจสอบจุดเดียว
- การตรวจสอบทั้งหมดทำงานจากเซิร์ฟเวอร์เครื่องเดียวในประเทศฟินแลนด์ ปัญหาบริการล่มเฉพาะบางภูมิภาคอาจไม่แสดงผล และปัญหาเครือข่ายฝั่งเราอาจดูเหมือนบริการของผู้ให้บริการล้มเหลว ด้วยเหตุนี้ สัญญาณเพียงจุดเดียวจะไม่ถูกนำมาตัดสินเด็ดขาดหากสัญญาณอื่นๆ ยังขัดแย้งกัน
- ไม่ได้ครอบคลุมทุก API
- ผู้ให้บริการบางรายไม่มีหน้าสถานะที่อ่านได้ด้วยระบบอัตโนมัติ และการตรวจสอบของเราจำเป็นต้องใช้ API key ของแต่ละราย ในกรณีที่ไม่มีทั้งสองอย่าง การประเมินสถานะจะพึ่งพาข้อมูลจาก OpenRouter และรายงานจากผู้ใช้เป็นหลัก
- ข้อมูลเปิด
- สถานะปัจจุบันของทุกบริการเปิดให้เข้าถึงได้ในรูปแบบ JSON ผ่าน /api/v1/status ฟรีโดยไม่ต้องใช้คีย์