โครงสร้างพื้นฐานการกำหนดเส้นทาง OrcaRouter: การกำหนดเส้นทางแบบรับรู้เซสชันและการยกระดับฟรอนเทียร์

ORCAROUTER · สถาปัตยกรรมการจัดเส้นทาง

เกตเวย์ LLM ทุกตัวที่แคชพรอมต์ต้องตรึงการสนทนาไว้กับโมเดลเดียว เกตเวย์ทุกตัวที่ตรึงการสนทนาจะตัดสินใจเลือกเส้นทางโดยอิงจากเทิร์นที่มีข้อมูลน้อยที่สุดของการสนทนานั้น นี่คือรายงานเกี่ยวกับการแลกเปลี่ยนดังกล่าว และเกี่ยวกับกลไกแบบ tiered-stickiness ที่ OrcaRouter นำเสนอเพื่อหลีกเลี่ยงมัน

หัวข้อ: OrcaRouter LLM เกตเวย์ (Go / Gin / Redis) · ส่วนประกอบ: การยึดติดเซสชัน + เอ็นจิน Frontier Escalation · วิธีการ: การรีเพลย์ 400 เซสชันกับโค้ดตัดสินใจในโปรดักชัน · วันที่: 14 สิงหาคม 2026

บทคัดย่อ — การจัดเส้นทาง LLM ระดับคำขอ — การให้คะแนนแต่ละคำขออย่างอิสระและจัดส่งไปยังโมเดลที่ถูกที่สุดแต่เพียงพอ — เป็นแนวทางที่งานวิจัยด้านเราเตอร์ที่ตีพิมพ์เกือบทั้งหมดกล่าวถึง มันยังเป็นแนวทางที่ผิดสำหรับการรับส่งข้อมูลที่ครองปริมาณเกตเวย์ในปัจจุบัน: เซสชันเอเจนต์แบบหลายเทิร์น ซึ่งพรอมpt์เป็นบริบทที่ส่งต่อมา 90% และแคชพรอมpt์ของผู้ให้บริการให้ผลตอบแทนกับความต่อเนื่อง การสลับโมเดลกลางบทสนทนาทำให้สูญเสียส่วนลด 10 เท่าบน prefix ร่วม ดังนั้นเกตเวย์จึงตรึงเซสชันไว้ แต่การตรึงที่ทำในเทิร์นที่ 1 คือการตรึงในเทิร์นที่มีหลักฐานน้อยที่สุด และมันคงอยู่ตลอดอายุของการสนทนา

100 / 100 — เซสชันแบบ latent-hard ซึ่งคะแนนในเทิร์นแรกแยกไม่ออกจากเซสชันธรรมดา

+16% — การเบี่ยงเบนของคะแนนความยากจากความยาวของบทถอดเสียงเพียงอย่างเดียว ในงานที่มีระดับความยากเท่ากัน

45% — ของต้นทุนแบบ always-frontier สำหรับ 67% ของความครอบคลุมแบบ hard-turn

0.019 — ระยะห่างระหว่างเกตที่ส่งออกกับเพดานของคะแนนตามความเป็นจริง

1 สองระบอบการกำหนดเส้นทาง

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

การกำหนดเส้นทางระดับคำขอ ปฏิบัติต่อแต่ละคำขออย่างเป็นอิสระ ตัวให้คะแนนจะประมาณความยากของคำขอหรือคุณภาพการตอบที่คาดการณ์ไว้ แล้วส่งคำขอดังกล่าวไปยังโมเดลที่ถูกที่สุดที่คาดว่าจะจัดการได้ นี่คือแนวทางของงานวิจัยด้านเราเตอร์ที่ตีพิมพ์แทบทั้งหมด: RouteLLM ฝึกเราเตอร์ด้วยข้อมูลความชอบ ซึ่งให้คุณภาพเท่ากับ GPT-4 ถึง 95% โดยใช้การเรียกใช้โมเดลที่แข็งแกร่งเพียง 14%sup>[1]/sup>; FrugalGPT ใช้การเรียงลำดับแบบต่อเนื่องจากโมเดลราคาถูกไปยังราคาแพง โดยมีการตรวจสอบยอมรับ/ปฏิเสธ และรายงานการลดต้นทุนได้ถึง 98%sup>[2]/sup>; RouterArena สร้างเบนช์มาร์กที่มีคำขอ 8,400 รายการเพื่อเปรียบเทียบเราเตอร์ในมิตินี้โดยเฉพาะsup>[3]/sup>. หน่วยการวิเคราะห์คือคำขอ

การกำหนดเส้นทางที่รับรู้เซสชัน

เหตุผลที่ session-aware routing มีอยู่ไม่ใช่เพื่อความสวยงาม แต่เป็นเรื่องของคณิตศาสตร์

2 เศรษฐศาสตร์ของแคชที่ทำให้ความยึดติดเป็นสิ่งจำเป็น

ในเซสชันเอเจนต์แบบหลายเทิร์น เทิร์นที่ n คือพรอมต์ของเทิร์นที่ n−1 บวกเดลต้า พอถึงเทิร์นที่ 10 คำนำหน้าที่ส่งต่อมาจะเป็นส่วนใหญ่ท่วมท้นของโทเคนอินพุตทั้งหมด ปัจจุบันผู้ให้บริการรายใหญ่ทุกรายคิดราคาคำนำหน้านั้นแตกต่างกันไปขึ้นอยู่กับว่าเป็นการแคชฮิตหรือไม่:

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

OrcaRouter กำหนดอายุการใช้งานเหล่านี้เป็น TTL ของพินอย่างแม่นยำ: แผนที่ตามประเภทช่องทางของหน้าต่างแคชของผู้ให้บริการ — 5 นาทีสำหรับ OpenAI, Anthropic และ Gemini, 60 นาทีสำหรับ DeepSeek — โดยค่าเริ่มต้นสำหรับผู้ให้บริการที่ไม่มีการแมปคือ 5 นาที พิน channel+key จะหมดอายุพร้อมกับหน้าต่างนั้น เนื่องจากดัชนีคีย์ที่ล้าสมัยไม่มีคุณค่าในการแคช และเพียงแค่บิดเบือนการจัดสรรโหลด. โมเดล พิน, บนการติดตั้งที่ใช้ Redis และสำหรับ session id ที่มีสิทธิ์ได้รับพินระยะยาว จะคงอยู่เป็นเวลา 30 วัน — ไม่ใช่เพื่อคุณค่าในการแคช ซึ่งหายไปนานแล้ว แต่เพื่อความต่อเนื่องของรูปแบบคำขอ. การสลับโมเดลระหว่างการสนทนาทำให้เกิดการแปลงรูปแบบคำขอที่อาจเข้ากันไม่ได้กับข้อมูล: บล็อกการคิดและ ID การเรียกใช้เครื่องมืออาจไม่คงอยู่เมื่อแปลงระหว่างสคีมาของผู้ให้บริการ

รายละเอียดที่ถูกมองข้าม

แคชพรอมปต์ถูกคีย์ต่อคีย์ API ไม่ใช่ต่อโมเดล เกตเวย์ที่ปักหมุดโมเดลแต่กระจายโหลดข้ามคีย์สามตัวบนช่องทางเดียวกัน ยังต้องอ่านจากแคชเย็นถึงสองในสามเทิร์น นี่คือสาเหตุที่ channel pin ของ OrcaRouter เก็บ {ChannelID, KeyIndex} แทนที่จะเป็นแค่ channel id และสาเหตุที่ pin จะถูกปลดเมื่อคีย์อินเดกซ์ที่บันทึกไว้ไม่ชี้ไปยังคีย์ที่เปิดใช้งานอยู่อีกต่อไป — คีย์ที่ถูกบูสต์แต่ถูกหมุนเวียนจะทำให้เอนเอียงไปทางแคชเย็น ขณะที่เลี่ยงการปรับสมดุล ซึ่งเป็นผลเสียทั้งสองทาง

พินเหล่านี้เป็นแบบอ่อนตลอดทั้งระบบ: การไม่มี session id ที่สามารถระบุได้ถือเป็นการไม่ดำเนินการใดๆ ช่องทางที่ถูกพินซึ่งถูกปิดใช้งานหรือไม่แข็งแรงจะถูกลดระดับไปใช้การเลือกแบบสมดุลตามปกติ และการพินไปยังช่องทางที่มีน้ำหนักเป็นศูนย์ในพูลแบบผสมจะถูกยกเลิก เพื่อไม่ให้ความยึดติดขัดขวางผู้ดูแลระบบที่กำลังระบายช่องทาง การพินเหล่านี้จะไม่ทำให้คำขอล้มเหลว

3 กับดัก: ความเกาะติด (stickiness) ทำให้เราเตอร์ถูกปิดใช้งาน

นี่คือโหมดความล้มเหลว ในส่วนของ OrcaRouter ที่เรียกว่า เส้นทางโค้ดก่อนการเพิ่มระดับ, สำหรับเราเตอร์ที่รับรู้เซสชันบนกลยุทธ์ที่ไม่ใช่ DSL ใดๆ ค่า pin จากเซสชันไปยังโมเดลที่ส่งคืน

นั่นคงจะพอทนได้ถ้าเทิร์น 1 เป็นตัวแทน แต่มันไม่เป็นเช่นนั้นอย่างเป็นระบบ ด้วยเหตุผลสองประการที่ซ้ำเติมกัน

3.1 เทิร์นที่ 1 เป็นเทิร์นที่ให้ข้อมูลน้อยที่สุด

สเกลาร์ความยาก (service/model_router_difficulty.go) คือผลรวมเชิงเส้นแบบถ่วงน้ำหนักของคุณลักษณะเชิงคำศัพท์หกประการ:

LogPromptTokens × 0.20 โดยมีเพดานที่ log(8001) ≈ 8.99

ReasoningCueCount × 0.15 สูงสุด 5

SystemPromptLogLen × 0.10 จำกัดสูงสุดที่ log(2001) ≈ 7.60

CodeKeywordDensity × 0.20 เพดาน 5.0 (จำนวนที่ตรงต่อ 100 ตัวอักษร)

HasTools × 0.15 เรียบร้อยแล้ว 0/1

คณิตศาสตร์ MarkerCount × 0.20 เพดาน 5

บทนำสั้นๆ ที่ไม่มีประวัติมีคะแนนต่ำเกือบจะโดยโครงสร้างอยู่แล้ว: เทอมโทเคนที่มีน้ำหนัก 0.20 อยู่ใกล้จุดต่ำสุด และเทอมการให้เหตุผล/คณิตศาสตร์ก็ทำงานบนคำศัพท์ที่ผู้ใช้ยังไม่มีเหตุผลจำเป็นต้องใช้ เซสชันจึงผูกมัดกับโมเดลพูลที่อ่อนแอในขณะที่มีข้อมูลน้อยที่สุด — และด้วยการปักหมุดโมเดล 30 วันบน Redis การผูกมัดนั้นจึงยาวนาน

รูปที่ 1. ค่าเฉลี่ยความยากของเทิร์นล่าสุดจำแนกตามเทิร์นการสนทนา จากเซสชันที่ยากแฝง 100 เซสชันและเซสชันที่ง่ายจริง 200 เซสชัน ให้คะแนนโดยตัวให้คะแนนฝั่งโปรดักชัน ที่เทิร์น 1 — เทิร์นที่เขียนพินติดหนึบ — ประชากรทั้งสองกลุ่มแยกไม่ออก (0.210 เทียบกับ 0.208) ประชากรกลุ่มยากข้ามเกตที่เทิร์น 5 ภายใต้นโยบายพินเท่านั้น เซสชันยากแฝงทั้งหมด 100 เซสชันถูกจัดเข้าไปในกลุ่มราคาถูกก่อนที่หลักฐานใดๆ เหล่านั้นจะเกิดขึ้น

3.2 ความยาวปลอมตัวเป็นความยาก

ปัญหาที่สองละเอียดอ่อนกว่า และมันบ่อนทำลายวิธีแก้ไขที่เห็นได้ชัด หากคุณเพียงแค่เรียกใช้เกณฑ์ความยากซ้ำในทุกเทิร์น คุณกำลังเรียกใช้มันบนคะแนนที่คำนวณจากทรานสคริปต์ที่เชื่อมต่อกันทั้งหมด คะแนนนั้นมีแนวโน้มเพิ่มขึ้นในตัว: เทอม LogPromptTokens ที่ถ่วงน้ำหนัก 0.20 จะเพิ่มขึ้นแบบโมโนโทนิกตามความยาวของการสนทนา และสำหรับเซสชันเอเจนต์ใดๆ เทอม HasTools ที่ 0.15 และเทอม SystemPromptLogLen ที่ 0.10 เป็นค่าพื้นคงที่ในทางปฏิบัติ เซสชันที่ยาวและน่าเบื่อจะดูยากขึ้นเรื่อยๆ

รูปที่ 2. อาร์ติแฟกต์ความเอนเอียงจากความยาว (length-bias artefact) ซึ่งวัดจากเซสชัน 60 เซสชันที่ประกอบด้วยการแก้ไขเล็กน้อยทั้งหมด ("เปลี่ยนชื่อตัวแปรนี้" "เพิ่มการตรวจสอบ nil") คะแนนทรานสคริปต์เต็มเบี่ยงเบนไป +16% ตลอด 25 เทิร์นที่ความยากของงานคงที่ ในขณะที่คะแนนเทิร์นล่าสุด (เดลต้า) นั้นคงที่ การประเมินคะแนนทรานสคริปต์เต็มซ้ำแบบไร้เดียงสาทุกเทิร์นจะทำให้เซสชันถูกยกระดับความสำคัญเพียงเพราะมันยาวเกินไป

การแก้ไขที่ OrcaRouter จัดส่งมานั้นคือแบบแยกต่างหากของเดลต้าเอ็กซ์แทรกเตอร์ (service/model_router_delta.go) ซึ่งให้คะแนนเฉพาะเทิร์นล่าสุดเท่านั้น — ข้อความใหม่จากผู้ใช้บวกกับผลลัพธ์จากเครื่องมือใดๆ ที่แนบมาหลังข้อความล่าสุดของผู้ช่วย — โดยใช้ค่าน้ำหนักและแคปชุดเดียวกัน แต่จงใจปรับ SystemPromptLogLen ให้เป็นศูนย์ ซึ่งไม่เป็นส่วนหนึ่งของเดลต้า เส้นสีน้ำเงินราบในรูปที่ 2 คือเอ็กซ์แทรกเตอร์นั้น

4 การออกแบบ: ความเหนียวแน่นแบบหลายระดับ

การหลีกหนีแบบง่ายๆ จากปัญหาการล็อกที่เทิร์นแรก (turn-1 lock-in) คือการเปลี่ยนเส้นทางทุกเทิร์น — ซึ่งเป็นแค่การจัดเส้นทางระดับคำขอ (request-level routing) และทำให้แคชไร้ประโยชน์ ในทางกลับกัน การแก้อีกแบบที่ง่ายเกินไปคือการทำให้ pin จดจำว่า “เซสชันนี้ยากแล้ว” — ซึ่งไม่สามารถแสดงถึงการลดระดับความยาก และไม่สามารถจำกัดเพดานได้ การออกแบบของ OrcaRouter ปฏิเสธทั้งสองแนวทางนี้

การปรับกรอบใหม่: เซสชันถูกปักหมุดกับโมเดลหนึ่งภายในเทียร์และใน Redis ขนาดเล็ก สถานะของเทียร์ คือหน่วยความจำสำหรับการยกระดับเพียงอย่างเดียว การปักหมุดโมเดลไม่เคยเป็นหน่วยความจำ

กลุ่มระดับชั้น ระดับชั้นแบบ strong คือพูลการเลื่อนระดับที่ถูกแก้ไขแล้ว (escalation_pool ซึ่งค่าเริ่มต้นคือ strong_pool ของเราเตอร์) ระดับชั้นพื้นฐานคือ AllowedModels \ พูลของระดับชั้น strong โมเดลที่อยู่ในทั้งสองจะจัดอยู่ในระดับชั้น strong ภายในระดับชั้นพื้นฐาน การแบ่งระดับความยาก weak/mid/strong ของ gated_adaptive ยังคงทำงานเหมือนเดิมทุกประการ

พินที่จำกัดขอบเขตตามเทียร์ คีย์พินโมเดลของเทียร์ที่แข็งแกร่งจะได้คำต่อท้าย :t:strong; เทียร์พื้นฐานจะคงคีย์ดั้งเดิมไว้ไม่เปลี่ยนแปลง ดังนั้นการยกระดับจึงคงรักษาพินพื้นฐานไว้ ทำให้เซสชันที่ถูกลดระดับ — หรือเซสชันที่กลับมาดำเนินการต่อหลังจากสถานะเทียร์หมดอายุ — กลับไปยังโมเดลเดิมที่เริ่มต้นไว้ ไม่ใช่การเลือกใหม่โดยพลการ พินที่แข็งแกร่งจะถูกเขียนด้วย TTL ระยะสั้นของหน้าต่างผู้ให้บริการเท่านั้น: พินที่แข็งแกร่งแบบ 30 วันจะมีอายุยืนกว่าสถานะเทียร์ 4 ชั่วโมงซึ่งเป็นเหตุผลที่ทำให้ต้องมีพินนั้น

เกตทำงานก่อน ใน selectByStrategy (service/model_router.go:1374) เทียร์จะถูกกำหนดไว้ล่วงหน้า ชุดตัวเลือกจะถูกจำกัดให้เหลือเพียงพูลของเทียร์นั้น และเฉพาะเมื่อถึงตอนนั้นจึงจะมีการตรวจสอบสติกกี้พิน — ภายในเทียร์นั้น นี่คือการแก้ไขเชิงโครงสร้างสำหรับ §3: การคำนวณความยากและทริกเกอร์การยกระดับจะทำงานทุกเทิร์น ก่อนที่พินจะลัดวงจรพวกมันได้

4.1 ทริกเกอร์สามคลาส จัดอันดับตามความน่าเชื่อถือ

ตารางที่ 2. ตัวกระตุ้นการเพิ่มระดับ ไม่มีสัญญาณคลุมเครือใดที่ขยับระดับขึ้นเองโดยลำพัง มีเพียงคำขอจากลูกค้าที่ชัดเจนเท่านั้นที่จะเริ่มดำเนินการที่ n=1 และแม้แต่คำขอดังกล่าวก็ยังต้องอยู่ภายใต้เพดานที่กำหนด

ข้อกำหนดสุขอนามัยสามประการเป็นแกนหลักของระบบ Strikes ถูกตัดซ้ำด้วย request id ผ่าน ring buffer ดังนั้นการ retry ของ client ที่สอดแทรกกันจะไม่นับซ้ำ ความล้มเหลวของโครงสร้างพื้นฐานไม่เคยเป็นความล้มเหลวของความสามารถ — 429s, 5xxs และ channel fallbacks ไม่ก่อให้เกิด strike; เฉพาะสัญญาณคุณภาพหลังความสำเร็จเท่านั้นที่นับ และ "เทิร์น" ถูกนิยามว่าเป็นคำขอที่เสร็จสมบูรณ์และถูกเรียกเก็บเงินสำเร็จซึ่งผ่านการประเมิน strike ดังนั้นคำขอที่ล้มเหลวจะไม่ทำให้เกิดการลดลงของ strike หรือตัวนับเทิร์นที่สะอาด

4.2 การ resolve เป็น pure; การ commit ถูกเลื่อนออกไป

คุณสมบัติเชิงโครงสร้างที่สำคัญที่สุดของเอนจินคือ ResolveEscalation ไม่เขียนอะไรเลย มันคืนการตัดสินใจพร้อมกับรายการของสิ่งที่รออยู่ อินเทนต์. ตัวกระจายจะนำอินเทนต์เหล่านั้นไปใช้ในบล็อกหลังความสำเร็จ ลงบน การอ่านข้อมูลใหม่ภายในธุรกรรม Redis WATCH. เรื่องนี้สำคัญเพราะตัว resolver ทำงานบนเส้นทางที่ไม่ควรเปลี่ยนแปลงสถานะเลย: การแก้ไขสายการสำรองแบบคาดการณ์ล่วงหน้า, เอนด์พอยต์การวินิจฉัยแบบอ่านอย่างเดียว, และคำขอที่ภายหลังจะคืนค่า 403 หรือล้มเหลวที่ต้นทาง การนำอินเทนต์ไปใช้ซ้ำกับสถานะใหม่ยังหมายความว่าผู้เขียนพร้อมกันที่เก่าจะไม่สามารถเขียนทับการยกระดับที่คอมมิตแล้วได้ และการยกระดับที่เหมือนกันสองรายการซึ่งแข่งขันกันจะรวมกันอย่างไอดีมโพเทนต์

4.3 แคปส์ และเหตุใดมันจึงผูกมัดทุกอย่าง

การยกระดับผลบวกลวงมีต้นทุนเท่ากับ (strong − base) price × จำนวนโทเคน warm-episode ที่เหลือ และมันแบกรับต้นทุนนั้นอย่างเงียบๆ — ไม่มีอะไรล้มเหลว รัศมีความเสียหายถูกจำกัดด้วยขีดจำกัดที่ใช้กับ ทุกคลาส:

escalation_max_per_session (ค่าเริ่มต้น 1) การลดระดับและการรีเซ็ตไคลเอนต์ไม่คืนค่าให้ ซึ่งปิดช่องทางการเล่นเกมแบบวนลูปรีเซ็ต

ต่อเราเตอร์หนึ่งตัวเพดานส่วนแบ่งการยกระดับ (ค่าเริ่มต้น 20 %) ในหน้าต่างย้อนหลัง 24–48 ชั่วโมงของบักเก็ตรายวันใน Redis รวมถึงเพดานข้ามเราเตอร์ระดับเวิร์กสเปซ เมื่อถึงเพดาน การกำหนดเส้นทางการยกระดับทั้งหมดจะถูกระงับ — รวมถึงการร้องขออย่างชัดเจนและการบูสต์แบบครั้งเดียว

การลดระดับจะเกิดขึ้นเฉพาะที่ขอบเขตของแคชเย็นเท่านั้น ดังนั้นผลบวกลวงจึงถูกจำกัดให้อยู่ภายในหนึ่งรอบของแคชอุ่น

เหตุผลที่ Class A ปฏิบัติตามขีดจำกัดคือข้อสรุปจากแบบจำลองภัยคุกคาม ไม่ใช่ความชอบเชิงนโยบาย: บน API gateway ผู้ที่ถือโทเค็นของเวิร์กสเปซจะเป็นผู้ควบคุมหัวข้อ (headers) เส้นทางที่ได้รับการยกเว้นขีดจำกัดแบบ "ลูกค้าขอมาเอง" คือช่องทางการใช้จ่ายที่ไม่ได้ถูกวัดปริมาณ §7 วัดสิ่งที่เกิดขึ้นเมื่อไคลเอนต์ทุกรายใช้มันในทางที่ผิด

4.4 การลดความตึงเครียดไม่สมมาตรโดยการออกแบบ

เลื่อนระดับเมื่อมีหลักฐานยืนยัน; ลดระดับเฉพาะเมื่อไม่มีค่าใช้จ่ายเท่านั้น เซสชันที่แข็งแกร่งจะกลับฐานก็ต่อเมื่อ ทั้งหมดของ: เซสชันอยู่ในสถานะ cache-cold (ว่างเกินกรอบของผู้ให้บริการที่บันทึกไว้ตอนเลื่อนระดับ), มีเทิร์นที่ประเมินแล้วโดยไม่มี strike ≥3 ครั้ง, และ delta difficulty ล่าสุดต่ำกว่า T1 ภายในกรอบ warm การสลับต้องจ่ายค่า re-read แบบเย็นเต็มราคา — การ flapping เป็นวิธีเดียวที่รับประกันได้ว่าจะทำให้ escalation มีต้นทุนติดลบ

5 วิธีการ

เราวัดกลไกโดยการเล่นซ้ำชุดข้อมูลเซสชันสังเคราะห์ผ่านโค้ดการตัดสินใจในระบบการผลิตจริง. ฮาร์เนสคือการทดสอบ Go ในแพ็กเกจบริการ ซึ่งเรียก ResolveEscalation และ CommitEscalationDecision ในแต่ละเทิร์นกับ tier store ที่ใช้ miniredis เป็นแบ็กเอนด์ พร้อมด้วยตัวให้คะแนนความยากจริง ตัวสร้าง strike ฝั่งรีเควสต์จริง และกลไก share-cap จริง ไม่มีสิ่งใดในเส้นทางการตัดสินใจที่ถูกเขียนขึ้นใหม่หรือถูกจำลองขึ้นมา ยกเว้น audit-event sink.

อะไรคือเรื่องจริง และอะไรไม่ใช่

จริง:ทุกการตัดสินใจเส้นทาง คะแนนความยาก การตรวจจับสไตรก์ กฎสตรีค การประเมินขีดจำกัด และการเปลี่ยนสถานะ Redis — สิ่งเหล่านี้คือฟังก์ชันที่ใช้งานจริงสังเคราะห์:ทราฟฟิก คอร์ปัสถูกสร้างขึ้น ไม่ได้สุ่มตัวอย่างจากล็อกการผลิตจริง สัดส่วนอาร์คีไทป์ (50% เป็นระดับยาก) เป็นส่วนผสมที่จงใจเลือกเพื่อกดดันกลไกให้ทำงาน ไม่ใช่การประมาณทราฟฟิกจริง §6.4 รายงานความไวต่อตัวเลือกดังกล่าว และพบว่ามีค่าสูง ตัวเลขความแม่นยำที่สะอาดด้านล่างสะท้อนถึงคอร์ปัสที่คลาสต่าง ๆ แยกออกจากกันได้โดยการออกแบบ และควรอ่านว่า “กลไกทำงานในจุดที่ถูกออกแบบให้ทำงาน” ไม่ใช่การประมาณค่าความแม่นยำสำหรับการผลิตจริง

5.1 คลังข้อมูล

400 เซสชัน 3,968 เทิร์น ถูกตั้งค่า seed และเป็น deterministic แต่ละเทิร์นคือ request body แบบเต็มรูปแบบของ chat-completions ที่มีประวัติสะสม อาร์เรย์นิยามเครื่องมือสองตัว และ system prompt ที่สมจริง — ซึ่งเป็นรูปแบบที่ coding agent ส่งจริง ห้า archetypes แต่ละตัวมีป้ายกำกับ ground-truth:

ตารางที่ 3. องค์ประกอบของคลังข้อมูล “ความต้องการที่แข็งแกร่ง” คือความจริงพื้นฐานที่ใช้สำหรับคะแนนความแม่นยำและความครอบคลุม

ในขั้นตอนการดีบักที่ยาก มักจะมีการวาง goroutine dump หรือส่วนย่อยของซอร์สโค้ดขนาด 3–8 KB ลงไปพร้อมกับข้อความบรรยาย เพราะนั่นคือสิ่งที่การดีบักที่ยากจริงๆ ประกอบด้วย รายละเอียดนี้กลับกลายเป็นสิ่งสำคัญอย่างยิ่ง — ดู §6.2

5.2 แบบจำลองต้นทุน

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

ตารางที่ 4. พารามิเตอร์ของแบบจำลองต้นทุน ราคาเป็นดอลลาร์ต่อ 1M โทเคน ตามรายการเดือนสิงหาคม 2026.

เทิร์นแบบ warm มีค่าใช้จ่าย 0.1·p_in·prefix + write·p_in·delta; เทิร์นแบบ cold มีค่าใช้จ่าย write·p_in·prompt เทิร์นที่ 1 จะเป็นการเขียนแคชเต็มรูปแบบเสมอ เทิร์นการสลับระดับ (tier-switch) ภายใต้นโยบายการยกระดับ (escalation policy) จะถูกคิดค่าใช้จ่ายเป็นแบบ cold อย่างชัดเจน ดังนั้นกลไกจึงจ่ายค่าใช้จ่ายสำหรับการทำให้แคชของตัวเองไม่ถูกต้อง

คุณภาพรายงานเป็น ความครอบคลุมของเทิร์นที่ยาก — สัดส่วนของเทิร์นที่ยากตาม ground truth ที่โมเดลแข็งแกร่งให้บริการจริง — แทนที่จะเป็นตัวเลขความแม่นยำ เราไม่ได้รัน upstream inference ดังนั้นเราจึงไม่ประดิษฐ์ตัวเลขความแม่นยำขึ้นมาเอง

6 ผลลัพธ์

6.1 กลไกยิงในตำแหน่งที่ออกแบบไว้

ตารางที่ 5. ผลลัพธ์การยกระดับตามอาร์คีไทป์, โหมดอัตโนมัติ, แคนารี 100 %, T2 = 0.70 (ค่าเริ่มต้นที่จัดส่ง)

ไม่มีผลบวกลวงแม้แต่รายการเดียวจาก 200 เซสชันง่าย ๆ รวมถึง 60 เซสชันที่ยาวนานซึ่งตัวให้คะแนนแบบทรานสคริปต์เต็มรูปแบบคงเลื่อนเข้าไปอยู่ในกลุ่มยาก คลาสทริกเกอร์แยกหน้าที่กันอย่างชัดเจนและไม่ทับซ้อน: difficulty จับงานที่ต้องใช้การให้เหตุผลอย่างหนัก ส่วน strikes จับลูปความล้มเหลว สังเกตว่าคะแนนความยากสูงสุดของ failure_loop คือ 0.262 — เกตความยากไม่เห็นเซสชันเหล่านั้นเลย. เอเจนต์ที่ติดอยู่ในลูป compile error ไม่ได้สร้างข้อความที่อัดแน่นไปด้วยตัวบ่งชี้การใช้เหตุผล แต่มันสร้างพรอมป์สั้นอันเดิมพร้อม stack trace ที่ต่างกัน หากไม่มี Class C strikes ทั้ง 60 เซสชันนั้นจะไถต่อบนโมเดลราคาถูกไปเรื่อย ๆ อย่างไม่รู้จบ

รูปที่ 3. เมื่อเซสชันมีการยกระดับ ให้แยกตามตัวกระตุ้น การยกระดับที่เกิดจากสไตรค์จะกระจุกตัวอย่างชัดเจน (เทิร์นที่ 4 ซึ่งเป็นเทิร์นแรกที่สไตรค์สองครั้งสามารถสะสมภายในหน้าต่างการสลายตัว); ส่วนการยกระดับที่เกิดจากความยากจะกระจายไปตามเทิร์นที่ 2–11 ตามการกระจายของการเริ่มต้นของคลังข้อมูล กฎการติดต่อกันสองเทิร์นติดต่อกันหมายความว่า การยกระดับจากความยากที่เร็วที่สุดที่เป็นไปได้คือเทิร์นที่ 2

6.2 ข้อค้นพบ: ประตูที่จัดส่งตั้งอยู่บนขอบหน้าผา

คอร์ปัสแรกของเราสร้างศูนย์การยกระดับที่ขับเคลื่อนด้วยความยาก. เทิร์นที่ยาก — ซึ่งเต็มไปด้วยเงื่อนไขการแข่งขัน, อินเวอร์เรียนต์, การวิเคราะห์ความซับซ้อน และคำศัพท์การพิสูจน์ — ทำจุดสูงสุดที่ 0.658 เทียบกับเกณฑ์ 0.70. การเพิ่มสแตกเทรซที่วางมา ซึ่งเทิร์นการดีบั๊กจริงประกอบไปด้วย ทำให้พุ่งขึ้นเป็น 0.719. เกณฑ์ผ่านด้วยส่วนต่าง 0.019.

รูปที่ 4. งบประมาณความยากจริงถูกใช้ไปที่ใด เฉลี่ยจากเทิร์นยาก 855 เทิร์นและเทิร์นง่าย 3,113 เทิร์น เทิร์นยากตามจริงถึง 0.719 ของค่าสูงสุดเดลต้าตามทฤษฎีที่ 0.90 เทอม CodeKeywordDensity มีส่วน 0.069 จากงบประมาณ 0.20 — ความหนาแน่นที่วัดได้คือ 1.72 คู่ต่อ 100 ตัวอักษร เทียบกับเพดานอิ่มตัวที่ 5.0 — และ 0.10 ของ SystemPromptLogLen เป็นศูนย์เชิงโครงสร้างในตัวแยกเดลต้า ประมาณหนึ่งในสามของพิสัยปกติของคะแนนไม่สามารถเข้าถึงได้ด้วยข้อความตามจริง

การกวาดค่าเกณฑ์ยืนยันว่านี่คือหน้าผา ไม่ใช่ทางลาด ข้าม T2 จาก 0.35 ถึง 0.65 ผลลัพธ์เหมือนกันทุกประการ — 200 จาก 400 เซสชันมีการยกระดับ โดยไม่พลาดแม้แต่ครั้งเดียว ที่ค่าที่จัดส่ง 0.70 ตัวจำแนกเริ่มสูญเสียเซสชัน ที่ 0.75 การยกระดับที่ขับเคลื่อนด้วยความยากล่มสลายจาก 122 เซสชันเหลือ 23

รูปที่ 5. ความไวของเกณฑ์ ช่วง 0.35–0.65 ทั้งหมดมีพฤติกรรมเหมือนกัน เนื่องจากไม่มีเดลตาเท็กซ์ตามจริงตกอยู่ในช่วงนั้น — การกระจายของคะแนนเป็นแบบสองโหมด (bimodal) โดยเทิร์นง่ายกระจุกตัวใกล้ 0.23 และเทิร์นยากใกล้ 0.72 โดยไม่มีค่าอยู่ระหว่างกลาง ค่าเริ่มต้นที่จัดส่งมาอยู่ที่ขอบบนของโหมดบน

ผลกระทบทางวิศวกรรม

T2 ได้รับการสอบเทียบสำหรับ full-transcript การแจกแจงซึ่งวง gated_adaptive ถูกปรับแต่ง และมันถูกนำกลับมาใช้เป็นเกณฑ์ของตัวแยกเดลต้า เอกสารการออกแบบชี้ให้เห็นว่าตัวแยกเดลต้า 'ต้องการการปรับแต่งของตัวเอง' การวัดนี้ระบุปริมาณว่ามากเพียงใด ไม่ว่าประตูเดลต้าจะต้องมี T2 ของตัวเองที่ต่ำกว่า — ค่าใดในช่วง 0.45–0.60 ก็ให้พฤติกรรมเหมือนกันโดยมีระยะขอบจริง — หรือเกณฑ์ตามเปอร์เซ็นไทล์ที่กำหนดไว้แล้วในเฟส 3 ('X% ที่สูงที่สุดของการจราจรล่าสุดของเราเตอร์นี้') ควรจะมา ซึ่งทำให้การยกระดับ อัตรา เป็นลูกบิดของผู้ปฏิบัติการ และหลีกเลี่ยงการปรับเทียบค่าสัมบูรณ์โดยสิ้นเชิง

6.3 ต้นทุนและความครอบคลุม

รูปที่ 6. นโยบายห้านโยบายในช่วง 400 เซสชันเดียวกัน ด้านซ้าย: ต้นทุนต่อ 1,000 เซสชัน (สเกลลอการิทึม) ด้านขวา: สัดส่วนของเทิร์นที่ยากอย่างแท้จริงซึ่งให้บริการโดยโมเดลที่แข็งแกร่ง

ตารางที่ 6.การเปรียบเทียบนโยบาย ต้นทุนต่อ 1,000 เซสชันภายใต้แบบจำลองในตารางที่ 4

ผลลัพธ์สองอย่างควรแยกออกจากกัน อย่างแรก, การยึดติดเซสชันเพียงอย่างเดียวประหยัด 24 % เมื่อเลือกโมเดลเดียวกัน (16.64 → 12.63) และ 35 % สำหรับคู่ frontier (290.93 → 188.30) นั่นคือเศรษฐศาสตร์ของแคชล้วน ๆ — โมเดลเดียวกัน ทุกอย่างเหมือนกัน ต่างกันเพียงความยึดติดของคีย์ การประหยัดจะมากขึ้นสำหรับคู่ frontier เพราะค่าพรีเมียมการเขียน 1.25× ของ Anthropic ทำให้รอบที่ไม่มีแคชมีราคาแพงอย่างไม่สมส่วน

ประการที่สอง การยกระดับเกิดขึ้นในจุดที่กลไกการช่วยเหลือควรจะอยู่: 45% ของต้นทุนแบบ always-frontier สำหรับ 67% ของความครอบคลุมเทิร์นที่ยาก โดยให้บริการโมเดลที่แข็งแกร่งเพียง 21.4% ของเทิร์นเท่านั้น

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

ตารางที่ 7. ความหน่วงของการยกระดับ — เทิร์นยากที่ให้บริการบนโมเดลราคาถูกก่อนที่วงล้อจะทำงาน

สองเทิร์นคือสิ่งที่กฎสตรีคสองเทิร์นติดต่อกันระบุไว้พอดี และหนึ่งเทิร์นคือสิ่งที่กฎสองสไตรค์ถึงแร็ตเช็ตระบุไว้พอดี ความหน่วงคือการออกแบบ และเป็นคุณสมบัติเดียวกันที่ทำให้เกิดผลบวกลวงเป็นศูนย์ ใครก็ตามที่ต้องการการช่วยเหลือที่เร็วกว่ามีส่วนหัว Class A ซึ่งทำงานที่ n=1 — นั่นคือเหตุผลที่แท้จริงที่ช่องทางหลบหนีแบบแมนนวลถูกปล่อยออกมาก่อน

6.4 อัตราส่วนพาดหัวขึ้นอยู่กับปริมาณการเข้าชมของคุณโดยสิ้นเชิง

คลังข้อมูลนี้ถูกสร้างให้มี 50% เป็น hard โดยการออกแบบ แต่การจราจรของเราเตอร์จริงไม่ได้เป็นเช่นนั้น และการเปรียบเทียบต้นทุนมีความอ่อนไหวต่อข้อเท็จจริงนี้อย่างมาก การถ่วงน้ำหนักต้นทุนที่วัดได้ต่ออาร์คีไทป์ใหม่ในช่วงความชุกของ hard-session ที่หลากหลาย:

รูปที่ 7.ต้นทุนต่อ 1,000 เซสชันซึ่งเป็นฟังก์ชันของปริมาณทราฟฟิกของคุณที่จำเป็นต้องใช้โมเดลที่แข็งแกร่งอย่างแท้จริง พฤติกรรมภายในคลาสถูกคงไว้ที่ค่าที่วัดได้ มีเพียงสัดส่วนผสมเท่านั้นที่เปลี่ยนแปลง

ตาราง 8.ความไวของความชุก, $ ต่อ 1,000 เซสชัน

ที่อัตราการเพิ่มระดับเป้าหมายของเอกสารการออกแบบเองที่ ≤5% ของเซสชัน การเพิ่มระดับมีต้นทุนเท่ากับ 1.6 เท่าของบิล cheap-pool และ 12% ของบิล frontier. ที่ stress-mix 50% ต้นทุนจะเท่ากับ 6.7 เท่าของบิล cheap-pool ทั้งสองข้อเป็นจริง; ทั้งสองตอบคำถามที่ต่างกัน ข้อที่เกี่ยวข้องในทางปฏิบัติคือข้อแรก และนี่คือเหตุผลที่เพดานส่วนแบ่งมีค่าเริ่มต้นเป็น 20% แทนที่จะเป็น “off” — สิ่งที่จำกัดบิลจริง ๆ คือเพดาน ไม่ใช่ความแม่นยำของทริกเกอร์

6.5 เพดานการใช้งานยังคงทนทานต่อการละเมิดจากผู้ไม่ประสงค์ดี

เราได้รันคอร์ปัสซ้ำอีกครั้งด้วยกลไก share-cap จริง — ไม่มีสตับ ใช้ Redis day-buckets จริง — ภายใต้โมเดลภัยคุกคาม §8: ไคลเอนต์ทุกตัวส่ง X-OrcaRouter-Tier: strong ในทุก ๆ เทิร์น

รูปที่ 8. การละเมิดส่วนหัวโดยผู้ไม่หวังดีต่อเพดานส่วนแบ่งการเลื่อนระดับ 20% คำขอ 20 รายการแรกไม่ถูกจำกัดโดยการออกแบบ — เกณฑ์พื้นขั้นต่ำในระยะอุ่นเครื่องช่วยป้องกันไม่ให้ “การเลื่อนระดับ 1 ครั้งจาก 2 ครั้ง” ถูกตีความเป็น 50% และป้องกันการล็อกฟีเจอร์บนเราเตอร์ที่เพิ่งเริ่มใช้งาน — หลังจากนั้นส่วนแบ่งจะลู่เข้าและคงที่ สถานะสุดท้าย: คำขอ 296 จาก 1,439 รายการให้บริการแบบ strong (20.6%) โดยมีคำขอที่ร้องขออย่างชัดเจนถูกปฏิเสธ 1,143 รายการ และถูกบันทึกการตรวจสอบเป็นเหตุการณ์ denied_cap

ส่วนเกินที่เหลือ 0.6 % เป็นพฤติกรรมที่ตั้งใจของการเปรียบเทียบแบบมากกว่าอย่างเคร่งครัดบนตัวนับแบบตามหลังโดยประมาณ และขีดจำกัดต่อเซสชันที่ 1 ทำให้แต่ละเซสชันไม่ใช้จนหมดงบประมาณ ทุกการปฏิเสธจะมองเห็นได้โดยไคลเอนต์ในส่วนหัวการตอบสนอง X-Orca-Session-Tier: base; reason=denied:share_cap และโดยผู้ปฏิบัติงานในตารางตรวจสอบ — การยกระดับที่ถูกระงับจะไม่มีวันเงียบ

7 สิ่งที่เราจะเปลี่ยน

ให้ตัวแยกเดลตามีเกณฑ์ของตัวเอง. การใช้ T2 จากทรานสคริปต์ฉบับเต็มซ้ำจะเหลือส่วนต่างเพียง 0.019 (§6.2) ขณะที่ T2 สำหรับเดลตาโดยเฉพาะในช่วง 0.45–0.60 มีพฤติกรรมเหมือนกันบนคลังข้อมูลนี้ และมีระยะเผื่อมากกว่าถึงสองอันดับขนาด งานกำหนดเกณฑ์ตามเปอร์เซนไทล์ที่วางแผนไว้แล้วครอบคลุมเรื่องนี้และเป็นทางแก้ที่ดีกว่า.

อย่าปล่อยให้คำว่า code-density ยังคงเป็นเพียงของตกแต่ง มันใช้ไป 0.069 จากงบประมาณ 0.20 บนข้อความจริงที่มีความหนาแน่นมากที่สุดที่เราสร้างได้ เนื่องจากขีดจำกัดความอิ่มตัวที่ 5 รายการที่ตรงกันต่อ 100 ตัวอักษรบ่งบอกว่ามีคีย์เวิร์ดโค้ดประมาณหนึ่งคำทุกยี่สิบตัวอักษร ควรกำหนดเพดานใหม่เทียบกับการแจกแจงจากการผลิตที่วัดได้จริง หรือจัดสรรน้ำหนักของมันใหม่

Class C เป็นตัวหลักที่แบกรับปริมาณงานของเอเจนต์ และเป็นคลาสที่พัฒนาน้อยที่สุด. ประชากรของ failure_loop ตรวจจับไม่ได้ด้วยเกณฑ์ความยาก (จุดสูงสุด 0.262) และถูกจับได้ทั้งหมดด้วย strikes เซสชันของเอเจนต์ล้มเหลวเพราะติดลูป ไม่ใช่เพราะเนื้อหามีคำศัพท์ยากขึ้น ตัวสร้างฝั่งการตอบสนองที่เหลืออยู่ — และฮุคสำหรับจับสตรีมมิ่งแบบ native-Gemini ที่ยังขาดอยู่ — คุ้มค่ากว่าการปรับแต่งความยากเพิ่มเติม.

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

8 ข้อจำกัด

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

แบบจำลองต้นทุนสมมติให้มีการสร้างโทเค็นเอาต์พุตคงที่ 500 โทเค็นต่อเทิร์น ซึ่งเป็นการซ่อนผลจริง: โมเดลชั้นนำ (frontier models) สร้างโทเค็นเชิงเหตุผล (reasoning tokens) มากกว่า ดังนั้นส่วนเพิ่มของโมเดลชั้นนำจริงจึงถูกประเมินต่ำไป อีกทั้งยังจำลองความอบอุ่นของแคชระดับคำขอ (request-level cache warmth) เป็นค่า 1/N ที่สม่ำเสมอทั่วทั้งสล็อตหลัก; พูลแบบถ่วงน้ำหนักควรใช้ดัชนี Herfindahl Σw² และช่องทางแบบคีย์เดียวจะไม่แสดงข้อได้เปรียบของแคชสำหรับความยึดติดกับเซสชัน (session affinity) เลยในชั้นช่องทาง — แม้การปักหมุดชั้นโมเดลยังคงสำคัญต่อกลยุทธ์แบบปรับตัว

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

สุดท้ายนี้ มาตรวัดนี้เป็นการวัดการนำไปใช้งานของเกตเวย์หนึ่ง ๆ โหมดความล้มเหลวแบบล็อกอินเทิร์น-1 ควรจะครอบคลุมไปถึงเราเตอร์ที่คำนึงถึงแคชใด ๆ ที่ปักหมุดเซสชัน แต่ตัวเลขเฉพาะนั้นเป็นคุณสมบัติของเกณฑ์เหล่านี้ น้ำหนักเหล่านี้ และราคาเหล่านี้

9 งานที่เกี่ยวข้อง

การกำหนดเส้นทางระดับคำขอได้รับการกล่าวถึงอย่างครอบคลุมแล้ว FrugalGPTsup>[2]/sup> ได้แนะนำ LLM cascade — สอบถามโมเดลราคาถูก ให้คะแนนคำตอบ แล้วเลื่อนระดับเมื่อความเชื่อมั่นต่ำ — โดยรายงานการลดต้นทุนสูงถึง 98 % ที่ความแม่นยำเท่าเดิม RouteLLMsup>[1]/sup> ฝึกเราเตอร์บนข้อมูลความพึงพอใจจาก Chatbot Arena และรายงานคุณภาพ 95 % ของ GPT-4 ด้วยการเรียกใช้โมเดลที่แข็งแกร่งเพียง 14 % โดยเราเตอร์สามารถถ่ายโอนข้ามคู่โมเดลได้โดยไม่ต้องฝึกใหม่ RouterArenasup>[3]/sup> เติมเต็มพื้นฐานการประเมินที่ขาดหายไป: คำสั่งค้นหา 8,400 รายการครอบคลุมหลายโดเมนและระดับความยาก โดยประเมินในด้านความแม่นยำ ต้นทุน ความเหมาะสมของการกำหนดเส้นทาง ความทนทาน และโอเวอร์เฮดของเราเตอร์

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

OrcaRouter มีชุดทดสอบ RouterArena ในทรี (eval/) ซึ่งวัดประสิทธิภาพของกลยุทธ์ระดับคำขอทั้งห้าแบบ ได้แก่ cheapest, quality, balanced, linucb, gated_adaptive กับชุดข้อมูลเปิด โดยไม่มีการแก้ไข repository ต้นทาง กลไกระดับเซสชันที่กล่าวถึงในที่นี้เป็นอิสระจากและทำงานร่วมกับทั้งห้ากลยุทธ์ได้

10 บทสรุป

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

การยึดติดแบบหลายชั้นแก้ปัญหานี้โดยการแยกสองสิ่งที่ดูเหมือนเป็นสิ่งเดียวกัน: โมเดลใดให้บริการเซสชันนี้ (พิน ซึ่งคงที่ภายในชั้น) และ เซสชันนี้อยู่ในชั้นใด (ชิ้นสถานะขนาดเล็ก ที่มีเพดานจำกัด ผ่านการยืนยันร่วมกัน และหมดอายุได้). ในการรีเพลย์ของเรา การแยกนี้กู้คืน 87% ของเซสชันซึ่งตรวจไม่พบความยากในเทิร์นที่ 1 โดยมีผลบวกลวงเป็นศูนย์ใน 200 เซสชันที่ง่าย คิดเป็น 45% ของต้นทุนแบบ always-frontier — และยังคงขีดจำกัดการใช้จ่ายไว้ที่ 20% ต่อไคลเอนต์ที่พยายามเอาชนะมันอย่างแข็งขัน.

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

11 แหล่งข้อมูล

1. LMSYS Org. RouteLLM: เฟรมเวิร์กโอเพนซอร์สสำหรับการกำหนดเส้นทาง LLM อย่างคุ้มค่า. a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · โค้ด: a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia & Zou. FrugalGPT: วิธีใช้โมเดลภาษาขนาดใหญ่พร้อมลดต้นทุนและเพิ่มประสิทธิภาพ. arXiv:2305.05176. a href="https://arxiv.org/abs/2305.05176">u>arxiv.org/abs/2305.05176/u>/a>

3. Lu, Liu, Yuan, Cui, Zhang, Liu & Xing. RouterArena: แพลตฟอร์มเปิดสำหรับการเปรียบเทียบเราเตอร์ LLM อย่างครอบคลุม. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. การแคชพรอมต์ใน API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — การแคชอัตโนมัติ, prefix ≥1,024 โทเคน เพิ่มครั้งละ 128 โทเคน, คัดออกเมื่อไม่ใช้งาน 5–10 นาที, ไม่เกิน 1 ชั่วโมง; ส่วนลดสำหรับอินพุตที่ถูกแคชตามระดับโมเดล ราคา: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Prompt caching. a href="https://platform.claude.com/docs/en/build-with-claude/prompt-caching">u>platform.claude.com/docs/en/build-with-claude/prompt-caching/u>/a> — cache reads 0.1× base input, writes 1.25× (5-minute TTL) or 2× (1-hour TTL), refreshed on use. Pricing: a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. DeepSeek API เปิดตัว Context Caching บนดิสก์. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — อัตโนมัติ คิดค่าบริการตามการเข้าใช้แคชจริง และลดลงสิบเท่าเมื่อมีการ hit.

7. Google. Gemini API context caching. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — implicit and explicit caching with storage-priced TTL.

8. OrcaRouter source, this repository: service/session_affinity.go (pins, TTLs, tier-scoped keys) · service/session_escalation.go (the engine) · service/model_router.go:1374 (selectByStrategy: tier narrowing before the pin read) · service/model_router_difficulty.go (weights and caps) · service/model_router_delta.go (delta extractor) · service/escalation_strikes.go (request-side producers) · service/escalation_caps.go (share caps) · docs/features/frontier-escalation.md (design, review rounds 1–4).

Reproducibility. The measurement harness is a Go test in the service package driving ResolveEscalation / CommitEscalationDecision against miniredis, plus a Python analysis and figure pipeline. Corpus generation is seeded (rand.NewSource(20260814)) and the full run is deterministic: 400 sessions, 3,968 turns, three experiments (main replay, adversarial cap run, 9-point threshold sweep). Figures use a CVD-validated categorical palette; every figure is paired with its underlying table. No production data was accessed, and no part of this analysis was committed to the repository.