Hạ tầng định tuyến OrcaRouter: Định tuyến nhận biết phiên và thăng cấp biên

ORCAROUTER · KIẾN TRÚC ĐỊNH TUYẾN

Mọi cổng LLM lưu cache các prompt đều phải ghim một cuộc hội thoại vào một mô hình duy nhất. Mọi cổng ghim một cuộc hội thoại đều đưa ra quyết định định tuyến dựa trên lượt trao đổi ít thông tin nhất của cuộc hội thoại đó. Đây là một báo cáo về sự đánh đổi đó, và về cơ chế ghim phân tầng mà OrcaRouter trang bị để thoát khỏi sự đánh đổi đó.

Chủ đề: Cổng LLM OrcaRouter (Go / Gin / Redis) · Thành phần: cố định phiên + bộ máy leo thang Frontier · Phương pháp: phát lại 400 phiên đối chiếu với mã quyết định production · Ngày: 14 tháng 8, 2026

TÓM TẮT — Định tuyến LLM ở cấp độ yêu cầu — chấm điểm từng yêu cầu một cách độc lập và điều phối nó đến mô hình rẻ nhất đủ năng lực — là chế độ mà gần như mọi công trình nghiên cứu về bộ định tuyến đã công bố đều đề cập đến. Đây cũng là chế độ sai cho lưu lượng hiện đang chiếm ưu thế trong khối lượng gateway: các phiên agent đa lượt, nơi 90 % prompt là ngữ cảnh được kế thừa từ các lượt trước và bộ đệm prompt của nhà cung cấp trả công cho sự liên tục. Chuyển đổi mô hình giữa cuộc hội thoại sẽ làm mất khoản giảm giá 10× trên tiền tố dùng chung, vì vậy các gateway khóa phiên. Nhưng việc khóa được thực hiện ở lượt 1 là việc khóa được thực hiện ở lượt có ít bằng chứng nhất, và nó tồn tại trong suốt vòng đời của cuộc trò chuyện.

100 / 100 — các phiên latent-hard có điểm lượt 1 không thể phân biệt được với một phiên tầm thường

+16% — mức lệch điểm độ khó chỉ do độ dài bản ghi, ở cùng độ khó nhiệm vụ

45% — của chi phí luôn-tiên-phong, cho 67% độ phủ rẽ-gắt của nó

0.019 — biên độ giữa ngưỡng phát hành và trần điểm số thực tế

1 Hai chế độ định tuyến

Một cổng LLM đứng trước nhiều nhà cung cấp phải trả lời một câu hỏi cho mỗi yêu cầu: mô hình nào phục vụ yêu cầu này? Có hai cách khác nhau về mặt cấu trúc để trả lời câu hỏi đó, và giới học thuật lẫn thực tế sản xuất đã tách rời nhau về cách nào mới thực sự quan trọng.

Định tuyến mức yêu cầu coi mỗi yêu cầu là độc lập. Một bộ chấm điểm ước lượng độ khó của truy vấn hoặc chất lượng phản hồi dự đoán, và yêu cầu được điều phối đến mô hình rẻ nhất dự kiến có thể xử lý. Đây là cách tiếp cận của hầu hết các công trình bộ định tuyến đã được công bố: RouteLLM huấn luyện các bộ định tuyến dựa trên dữ liệu sở thích đạt 95% chất lượng của GPT-4 với 14% số lần gọi mô hình mạnhsup>[1]/sup>; FrugalGPT xếp tầng từ mô hình rẻ đến đắt với cơ chế kiểm tra chấp nhận/từ chối và báo cáo giảm chi phí tới 98%sup>[2]/sup>; RouterArena xây dựng một bộ điểm chuẩn gồm 8.400 truy vấn để so sánh các bộ định tuyến trên chính trục nàysup>[3]/sup>. Đơn vị phân tích là truy vấn.

Định tuyến nhận biết phiên

Lý do định tuyến nhận biết phiên tồn tại không phải vì sự thanh lịch. Đó là số học.

2 Kinh tế cache khiến tính gắn kết trở thành điều bắt buộc

Trong một phiên hội thoại đa lượt, prompt của lượt n là prompt của lượt n−1 cộng thêm một delta. Đến lượt 10, tiền tố được mang theo chiếm đại đa số token đầu vào. Mọi nhà cung cấp lớn hiện đang định giá tiền tố đó khác nhau tùy thuộc vào việc nó có phải là cache hit hay không:

Bảng 1.Ngữ nghĩa prompt-cache theo nhà cung cấp. Bộ đệm được khóa theo một tiền tố chính xác và theo khóa phục vụ — việc chuyển đổi mô hình hoặc xoay vòng khóa là một lần đọc nguội với giá đầy đủ.

OrcaRouter mã hóa chính xác các khoảng thời gian sống này dưới dạng TTL của pin: một bản đồ theo loại kênh của các cửa sổ bộ nhớ cache của nhà cung cấp — 5 phút cho OpenAI, Anthropic và Gemini, 60 phút cho DeepSeek — với mặc định 5 phút cho nhà cung cấp chưa được ánh xạ. Pin kênh+khóa hết hạn trong cửa sổ đó, vì chỉ mục khóa cũ không có giá trị bộ nhớ cache và chỉ làm sai lệch cân bằng tải. Pin của model, trên một triển khai dựa trên Redis và cho một id phiên đủ điều kiện pin dài, tồn tại trong 30 ngày — không phải vì giá trị bộ nhớ cache, vốn đã biến mất từ lâu, mà vì tính liên tục của định dạng yêu cầu. Việc chuyển đổi model giữa cuộc trò chuyện buộc một sự chuyển đổi định dạng yêu cầu có thể không tương thích dữ liệu: các khối suy luận và id gọi công cụ không nhất thiết sống sót qua quá trình dịch chuyển giữa các lược đồ nhà cung cấp.

CHI TIẾT CHƯA ĐƯỢC ĐÁNH GIÁ ĐÚNG MỨC

Bộ nhớ đệm prompt được khóatheo khóa API, không phải theo mô hình. Một gateway ghim mô hình nhưng cân bằng tải giữa ba khóa trên cùng một kênh vẫn đọc nguội hai trong ba lượt. Đây là lý do OrcaRouter ghim kênh bằng cách lưu {ChannelID, KeyIndex} thay vì một id kênh, và lý do ghim bị gỡ bỏ khi chỉ số khóa đã ghi không còn trỏ tới một khóa đang bật — một khóa được tăng cường nhưng đã xoay vòng sẽ thiên về cache nguội trong khi bỏ qua cân bằng tải, đây là điều tồi tệ nhất của cả hai thế giới.

Các chốt đều mềm xuyên suốt: id phiên không thể phân giải sẽ là no-op, kênh được chốt bị vô hiệu hoá hoặc không khỏe mạnh sẽ hạ cấp thành lựa chọn cân bằng thông thường, và chốt tới kênh có trọng số 0 trong pool hỗn hợp sẽ bị bỏ qua để quản trị viên đang rút cạn kênh không bị cản trở bởi tính dính. Chúng không bao giờ làm thất bại một yêu cầu.

3 Cái bẫy: tính dính vô hiệu hóa bộ định tuyến

Đây là chế độ lỗi. Trong OrcaRouter, tại đường dẫn mã tiền leo thang, đối với bộ định tuyến nhận biết phiên trên bất kỳ chiến lược không phải DSL nào, pin session→model đã trả về

Điều đó có thể chấp nhận được nếu lượt 1 là đại diện. Nhưng nó không đại diện một cách có hệ thống, vì hai lý do cộng hưởng.

3.1 Lượt 1 là lượt ít thông tin nhất

Độ khó vô hướng (service/model_router_difficulty.go) là một tổ hợp tuyến tính có trọng số của sáu đặc trưng từ vựng:

LogPromptTokens × 0.20, tối đa log(8001) ≈ 8.99

ReasoningCueCount × 0.15, tối đa 5

SystemPromptLogLen × 0.10 cap log(2001) ≈ 7,60

CodeKeywordDensity × 0.20 trần 5.0 (số lần khớp trên 100 ký tự)

HasTools × 0.15 đã 0/1

Số lượng MathMarker × 0,20 giới hạn tối đa 5

Một đoạn mở đầu ngắn không có lịch sử đạt điểm thấp gần như do cấu trúc: thành phần token có trọng số 0.20 nằm gần mức sàn, và các thành phần lý luận/toán học được kích hoạt trên từ vựng mà người dùng chưa có lý do để sử dụng. Do đó, các phiên cam kết với một mô hình pool yếu tại thời điểm ít thông tin nhất — và với việc ghim mô hình 30 ngày dựa trên Redis, cam kết đó là dài hạn.

Hình 1. Độ khó lượt mới nhất trung bình theo số lượt hội thoại, trên 100 phiên khó tiềm ẩn và 200 phiên thực sự dễ, được chấm bằng bộ chấm điểm sản xuất. Ở lượt 1 — lượt mà ghim cố định được viết — hai nhóm không thể phân biệt được (0,210 so với 0,208). Nhóm khó vượt qua ngưỡng ở lượt 5. Với chính sách chỉ dùng ghim, tất cả 100 phiên khó tiềm ẩn được đưa vào nhóm chi phí thấp trước khi có bất kỳ bằng chứng nào về điều đó.

3.2 Độ dài ngụy trang thành độ khó

Vấn đề thứ hai tinh vi hơn và nó làm suy yếu giải pháp hiển nhiên. Nếu bạn chỉ đơn giản chạy lại cổng độ khó mỗi lượt, bạn đang chạy lại nó trên một điểm số được tính trên toàn bộ bản ghi hội thoại được nối lại. Điểm số đó có độ trôi tăng dần vốn có: số hạng LogPromptTokens có trọng số 0.20 tăng đơn điệu theo độ dài hội thoại, và với bất kỳ phiên tác nhân nào, các số hạng HasTools trọng số 0.15 và SystemPromptLogLen trọng số 0.10 thực chất là các mức sàn không đổi. Một phiên dài và nhàm chán trông có vẻ ngày càng khó hơn.

Hình 2. Hiện tượng thiên lệch độ dài, được đo trên 60 phiên chỉ gồm các chỉnh sửa vụn vặt (“đổi tên biến này”, “thêm kiểm tra nil”). Điểm số trên toàn bộ biên bản trôi +16% qua 25 lượt với độ khó nhiệm vụ không đổi; điểm số của lượt mới nhất (delta) thì không đổi. Việc đánh giá lại một cách ngây thơ điểm số toàn bộ biên bản ở mỗi lượt sẽ khiến các phiên bị leo thang vì tội quá dài.

Bản sửa lỗi mà OrcaRouter cung cấp là một bộ phận riêng biệt: delta extractor (service/model_router_delta.go), chỉ tính điểm lượt mới nhất — văn bản người dùng mới cộng với bất kỳ kết quả công cụ nào được đính kèm sau thông điệp trợ lý cuối cùng — tái sử dụng cùng các trọng số và giới hạn nhưng cố tình đặt SystemPromptLogLen bằng 0, vì nó không nằm trong delta. Đường nằm ngang màu xanh dương trong Hình 2 là trình trích xuất đó.

4 Thiết kế: độ gắn bó phân tầng

Cách thoát ngây thơ khỏi sự khóa chặt vào turn-1 là định tuyến lại từng lượt — thứ chỉ là định tuyến ở mức yêu cầu, và đánh mất cache. Cách khắc phục ngây thơ theo hướng ngược lại là biến chốt thành bộ nhớ ghi nhận “phiên này đã trở nên khó” — điều không thể diễn tả sự hạ nhiệt và không thể bị khống chế. Thiết kế của OrcaRouter từ chối cả hai.

Cách diễn giải lại: một phiên được ghim vào một mô hình trong một tầng, và một Redis nhỏ trạng thái tầng là bộ nhớ leo thang duy nhất. Việc ghim mô hình không bao giờ là bộ nhớ.

Các nhóm tier. Tier mạnh là nhóm leo thang đã được phân giải (escalation_pool, mặc định sử dụng strong_pool của router). Tier cơ sở là AllowedModels \ nhóm tier mạnh; một mô hình thuộc cả hai nhóm sẽ nằm trong tier mạnh. Bên trong tier cơ sở, việc phân loại độ khó yếu/trung bình/mạnh của gated_adaptive vẫn hoạt động chính xác như trước.

Pin theo phạm vi tầng. Khóa pin mô hình của tầng mạnh có hậu tố :t:strong; tầng cơ sở giữ nguyên khóa kế thừa. Do đó, việc leo thang bảo toàn pin cơ sở, vì vậy phiên đã hạ cấp — hoặc phiên được tiếp tục sau khi trạng thái tầng hết hạn — sẽ quay lại đúng mô hình ban đầu, chứ không phải chọn lại tùy ý. Pin mạnh chỉ được ghi với TTL cửa sổ nhà cung cấp ngắn: pin mạnh 30 ngày sẽ tồn tại lâu hơn trạng thái tầng 4 giờ đã biện minh cho nó.

Cổng kiểm tra chạy trước. Trong selectByStrategy (service/model_router.go:1374), tier được xác định ngay từ đầu, tập ứng viên được thu hẹp về pool của tier đó, và chỉ sau đó sticky pin mới được tham chiếu — trong phạm vi tier đó. Đây là sửa đổi cấu trúc cho §3: phép tính độ khó và các bộ kích hoạt leo thang chạy mỗi lượt, trước khi pin có thể short-circuit chúng.

4.1 Ba lớp kích hoạt, xếp hạng theo mức độ tin cậy

Bảng 2. Các trình kích hoạt leo thang. Không có tín hiệu mơ hồ nào tự leo thang một mình; chỉ có yêu cầu tường minh từ khách hàng mới được kích hoạt tại n=1, và ngay cả điều đó cũng phải tuân thủ các giới hạn.

Ba bất biến vệ sinh đóng vai trò trụ cột. Các điểm phạt được khử trùng lặp theo ID yêu cầu thông qua bộ đệm vòng, nên các lần thử lại xen kẽ từ phía client không thể bị tính trùng. Sự cố hạ tầng không bao giờ là sự cố năng lực — 429, 5xx và kênh dự phòng không bao giờ bị tính là điểm phạt; chỉ các tín hiệu chất lượng sau thành công mới được tính. Và một “lượt” được định nghĩa là một yêu cầu đã hoàn tất, lập hóa đơn thành công và đã chạy đánh giá điểm phạt, nên các yêu cầu thất bại không thúc đẩy cả quá trình suy giảm điểm phạt lẫn bộ đếm lượt sạch.

4.2 Giải quyết là thuần khiết; commit được trì hoãn.

Thuộc tính cấu trúc quan trọng nhất của engine là ResolveEscalation không ghi gì cả. Nó trả về một quyết định cùng một danh sách những gì đang chờ xử lý — các ý định. Bộ phân phối áp dụng những ý định đó trong khối post-success của nó, lên một bản đọc mới bên trong một giao dịch Redis WATCH. Điều này quan trọng vì resolver chạy trên các đường dẫn không bao giờ được phép thay đổi trạng thái: các phân giải chuỗi dự phòng mang tính suy đoán, các điểm cuối chẩn đoán chỉ đọc, và các yêu cầu sau đó bị 403 hoặc thất bại ở thượng nguồn. Việc áp dụng lại các ý định lên trạng thái mới cũng có nghĩa là một writer đồng thời lỗi thời không thể ghi đè một escalation đã cam kết, và hai escalation giống hệt nhau đang cạnh tranh sẽ hợp nhất một cách lũy đẳng.

4.3 Caps, và tại sao chúng ràng buộc mọi thứ

Một sự leo thang dương tính giả tiêu tốn (strong − base) price × số token warm-episode còn lại, và nó tiêu tốn một cách âm thầm — không có gì gặp lỗi. Bán kính ảnh hưởng bị giới hạn bởi các mức trần áp dụng cho mọi lớp:

escalation_max_per_session (mặc định là 1). Việc hạ cấp và reset từ phía khách hàng không được hoàn trả, điều này chặn đường lạm dụng vòng lặp reset.

Mức trần trên mỗi bộ định tuyến về tỷ lệ leo thang (mặc định 20 %) trong cửa sổ trượt 24–48 giờ của các nhóm ngày Redis, cùng với mức trần chung trên toàn không gian làm việc cho mọi bộ định tuyến. Khi đạt mức trần, mọi định tuyến leo thang đều bị vô hiệu hóa — bao gồm cả các yêu cầu tường minh và các lượt tăng cường một lần.

Giảm leo thang chỉ xảy ra tại các ranh giới cache-cold, do đó một dương tính giả bị giới hạn trong một giai đoạn ấm duy nhất.

Lý do Class A tuân thủ các hạn mức là một kết luận từ mô hình mối đe dọa, chứ không phải sở thích chính sách: trên một API gateway, bất kỳ ai giữ workspace token đều kiểm soát các header. Một đường dẫn miễn hạn mức kiểu “khách hàng yêu cầu” là một kênh chi tiêu không được đo đếm. §7 đo lường điều gì xảy ra khi mọi client lạm dụng nó.

4.4 Giảm leo thang bất đối xứng theo thiết kế

Leo thang dựa trên bằng chứng được xác nhận; chỉ hạ cấp khi việc đó không phải trả giá. Một phiên mạnh chỉ trở về trạng thái cơ sở khi tất cả các điều kiện sau đều được đáp ứng: phiên có bộ đệm nguội (không hoạt động vượt quá cửa sổ nhà cung cấp được ghi nhận tại thời điểm leo thang), phiên đã tích lũy ≥3 lượt đánh giá không có sự cố, và mức chênh lệch độ khó mới nhất dưới T1. Trong cửa sổ ấm, một lần chuyển đổi phải trả trọn giá cho một lần đọc lại nguội — dao động trạng thái (flapping) là cách chắc chắn duy nhất khiến việc leo thang có chi phí âm.

5 Phương pháp

Chúng tôi đã đo lường cơ chế bằng cách phát lại một kho ngữ liệu phiên tổng hợp thông qua mã ra quyết định trong sản xuất thực tế. Bộ khung kiểm thử là một bài kiểm thử Go trong package service, gọi ResolveEscalation và CommitEscalationDecision cho từng lượt trên một tier store dựa trên miniredis, sử dụng các bộ chấm điểm độ khó thật, các bộ tạo strike phía yêu cầu thật và cơ chế share-cap thật. Không có gì trong đường dẫn ra quyết định bị viết lại hoặc giả lập, ngoại trừ bộ tiêu thụ sự kiện kiểm toán.

CÁI GÌ LÀ THẬT VÀ CÁI GÌ KHÔNG PHẢI

Thực: mọi quyết định định tuyến, điểm độ khó, phát hiện vi phạm, quy tắc chuỗi, đánh giá hạn mức và chuyển đổi trạng thái Redis — đây là các hàm đã được triển khai. Tổng hợp: lưu lượng truy cập. Bộ dữ liệu được tạo ra, không phải được lấy mẫu từ nhật ký sản xuất. Sự pha trộn các archetype của nó (50 % khó) là một hỗn hợp áp lực được chọn để thử thách cơ chế, chứ không phải là ước tính về lưu lượng thực tế; §6.4 trình bày độ nhạy với sự lựa chọn đó, và độ nhạy này rất lớn. Các con số precision sạch bên dưới phản ánh một bộ dữ liệu có các lớp phân tách được ngay từ thiết kế, và nên được hiểu là “cơ chế kích hoạt đúng nơi nó được thiết kế để kích hoạt”, chứ không phải là ước tính precision trong sản xuất.

5.1 Kho ngữ liệu

400 phiên, 3.968 lượt, có seed và mang tính xác định. Mỗi lượt là một thân yêu cầu chat-completions đầy đủ mang theo lịch sử tích lũy, một mảng định nghĩa hai công cụ, và một prompt hệ thống thực tế — hình dạng mà một agent lập trình thực sự gửi. Năm nguyên mẫu, mỗi nguyên mẫu mang một nhãn ground-truth:

Bảng 3. Thành phần kho ngữ liệu. "Needs strong" là chuẩn vàng được sử dụng cho các điểm số về độ chính xác và độ phủ.

Các lượt khó mang theo một bản dump goroutine được dán hoặc trích đoạn mã nguồn từ 3–8 KB bên cạnh phần văn xuôi, vì đó là những gì một lượt gỡ lỗi khó thực sự chứa đựng. Chi tiết này hóa ra lại quan trọng đến mức không ngờ — xem §6.2.

5.2 Mô hình chi phí

Chi phí được tính từ giá niêm yết công bố với ngữ nghĩa bộ nhớ đệm theo từng nhà cung cấp; mô hình được mô tả đầy đủ để có thể phản biện.

Bảng 4. Các tham số mô hình chi phí. Giá tính bằng USD trên mỗi 1 triệu token, theo bảng giá tháng 8 năm 2026.

Một lượt nóng có chi phí là 0.1·p_in·prefix + write·p_in·delta; một lượt nguội có chi phí là write·p_in·prompt. Lượt 1 luôn là một lần ghi đầy bộ nhớ đệm. Lượt chuyển cấp theo chính sách leo thang được tính phí rõ ràng như lượt nguội, do đó cơ chế tự trả phí cho việc vô hiệu hóa bộ nhớ đệm của chính nó.

Chất lượng được báo cáo dưới dạng độ bao phủ lượt hội thoại khó — tỷ lệ các lượt hội thoại khó theo ground-truth thực sự được mô hình mạnh phục vụ — thay vì là một con số độ chính xác. Chúng tôi không chạy suy luận ngược dòng, vì vậy chúng tôi từ chối bịa ra các con số độ chính xác.

6 kết quả

6.1 Cơ chế kích hoạt ở nơi mà nó được thiết kế.

Bảng 5. Kết quả leo thang theo nguyên mẫu, chế độ tự động, canary 100%, T2 = 0.70 (mặc định khi xuất xưởng).

Không có dương tính giả nào trong 200 phiên dễ, bao gồm 60 phiên dài mà một bộ chấm điểm toàn bộ bản ghi lẽ ra đã trôi vào nhóm khó. Các lớp kích hoạt chuyên biệt rõ ràng và không chồng lấn: difficulty bắt các tác vụ nặng về suy luận, strikes bắt các vòng lặp thất bại. Lưu ý rằng điểm độ khó cao nhất của failure_loop là 0.262 — cổng độ khó không bao giờ thấy những phiên đó cả. Một tác nhân mắc kẹt trong vòng lặp lỗi biên dịch không tạo ra văn bản giàu tín hiệu suy luận; nó đang tạo ra cùng một lời nhắc ngắn với một stack trace khác. Nếu không có các strike Class C, mỗi phiên trong số 60 phiên đó sẽ ì ạch trên mô hình rẻ tiền vô thời hạn.

Hình 3. Khi các phiên tăng cấp, hãy phân tách theo tác nhân kích hoạt. Các mức tăng cấp do đòn tấn công gây ra tập trung rõ rệt (lượt 4, lượt đầu tiên mà hai đòn tấn công có thể tích lũy trong cửa sổ suy giảm); các mức tăng cấp do độ khó gây ra trải dài từ lượt 2–11 theo phân bố khởi phát của kho ngữ liệu. Quy tắc chuỗi hai lượt liên tiếp có nghĩa là mức tăng độ khó sớm nhất có thể là lượt 2.

6.2 Phát hiện: cổng đã được giao nằm trên bờ vực.

Kho ngữ liệu đầu tiên của chúng tôi tạo ra không có sự leo thang nào do độ khó gây ra. Các lượt khó — chứa đầy các điều kiện cạnh tranh, bất biến, phân tích độ phức tạp và từ vựng chứng minh — đạt đỉnh 0.658 so với ngưỡng 0.70. Việc thêm các dấu vết ngăn xếp được dán mà các lượt gỡ lỗi thực tế thực sự mang theo đã đẩy chúng lên 0.719. Ngưỡng được vượt qua với biên độ 0.019.

Hình 4. Nơi ngân sách độ khó thực sự được phân bổ, tính trung bình trên 855 lượt khó và 3,113 lượt dễ. Một lượt khó thực tế đạt 0.719 trên mức tối đa delta lý thuyết là 0.90. Hạng mục CodeKeywordDensity đóng góp 0.069 trong ngân sách 0.20 của nó — mật độ đo được là 1.72 trùng khớp trên 100 ký tự so với trần bão hòa 5.0 — và giá trị 0.10 của SystemPromptLogLen là bằng 0 về mặt cấu trúc trong bộ trích xuất delta. Gần một phần ba phạm vi danh nghĩa của điểm số là không thể đạt được bằng văn bản thực tế.

Quét ngưỡng xác nhận đây là vách đá, không phải dốc. Trên T2 từ 0.35 đến 0.65, kết quả giống hệt nhau — 200 trên 400 phiên leo thang, không có lần bỏ sót nào. Ở ngưỡng 0.70 đã phát hành, bộ phân loại bắt đầu mất phiên; ở 0.75, sự leo thang do độ khó giảm mạnh từ 122 phiên xuống còn 23.

Hình 5.Độ nhạy ngưỡng. Toàn bộ khoảng 0,35–0,65 giống hệt nhau về mặt hành vi vì không có văn bản delta thực tế nào rơi vào đó — phân bố điểm là hai đỉnh, với các lượt dễ tập trung quanh 0,23 và các lượt khó quanh 0,72, và không có gì ở giữa. Ngưỡng mặc định được đặt ở mép trên của đỉnh phía trên.

HÀM Ý KỸ THUẬT

T2 được hiệu chỉnh cho toàn bộ bản ghi phân phối mà các dải gated_adaptive đã được tinh chỉnh, và nó đang được tái sử dụng làm ngưỡng của bộ trích xuất delta. Tài liệu thiết kế nêu rõ rằng bộ trích xuất delta “cần được tinh chỉnh riêng”; phép đo này định lượng mức độ cần thiết. Hoặc bộ lọc delta cần một T2 thấp hơn riêng của nó — bất kỳ giá trị nào trong khoảng 0,45–0,60 đều mang lại hành vi tương tự với biên độ thực — hoặc ngưỡng dựa trên phần trăm vốn đã được lên lịch cho Giai đoạn 3 (“X % hàng đầu trong lưu lượng gần đây của bộ định tuyến này”) nên được triển khai, điều này biến tốc độ leo thang thành núm vặn của người vận hành và hoàn toàn tránh việc hiệu chỉnh tuyệt đối.

6.3 Chi phí và phạm vi

Hình 6. Năm chính sách trên cùng 400 phiên. Bên trái: chi phí cho mỗi 1.000 phiên (thang log). Bên phải: tỷ lệ các lượt thực sự khó được phục vụ bởi mô hình mạnh.

Bảng 6.So sánh chính sách. Chi phí trên 1.000 phiên theo mô hình Bảng 4.

Hai kết quả cần được tách riêng. Đầu tiên, chỉ riêng độ bám phiên đã tiết kiệm 24 % khi chọn cùng một mô hình (16.64 → 12.63) và 35 % trên cặp tiên tiến nhất (290.93 → 188.30). Đó thuần túy là kinh tế bộ nhớ đệm — cùng mô hình, cùng mọi thứ, chỉ khác độ dính của khóa. Mức tiết kiệm lớn hơn trên cặp tiên tiến vì phí ghi 1.25× của Anthropic khiến các lượt nguội trở nên đắt một cách không cân xứng.

Thứ hai, việc leo thang diễn ra đúng như một cơ chế cứu hộ cần có: 45% chi phí của phương án luôn dùng mô hình tiên phong cho 67% mức bao phủ các lượt khó, chỉ phục vụ mô hình mạnh trong 21,4% số lượt.

Phần ba còn thiếu của mức độ bao phủ không phải là khiếm khuyết; đó là cái giá của cơ chế bánh cóc. Các quy tắc đối chứng tạo ra kết quả dương tính giả bằng không cũng có nghĩa là cơ chế không thể hành động ngay từ lượt đầu tiên của một vấn đề:

Bảng 7. Độ trễ leo thang — các lượt rẽ gắt được phục vụ trên mô hình giá rẻ trước khi bánh cóc kích hoạt.

Hai lượt chính là con số chính xác mà quy tắc chuỗi hai lượt liên tiếp quy định, và một lượt chính là con số chính xác mà quy tắc hai-lần-vi-phạm-để-siết-chặt quy định. Độ trễ nằm ngay trong thiết kế, và cũng chính đặc tính đó đã tạo ra kết quả không có bất kỳ trường hợp dương tính giả nào. Bất kỳ ai muốn giải cứu nhanh hơn đều có header Class A, vốn hoạt động ở n=1 — đó chính xác là lý do cửa thoát hiểm thủ công được phát hành trước tiên.

6.4 Tỷ lệ tiêu đề phụ thuộc hoàn toàn vào lưu lượng truy cập của bạn.

Corpus có 50% là phiên khó theo thiết kế. Lưu lượng router thực tế không phải như vậy, và việc so sánh chi phí cực kỳ nhạy cảm với điều đó. Tính lại trọng số các chi phí đo được theo từng archetype trên một phạm vi các mức độ phổ biến của phiên khó:

Hình 7. Chi phí cho mỗi 1.000 phiên như một hàm số của mức độ lưu lượng truy cập của bạn thực sự cần mô hình mạnh. Hành vi trong từng lớp được giữ ở các giá trị đo được; chỉ có sự pha trộn thay đổi.

Bảng 8. Độ nhạy tỷ lệ hiện mắc, $ trên 1.000 phiên.

Theo tỷ lệ leo thang mục tiêu của chính tài liệu thiết kế là ≤5 % số phiên, chi phí leo thang gấp 1,6 lần hóa đơn pool rẻ và bằng 12 % hóa đơn pool biên. Ở mức hỗn hợp căng thẳng 50 %, chi phí này gấp 6,7 lần hóa đơn pool rẻ. Cả hai đều đúng; chúng trả lời các câu hỏi khác nhau. Con số có ý nghĩa vận hành là con số đầu tiên, và đó là lý do trần tỷ trọng mặc định là 20 % thay vì “tắt” — chính trần, chứ không phải độ chính xác của bộ kích hoạt, mới là thứ thực sự giới hạn hóa đơn.

6.5 Các giới hạn vẫn giữ vững dưới sự lạm dụng đối nghịch.

Chúng tôi đã chạy lại kho ngữ liệu với cơ chế giới hạn chia sẻ thực sự — không dùng stub, dùng day-buckets Redis thực — dưới mô hình đe dọa §8: mọi client gửi X-OrcaRouter-Tier: strong trong từng lượt.

Hình 8. Lạm dụng tiêu đề đối kháng đối với giới hạn phần chia tăng cường 20%. 20 yêu cầu đầu tiên không bị ràng buộc theo thiết kế — mức sàn khởi động ngăn việc "1 lần tăng cường trong 2" bị đọc là 50% và khóa tính năng trên bộ định tuyến mới — sau đó phần chia hội tụ và duy trì. Trạng thái cuối cùng: 296 trong số 1.439 yêu cầu được phục vụ ở mức mạnh (20,6%), với 1.143 yêu cầu tường minh bị từ chối và được ghi nhận là các sự kiện denied_cap.

Độ vọt lố còn lại 0,6% là hành vi dự kiến của phép so sánh lớn hơn nghiêm ngặt trên một bộ đếm trượt gần đúng, và mức trần mỗi phiên là 1 giữ cho các phiên riêng lẻ không tiêu thụ hết ngân sách. Mọi lần từ chối đều hiển thị cho máy khách trong tiêu đề phản hồi X-Orca-Session-Tier: base; reason=denied:share_cap và cho nhà điều hành trong bảng kiểm toán — một lần leo thang bị kìm nén không bao giờ im lặng.

7 Điều chúng tôi sẽ thay đổi

Cấp cho bộ trích xuất delta một ngưỡng riêng.Việc tái sử dụng T2 của bản ghi đầy đủ để lại một biên 0.019 (§6.2). Một T2 riêng cho delta trong khoảng 0.45–0.60 có hành vi giống hệt trên kho văn bản này và có dư địa lớn hơn hai bậc độ lớn. Công việc về ngưỡng phần trăm đã được lên lịch sẽ bao hàm vấn đề này và là giải pháp tốt hơn.

Đừng để thành phần mật độ mã chỉ mang tính trang trí. Nó đóng góp 0,069 trong ngân sách 0,20 của nó trên văn bản thực tế dày đặc nhất mà chúng tôi có thể xây dựng, vì giới hạn bão hòa 5 kết quả khớp trên 100 ký tự của nó ngụ ý rằng cứ khoảng hai mươi ký tự lại có một từ khóa mã. Hoặc định lại giới hạn dựa trên phân bố sản xuất đã đo được, hoặc phân bổ lại trọng số của nó.

Class C là công cụ chủ lực cho lưu lượng agent, và nó là phần kém phát triển nhất. Quần thể failure_loop vô hình với ngưỡng độ khó (đỉnh 0.262) và bị bắt hoàn toàn bởi strikes. Các phiên agent thất bại do lặp, không phải do trở nên khó hơn về từ vựng. Các bộ sinh phía phản hồi còn lại — cùng với hook thu thập luồng native-Gemini vẫn còn thiếu — đáng giá hơn việc tinh chỉnh độ khó thêm nữa.

Công bố độ trễ leo thang. Hai vòng xử lý nặng nhọc chạy trên mô hình giá rẻ là cái giá thực sự của cơ chế xác nhận lũy tiến, và người vận hành cần thấy nó trong bảng phân tích bên cạnh độ chính xác, chứ không phải tự phát hiện ra.

8 Hạn chế

Kho ngữ liệu là dữ liệu tổng hợp. Nó được xây dựng để tách bạch rõ ràng, vì vậy kết quả không có dương tính giả đặc trưng cho độ đặc hiệu của cơ chế trên đầu vào có thể tách bạch, chứ không phải độ chính xác của nó trên lưu lượng sản xuất. Con số độ chính xác thực tế chỉ có thể đến từ công việc gán nhãn chế độ shadow theo quy định của thiết kế — đường ống kích hoạt chạy đầy đủ, không định tuyến gì, quyết định được gán nhãn hồi tố — với điều kiện go-live ở mức ≥70 % độ chính xác gán nhãn.

Mô hình chi phí giả định cố định 500 token đầu ra cho mỗi lượt, điều này che giấu một hiệu ứng thực tế: các mô hình tiên phong phát ra nhiều token suy luận hơn, vì vậy mức phí bảo hiểm thực sự của mô hình tiên phong bị đánh giá thấp. Nó cũng mô hình hóa độ ấm của bộ nhớ đệm ở cấp độ yêu cầu như một tỷ lệ 1/N đồng nhất trên các slot khóa; một nhóm có trọng số sẽ sử dụng chỉ số Herfindahl Σw², và một kênh đơn khóa sẽ không cho thấy lợi thế bộ nhớ đệm nào cho độ bám phiên ở tầng kênh — mặc dù việc ghim ở tầng mô hình vẫn quan trọng đối với các chiến lược thích ứng.

Chúng tôi không chạy suy luận ngược dòng, vì vậy không đưa ra tuyên bố nào về độ chính xác hay mức độ thành công của nhiệm vụ. Độ bao phủ của các lượt khó là một chỉ số thay thế cho chất lượng, và nó giả định rằng mô hình mạnh thực sự tốt hơn ở những lượt đó — điều hợp lý đối với các nguyên mẫu được xây dựng, nhưng chưa được xác minh ở đây.

Cuối cùng, phép đo này đánh giá việc triển khai của một gateway cụ thể. Chế độ lỗi khóa ngay từ lượt 1 có thể khái quát hóa cho bất kỳ bộ định tuyến nhận biết bộ nhớ đệm nào ghim phiên, nhưng các con số cụ thể là thuộc tính của các ngưỡng, trọng số và mức giá này.

9 Công trình liên quan

Định tuyến ở mức yêu cầu đã được đề cập kỹ lưỡng. FrugalGPTsup>[2]/sup> đã giới thiệu chuỗi mô hình ngôn ngữ lớn (LLM cascade) — truy vấn mô hình rẻ, chấm điểm câu trả lời, chuyển lên mô hình mạnh hơn khi độ tin cậy thấp — báo cáo giảm chi phí tới 98 % với độ chính xác tương đương. RouteLLMsup>[1]/sup> huấn luyện bộ định tuyến trên dữ liệu sở thích của Chatbot Arena và báo cáo đạt 95 % chất lượng của GPT-4 với 14 % số lần gọi mô hình mạnh, với các bộ định tuyến có thể chuyển đổi giữa các cặp mô hình mà không cần huấn luyện lại. RouterArenasup>[3]/sup> cung cấp nền tảng đánh giá còn thiếu: 8,400 truy vấn trên nhiều lĩnh vực và mức độ khó, được chấm điểm dựa trên độ chính xác, chi phí, tính tối ưu của định tuyến, độ mạnh mẽ và chi phí phụ trội của bộ định tuyến.

Điều mà không ai trong số này đề cập đến là cuộc hội thoại như là đơn vị định tuyến. Một chuỗi leo thang một yêu cầu và quên đi; lượt tiếp theo chạy lại cùng một mô hình rẻ tiền trên cùng một tác vụ mà giờ đây đã biết là khó. Một bộ định tuyến được huấn luyện theo sở thích chấm điểm một truy vấn, không phải một quỹ đạo. Khoảng trống mà báo cáo này giải quyết là những gì một bộ định tuyến nên nhớ giữa các lượt, trong bao lâu, và điều gì được phép thay đổi quyết định của nó — một câu hỏi chỉ trở nên cấp thiết khi bộ nhớ đệm lời nhắc khiến việc quên trở nên tốn kém.

OrcaRouter đi kèm một bộ kiểm thử RouterArena trong cây mã nguồn (eval/) để đo điểm chuẩn năm chiến lược ở mức yêu cầu của nó — cheapest, quality, balanced, linucb, gated_adaptive — trên tập dữ liệu mở mà không sửa đổi kho lưu trữ gốc. Cơ chế ở mức phiên được mô tả ở đây độc lập và có thể kết hợp với cả năm chiến lược này.

10 Kết luận

Bộ nhớ đệm prompt đã thay đổi kinh tế học của việc định tuyến LLM theo cách mà các tài liệu nghiên cứu về định tuyến chưa theo kịp. Khi tính liên tục đáng giá mức giảm 10× cho phần lớn token đầu vào, bộ định tuyến phải ghim — và ngay khi ghim, nó đưa ra quyết định ở lượt mà nó biết ít nhất, rồi sống với quyết định đó suốt chiều dài cuộc hội thoại. Định tuyến cấp yêu cầu không gặp vấn đề này và phải trả giá bằng các lần trượt bộ nhớ đệm; việc đánh giá lại từng lượt một cách ngây thơ đưa lại các lần trượt đó và thêm vào một hiện tượng thiên lệch theo độ dài.

Tính bám dính phân tầng giải quyết vấn đề này bằng cách tách hai thứ trông có vẻ là một: mô hình nào phục vụ phiên này (điểm neo, ổn định trong một tầng) và phiên này thuộc tầng nào (một phần trạng thái nhỏ, có trần, được xác nhận chéo và có thời hạn). Trong mô phỏng lại của chúng tôi, sự tách bạch đó khôi phục được 87% số phiên có độ khó không thể phát hiện được ngay từ lượt 1, không có dương tính giả nào trong 200 phiên dễ, với chi phí chỉ bằng 45% so với phương án luôn dùng mô hình tiên phong — và vẫn duy trì được trần chi tiêu 20% ngay cả khi các khách hàng chủ động tìm cách phá vỡ nó.

Những điểm yếu thực sự của cơ chế này nằm ở việc hiệu chỉnh, không phải kiến trúc: một cổng độ khó được tái sử dụng từ một phân phối mà nó không được tinh chỉnh cho phù hợp, một hạng mục đặc trưng không thể đạt tới ngân sách của nó, và hai lượt trễ giải cứu không thể tránh khỏi. Những điều đó có thể xử lý được. Tuyên bố về kiến trúc — rằng bộ nhớ leo thang phải tách biệt với mã pin, rằng không một tín hiệu mờ nào được phép tự động tăng cường một mình, và rằng các giới hạn phải ràng buộc chính yêu cầu tường minh của khách hàng vì khách hàng nắm giữ token — chính là phần chúng tôi muốn giữ lại.

11 Nguồn

1. LMSYS Org. RouteLLM: Một Framework Mã Nguồn Mở để Định Tuyến LLM Tiết Kiệm Chi Phí. a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · mã: a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia & Zou. FrugalGPT: Cách sử dụng các mô hình ngôn ngữ lớn trong khi giảm chi phí và cải thiện hiệu suất. 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: Nền tảng mở để so sánh toàn diện các router LLM. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. Prompt Caching trong API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — tự động lưu cache, tiền tố ≥1,024 token theo các bước tăng 128 token, loại bỏ khi không hoạt động trong 5–10 phút, tối đa 1 giờ; chiết khấu đầu vào cache theo từng nhóm mô hình. Giá: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Bộ đệm lời nhắc. 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> — đọc bộ đệm 0.1× đầu vào cơ sở, ghi 1.25× (TTL 5 phút) hoặc 2× (TTL 1 giờ), được làm mới khi sử dụng. Giá: a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. DeepSeek API giới thiệu Context Caching on Disk. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — tự động, tính phí dựa trên số lần trúng bộ nhớ đệm thực tế, giảm một bậc độ lớn khi trúng bộ nhớ đệm.

7. Google. Bộ nhớ đệm ngữ cảnh của Gemini API. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — bộ nhớ đệm ngầm định và tường minh với TTL tính phí theo lưu trữ.

8. Mã nguồn OrcaRouter, trong kho lưu trữ này: service/session_affinity.go (pin, TTL, khóa theo phạm vi tầng) · service/session_escalation.go (bộ máy xử lý) · service/model_router.go:1374 (selectByStrategy: thu hẹp tầng trước khi đọc pin) · service/model_router_difficulty.go (trọng số và giới hạn) · service/model_router_delta.go (bộ trích xuất delta) · service/escalation_strikes.go (bộ sinh phía yêu cầu) · service/escalation_caps.go (giới hạn chia sẻ) · docs/features/frontier-escalation.md (thiết kế, các vòng rà soát 1–4).

Tính tái lập. Bộ khung đo lường là một bài test Go trong package service, điều khiển ResolveEscalation / CommitEscalationDecision chạy trên miniredis, cùng với một quy trình phân tích và tạo biểu đồ bằng Python. Việc sinh kho ngữ liệu được khởi tạo bằng seed (rand.NewSource(20260814)) và toàn bộ lần chạy là tất định: 400 phiên, 3.968 lượt, ba thí nghiệm (phát lại chính, lần chạy giới hạn đối kháng, quét ngưỡng 9 điểm). Các biểu đồ sử dụng bảng màu phân loại được kiểm chứng CVD; mỗi biểu đồ đều đi kèm với bảng dữ liệu nền tương ứng. Không có dữ liệu sản xuất nào được truy cập và không có phần nào của phân tích này được commit vào kho lưu trữ.