Skip to content

AUTO-COMBO.md

Latest commit

 

History

History
802 lines (619 loc) · 101 KB

AUTO-COMBO.md

File metadata and controls

802 lines (619 loc) · 101 KB
Raw

OmniRoute Auto-Combo Engine (ਪੰਜਾਬੀ)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇧🇦 bs · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

ਵਰਤੋਂਕਾਰਾਂ ਲਈ: ਤੁਰੰਤ ਸ਼ੁਰੂਆਤ ਕਰਨੀ ਹੈ? ਸਰਲ ਵਿਆਖਿਆਵਾਂ ਅਤੇ ਉਦਾਹਰਨਾਂ ਲਈ ਆਟੋ-ਕੌਂਬੋ ਵਰਤੋਂਕਾਰ ਗਾਈਡ ਵੇਖੋ।

ਅਨੁਕੂਲ ਸਕੋਰਿੰਗ + ਬਿਨਾਂ ਸੰਰਚਨਾ ਵਾਲੀ ਸਵੈਚਾਲਿਤ ਰੂਟਿੰਗ ਨਾਲ ਖੁਦ-ਪ੍ਰਬੰਧਿਤ ਮਾਡਲ ਲੜੀਆਂ

ਜ਼ੀਰੋ-ਕੌਂਫਿਗ ਆਟੋ-ਰੂਟਿੰਗ (auto/ ਪ੍ਰੀਫਿਕਸ)

ਨਵਾਂ: ਕੰਬੋ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਕਿਸੇ ਵੀ ਕਲਾਇੰਟ ਵਿੱਚ ਸਿੱਧੇ auto/ ਪ੍ਰੀਫਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਤੁਰੰਤ ਉਦਾਹਰਨਾਂ

ਮਾਡਲ ID ਵੇਰੀਐਂਟ ਵਿਹਾਰ
auto ਡਿਫੌਲਟ ਸਾਰੇ ਕਨੈਕਟ ਕੀਤੇ ਪ੍ਰਦਾਤਾ, LKGP ਰਣਨੀਤੀ, ਸੰਤੁਲਿਤ ਵਜ਼ਨ
auto/coding ਕੋਡਿੰਗ ਗੁਣਵੱਤਾ-ਪਹਿਲਾਂ ਵਜ਼ਨ, ਕੋਡ ਜਨਰੇਸ਼ਨ ਲਈ ਢੁਕਵਾਂ
auto/fast ਤੇਜ਼ ਘੱਟ-ਲੇਟੈਂਸੀ ਵਾਲੀ ਵਜ਼ਨਬੱਧ ਚੋਣ
auto/cheap ਸਸਤਾ ਲਾਗਤ-ਅਨੁਕੂਲਿਤ ਰੂਟਿੰਗ (ਸਭ ਤੋਂ ਘੱਟ ਲਾਗਤ ਪਹਿਲਾਂ)
auto/offline ਆਫ਼ਲਾਈਨ ਸਭ ਤੋਂ ਵੱਧ ਕੋਟਾ ਉਪਲਬਧਤਾ ਵਾਲੇ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਤਰਜੀਹ
auto/smart ਸਮਾਰਟ ਬਿਹਤਰ ਮਾਡਲ ਖੋਜ ਲਈ ਗੁਣਵੱਤਾ-ਪਹਿਲਾਂ + ਉੱਚ ਖੋਜ ਦਰ (10%)
auto/lkgp lkgp ਸਪਸ਼ਟ LKGP (ਡਿਫੌਲਟ auto ਦੇ ਸਮਾਨ)
auto/chaos ਕੇਆਸ ਲਚਕੀਲੇਪਣ ਜਾਂਚ ਲਈ ਫਾਲਟ-ਇੰਜੈਕਸ਼ਨ ਵਜ਼ਨ (ਕੇਆਸ ਇੰਜੀਨੀਅਰਿੰਗ)

ਸ਼੍ਰੇਣੀ × ਟੀਅਰ ਸੰਯੋਜਨ (auto/<category>:<tier>)

OpenRouter-ਸ਼ੈਲੀ ਦੇ ਸਫ਼ਿਕਸ ਕਿਸ ਕਿਸਮ ਦਾ ਰੂਟ (ਸ਼੍ਰੇਣੀ) ਨੂੰ ਇਸਨੂੰ ਕਿਵੇਂ ਅਨੁਕੂਲਿਤ ਕਰਨਾ ਹੈ (ਟੀਅਰ) ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਜੋੜ ਸਕੋ (#4235 Phase B, open-sse/services/autoCombo/suffixComposition.ts):

  • ਸ਼੍ਰੇਣੀਆਂ (ਸਮਰੱਥਾ ਅਨੁਸਾਰ ਉਮੀਦਵਾਰ ਪੂਲ ਨੂੰ ਫਿਲਟਰ ਕਰੋ): coding · reasoning · vision · chat · multimodal। vision/multimodal ਵਿਜ਼ਨ-ਸਮਰੱਥ ਮਾਡਲਾਂ ਨੂੰ ਰੱਖਦੇ ਹਨ; reasoning ਤਰਕ/ਚਿੰਤਨ ਮਾਡਲਾਂ ਨੂੰ ਰੱਖਦਾ ਹੈ।
  • ਟੀਅਰ (ਸਕੋਰਿੰਗ ਵਜ਼ਨ / ਪੂਲ ਫਿਲਟਰ ਚੁਣੋ): fast (ਤੁਰੰਤ ਡਿਲੀਵਰੀ) · cheap (ਉਪਨਾਮ floor, ਲਾਗਤ-ਬਚਾਉਣ ਵਾਲਾ) · reliable (ਸਰਕਿਟ-ਬ੍ਰੇਕਰ ਸਿਹਤ + ਲੇਟੈਂਸੀ ਸਥਿਰਤਾ) · free / pro (classifyTier ਰਾਹੀਂ ਮਾਡਲ ਟੀਅਰ ਮੁਤਾਬਕ ਪੂਲ ਫਿਲਟਰ ਕਰੋ — ਮੁਫ਼ਤ ਟੀਅਰ ਬਨਾਮ ਪ੍ਰੀਮੀਅਮ)।
ਉਦਾਹਰਨ ਇਸ ਵਿੱਚ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੈ
auto/coding:fast ਕੋਡਿੰਗ ਪੂਲ, ਘੱਟ-ਲੇਟੈਂਸੀ ਵਜ਼ਨ
auto/coding:cheap ਕੋਡਿੰਗ ਪੂਲ, ਲਾਗਤ-ਅਨੁਕੂਲਿਤ (auto/coding:floor ਦਾ ਉਪਨਾਮ)
auto/reasoning:pro ਸਿਰਫ਼ ਤਰਕ/ਚਿੰਤਨ ਮਾਡਲ, ਪ੍ਰੀਮੀਅਮ ਟੀਅਰ
auto/vision ਵਿਜ਼ਨ-ਸਮਰੱਥ ਮਾਡਲ (ਕੋਈ ਟੀਅਰ ਨਹੀਂ → ਸੰਤੁਲਿਤ ਵਜ਼ਨ)
auto/multimodal:free ਮਲਟੀਮੋਡਲ-ਸਮਰੱਥ ਮਾਡਲ, ਸਿਰਫ਼ ਮੁਫ਼ਤ ਟੀਅਰ

ਕੋਈ ਵੀ ਵੈਧ auto/<category>[:<tier>] ਮੰਗ ਅਨੁਸਾਰ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੈ; ਇੱਕ ਚੁਣਿਆ ਹੋਇਆ ਉਪ-ਸਮੂਹ /v1/models ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (open-sse/services/autoCombo/builtinCatalog.ts ਵਿੱਚ AUTO_SUFFIX_VARIANTS)। ਫਿਲਟਰਿੰਗ ਫੇਲ-ਓਪਨ ਹੈ — ਜੇ ਕੋਈ ਪਾਬੰਦੀ ਕਿਸੇ ਵੀ ਕਨੈਕਟ ਕੀਤੇ ਮਾਡਲ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ, ਤਾਂ ਪੂਰਾ ਪੂਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਰੂਟਿੰਗ ਕਦੇ ਨਾ ਟੁੱਟੇ। ਮੁੱਖ ਸਕੋਰਰ (combo.ts) ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਹੈ; ਸ਼੍ਰੇਣੀ/ਟੀਅਰ ਫਿਲਟਰ buildAutoCandidates ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਲਾਈਵ ਮਾਡਲ ਇੰਟੈਲੀਜੈਂਸ: ਜਦੋਂ ARENA_ELO_SYNC_ENABLED ਫਲੈਗ ਚਾਲੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਆਟੋ-ਰੂਟਿੰਗ ਦੀ ਯੋਗਤਾ ਲਾਈਵ Arena ELO ਰੈਂਕਿੰਗਾਂ + models.dev ਟੀਅਰ ਡਾਟਾ ਤੋਂ ਨਿਰਧਾਰਤ ਹੁੰਦੀ ਹੈ (ਨਹੀਂ ਤਾਂ ਸਥਿਰ ਫਿਟਨੈੱਸ ਮੈਪ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ)।

ਵਰਤਣ ਦਾ ਤਰੀਕਾ:

# ਕੋਈ ਵੀ IDE ਜਾਂ CLI ਟੂਲ ਜੋ OpenAI ਫਾਰਮੈਟ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ
ਬੇਸ URL: http://localhost:20128/v1
API ਕੁੰਜੀ:  <ਤੁਹਾਡੀ-ਐਂਡਪੌਇੰਟ-ਕੁੰਜੀ>

# ਆਪਣੇ ਕੋਡ/ਕੌਂਫਿਗ ਵਿੱਚ ਮਾਡਲ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੈੱਟ ਕਰੋ:
model: "auto"                 # ਸੰਤੁਲਿਤ ਡਿਫੌਲਟ
model: "auto/coding"          # ਕੋਡਿੰਗ ਕਾਰਜਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ
model: "auto/fast"            # ਸਭ ਤੋਂ ਤੇਜ਼ ਉਪਲਬਧ
model: "auto/cheap"           # ਪ੍ਰਤੀ ਟੋਕਨ ਸਭ ਤੋਂ ਸਸਤਾ

ਕੀ ਹੁੰਦਾ ਹੈ:

  1. OmniRoute src/sse/handlers/chat.ts ਵਿੱਚ auto/ ਪ੍ਰੀਫਿਕਸ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ
  2. ਡਾਟਾਬੇਸ ਤੋਂ ਸਾਰੇ ਸਰਗਰਮ ਪ੍ਰਦਾਤਾ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਕਵੇਰੀ ਕਰਦਾ ਹੈ
  3. ਵੈਧ ਕ੍ਰੀਡੈਂਸ਼ਲਾਂ (API ਕੁੰਜੀ ਜਾਂ OAuth ਟੋਕਨ) ਵਾਲਿਆਂ ਨੂੰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ
  4. ਹਰ ਕਨੈਕਸ਼ਨ ਲਈ ਮਾਡਲ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ (connection.defaultModel ਜਾਂ ਪ੍ਰਦਾਤਾ ਦਾ ਪਹਿਲਾ ਮਾਡਲ)
  5. ਮੈਮੋਰੀ ਵਿੱਚ ਇੱਕ ਵਰਚੁਅਲ ਕੰਬੋ ਬਣਾਉਂਦਾ ਹੈ (DB ਵਿੱਚ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ)
  6. ਚੁਣੇ ਹੋਏ ਵੇਰੀਐਂਟ ਦੇ ਵਜ਼ਨ ਪ੍ਰੋਫਾਈਲ + LKGP ਰਣਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰੂਟ ਕਰਦਾ ਹੈ

ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ:

  • ✅ ਹਮੇਸ਼ਾ ਚਾਲੂ: ਕਿਸੇ ਟੌਗਲ, ਕੰਬੋ ਬਣਾਉਣ ਜਾਂ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ
  • ✅ ਡਾਇਨਾਮਿਕ: ਮੌਜੂਦਾ ਕਨੈਕਟ ਕੀਤੇ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਦਰਸਾਉਂਦਾ ਹੈ
  • ✅ ਸੈਸ਼ਨ ਸਟਿਕੀਨੈੱਸ: LKGP ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਆਖਰੀ ਸਫਲ ਪ੍ਰਦਾਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਵੇ
  • ✅ ਮਲਟੀ-ਅਕਾਊਂਟ ਸਮਰੱਥ: ਹਰ ਪ੍ਰਦਾਤਾ ਕਨੈਕਸ਼ਨ ਇੱਕ ਵੱਖਰਾ ਉਮੀਦਵਾਰ ਬਣ ਜਾਂਦਾ ਹੈ
  • ✅ ਕੋਈ DB ਲਿਖਤ ਨਹੀਂ: ਵਰਚੁਅਲ ਕੰਬੋ ਸਿਰਫ਼ ਬੇਨਤੀ ਲਈ ਮੌਜੂਦ ਰਹਿੰਦਾ ਹੈ, ਸਥਿਰ ਸਟੋਰੇਜ ਦਾ ਕੋਈ ਵਾਧੂ ਭਾਰ ਨਹੀਂ

ਪ੍ਰਤੀ-ਕੁੰਜੀ ਉਮੀਦਵਾਰ ਨਿਯੰਤਰਣ (#7819, Level 1+2)

GET /v1/auto-combo/{channel}/candidates ({channel} = auto/ ਤੋਂ ਬਾਅਦ ਵਾਲਾ ਸਫ਼ਿਕਸ, ਜਾਂ ਬੇਸ ਚੈਨਲ ਲਈ ਸ਼ਾਬਦਿਕ auto) ਇੱਕ ਸਿਰਫ਼-ਪੜ੍ਹਨਯੋਗ ਐਂਡਪੌਇੰਟ ਹੈ ਜੋ ਕਿਸੇ auto/* ਚੈਨਲ ਦੇ ਮੌਜੂਦਾ ਉਮੀਦਵਾਰ ਪੂਲ ਨੂੰ ਲਾਈਵ ਪਹੁੰਚਯੋਗਤਾ ਸਮੇਤ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਲਚਕੀਲੇਪਣ ਰੀਡਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਦਾ ਹੈ (ਕਦੇ ਵੀ ਕੱਚਾ ਬ੍ਰੇਕਰ state ਨਹੀਂ):

  • ਪ੍ਰਦਾਤਾ ਸਰਕਿਟ ਬ੍ਰੇਕਰ — getCircuitBreaker(provider).getStatus() / .canExecute()
  • ਕਨੈਕਸ਼ਨ ਕੂਲਡਾਊਨ — ਰਿਜ਼ੌਲਵ ਕੀਤੀ provider_connections ਕਤਾਰ ਉੱਤੇ rateLimitedUntil / testStatus
  • ਮਾਡਲ ਲੌਕਆਊਟ — isModelLocked(provider, connectionId, model)

ਹਰ ਉਮੀਦਵਾਰ ਇਸ API ਕੁੰਜੀ ਦਾ excluded ਫ਼ਲੈਗ ਵੀ ਰੱਖਦਾ ਹੈ। ਬਾਹਰ ਰੱਖਣ ਸੰਬੰਧੀ ਸੈਟਿੰਗਾਂ ਹਰੇਕ API ਕੁੰਜੀ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ (auto_candidate_overrides ਟੇਬਲ, ਮਾਈਗ੍ਰੇਸ਼ਨ 128) — OmniRoute ਇੱਕਲ-ਟੈਨੈਂਟ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਕੋਈ users ਟੇਬਲ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ apiKeyId ਕਾਲ ਕਰਨ ਵਾਲੇ ਦੀ ਸਭ ਤੋਂ ਨੇੜਲੀ ਅਸਲ ਪਛਾਣ ਹੈ — ਅਤੇ ਇਹਨਾਂ ਨੂੰ open-sse/services/autoCombo/virtualFactory.ts ਵਿੱਚ ਉਮੀਦਵਾਰ-ਪੂਲ ਦੇ ਚੋਕਪੋਇੰਟ 'ਤੇ ਸ਼ੁੱਧ, ਯੂਨਿਟ-ਟੈਸਟ ਕੀਤੇ filterExcludedCandidates() (open-sse/services/autoCombo/candidateOverrides.ts) ਰਾਹੀਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਫ਼ਿਲਟਰ fail-open ਹੈ: ਸੈੱਟ ਨਾ ਕੀਤਾ ਗਿਆ apiKeyId/channel ਜਾਂ DB ਲੁੱਕਅੱਪ ਦੀ ਅਸਫਲਤਾ, ਦੋਵੇਂ ਹੀ ਪੂਲ ਨੂੰ ਬਿਨਾਂ ਫ਼ਿਲਟਰ ਕੀਤੇ ਛੱਡਦੇ ਹਨ, ਇਸ ਲਈ ਜਿਸ ਓਪਰੇਟਰ ਲਈ ਕੋਈ ਓਵਰਰਾਈਡ ਸੰਰਚਿਤ ਨਹੀਂ ਹੈ, ਉਸ ਨੂੰ ਰਾਊਟਿੰਗ ਇਸ ਫੀਚਰ ਤੋਂ ਪਹਿਲਾਂ ਵਾਂਗ ਬਾਈਟ-ਦਰ-ਬਾਈਟ ਇੱਕੋ ਜਿਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

ਅਗਲੇ ਫਾਲੋ-ਅੱਪ ਮੁੱਦੇ ਲਈ ਮੁਲਤਵੀ: ਹਰੇਕ ਉਮੀਦਵਾਰ ਲਈ ਵਜ਼ਨ + ਸਪਸ਼ਟ ਕ੍ਰਮਬੱਧਤਾ (ਲੈਵਲ 3 — ਮੌਜੂਦਾ ਵਜ਼ਨਦਾਰ/ਤਰਜੀਹੀ ਰਣਨੀਤੀ ਪਾਥਾਂ ਵਿੱਚ ਜਾਂਦੀ ਹੈ) ਅਤੇ ਹਰੇਕ auto/* ਚੈਨਲ ਲਈ ਇੱਕ ਖ਼ਾਸ combo.ts ਰਣਨੀਤੀ ਨੂੰ ਪਿੰਨ ਕਰਨਾ (ਲੈਵਲ 4)। ਇਸ ਖੁੱਲ੍ਹੇ ਸਵਾਲ ਲਈ #7819 ਯੋਜਨਾ ਵੇਖੋ ਕਿ ਇੱਕਲ-ਟੈਨੈਂਟ ਮਾਡਲ ਨੂੰ ਦੇਖਦੇ ਹੋਏ ਓਵਰਰਾਈਡ ਹਰੇਕ API ਕੁੰਜੀ ਲਈ ਵੱਖਰੇ ਰਹਿਣ ਜਾਂ ਗਲੋਬਲ ਬਣ ਜਾਣ।

ਪਰਦੇ ਦੇ ਪਿੱਛੇ:

ਬੇਨਤੀ: { model: "auto/coding" }
   ↓
src/sse/handlers/chat.ts ਪ੍ਰੀਫਿਕਸ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ
   ↓
createVirtualAutoCombo('coding') → ਸਰਗਰਮ ਕਨੈਕਸ਼ਨਾਂ ਤੋਂ candidatePool
   ↓
handleComboChat (ਸਥਾਈ ਤੌਰ 'ਤੇ ਸੰਭਾਲੇ ਕੰਬੋਜ਼ ਵਾਲਾ ਹੀ ਇੰਜਣ)
   ↓
ਆਟੋ-ਸਕੋਰਿੰਗ ਹਰੇਕ ਬੇਨਤੀ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਪ੍ਰਦਾਤਾ/ਮਾਡਲ ਚੁਣਦੀ ਹੈ

ਲਾਗੂਕਰਨ ਫ਼ਾਈਲਾਂ:

ਫ਼ਾਈਲ ਉਦੇਸ਼
open-sse/services/autoCombo/autoPrefix.ts ਪ੍ਰੀਫਿਕਸ ਪਾਰਸਰ (parseAutoPrefix)
open-sse/services/autoCombo/virtualFactory.ts ਵਰਚੁਅਲ AutoComboConfig ਆਬਜੈਕਟ ਬਣਾਉਂਦੀ ਹੈ
open-sse/services/autoCombo/providerRegistryAccessor.ts ਪ੍ਰਦਾਤਾ ਰਜਿਸਟਰੀ ਨੂੰ ਮੌਕ ਕਰਨ ਲਈ ਟੈਸਟ ਹੁੱਕ
src/sse/handlers/chat.ts ਏਕੀਕਰਨ: ਆਟੋ ਪ੍ਰੀਫਿਕਸ ਸ਼ਾਰਟ-ਸਰਕਿਟ
src/shared/constants/providers.ts SYSTEM_PROVIDERS.auto ਸਿਸਟਮ ਐਂਟਰੀ

ਅਸਲ ਮਾਡਲ Id ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਕੰਬੋ ਨਾਮ

ਅਜਿਹਾ ਕੰਬੋ ਜਿਸਦਾ name ਕਿਸੇ ਸਿੱਧੇ ਮਾਡਲ id ਦੇ ਬਿਲਕੁਲ ਸਮਾਨ ਹੋਵੇ (ਉਦਾਹਰਨ ਵਜੋਂ, gpt-5.5 ਨਾਮ ਵਾਲਾ ਕੰਬੋ), ਇੱਕ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਇਆ ਗਿਆ, ਸਮਰਥਿਤ ਪੈਟਰਨ ਹੈ, ਕੋਈ ਬੱਗ ਨਹੀਂ: ਇਹ ਪ੍ਰਤੀ-ਮਾਡਲ-id ਪ੍ਰੋਵਾਈਡਰ ਫਾਲਬੈਕ ਲਈ ਉਹ ਵਿਧੀ ਹੈ ਜਿਸਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ #6940 ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਹੈ। ਕਿਉਂਕਿ ਕੰਬੋ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਦੀ ਜਾਂਚ ਸਿੱਧੇ-ਮਾਡਲ-id ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (src/sse/services/model.ts ਵਿੱਚ getComboForModel()), ਇਸ ਲਈ ਸਿੱਧੀ id gpt-5.5 ਲਈ ਬੇਨਤੀ ਨੂੰ ਸਿੱਧਾ ਕਿਸੇ ਇੱਕ ਪ੍ਰੋਵਾਈਡਰ ਕੋਲ ਭੇਜਣ ਦੀ ਬਜਾਏ ਕੰਬੋ ਦੇ ਟਾਰਗੇਟਾਂ (ਉਦਾਹਰਨ ਵਜੋਂ, acme-responses/gpt-5.5, backup-responses/gpt-5.5) ਰਾਹੀਂ ਰੂਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ — ਇਹ #3227/#3233 ਲਈ ਬਣਾਈ ਗਈ ਕੰਬੋ-ਪਹਿਲਾਂ-ਰੀਰਾਈਟ ਤਰਜੀਹ ਨੂੰ ਮੁੜ ਵਰਤਦਾ ਹੈ ਅਤੇ tests/unit/responses-combo-resolution-3227.test.ts ਅਤੇ tests/unit/combo-name-codex-responses-rewrite.test.ts ਦੁਆਰਾ ਇਸਦੀ ਰਿਗ੍ਰੈਸ਼ਨ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਕਿਸੇ ਕੰਬੋ ਨੂੰ ਅਜਿਹਾ ਨਾਮ ਦੇ ਕੇ ਬਣਾਉਣਾ ਜਾਂ ਉਸਦਾ ਨਾਮ ਬਦਲਣਾ, ਜੋ ਕਿਸੇ ਅਸਲ ਮਾਡਲ id ਨੂੰ ਓਹਲੇ ਕਰਦਾ ਹੋਵੇ, ਕਦੇ ਵੀ ਅਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ — ਅਜਿਹਾ ਕਰਨ ਨਾਲ ਇਹ ਦਸਤਾਵੇਜ਼ਬੱਧ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਟੁੱਟ ਜਾਵੇਗਾ। ਇਸਦੀ ਬਜਾਏ (#8530), POST /api/combos ਅਤੇ PUT /api/combos/[id] ਜਵਾਬ ਵਿੱਚ ਇੱਕ ਗੈਰ-ਰੋਕੂ warning ਫੀਲਡ ਜੋੜਦੇ ਹਨ, ਜਦੋਂ (ਨਵਾਂ) ਨਾਮ ਕਿਸੇ ਅਸਲ ਮਾਡਲ id ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ:

{
  "warning": {
    "code": "COMBO_NAME_SHADOWS_MODEL",
    "modelId": "gpt-5.5",
    "providerId": "openai"
  }
}

ਬੂਟ ਸਮੇਂ, scanComboModelNameCollisionsAtBoot() (src/instrumentation-node.ts) ਇੱਕ-ਲਾਈਨ ਵਾਲੀ [STARTUP] ਚੇਤਾਵਨੀ ਵੀ ਲੌਗ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਮਾਡਲ id ਨੂੰ ਓਹਲੇ ਕਰਨ ਵਾਲੇ ਹਰੇਕ ਮੌਜੂਦਾ ਕੰਬੋ ਦੀ ਸੂਚੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਜੋ ਉਹ ਆਪਰੇਟਰ, ਜੋ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਜਾਣਬੁੱਝ ਕੇ (#6940 ਅਨੁਸਾਰ) ਨਹੀਂ ਸਗੋਂ ਗਲਤੀ ਨਾਲ ਪਹੁੰਚੇ ਹਨ, ਇਸ ਬਾਰੇ ਸੰਕੇਤ ਪ੍ਰਾਪਤ ਕਰ ਸਕਣ। ਖੋਜ ਸਹਾਇਕ src/lib/combos/modelNameCollision.ts ਵਿੱਚ ਮੌਜੂਦ ਹੈ।

ਕਲਾਇੰਟ ਤੋਂ ਕਸਟਮ ਕੰਬੋ ਨੂੰ ਕਾਲ ਕਰਨਾ

ਸਥਾਈ ਤੌਰ 'ਤੇ ਸੰਭਾਲੇ ਕੰਬੋ (ਸੈਟਿੰਗਾਂ → ਕੰਬੋ) ਸਿਰਫ਼ ਉਦੋਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਕਲਾਇੰਟ model ਫੀਲਡ ਵਿੱਚ ਕੰਬੋ ਦਾ ਬਿਲਕੁਲ ਸਹੀ ਨਾਮ ਭੇਜਦਾ ਹੈ — ਕੰਬੋ ਨਾਮ ਲਈ ਕੋਈ ਅੰਦਾਜ਼ਨ ਜਾਂ ਅੰਸ਼ਕ ਮਿਲਾਣ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਕੋਈ auto/ ਪ੍ਰੀਫਿਕਸ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ। ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਕ੍ਰਮ (src/sse/services/model.ts ਵਿੱਚ getComboForModel()):

  1. ਕੰਬੋ ਨਾਮ ਦਾ ਬਿਲਕੁਲ ਸਹੀ ਮੇਲ (model: "my-combo"),
  2. combo/<name> ਪ੍ਰੀਫਿਕਸ (model: "combo/my-combo"),
  3. ਮਾਡਲ→ਕੰਬੋ ਗਲੌਬ ਮੈਪਿੰਗਾਂ (/api/model-combo-mappings)।
curl -X POST http://localhost:20128/v1/chat/completions \
  -H "Authorization: Bearer <key>" \
  -H "Content-Type: application/json" \
  -d '{"model":"my-combo","messages":[{"role":"user","content":"Hello"}]}'

ਦੋ ਆਮ ਗਲਤੀਆਂ:

  • auto ਤੁਹਾਡੇ ਕੰਬੋ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ। auto/auto/* ਆਪਣਾ ਜ਼ੀਰੋ-ਕਾਨਫਿਗ ਉਮੀਦਵਾਰ ਪੂਲ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸਥਾਈ ਤੌਰ 'ਤੇ ਸੰਭਾਲੇ ਕੰਬੋ ਨਾਲ ਸਿਰਫ਼ ਉਦੋਂ ਸਲਾਹ ਕਰਦਾ ਹੈ, ਜੇ ਕਿਸੇ ਕੰਬੋ ਦਾ ਨਾਮ ਅੱਖਰਸ਼ auto ਹੋਵੇ (ਇਸਦੀ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ)। ਕਿਸੇ ਕੰਬੋ ਰਾਹੀਂ ਰੂਟ ਕਰਨ ਲਈ, ਉਸਦਾ ਬਿਲਕੁਲ ਸਹੀ ਨਾਮ ਭੇਜੋ — auto ਨਹੀਂ।
  • openrouter/auto ਇੱਕ ਅਸਲ ਭੁਗਤਾਨਯੋਗ OpenRouter ਉਤਪਾਦ ("ਆਟੋ ਸਰਵੋਤਮ ਉਪਲਬਧ") ਹੈ, ਕੋਈ OmniRoute ਉਪਨਾਮ ਨਹੀਂ। ਇਹ OpenRouter ਰਜਿਸਟਰੀ (open-sse/config/providers/registry/openrouter/index.ts) ਦੀ ਇਕੱਲੀ ਸਥਿਰ ਮਾਡਲ ਐਂਟਰੀ ਹੈ ਅਤੇ ਇਸਦਾ ਬਿੱਲ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲੱਗਦਾ ਹੈ। ਇਸਨੂੰ auto ਪੂਲਾਂ ਵਿੱਚੋਂ ਬਾਹਰ ਰੱਖਣ ਲਈ ਸੈਟਿੰਗਾਂ → ਰੂਟਿੰਗ → ਭੁਗਤਾਨਯੋਗ ਮਾਡਲ ਲੁਕਾਓ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਇੱਥੇ ਦਸਤਾਵੇਜ਼ਬੱਧ ਮੂਲ ਉਲਝਣ ਲਈ #7992 ਅਤੇ #7111 ਵੇਖੋ।

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ (ਸਥਾਈ Auto-Combos)

Auto-Combo Engine ਇੱਕ 16-ਕਾਰਕ ਸਕੋਰਿੰਗ ਫੰਕਸ਼ਨ (open-sse/services/autoCombo/scoring.ts → DEFAULT_WEIGHTS ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਰ ਬੇਨਤੀ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ provider/model ਨੂੰ ਗਤੀਸ਼ੀਲ ਢੰਗ ਨਾਲ ਚੁਣਦਾ ਹੈ। ਡਿਫਾਲਟ ਭਾਰਾਂ ਦਾ ਜੋੜ 1.0 ਹੈ; ਕਸਟਮ ਭਾਰਾਂ ਨੂੰ normalizeScoringWeights() ਦੁਆਰਾ ਮੁੜ ਨਾਰਮਲਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸੋਲ੍ਹਾਂ ਵਿੱਚੋਂ ਦੋ — cacheAffinity ਅਤੇ resetWindowAffinity — ਦਾ ਡਿਫਾਲਟ ਭਾਰ 0 ਹੈ; reliability ਦਾ DEFAULT_WEIGHTS ਵਿੱਚ ਭਾਰ 0 ਹੈ, ਪਰ ਆਮ ਪੈਕਾਂ ਵਿੱਚ 0.03 ਅਤੇ reliability-first ਵਿੱਚ 0.04 ਹੈ, ਅਤੇ quality ਦਾ ਪੈਕਾਂ ਵਿੱਚ ਭਾਰ 0.02 (quality-first ਵਿੱਚ 0.03) ਹੈ: ਫਿਰ ਵੀ ਹਰ ਉਮੀਦਵਾਰ ਲਈ ਇਨ੍ਹਾਂ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ cacheAffinity ਸਕੋਰ ਤੋਂ ਬਾਹਰ prompt-cache ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਫ਼ਰ-ਡਿਫਾਲਟ ਵਾਲੇ ਕਾਰਕ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਵੋਟ ਨਹੀਂ ਦਿੰਦੇ, ਜਦਕਿ ਪੈਕ ਦਿੰਦੇ ਹਨ।

Auto-Combo ਦੀ 16-ਕਾਰਕ ਸਕੋਰਿੰਗ

ਸਰੋਤ: diagrams/auto-combo-scoring.mmd (npm run docs:render-diagrams ਰਾਹੀਂ ਮੁੜ ਤਿਆਰ ਕਰੋ)। ਫ਼ਾਈਲ ਦਾ ਨਾਮ ਇਤਿਹਾਸਕ ਹੈ; ਸਰੋਤ ਅਤੇ ਰੈਂਡਰ ਕੀਤਾ ਡਾਇਗ੍ਰਾਮ DEFAULT_WEIGHTS ਵਿੱਚ ਘੋਸ਼ਿਤ ਸਾਰੇ 16 ਕਾਰਕ ਦਿਖਾਉਂਦੇ ਹਨ।

ਕਾਰਕ ਡਿਫਾਲਟ ਭਾਰ ਵੇਰਵਾ
quota 0.1429 ਬਾਕੀ quota / rate-limit ਸਮਰੱਥਾ [0..1]
health 0.1605 circuit breaker ਤੋਂ ਸਿਹਤ ਸਕੋਰ (CLOSED=1.0, HALF_OPEN=0.5, OPEN=0.0)
costInv 0.1429 ਉਲਟੀ ਮਿਸ਼ਰਤ ਲਾਗਤ (60% ਇਨਪੁੱਟ + 40% ਆਉਟਪੁੱਟ token ਕੀਮਤ, ਨਾਰਮਲਾਈਜ਼ ਕੀਤੀ) — ਘੱਟ ਲਾਗਤ = ਵੱਧ ਸਕੋਰ
latencyInv 0.1143 pool ਦੇ ਮੁਕਾਬਲੇ ਨਾਰਮਲਾਈਜ਼ ਕੀਤੀ ਉਲਟੀ p95 latency — ਵੱਧ ਤੇਜ਼ = ਵੱਧ ਸਕੋਰ
taskFit 0.0762 ਕਾਰਜ-ਕਿਸਮ ਲਈ ਉਪਯੋਗਤਾ (ਕੋਡਿੰਗ, ਸਮੀਖਿਆ, ਯੋਜਨਾ, ਵਿਸ਼ਲੇਸ਼ਣ, ਡੀਬੱਗਿੰਗ, ਦਸਤਾਵੇਜ਼)
stability 0.0476 latency ਦੇ ਮਿਆਰੀ ਵਿਸਥਾਪਨ ਤੋਂ variance-ਅਧਾਰਿਤ ਸਥਿਰਤਾ — ਜਿਸ ਉਮੀਦਵਾਰ ਦਾ ਜਵਾਬ ਸਮਾਂ ਵੱਧ ਉਤਰਾਅ-ਚੜ੍ਹਾਅ ਕਰਦਾ ਹੈ, ਉਸਨੂੰ ਘੱਟ ਸਕੋਰ ਮਿਲਦਾ ਹੈ
tierPriority 0.0476 ਖਾਤਾ-tier ਤਰਜੀਹ — Ultra=1.0, Pro=0.67, Standard=0.33, Free=0.0
tierAffinity 0.0476 ਉਮੀਦਵਾਰ ਦੇ tier ਅਤੇ manifest ਦੁਆਰਾ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੇ tier ਵਿਚਕਾਰ ਅਨੁਕੂਲਤਾ
specificityMatch 0.0476 ਬੇਨਤੀ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ (manifest ਸੰਕੇਤ) ਅਤੇ model tier ਵਿਚਕਾਰ ਮੇਲ
contextAffinity 0.0476 ਬੇਨਤੀ ਦੀ context-window ਲੋੜ ਅਤੇ model ਦੀ context window ਵਿਚਕਾਰ ਅਨੁਕੂਲਤਾ
sessionAvailability 0.0476 ਇਸ session ਲਈ ਉਮੀਦਵਾਰ connection ਦੀ OAuth session ਉਪਲਬਧਤਾ (getOAuthSessionAvailability(); ਗੈਰ-OAuth connections ਨੂੰ 1.0 ਸਕੋਰ ਮਿਲਦਾ ਹੈ)
connectionDensity 0.0476 ਇੱਕੋ provider ਦੇ connections ਵਿਚਕਾਰ ਲੋਡ ਵੰਡਦਾ ਹੈ (ਕੇਂਦਰੀਕਰਨ-ਵਿਰੋਧੀ)
cacheAffinity 0.00 ਉਸ connection ਵੱਲ Rendezvous-hash ਅਨੁਕੂਲਤਾ, ਜਿਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਸ ਬੇਨਤੀ ਦਾ prompt-cache prefix ਹੋਣ ਦੀ ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਹੈ (open-sse/services/combo/promptCacheAffinity.ts); ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਅਸਮਰੱਥ (#8008)
resetWindowAffinity 0.00 ਉਨ੍ਹਾਂ connections ਵੱਲ ਝੁਕਾਅ, ਜਿਨ੍ਹਾਂ ਦੀ quota reset window ਅਨੁਕੂਲ ਹੈ (ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਅਸਮਰੱਥ)
quality 0.03 routing-event ਗੁਣਵੱਤਾ tracker ਤੋਂ feedback-ਅਧਾਰਿਤ ਆਉਟਪੁੱਟ-ਗੁਣਵੱਤਾ ਸੰਕੇਤ; ਬਿਨਾਂ ਨਿਰੀਖਣਾਂ ਵਾਲੇ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਨਿਰਪੱਖ 0.5 ਮਿਲਦਾ ਹੈ
reliability 0.00 ਦਸ-sample ਦੀ ਘੱਟੋ-ਘੱਟ ਸੀਮਾ ਪਿੱਛੇ 24h ਦੇ ਵਰਤੋਂ ਇਤਿਹਾਸ ਤੋਂ ਦੇਖਿਆ ਗਿਆ ਸਫਲਤਾ ਅਨੁਪਾਤ, 1 - failureRate (ਨਹੀਂ ਤਾਂ real-time metrics); ਬਿਨਾਂ ਨਿਰੀਖਣਾਂ ਵਾਲੇ ਉਮੀਦਵਾਰਾਂ ਲਈ ਇਸਨੂੰ 1.0 ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਅਸਮਰੱਥ

ਜੋੜ: 0.1429 + 0.1605 + 0.1429 + 0.1143 + 0.0762 + (7 × 0.0476) + 0.00 + 0.00 + 0.03 + 0.00 = 1.0, ਜਿਵੇਂ DEFAULT_WEIGHTS ਵਿੱਚ ਘੋਸ਼ਿਤ ਹੈ; ਸਕੋਰਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤੋਂਕਾਰ ਦੁਆਰਾ ਸੰਰਚਿਤ ਭਾਰਾਂ ਨੂੰ normalizeScoringWeights() ਦੁਆਰਾ ਮੁੜ ਨਾਰਮਲਾਈਜ਼ ਕਰਕੇ ਇੱਕ ਵੰਡ ਵਿੱਚ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ।

ਮੋਡ ਪੈਕ

open-sse/services/autoCombo/modePacks.ts ਵਿੱਚ 6 ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਵੇਟ ਪ੍ਰੋਫ਼ਾਈਲ ਹਨ। ਹਰ ਪੈਕ ਇੱਕ ਟੀਚੇ ਵੱਲ ਚੋਣ ਨੂੰ ਝੁਕਾਉਣ ਲਈ ਡਿਫੌਲਟ ਵੇਟਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਹਰ ਪੈਕ ਦਾ ਜੋੜ ਪਹਿਲਾਂ ਹੀ 1.0 ਹੈ (ਚਾਰ ਦਸ਼ਮਲਵ ਅੰਕਾਂ ਤੱਕ ਪ੍ਰਿੰਟ ਕਰਨ 'ਤੇ 0.9999), ਇਸ ਲਈ ਜਦੋਂ ਕੋਈ ਪੈਕ ਸਰਗਰਮ ਹੁੰਦਾ ਹੈ ਤਾਂ normalizeScoringWeights() ਕੋਲ ਠੀਕ ਕਰਨ ਲਈ ਕੋਈ ਅਰਥਪੂਰਨ ਚੀਜ਼ ਨਹੀਂ ਹੁੰਦੀ — ਹੇਠਾਂ ਦਿੱਤੇ ਮੁੱਲ, ਰਾਊਂਡਿੰਗ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਿਆਂ, ਉਹੀ ਹਨ ਜੋ ਸਕੋਰਰ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਕਾਰਕ ship-fast cost-saver quality-first offline-friendly reliability-first chaos-mode
quota 0.1133 0.1133 0.0752 0.3324 0.1133 0.0376
health 0.2667 0.1810 0.1714 0.2667 0.3524 0.4000
costInv 0.0276 0.3324 0.0276 0.0752 0.0181 0.0140
latencyInv 0.3048 0.0476 0.0476 0.0476 0.0476 0.0186
taskFit 0.0952 0.0952 0.3524 0.0000 0.0952 0.1905
stability 0.0000 0.0476 0.1429 0.0952 0.1905 0.1714
tierPriority 0.0376 0.0376 0.0276 0.0376 0.0276 0.0040
tierAffinity 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
specificityMatch 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
contextAffinity 0.0095 0.0000 0.0000 0.0000 0.0000 0.0186
sessionAvailability 0.0476 0.0476 0.0476 0.0476 0.0476 0.0476
resetWindowAffinity 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
connectionDensity 0.0476 0.0476 0.0476 0.0476 0.0476 0.0476
quality 0.02 0.02 0.03 0.02 0.02 0.02
reliability 0.03 0.03 0.03 0.03 0.04 0.03

ਨੋਟ:

  • ਪੈਕਾਂ ਵਿੱਚ quality ਅਤੇ reliability ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ (quality 0.02, quality-first 0.03; reliability 0.03, reliability-first 0.04) ਅਤੇ ਇਹ ਵੇਟ ਮੈਪ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਦਿੰਦੇ ਹਨ (weights = pack, ਮਰਜ ਨਹੀਂ)। DEFAULT_WEIGHTS ਵਿੱਚ quality 0.03 / reliability 0 ਹੁੰਦਾ ਹੈ; balanced/default ਚੁਣਨ ਨਾਲ ਉਹ ਡਿਫੌਲਟ ਬਰਕਰਾਰ ਰਹਿੰਦੇ ਹਨ, ਜਦਕਿ ਕੋਈ ਪੈਕ ਚੁਣਨ ਨਾਲ ਉੱਪਰ ਦਿੱਤੇ ਪੈਕ ਦੇ ਮੁੱਲ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਕੋਲਡ ਪੂਲ ਵਿੱਚ (ਅਜੇ ਤੱਕ ਕੋਈ ਨਿਰੀਖਣ ਨਹੀਂ, ਇਸ ਲਈ quality 0.5 ਅਤੇ reliability 1) ਇਹ ਦੋਵੇਂ ਕਾਰਕ ਇੱਕ ਆਮ ਪੈਕ ਹੇਠ +0.04 (0.03 + 0.01), quality-first ਹੇਠ +0.045, ਅਤੇ reliability-first ਹੇਠ +0.05 ਜੋੜਦੇ ਹਨ।
  • ਹਰ ਪੈਕ ਵਿੱਚ tierAffinity, specificityMatch ਅਤੇ resetWindowAffinity ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ 0 ਹਨ।
  • ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਹਰ ਪੈਕ ਦਾ ਜ਼ੋਰ:
    • ship-fast → latencyInv 0.3048 + health 0.2667 (ਘੱਟ ਲੇਟੈਂਸੀ ਵਾਲੇ, ਸਿਹਤਮੰਦ ਕਨੈਕਸ਼ਨ)
    • cost-saver → costInv 0.3324 (ਸਭ ਤੋਂ ਸਸਤੇ ਟੋਕਨ ਜਿੱਤਦੇ ਹਨ)
    • quality-first → taskFit 0.3524 + stability 0.1429 + quality 0.03, ਜੋ ਕਿਸੇ ਵੀ ਪੈਕ ਨਾਲੋਂ ਸਭ ਤੋਂ ਵੱਧ ਹੈ (ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ, ਇਕਸਾਰ ਮਾਡਲ)
    • offline-friendly → quota 0.3324 + health 0.2667 (ਗਤੀ/ਲਾਗਤ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਵਾਧੂ ਸਮਰੱਥਾ)
    • reliability-first → health 0.3524 + stability 0.1905 + reliability 0.04, ਜੋ ਕਿਸੇ ਵੀ ਪੈਕ ਨਾਲੋਂ ਸਭ ਤੋਂ ਵੱਧ ਹੈ (ਸਭ ਤੋਂ ਘੱਟ ਅਣਕਿਆਸੇ ਨਤੀਜੇ)
    • chaos-mode → health 0.4000 + taskFit 0.1905 (ਫਾਲਟ-ਇੰਜੈਕਸ਼ਨ ਪ੍ਰੋਫ਼ਾਈਲ)

ਪ੍ਰਤੀ-ਬੇਨਤੀ ਕੰਟਰੋਲ (ਹੈਡਰ) — #6023 / #6024 / #6025 / #3470

ਕਿਸੇ auto ਕਾਂਬੋ ਦੀ ਸਟੋਰ ਕੀਤੀ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ, ਤਿੰਨ ਹੈਡਰਾਂ ਰਾਹੀਂ ਇਸ ਨੂੰ ਪ੍ਰਤੀ ਬੇਨਤੀ ਨਿਰਦੇਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ auto ਰਣਨੀਤੀ ਅਤੇ ਸਿਰਫ਼ ਉਸ ਬੇਨਤੀ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਇਹ ਮੌਜੂਦ ਹੋਣ; ਜਦੋਂ ਹੈਡਰ ਮੌਜੂਦ ਨਾ ਹੋਵੇ, ਤਾਂ ਕਾਂਬੋ ਦੇ ਸੇਵ ਕੀਤੇ modePack/budgetCap/budgetFallback ਵਰਤੇ ਜਾਂਦੇ ਹਨ।

ਹੈਡਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਪ੍ਰਭਾਵ
X-OmniRoute-Mode ਇੱਕ ਪ੍ਰੀਸੈੱਟ ਉਪਨਾਮ (fast, balanced, quality, cheap, reliable, offline) ਜਾਂ ਇੱਕ ਕੱਚਾ ਪੈਕ ਨਾਮ (ship-fast, cost-saver, quality-first, offline-friendly, reliability-first) ਇਸ ਬੇਨਤੀ ਲਈ ਸਕੋਰਿੰਗ ਭਾਰਾਂ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰਦਾ ਹੈ। balanced/default ਡਿਫੌਲਟ ਭਾਰਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ (ਕੋਈ ਪੈਕ ਨਹੀਂ)। ਅਣਜਾਣ ਮੁੱਲਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਕਨਫਿਗਰੇਸ਼ਨ ਬਰਕਰਾਰ ਰਹਿੰਦੀ ਹੈ)।
X-OmniRoute-Budget ਇੱਕ ਧਨਾਤਮਕ ਸੰਖਿਆ (ਪ੍ਰਤੀ ਬੇਨਤੀ ਅਧਿਕਤਮ USD) ਸਖ਼ਤ ਲਾਗਤ ਸੀਮਾ: ਜਿਨ੍ਹਾਂ ਉਮੀਦਵਾਰਾਂ ਦੀ ਅਨੁਮਾਨਿਤ ਲਾਗਤ ਇਸ ਤੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਚੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫਿਲਟਰ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਹਰੇਕ ਉਮੀਦਵਾਰ ਇਸ ਸੀਮਾ ਤੋਂ ਵੱਧ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਇਹ ਹੇਠਾਂ ਦਿੱਤੇ X-OmniRoute-Budget-Fallback ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
X-OmniRoute-Budget-Fallback cheapest (ਡਿਫੌਲਟ, ਉਪਨਾਮ: cheapest-viable, soft) ਜਾਂ strict (ਉਪਨਾਮ: block, hard) cheapest: ਸੀਮਾ ਤੋਂ ਵੱਧ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸਸਤੇ ਉਮੀਦਵਾਰ ਨੂੰ ਫਾਲਬੈਕ ਵਜੋਂ ਚੁਣਦਾ ਹੈ (ਪੁਰਾਤਨ ਵਿਹਾਰ)। strict: ਚੋਣ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ—ਚੁੱਪਚਾਪ ਵੱਧ ਖਰਚ ਕਰਨ ਦੀ ਬਜਾਏ ਬੇਨਤੀ HTTP 402 ਨਾਲ ਤੁਰੰਤ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਅਣਜਾਣ ਮੁੱਲਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
X-OmniRoute-Effort auto (ਹੋਰ ਮੁੱਲ ਰਾਖਵੇਂ ਹਨ) ਅਨੁਕੂਲ ਸੋਚ ਬਜਟ: ਜਦੋਂ ਬੇਨਤੀ ਵਿੱਚ ਕਿਸੇ ਵੀ ਰੂਪ ਦਾ ਕੋਈ ਤਰਕ ਖੇਤਰ (reasoning_effort, reasoning, thinking) ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਗੇਟਵੇ ਨਿਰਧਾਰਤ ਬੇਨਤੀ-ਆਕਾਰ ਸੰਕੇਤਾਂ (ਆਖਰੀ-ਉਪਭੋਗਤਾ-ਸੁਨੇਹੇ ਦੀ ਲੰਬਾਈ, ਆਖਰੀ ਉਪਭੋਗਤਾ ਸੁਨੇਹੇ ਤੱਕ ਸੰਦਰਭ ਦਾ ਆਕਾਰ, ਪਿਛਲੇ ਟੂਲ ਨਤੀਜੇ, ਟੂਲ-ਲੂਪ ਦੀ ਡੂੰਘਾਈ) ਤੋਂ auto ਨੂੰ low/medium/high ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਸੰਕੇਤ ਮੌਜੂਦਾ ਟਰਨ ਤੱਕ ਸੀਮਿਤ ਹੁੰਦੇ ਹਨ—ਆਖਰੀ ਉਪਭੋਗਤਾ ਸੁਨੇਹੇ ਤੋਂ ਬਾਅਦ ਦੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਅਣਡਿੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਇਸ ਲਈ ਟੂਲ ਲੂਪ ਵਿੱਚ ਹਰ ਬੇਨਤੀ ਇੱਕੋ ਪੱਧਰ 'ਤੇ ਨਿਰਧਾਰਤ ਹੁੰਦੀ ਹੈ (ਸਟੇਟਲੈੱਸ ਪ੍ਰਤੀ-ਟਰਨ ਪਿੰਨ, ਕੋਈ ਸੈਸ਼ਨ ਸਥਿਤੀ ਨਹੀਂ, ਲੂਪ ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਅਜਿਹਾ ਵਾਧਾ ਨਹੀਂ ਜੋ ਅੱਪਸਟ੍ਰੀਮ ਪ੍ਰੌਂਪਟ-ਕੈਸ਼ ਪ੍ਰੀਫਿਕਸਾਂ ਨੂੰ ਤੋੜੇ)। ਕਲਾਇੰਟ ਦੁਆਰਾ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿੱਤਾ ਤਰਕ ਖੇਤਰ ਹਮੇਸ਼ਾ ਪਹਿਲ ਲੈਂਦਾ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਬੇਨਤੀਆਂ ਤੱਕ ਸੀਮਿਤ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਅੱਪਸਟ੍ਰੀਮ ਡਿਸਪੈਚ OpenAI Chat Completions ਆਕਾਰ (targetFormat === FORMATS.OPENAI) ਵਿੱਚ ਨਿਰਧਾਰਤ ਹੁੰਦੀ ਹੈ—reasoning_effort ਇੱਕ OpenAI-ਆਕਾਰ ਵਾਲਾ ਖੇਤਰ ਹੈ, ਇਸ ਲਈ Claude- ਜਾਂ Gemini-ਲਕਸ਼ਿਤ ਬੇਨਤੀ 'ਤੇ ਇਸ ਹੈਡਰ ਦਾ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਹੁੰਦਾ (open-sse/handlers/chatCore/adaptiveEffortWiring.ts ਵੇਖੋ)। 
# ਸਭ ਤੋਂ ਤੇਜ਼ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਲਾਜ਼ਮੀ ਕਰੋ, ਇਸ ਬੇਨਤੀ ਦੀ ਸੀਮਾ $0.05 ਰੱਖੋ, ਅਤੇ ਵੱਧ ਖਰਚ ਕਰਨ ਦੀ ਬਜਾਏ ਇਸਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਬਲੌਕ ਕਰੋ
curl -sS http://localhost:20128/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "X-OmniRoute-Mode: fast" \
  -H "X-OmniRoute-Budget: 0.05" \
  -H "X-OmniRoute-Budget-Fallback: strict" \
  -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}'

ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਇੱਕ ਸ਼ੁੱਧ ਫੰਕਸ਼ਨ ਹੈ (open-sse/services/autoCombo/requestControls.ts); ਰੈਜ਼ੋਲਵ ਕੀਤੇ ਮੁੱਲ ਇੰਜਣ ਦੇ ਮੌਜੂਦਾ config.modePack / config.budgetCap / config.budgetFallback ਇਨਪੁੱਟਾਂ ਵਿੱਚ ਜਾਂਦੇ ਹਨ। ਕਿਸੇ ਕਾਂਬੋ ਦਾ ਸਟੋਰ ਕੀਤਾ config.budgetFallback ("strict" | "cheapest") ਸਥਾਈ ਨੀਤੀ ਸੈੱਟ ਕਰਦਾ ਹੈ; ਹੈਡਰ ਇੱਕ ਬੇਨਤੀ ਲਈ ਇਸਨੂੰ ਓਵਰਰਾਈਡ ਕਰਦਾ ਹੈ।

ਸਾਰੀਆਂ ਰਾਊਟਿੰਗ ਰਣਨੀਤੀਆਂ

OmniRoute ਦਾ ਕਾਂਬੋ ਇੰਜਣ 19 ਰਾਊਟਿੰਗ ਰਣਨੀਤੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ (src/shared/constants/routingStrategies.ts → ROUTING_STRATEGY_VALUES ਵਿੱਚ ਘੋਸ਼ਿਤ)। Auto Combo ਇੰਜਣ ਖੁਦ auto ਰਣਨੀਤੀ ਅਧੀਨ ਉਪਲਬਧ ਹੈ; ਬਾਕੀ ਰਣਨੀਤੀਆਂ ਸਥਾਈ ਕਾਂਬੋਆਂ ਲਈ ਉਪਲਬਧ ਹਨ।

ਰਣਨੀਤੀ ਵੇਰਵਾ
priority ਸਪਸ਼ਟ ਤਰਜੀਹ ਵਾਲੀ ਪਹਿਲੇ-ਟਾਰਗੇਟ ਦੀ ਕ੍ਰਮਬੱਧ ਸੂਚੀ
weighted ਪ੍ਰਤੀ-ਟਾਰਗੇਟ ਭਾਰ ਅਨੁਸਾਰ ਭਾਰਿਤ ਬੇਤਰਤੀਬ ਚੋਣ
round-robin ਟਾਰਗੇਟਾਂ ਵਿੱਚ ਕ੍ਰਮ ਅਨੁਸਾਰ ਚੱਕਰ ਲਗਾਓ (ਬੈਚਾਂ ਵਿੱਚ; ਹੇਠਾਂ ਵੇਖੋ)
context-relay ਟਾਰਗੇਟਾਂ ਵਿਚਕਾਰ ਸੰਦਰਭ ਅੱਗੇ ਸੌਂਪੋ (ਲੰਬੀਆਂ ਗੱਲਬਾਤਾਂ)
fill-first ਅਗਲੇ ਟਾਰਗੇਟ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰੇਕ ਟਾਰਗੇਟ ਦਾ ਕੋਟਾ ਭਰੋ
p2c 2-ਚੋਣਾਂ ਦੀ ਤਾਕਤ ਵਾਲਾ ਬੇਤਰਤੀਬ ਲੋਡ ਸੰਤੁਲਨ
random ਇਕਸਾਰ ਬੇਤਰਤੀਬ ਚੋਣ
least-used ਸਭ ਤੋਂ ਘੱਟ ਮੌਜੂਦਾ ਲੋਡ ਵਾਲਾ ਟਾਰਗੇਟ ਚੁਣੋ
cost-optimized ਕੈਟਾਲਾਗ ਕੀਮਤ ਦੇ ਆਧਾਰ 'ਤੇ ਪ੍ਰਤੀ ਬੇਨਤੀ $ ਘੱਟੋ-ਘੱਟ ਕਰੋ
reset-aware ⭐ ਕੋਟਾ ਰੀਸੈੱਟ ਸਮੇਂ ਅਨੁਸਾਰ ਤਰਜੀਹ ਦਿਓ — ਛੋਟੀਆਂ ਰੀਸੈੱਟ ਵਿੰਡੋਆਂ ਨੂੰ ਉੱਚਾ ਦਰਜਾ ਮਿਲਦਾ ਹੈ
reset-window ਉਹਨਾਂ ਟਾਰਗੇਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜਿਨ੍ਹਾਂ ਦੀ ਕੋਟਾ ਵਿੰਡੋ ਸਭ ਤੋਂ ਜਲਦੀ ਰੀਸੈੱਟ ਹੁੰਦੀ ਹੈ
headroom ਸਭ ਤੋਂ ਵੱਧ ਬਚੀ ਹੋਈ ਕੋਟਾ ਗੁੰਜਾਇਸ਼ ਵਾਲਾ ਟਾਰਗੇਟ ਚੁਣੋ
strict-random ਦੁਹਰਾਵਾਂ ਦੀ ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਬੇਤਰਤੀਬ ਚੋਣ
auto Auto Combo ਸਕੋਰਿੰਗ (16-ਕਾਰਕ) ਵਰਤੋ — ਸਿਫ਼ਾਰਸ਼ੀ
lkgp ਆਖਰੀ-ਜਾਣਿਆ-ਚੰਗਾ ਪਾਥ (ਆਖਰੀ ਸਫਲ ਪ੍ਰਦਾਤਾ ਨਾਲ ਜੋੜੀ ਰੱਖਦਾ ਹੈ, ਫਿਰ ਨਿਯਮਾਂ 'ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ)
context-optimized ਮੌਜੂਦਾ ਸੰਦਰਭ ਆਕਾਰ ਲਈ ਸਭ ਤੋਂ ਢੁਕਵਾਂ ਟਾਰਗੇਟ ਚੁਣੋ
cache-optimized ਪ੍ਰੌਂਪਟ-ਕੈਸ਼ ਅਨੁਕੂਲਤਾ ਅਨੁਸਾਰ ਟਾਰਗੇਟਾਂ ਨੂੰ ਮੁੜ ਕ੍ਰਮਬੱਧ ਕਰੋ — ਜਿਸ ਕਨੈਕਸ਼ਨ ਕੋਲ ਇਸ ਬੇਨਤੀ ਦਾ ਕੈਸ਼ ਕੀਤਾ ਪ੍ਰੀਫਿਕਸ ਪਹਿਲਾਂ ਤੋਂ ਹੋਣ ਦੀ ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਹੈ, ਉਸ ਨੂੰ ਪਹਿਲਾਂ ਅਜ਼ਮਾਇਆ ਜਾਂਦਾ ਹੈ (open-sse/services/combo/promptCacheAffinity.ts, #8008)
fusion 🧬 ਮਾਡਲਾਂ ਦੇ ਇੱਕ ਪੈਨਲ ਨੂੰ ਸਮਾਂਤਰ ਚਲਾਓ, ਫਿਰ ਇੱਕ ਨਿਰਣਾਇਕ ਰਾਹੀਂ ਇੱਕ ਜਵਾਬ ਸੰਸ਼ਲੇਸ਼ਿਤ ਕਰੋ (ਹੇਠਾਂ ਵੇਖੋ)
pipeline ਟਾਰਗੇਟਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਚਲਾਓ, ਹਰੇਕ ਪੜਾਅ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਅਗਲੇ ਪੜਾਅ ਦੇ ਇਨਪੁੱਟ ਵਿੱਚ ਪਾਓ; ਸਿਰਫ਼ ਅੰਤਿਮ ਜਵਾਬ ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (#6396)

⭐ = v3.8.0 ਵਿੱਚ ਨਵਾਂ · 🧬 = v3.8.36 ਵਿੱਚ ਨਵਾਂ

weighted ਦੇ ਅਰਥ

weighted ਹਰੇਕ ਬੇਨਤੀ ਲਈ ਅਨੁਪਾਤਕ ਬੇਤਰਤੀਬ ਡਰਾਅ ਹੈ (open-sse/services/combo/targetSorters.ts → selectWeightedTarget), ਕੋਈ ਸਮਤੁਲਕ ਨਹੀਂ:

  • ਹਰੇਕ ਬੇਨਤੀ weight / totalWeight ਸੰਭਾਵਨਾ ਨਾਲ ਇੱਕ ਪੜਾਅ ਚੁਣਦੀ ਹੈ; ਬਾਕੀ ਪੜਾਅ ਉਸ ਬੇਨਤੀ ਲਈ ਫਾਲਬੈਕ ਲੜੀ ਵਜੋਂ ਘਟਦੇ ਭਾਰ ਅਨੁਸਾਰ ਕ੍ਰਮਬੱਧ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
  • ਜਿਸ ਪੜਾਅ ਦਾ ਭਾਰ 0 ਹੈ (ਜਾਂ ਮੌਜੂਦ ਨਹੀਂ ਹੈ), ਉਹ ਉਦੋਂ ਤੱਕ ਕਦੇ ਨਹੀਂ ਚੁਣਿਆ ਜਾਂਦਾ ਜਦੋਂ ਕੋਈ ਹੋਰ ਪੜਾਅ

    0 ਭਾਰ ਰੱਖਦਾ ਹੋਵੇ — ਉਹ ਸਿਰਫ਼ ਚੁਣੇ ਹੋਏ ਪੜਾਅ ਦੇ ਅਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਫਾਲਬੈਕ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ ਜਦੋਂ ਸਾਰੇ ਭਾਰ 0 ਹੋਣ, ਚੋਣ ਇਕਸਾਰ ਬਣਦੀ ਹੈ।

  • ਉਹ ਪੜਾਅ ਜਿਨ੍ਹਾਂ ਦੇ ਸਾਰੇ ਟਾਰਗੇਟ ਅਣਉਪਲਬਧ ਹਨ — ਪ੍ਰਦਾਤਾ ਸਰਕਿਟ ਬ੍ਰੇਕਰ OPEN, ਕਨੈਕਸ਼ਨ ਕੂਲਡਾਊਨ, ਮਾਡਲ ਲਾਕਆਉਟ — ਡਰਾਅ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਉਸ ਵਿੱਚੋਂ ਹਟਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ (open-sse/services/combo/targetResolution.ts), ਇਸ ਲਈ ਇੱਕੋ ਸਿਹਤਮੰਦ ਪੜਾਅ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਹਰੇਕ ਬੇਨਤੀ ਜਿੱਤ ਸਕਦਾ ਹੈ।
  • stickyWeightedLimit (ਕਾਂਬੋ ਸੰਰਚਨਾ, ਡਿਫਾਲਟ 1 = ਬੰਦ) ਮੁੜ ਡਰਾਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਚੁਣੇ ਹੋਏ ਪੜਾਅ ਨੂੰ ਇੰਨੀਆਂ ਲਗਾਤਾਰ ਸਫਲਤਾਵਾਂ ਲਈ ਸਥਿਰ ਰੱਖਦਾ ਹੈ।

ਸਖ਼ਤ ਆਵਰਤਨ ਲਈ round-robin ਵਰਤੋ; weighted ਵਿੱਚ ਬਰਾਬਰ ਭਾਰ ਅੰਕੜਾਤਮਕ — ਨਾ ਕਿ ਸਖ਼ਤ — ਸੰਤੁਲਨ ਦਿੰਦੇ ਹਨ।

ਏਜੰਟਿਕ ਪਾਈਪਲਾਈਨ ਮੋਡ

ਦੋ-ਪੜਾਅ ਵਾਲਾ pipeline ਕੌਂਬੋ config.agenticOrchestration.enabled ਨਾਲ ਪਲੈਨਰ/ਐਗਜ਼ਿਕਿਊਟਰ ਰਾਊਟਿੰਗ ਨੂੰ ਚੁਣ ਸਕਦਾ ਹੈ। ਪਹਿਲਾ ਟਾਰਗੇਟ ਯੋਜਨਾ ਬਣਾਉਣ ਅਤੇ ਅੰਤਿਮ ਜਵਾਬਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ; ਦੂਜਾ ਟਾਰਗੇਟ ਕਲਾਇੰਟ-ਨੇਟਿਵ ਟੂਲ ਕਾਲਾਂ ਭੇਜਦਾ ਹੈ। OmniRoute ਬੇਨਤੀ ਪ੍ਰੋਟੋਕੋਲ ਤੋਂ ਟੂਲ-ਨਤੀਜਾ ਜਾਰੀਕਰਨਾਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਪਲੈਨਰ ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੀ ਇੱਕ ਹੋਰ ਟੂਲ ਰਾਊਂਡ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਡਾਇਨਾਮਿਕ ਢੰਗ ਨਾਲ ਐਗਜ਼ਿਕਿਊਟਰ ਜਾਂ ਪਲੈਨਰ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਨੂੰ ਕਲਾਇੰਟ-ਮੁਖੀ ਅੰਤਿਮ ਪੜਾਅ ਬਣਾਉਂਦਾ ਹੈ।

{
  "strategy": "pipeline",
  "models": [{ "model": "provider/planner" }, { "model": "provider/executor" }],
  "config": {
    "agenticOrchestration": { "enabled": true, "maxToolRounds": 8 }
  }
}

ਐਗਜ਼ਿਕਿਊਟਰ ਇੱਕ ਜਵਾਬ ਵਿੱਚ ਕਈ ਸੁਤੰਤਰ ਕਾਲਾਂ ਭੇਜ ਸਕਦਾ ਹੈ। ਨਿਰਭਰ ਕਾਲਾਂ ਨੂੰ ਬਾਅਦ ਵਾਲੇ ਕਲਾਇੰਟ ਟੂਲ-ਨਤੀਜਾ ਟਰਨਾਂ ਵਿੱਚ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਪਲੈਨਰ ਹਰ ਨਤੀਜੇ ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ। maxToolRounds ਦਾ ਡਿਫੌਲਟ ਮੁੱਲ 8 ਹੈ ਅਤੇ ਇਹ 1–32 ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ; ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ, ਪਲੈਨਰ ਨੂੰ ਉਪਲਬਧ ਸਭ ਤੋਂ ਵਧੀਆ ਅੰਤਿਮ ਜਵਾਬ ਤਿਆਰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਅੰਦਰੂਨੀ ਪਲੈਨਰ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਬਫ਼ਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ ਚੁਣਿਆ ਗਿਆ ਕਲਾਇੰਟ-ਮੁਖੀ ਜਵਾਬ ਮੂਲ ਸਟ੍ਰੀਮਿੰਗ ਤਰਜੀਹ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ।

round-robin ਸਟਿੱਕੀ ਬੈਚ ਅਤੇ ਅਕਾਊਂਟ ਵਿਸਤਾਰ

ਰਾਊਂਡ-ਰੌਬਿਨ ਬੈਚਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ, ਹਰ ਪੜਾਅ ਲਈ ਇੱਕ ਬੇਨਤੀ ਦੇ ਰੂਪ ਵਿੱਚ ਨਹੀਂ:

  • stickyRoundRobinLimit (ਪਹਿਲਾਂ ਕੌਂਬੋ ਸੰਰਚਨਾ, ਫਿਰ comboStickyRoundRobinLimit, ਫਿਰ settings.stickyRoundRobinLimit, ਡਿਫੌਲਟ 3) ਰੋਟੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਗਾਤਾਰ ਇੰਨੀਆਂ ਸਫਲਤਾਵਾਂ ਲਈ ਉਸੇ ਟਾਰਗੇਟ ਨੂੰ ਕਾਇਮ ਰੱਖਦਾ ਹੈ। ਹਰ ਬੇਨਤੀ ਤੋਂ ਬਾਅਦ ਰੋਟੇਸ਼ਨ ਲਈ ਕੌਂਬੋ ਓਵਰਰਾਈਡ ਨੂੰ 1 'ਤੇ ਸੈੱਟ ਕਰੋ। ਕੌਂਬੋ ਐਡੀਟਰ ਪ੍ਰਭਾਵੀ ਮੁੱਲ ਅਤੇ ਇਹ ਕਿਸ ਲੇਅਰ ਤੋਂ ਆਇਆ ਹੈ, ਦੋਵੇਂ ਦਿਖਾਉਂਦਾ ਹੈ।
  • connectionAwareExpansion (ਪਹਿਲਾਂ ਕੌਂਬੋ ਸੰਰਚਨਾ, ਫਿਰ ਸੈਟਿੰਗਾਂ, ਡਿਫੌਲਟ false) ਰੋਟੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰੇਕ ਪ੍ਰਦਾਤਾ-ਪੱਧਰੀ ਪੜਾਅ ਨੂੰ ਪ੍ਰਤੀ-ਅਕਾਊਂਟ ਟਾਰਗੇਟਾਂ ਵਿੱਚ ਵਿਸਤਾਰਦਾ ਹੈ। ਗਰੁੱਪ-B ਰਣਨੀਤੀਆਂ (priority, weighted, round-robin, random, p2c, least-used, cost-optimized, lkgp, fill-first, strict-random, context-optimized, cache-optimized, context-relay, fusion, pipeline) ਇਸਨੂੰ ਚਾਲੂ ਕੀਤੇ ਜਾਣ ਤੱਕ ਪ੍ਰਦਾਤਾ-ਪੱਧਰੀ ਦ੍ਰਿਸ਼ ਕਾਇਮ ਰੱਖਦੀਆਂ ਹਨ। ਕੌਂਬੋ ਐਡੀਟਰ inherit / on / off ਵਿਕਲਪ ਉਪਲਬਧ ਕਰਦਾ ਹੈ; inherit ਗਲੋਬਲ ਡਿਫੌਲਟ (off) ਵਰਤਦਾ ਹੈ।
  • ਪ੍ਰੌਂਪਟ-ਕੈਸ਼ ਲੋਕੈਲਿਟੀ ਰਾਊਟਿੰਗ (promptCacheAffinityEnabled, ਡਿਫੌਲਟ true) ਪਿੰਨ ਕੀਤੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਮੁੜ ਕ੍ਰਮਬੱਧ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਮੇਲ ਖਾਂਦੀਆਂ ਕੈਸ਼ ਕੁੰਜੀਆਂ ਇੱਕੋ ਅਕਾਊਂਟ 'ਤੇ ਰਹਿਣ। ਪਿੰਨ ਕੀਤੇ ਪ੍ਰਤੀ-ਅਕਾਊਂਟ ਪੜਾਵਾਂ ਵਿੱਚ ਇਹ ਰਾਊਂਡ-ਰੌਬਿਨ ਅਤੇ ਵੇਟਡ ਰੋਟੇਸ਼ਨ ਨਾਲੋਂ ਪਹਿਲ ਲੈਂਦੀ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਸਖ਼ਤ ਰੋਟੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ Settings → Combo defaults ਦੇ ਅਧੀਨ ਇਸਨੂੰ ਬੰਦ ਕਰੋ। ਇਸ ਲਈ ਕੋਈ ਪ੍ਰਤੀ-ਕੌਂਬੋ ਓਵਰਰਾਈਡ ਨਹੀਂ ਹੈ।

ਇੱਕ ਮਾਡਲ ਉੱਤੇ ਬਹੁ-ਅਕਾਊਂਟ ਰੋਟੇਸ਼ਨ ਲਈ, ਤਿੰਨ ਪਿੰਨ ਕੀਤੇ connectionIds ਦੀ ਬਜਾਏ ਸਟਿੱਕੀ ਸੀਮਾ 1 ਵਾਲੇ ਇੱਕ ਡਾਇਨਾਮਿਕ-ਅਕਾਊਂਟ ਪੜਾਅ (ਖਾਲੀ connectionId, ਪੂਰਾ ਪੂਲ) ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਐਫਿਨਿਟੀ ਨਾਲ ਪਿੰਨ ਕੀਤੇ ਪੜਾਅ ਉਸੇ ਅਕਾਊਂਟ ਉੱਤੇ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਭਾਵੇਂ RR ਕਾਊਂਟਰ ਅੱਗੇ ਵਧਦਾ ਰਹੇ।

ਫਿਊਜ਼ਨ ਰਣਨੀਤੀ

fusion ਇੱਕੋ-ਇੱਕ ਅਜਿਹੀ ਰਣਨੀਤੀ ਹੈ ਜੋ ਕਿਸੇ ਇੱਕ ਟਾਰਗੇਟ ਨੂੰ ਨਹੀਂ ਚੁਣਦੀ। ਇਹ ਪ੍ਰੌਂਪਟ ਨੂੰ ਹਰੇਕ ਪੈਨਲ ਮਾਡਲ ਨੂੰ ਸਮਾਂਤਰ ਤੌਰ 'ਤੇ ਭੇਜਦੀ ਹੈ, ਫਿਰ ਇੱਕ ਸੰਰਚਨਾਯੋਗ ਜੱਜ ਮਾਡਲ ਸਾਰੇ ਪੈਨਲ ਜਵਾਬਾਂ ਤੋਂ ਇੱਕ ਅੰਤਿਮ ਜਵਾਬ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਅੱਪਸਟ੍ਰੀਮ decolua/9router (OpenRouter ਦੇ Fusion ਡਿਜ਼ਾਈਨ) ਤੋਂ ਪੋਰਟ ਕੀਤਾ ਗਿਆ; ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ open-sse/services/fusion.ts ਵਿੱਚ ਹੈ।

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ:

  1. ਟੂਲ-ਯੁਕਤ ਬਾਈਪਾਸ — ਇੱਕ ਬੇਨਤੀ ਜਿਸ ਵਿੱਚ ਗੈਰ-ਖਾਲੀ tools ਐਰੇ ਹੋਵੇ ਅਤੇ tool_choice ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ "none" ਨਾ ਹੋਵੇ, ਪੈਨਲ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੰਦੀ ਹੈ: ਇਹ tools/tool_choice ਨੂੰ ਬਿਨਾਂ ਤਬਦੀਲੀ ਅੱਗੇ ਭੇਜਦੇ ਹੋਏ ਸਿੱਧੀ ਇੱਕ ਮਾਡਲ (ਸੰਰਚਿਤ ਜੱਜ, ਜਾਂ panel[0]) ਵੱਲ ਰੂਟ ਹੁੰਦੀ ਹੈ। ਪੈਨਲ ਮੈਂਬਰਾਂ ਕੋਲ ਟੂਲ ਪਹੁੰਚ ਨਹੀਂ ਹੁੰਦੀ ਅਤੇ ਜੱਜ ਦਾ ਸੰਸਲੇਸ਼ਣ ਨਿਰਦੇਸ਼ ਟੂਲ-ਕਾਲ ਬਣਾਉਣ ਤੋਂ ਵਰਜਦਾ ਹੈ, ਇਸ ਲਈ ਏਜੈਂਟਿਕ/ਟੂਲ-ਕਾਲਿੰਗ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸੰਸਲੇਸ਼ਿਤ ਗੱਦ ਦੀ ਥਾਂ ਇੱਕ ਅਸਲ ਟੂਲ-ਕਾਲ ਫ਼ੈਸਲਾ ਮਿਲਦਾ ਹੈ (#6771)।
  2. ਫੈਨ-ਆਉਟ (ਸਿਰਫ਼ ਟੂਲ-ਰਹਿਤ ਬੇਨਤੀਆਂ) — ਪ੍ਰੌਂਪਟ ਇੱਕੋ ਸਮੇਂ ਹਰੇਕ ਪੈਨਲ ਮਾਡਲ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਟੂਲਾਂ ਨੂੰ ਹਟਾ ਕੇ ਨਾਨ-ਸਟ੍ਰੀਮਿੰਗ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜੱਜ ਨੂੰ ਸੰਸਲੇਸ਼ਣ ਲਈ ਪੂਰਾ ਗੱਦ ਚਾਹੀਦਾ ਹੈ)।
  3. ਕੋਰਮ-ਗ੍ਰੇਸ ਇਕੱਤਰੀਕਰਨ — ਜਿਵੇਂ ਹੀ minPanel ਜਵਾਬ ਆ ਜਾਂਦੇ ਹਨ, ਪਿੱਛੇ ਰਹਿ ਗਏ ਮਾਡਲਾਂ ਲਈ ਇੱਕ ਛੋਟਾ ਗ੍ਰੇਸ ਟਾਈਮਰ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਜੋ ਵੀ ਇਕੱਠਾ ਹੋਇਆ ਹੋਵੇ ਉਸ ਨਾਲ ਫਿਊਜ਼ਨ ਅੱਗੇ ਵਧਦੀ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਹੌਲੀ ਮਾਡਲ ਕਾਰਨ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਹੋਣ ਵਾਲੀ ਦੇਰੀ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਉੱਤੇ ਇੱਕ ਹਾਰਡ ਟਾਈਮਆਉਟ ਦੀ ਹੱਦ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
  4. ਜੱਜ ਸੰਸਲੇਸ਼ਣ — ਪੈਨਲ ਜਵਾਬਾਂ ਨੂੰ ਅਗਿਆਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (Source 1, Source 2, … — ਤਾਂ ਜੋ ਜੱਜ ਮਾਡਲ ਬ੍ਰਾਂਡ ਦੀ ਬਜਾਏ ਸਮੱਗਰੀ ਨੂੰ ਮਹੱਤਤਾ ਦੇਵੇ) ਅਤੇ ਜੱਜ ਨੂੰ ਸੌਂਪਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਸਹਿਮਤੀ / ਵਿਰੋਧਾਭਾਸ / ਅੰਸ਼ਕ ਕਵਰੇਜ / ਵਿਲੱਖਣ ਅੰਤਰਦ੍ਰਿਸ਼ਟੀਆਂ / ਅਣਡਿੱਠੇ ਪੱਖਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ, ਫਿਰ ਇੱਕ ਪ੍ਰਮਾਣਿਕ ਜਵਾਬ ਲਿਖਦਾ ਹੈ। ਜੱਜ ਕਾਲ ਕਲਾਇੰਟ ਦੇ ਮੂਲ stream ਫਲੈਗ + ਟੂਲਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਦੀ ਹੈ, ਇਸ ਲਈ ਸਟ੍ਰੀਮਿੰਗ ਅਤੇ ਡਾਊਨਸਟ੍ਰੀਮ ਟੂਲ ਵਰਤੋਂ ਫਿਰ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ।
  5. ਸੁਚਾਰੂ ਡਿਗਰੇਡੇਸ਼ਨ — 0 ਪੈਨਲ ਜਵਾਬ → 503; ਸਿਰਫ਼ 1 ਬਚਿਆ ਜਵਾਬ → ਉਹ ਜਵਾਬ ਸਿੱਧਾ ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਫਿਊਜ਼ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ); ਇੱਕ-ਮਾਡਲ ਪੈਨਲ ਸਿੱਧਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ਕੋਈ ਪੈਨਲ ਮੈਂਬਰ ਇੱਕ combo-ref ਪੜਾਅ ({kind: "combo-ref", comboName: "..."}) ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਕਿਸੇ ਹੋਰ ਕੌਂਬੋ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ — ਇਹ ਇੱਕ ਬਲੈਕ-ਬਾਕਸ ਪੈਨਲ ਆਵਾਜ਼ ਵਜੋਂ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੈ (ਹਵਾਲਾ ਦਿੱਤੇ ਕੌਂਬੋ ਵਿੱਚ ਪੂਰਾ ਰਿਕਰਸਿਵ ਡਿਸਪੈਚ, ਨਾ ਕਿ ਉਸ ਕੌਂਬੋ ਦੇ ਆਪਣੇ ਟਾਰਗੇਟਾਂ ਦਾ ਫੈਨ-ਆਉਟ), ਅਤੇ ਇਸ ਵਿੱਚ ਉਹੀ ਡੈਪਥ/ਸਾਈਕਲ ਸੁਰੱਖਿਆ ਹੁੰਦੀ ਹੈ ਜੋ ਹਰ ਦੂਜੀ combo-ref ਵਰਤਣ ਵਾਲੀ ਰਣਨੀਤੀ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੀ ਹੈ (#6764)।

ਸੰਰਚਨਾ

ਕੌਂਬੋ ਦੇ config ਬਲੌਬ ਉੱਤੇ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਕਿਸੇ ਸਕੀਮਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ — ਇਹ ਮੌਜੂਦਾ combos ਟੇਬਲ ਨੂੰ ਮੁੜ ਵਰਤਦਾ ਹੈ):

ਫ਼ੀਲਡ ਕਿਸਮ ਡਿਫੌਲਟ ਉਦੇਸ਼
config.judgeModel string ਪਹਿਲਾ ਪੈਨਲ ਮਾਡਲ ਅੰਤਿਮ ਜਵਾਬ ਦਾ ਸੰਸਲੇਸ਼ਣ ਕਰਨ ਵਾਲਾ ਮਾਡਲ
config.fusionTuning.minPanel number 2 ਗ੍ਰੇਸ ਟਾਈਮਰ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜੀਂਦੇ ਸਫਲ ਜਵਾਬ ([2, panelSize] ਤੱਕ ਸੀਮਿਤ)
config.fusionTuning.stragglerGraceMs number 8000 ਕੋਰਮ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪਿੱਛੇ ਰਹਿ ਗਏ ਮਾਡਲਾਂ ਲਈ ਕਿੰਨਾ ਸਮਾਂ ਉਡੀਕ ਕਰਨੀ ਹੈ
config.fusionTuning.panelHardTimeoutMs number 90000 ਪੂਰਨ ਸੀਮਾ ਤਾਂ ਜੋ ਇੱਕ ਅਟਕਿਆ ਹੋਇਆ ਮਾਡਲ ਬੇਨਤੀ ਨੂੰ ਰੋਕ ਨਾ ਸਕੇ

ਡਿਫੌਲਟ FUSION_DEFAULTS (open-sse/services/fusion.ts) ਵਿੱਚ ਮੌਜੂਦ ਹਨ।

ਉਦਾਹਰਨ

curl -X POST http://localhost:20128/api/combos \
  -H "Authorization: Bearer <key>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "fusion-panel",
    "strategy": "fusion",
    "targets": [
      { "model": "cc/claude-opus-4-7" },
      { "model": "cx/gpt-5.5" },
      { "model": "glm/glm-5.1" }
    ],
    "config": {
      "judgeModel": "cc/claude-opus-4-7",
      "fusionTuning": { "minPanel": 2, "stragglerGraceMs": 8000, "panelHardTimeoutMs": 90000 }
    }
  }'

ਫਿਰ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਕੌਂਬੋ ਵਾਂਗ ਕਾਲ ਕਰੋ: {"model":"fusion-panel","messages":[...]}।

ਵਰਚੁਅਲ ਆਟੋ-ਕੌਂਬੋ ਫੈਕਟਰੀ

ਆਟੋ ਕੌਂਬੋ ਇੰਜਣ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੌਂਬੋਆਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਦੀ ਬਜਾਏ, open-sse/services/autoCombo/virtualFactory.ts ਤੁਰੰਤ ਉਮੀਦਵਾਰ ਬਣਾਉਂਦੀ ਹੈ:

  1. getProviderConnections({ isActive: true }) ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ (ਸਾਰੇ ਸਮਰੱਥ ਕੀਤੇ ਕਨੈਕਸ਼ਨ)
  2. ਵੈਧ ਕ੍ਰੈਡੈਂਸ਼ਲਾਂ ਵਾਲਿਆਂ ਤੱਕ ਫਿਲਟਰ ਕਰਦੀ ਹੈ (API ਕੁੰਜੀ ਜਾਂ hasUsableOAuthToken() ਰਾਹੀਂ ਮਿਆਦ ਨਾ ਪੁੱਗਿਆ OAuth ਟੋਕਨ)
  3. ਮਾਡਲ ਉਪਲਬਧਤਾ + ਕੀਮਤ ਲਈ getProviderRegistry() ਨਾਲ ਕਰਾਸ-ਰੈਫਰੈਂਸ ਕਰਦੀ ਹੈ
  4. ਹਰੇਕ ਟਿਊਪਲ (provider, model, connection) ਲਈ, ਇੱਕ VirtualAutoComboCandidate ਬਣਾਉਂਦੀ ਹੈ
  5. ਡਿਸਪੈਚ ਟਾਰਗੇਟ ਵਜੋਂ connection.defaultModel (ਜਾਂ ਰਜਿਸਟਰੀ ਦਾ ਪਹਿਲਾ ਮਾਡਲ) ਚੁਣਦੀ ਹੈ
  6. 16-ਫੈਕਟਰ scorePool() ਅਤੇ ਵੇਰੀਐਂਟ ਦੇ ਵੇਟ ਪੈਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਰੇਕ ਉਮੀਦਵਾਰ ਨੂੰ ਸਕੋਰ ਦਿੰਦੀ ਹੈ
  7. handleComboChat() ਲਈ ਨਤੀਜੇ ਵਜੋਂ ਬਣਿਆ ਇਨ-ਮੈਮਰੀ AutoComboConfig ਵਾਪਸ ਕਰਦੀ ਹੈ — ਇਸਨੂੰ ਕਦੇ ਵੀ DB ਵਿੱਚ ਸਥਾਈ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ auto/* ਸਮਰੱਥ ਕਿਸੇ ਨਵੇਂ ਪ੍ਰਦਾਤਾ ਨੂੰ ਜੋੜਨ ਨਾਲ ਉਮੀਦਵਾਰ ਪੂਲ ਆਪਣੇ ਆਪ ਵਿਸਤਾਰਿਤ ਹੋ ਜਾਂਦਾ ਹੈ — ਕੌਂਬੋ ਨੂੰ ਹੱਥੀਂ ਸੰਪਾਦਿਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਵਰਚੁਅਲ ਕੌਂਬੋ ਹਰ ਬੇਨਤੀ ਲਈ ਦੁਬਾਰਾ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਨਵੇਂ ਜੋੜੇ ਗਏ ਜਾਂ ਹੁਣੇ-ਹੁਣੇ ਸਿਹਤਮੰਦ ਹੋਏ ਕਨੈਕਸ਼ਨ ਤੁਰੰਤ ਵਰਤ ਲਏ ਜਾਂਦੇ ਹਨ।

ਸਵੈ-ਮੁਰੰਮਤ

  • ਅਸਥਾਈ ਬਾਹਰਕੱਢਣਾ: ਸਕੋਰ < 0.2 → 5 ਮਿੰਟ ਲਈ ਬਾਹਰ (ਪ੍ਰਗਤੀਸ਼ੀਲ ਬੈਕਆਫ਼, ਵੱਧ ਤੋਂ ਵੱਧ 30 ਮਿੰਟ)
  • ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਜਾਗਰੂਕਤਾ: OPEN → ਆਪਣੇ ਆਪ ਬਾਹਰ; HALF_OPEN → ਜਾਂਚ ਬੇਨਤੀਆਂ
  • ਘਟਨਾ ਮੋਡ: >50% OPEN → ਖੋਜ ਬੰਦ ਕਰੋ, ਸਥਿਰਤਾ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰੋ
  • ਕੂਲਡਾਊਨ ਰਿਕਵਰੀ: ਬਾਹਰਕੱਢਣ ਤੋਂ ਬਾਅਦ, ਪਹਿਲੀ ਬੇਨਤੀ ਘਟਾਏ ਹੋਏ ਟਾਈਮਆਊਟ ਨਾਲ ਇੱਕ "ਜਾਂਚ" ਹੁੰਦੀ ਹੈ

ਬੈਂਡਿਟ ਖੋਜ

5% ਬੇਨਤੀਆਂ (ਕਨਫਿਗਰ ਕਰਨ ਯੋਗ) ਖੋਜ ਲਈ ਬੇਤਰਤੀਬ ਪ੍ਰਦਾਤਾਵਾਂ ਵੱਲ ਰੂਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਘਟਨਾ ਮੋਡ ਵਿੱਚ ਇਹ ਬੰਦ ਰਹਿੰਦੀ ਹੈ।

API

ਕੋਈ ਸਮਰਪਿਤ POST /api/combos/auto ਐਂਡਪੌਇੰਟ ਨਹੀਂ ਹੈ — ਆਟੋ-ਕੌਂਬੋ ਨੂੰ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ:

  1. ਜ਼ੀਰੋ-ਕਨਫਿਗ (ਸਿਫ਼ਾਰਸ਼ੀ): model: "auto" ਜਾਂ model: "auto/<variant>" ਨਾਲ ਕੋਈ ਵੀ ਚੈਟ ਕੰਪਲੀਸ਼ਨ ਬੇਨਤੀ ਭੇਜੋ। ਵਰਚੁਅਲ ਫੈਕਟਰੀ ਹਰ ਬੇਨਤੀ ਲਈ ਕੌਂਬੋ ਬਣਾਉਂਦੀ ਹੈ — ਨਾ ਕੋਈ ਸਥਾਈ ਸਟੋਰੇਜ, ਨਾ ਹੀ API ਕਾਲਾਂ ਦੀ ਲੋੜ।

  2. strategy: "auto" ਵਾਲਾ ਸਥਾਈ ਕੌਂਬੋ: POST /api/combos ਰਾਹੀਂ ਇੱਕ ਨਿਯਮਤ ਕੌਂਬੋ ਬਣਾਓ ਅਤੇ strategy: "auto" ਦੇ ਨਾਲ config.auto.weights / config.auto.candidatePool ਸੈੱਟ ਕਰੋ। ਉਹੀ ਸਕੋਰਿੰਗ ਇੰਜਣ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ; ਕੌਂਬੋ combos ਵਿੱਚ ਸਟੋਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ID ਰਾਹੀਂ ਮੁੜ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਖੋਜ ਲਈ, GET /api/combos/auto ਹਰੇਕ ਵੇਰੀਐਂਟ ਨੂੰ ਉਸਦੇ ਹੱਲ ਕੀਤੇ ਉਮੀਦਵਾਰ ਪੂਲ ਦੇ ਨਾਲ, ਅਤੇ context_length / max_output_tokens ਸਮੇਤ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ — ਇਹ ਉਮੀਦਵਾਰ ਪੂਲ ਦੀਆਂ ਵਿੰਡੋਆਂ ਵਿੱਚੋਂ MAX ਹੁੰਦਾ ਹੈ। ਕਲਾਇੰਟਾਂ (ਉਦਾਹਰਨ ਵਜੋਂ opencode ਪਲੱਗਇਨ) ਨੂੰ 0 ਦੀ ਬਜਾਏ ਇਹ ਮੁੱਲ ਪ੍ਰਚਾਰਿਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ: ਸਿਫ਼ਰ ਕਾਂਟੈਕਸਟ opencode ਦੀ ਆਟੋ-ਕੰਪੈਕਸ਼ਨ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸੈਸ਼ਨ ਉਦੋਂ ਤੱਕ ਵਧਦੇ ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਗੇਟਵੇ ਦੀ ਹਿਸਟਰੀ ਪਰਜ ਕਾਂਟੈਕਸਟ ਨੂੰ ਨਸ਼ਟ ਨਹੀਂ ਕਰ ਦਿੰਦੀ। MAX ਨੂੰ ਪ੍ਰਚਾਰਿਤ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੈ, ਕਿਉਂਕਿ ਆਟੋ-ਕੌਂਬੋ ਕਾਂਟੈਕਸਟ ਪ੍ਰੀ-ਫਿਲਟਰ ਵੱਧ ਆਕਾਰ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਵੱਡੀ-ਵਿੰਡੋ ਵਾਲੇ ਉਮੀਦਵਾਰਾਂ ਵੱਲ ਰੂਟ ਕਰਦਾ ਹੈ।

# ਜ਼ੀਰੋ-ਕਨਫਿਗ ਵਰਤੋਂ (ਕੌਂਬੋ ਬਣਾਉਣ ਤੋਂ ਬਿਨਾਂ)
curl -X POST http://localhost:20128/v1/chat/completions \
  -H "Authorization: Bearer <key>" \
  -H "Content-Type: application/json" \
  -d '{"model":"auto/coding","messages":[{"role":"user","content":"Hello"}]}'

# ਨਿਯਮਤ ਕੌਂਬੋ ਐਂਡਪੌਇੰਟ ਰਾਹੀਂ ਸਥਾਈ ਆਟੋ ਕੌਂਬੋ
curl -X POST http://localhost:20128/api/combos \
  -H "Content-Type: application/json" \
  -d '{"id":"my-auto","name":"Auto Coder","strategy":"auto","config":{"auto":{"candidatePool":["anthropic","google","openai"],"weights":{"quota":0.15,"health":0.3,"costInv":0.05,"latencyInv":0.35,"taskFit":0.1,"stability":0,"tierPriority":0.05}}}}'

ਆਟੋ ਰਾਊਟਰ ਰਣਨੀਤੀਆਂ

ਸਥਾਈ strategy: "auto" ਕੌਂਬੋ config.routerStrategy (ਜਾਂ ਪੁਰਾਤਨ config.auto.routerStrategy) ਨੂੰ ਹੇਠਾਂ ਦਿੱਤਿਆਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ 'ਤੇ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹਨ:

  • rules — ਮੂਲ ਵੇਟਿਡ ਸਕੋਰਿੰਗ
  • score — ਸਭ ਤੋਂ ਉੱਚਾ ਕਨਫਿਗਰ ਕੀਤਾ ਵੇਟਿਡ ਸਕੋਰ ਚੁਣਦਾ ਹੈ। ਬਿਲਕੁਲ ਬਰਾਬਰ ਸਕੋਰ ਹੋਣ 'ਤੇ ਕਨਫਿਗਰ ਕੀਤਾ ਉਮੀਦਵਾਰ ਕ੍ਰਮ ਬਰਕਰਾਰ ਰਹਿੰਦਾ ਹੈ; ਮੌਜੂਦਾ explorationRate ਪੂਰੇ ਰੈਂਕ ਕੀਤੇ ਪੂਲ ਵਿੱਚੋਂ ਨਮੂਨਾ ਚੁਣਦਾ ਹੈ।
  • cost / eco — ਸਭ ਤੋਂ ਸਸਤਾ ਸਿਹਤਮੰਦ ਪ੍ਰਦਾਤਾ
  • latency / fast — ਭਰੋਸੇਯੋਗਤਾ ਪੈਨਲਟੀ ਨਾਲ ਸਭ ਤੋਂ ਘੱਟ p95 ਲੇਟੈਂਸੀ
  • sla-aware / sla — ਉਹਨਾਂ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ p95 ਲੇਟੈਂਸੀ, ਗਲਤੀ ਦਰ ਅਤੇ ਵਿਕਲਪਿਕ ਲਾਗਤ SLOs ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ
  • lkgp — ਆਖਰੀ ਜਾਣਿਆ ਚੰਗਾ ਪ੍ਰਦਾਤਾ ਪਹਿਲਾਂ

ਰਾਊਟਰ ਰਣਨੀਤੀਆਂ ਦਾ ਵਿਸਤਾਰ

ਆਟੋ-ਕੌਂਬੋ ਇੰਜਣ 6 ਪਲੱਗ ਕਰਨ ਯੋਗ RouterStrategy ਲਾਗੂਕਰਨ ਉਪਲਬਧ ਕਰਵਾਉਂਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ config.routerStrategy (ਜਾਂ ਪੁਰਾਤਨ config.auto.routerStrategy) ਰਾਹੀਂ ਬਦਲ ਸਕਦੇ ਹੋ। ਹਰੇਕ ਰਣਨੀਤੀ ਇੱਕ RoutingContext ਦਿੱਤੇ ਜਾਣ 'ਤੇ ਉਮੀਦਵਾਰ ਪੂਲ ਵਿੱਚੋਂ ਇੱਕ ਪ੍ਰਦਾਤਾ ਚੁਣਦੀ ਹੈ (ਟਾਸਕ ਕਿਸਮ, ਟੂਲ/ਵਿਜ਼ਨ ਸੰਕੇਤ, ਟੋਕਨ ਅਨੁਮਾਨ, ਵਿਕਲਪਿਕ SLA ਨੀਤੀ, ਵਿਕਲਪਿਕ ਆਖਰੀ-ਜਾਣਿਆ-ਚੰਗਾ ਪ੍ਰਦਾਤਾ)।

1. rules (ਮੂਲ) — 16-ਫੈਕਟਰ ਵੇਟਿਡ ਸਕੋਰਿੰਗ

ਮੌਜੂਦਾ ਸਕੋਰਿੰਗ ਇੰਜਣ ਨੂੰ ਰੈਪ ਕਰਦਾ ਹੈ। OPEN ਸਰਕਿਟ-ਬ੍ਰੇਕਰ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਬਾਹਰ ਕਰਦਾ ਹੈ, ਫਿਰ ਮੌਜੂਦਾ ਟਾਸਕ ਕਿਸਮ ਅਤੇ getTaskFitness() ਨਾਲ scorePool() ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਵੱਧ ਸਕੋਰ ਵਾਲਾ ਪ੍ਰਦਾਤਾ ਚੁਣਦਾ ਹੈ।

class RulesStrategyImpl implements RouterStrategy {
  readonly name = "rules";
  readonly description = "16-factor weighted scoring (see DEFAULT_WEIGHTS)";

  select(pool, context) {
    const eligible = pool.filter((c) => c.circuitBreakerState !== "OPEN");
    const ranked = scorePool(
      eligible.length > 0 ? eligible : pool,
      context.taskType,
      undefined,
      getTaskFitness
    );
    return { provider: ranked[0].provider /* ... */ };
  }
}

ਕਦੋਂ ਵਰਤਣਾ ਹੈ: ਮੂਲ। ਜਦੋਂ ਤੁਸੀਂ ਸਾਰੇ ਸੰਕੇਤਾਂ ਵਿਚਕਾਰ ਸੰਤੁਲਿਤ ਸਮਝੌਤਾ ਚਾਹੁੰਦੇ ਹੋ, ਉਦੋਂ ਵਰਤੋ।

ਉਪਨਾਮ: rules (ਕੋਈ ਉਪਨਾਮ ਨਹੀਂ)

2. cost / eco — ਸਭ ਤੋਂ ਸਸਤਾ ਸਿਹਤਮੰਦ ਪ੍ਰਦਾਤਾ

ਉਮੀਦਵਾਰ ਪੂਲ ਨੂੰ costPer1MTokens (ਵਧਦੇ ਕ੍ਰਮ ਵਿੱਚ) ਅਨੁਸਾਰ ਲੜੀਬੱਧ ਕਰਦਾ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਸਸਤਾ ਚੁਣਦਾ ਹੈ। ਪਹਿਲਾਂ OPEN ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਬਾਹਰ ਕਰਦਾ ਹੈ।

class CostStrategyImpl implements RouterStrategy {
  readonly name = "cost";
  readonly description = "Always selects cheapest available provider";

  select(pool, context) {
    const healthy = pool.filter((c) => c.circuitBreakerState !== "OPEN");
    const sorted = [...healthy].sort((a, b) => a.costPer1MTokens - b.costPer1MTokens);
    return { provider: sorted[0].provider /* ... */ };
  }
}

ਕਦੋਂ ਵਰਤਣਾ ਹੈ: ਲਾਗਤ-ਸੰਵੇਦਨਸ਼ੀਲ ਵਰਕਲੋਡਾਂ, ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਾਂ ਲਈ।

ਉਪਨਾਮ: cost, eco

3. latency / fast — ਭਰੋਸੇਯੋਗਤਾ ਪੈਨਲਟੀ ਨਾਲ ਸਭ ਤੋਂ ਘੱਟ p95 ਲੇਟੈਂਸੀ

p95LatencyMs + (errorRate * 1000) ਅਨੁਸਾਰ ਕ੍ਰਮਬੱਧ ਕਰਦਾ ਹੈ। ਗਲਤੀ-ਦਰ ਦੀ ਪੈਨਲਟੀ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਗੈਰ-ਭਰੋਸੇਯੋਗ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਹੇਠਾਂ ਦਰਜਾ ਦਿੱਤਾ ਜਾਵੇ, ਭਾਵੇਂ ਉਨ੍ਹਾਂ ਦੀ ਨਾਮਾਤਰ ਲੇਟੈਂਸੀ ਘੱਟ ਹੋਵੇ।

class LatencyStrategyImpl implements RouterStrategy {
  readonly name = "latency";
  readonly description = "Prioritizes lowest p95 latency with reliability weighting";

  select(pool, context) {
    const healthy = pool.filter((c) => c.circuitBreakerState !== "OPEN");
    const sorted = [...healthy].sort(
      (a, b) => a.p95LatencyMs + a.errorRate * 1000 - (b.p95LatencyMs + b.errorRate * 1000)
    );
    return { provider: sorted[0].provider /* ... */ };
  }
}

ਕਦੋਂ ਵਰਤਣਾ ਹੈ: ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਵਰਕਲੋਡ, ਜਿਵੇਂ ਕਿ ਰੀਅਲ-ਟਾਈਮ ਚੈਟ, ਆਟੋਕੰਪਲੀਟ, ਜਾਂ ਇੰਟਰਐਕਟਿਵ ਕੋਡਿੰਗ ਸਹਾਇਕ।

ਉਪਨਾਮ: latency, fast

4. sla-aware / sla — ਲੇਟੈਂਸੀ/ਗਲਤੀ/ਲਾਗਤ SLO ਦੀ ਪਾਲਣਾ

ਹਰੇਕ ਉਮੀਦਵਾਰ ਨੂੰ ਇਸ ਆਧਾਰ 'ਤੇ ਸਕੋਰ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹ ਸੰਰਚਿਤ SLO ਨੀਤੀ ਨੂੰ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪੂਰਾ ਕਰਦਾ ਹੈ:

ਕਾਰਕ ਭਾਰ ਫਾਰਮੂਲਾ
ਲੇਟੈਂਸੀ ਸਕੋਰ 35% threshold / max(value, ε)
ਗਲਤੀ ਸਕੋਰ 35% threshold / max(value, ε)
ਸਿਹਤ ਸਕੋਰ 15% 1.0 (CLOSED) / 0.5 (HALF_OPEN) / 0.0 (OPEN)
ਲਾਗਤ ਸਕੋਰ 10% threshold / max(value, ε) ਜਾਂ ਉਲਟ ਨਾਰਮਲਾਈਜ਼ਡ
ਸਥਿਰਤਾ ਸਕੋਰ 5% ਉਲਟ ਨਾਰਮਲਾਈਜ਼ਡ ਲੇਟੈਂਸੀ ਮਿਆਰੀ ਵਿਛੱਲਣ

ਜਦੋਂ hardConstraints: true ਹੋਵੇ, ਤਾਂ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਲੰਘਣਾ ਸਕੋਰ (ਉਹ ਕਿਸੇ ਵੀ SLO ਤੋਂ ਕਿੰਨਾ ਵੱਧ ਜਾਂਦੇ ਹਨ) ਅਨੁਸਾਰ ਅਤੇ ਫਿਰ ਸੰਯੁਕਤ ਸਕੋਰ ਅਨੁਸਾਰ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ ਸਿਰਫ਼ ਸੰਯੁਕਤ ਸਕੋਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

class SLAStrategyImpl implements RouterStrategy {
  readonly name = "sla-aware";
  readonly description =
    "Selects the provider most likely to satisfy latency, error-rate, and cost SLOs";

  select(pool, context) {
    // ... ਨੀਤੀ ਦੇ ਮੁਕਾਬਲੇ ਹਰੇਕ ਉਮੀਦਵਾਰ ਨੂੰ ਸਕੋਰ ਦਿੰਦਾ ਹੈ: { targetP95Ms, maxErrorRate, maxCostPer1MTokens, hardConstraints }
  }
}

SLA ਖੇਤਰ (ਕੌਂਬੋ ਸੰਰਚਨਾ ਵਿੱਚ ਸੈੱਟ ਕਰੋ):

{
  "strategy": "auto",
  "config": {
    "routerStrategy": "sla-aware",
    "slaTargetP95Ms": 1500,
    "slaMaxErrorRate": 0.05,
    "slaMaxCostPer1MTokens": 5,
    "slaHardConstraints": true
  }
}

ਕਦੋਂ ਵਰਤਣਾ ਹੈ: ਸਖ਼ਤ ਲੇਟੈਂਸੀ, ਗਲਤੀ-ਦਰ, ਜਾਂ ਲਾਗਤ ਬਜਟ ਵਾਲੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਕਲੋਡ।

ਉਪਨਾਮ: sla-aware, sla

5. lkgp — ਆਖਰੀ ਜਾਣਿਆ ਚੰਗਾ ਪ੍ਰਦਾਤਾ ਪਹਿਲਾਂ

ਪਹਿਲਾਂ ਆਖਰੀ ਜਾਣੇ ਚੰਗੇ ਪ੍ਰਦਾਤਾ ਨੂੰ ਅਜ਼ਮਾਉਂਦਾ ਹੈ (ਜੇ ਸੈੱਟ ਕੀਤਾ ਹੋਵੇ), ਫਿਰ rules ਰਣਨੀਤੀ 'ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ। ਸੈਸ਼ਨ ਸਟਿੱਕੀਨੈੱਸ ਲਈ ਲਾਭਦਾਇਕ — ਇੱਕੋ ਪ੍ਰਦਾਤਾ ਗੱਲਬਾਤ ਵਿੱਚ ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।

class LKGPStrategyImpl implements RouterStrategy {
  readonly name = "lkgp";
  readonly description = "Tries last known good provider first, then falls back to rules";

  select(pool, context) {
    if (context.lkgpEnabled === false) {
      return getStrategy("rules").select(pool, context);
    }

    if (context.lastKnownGoodProvider) {
      const candidates = pool.filter(
        (c) => c.provider === context.lastKnownGoodProvider && c.circuitBreakerState !== "OPEN"
      );
      if (candidates.length > 0) {
        return { provider: candidates[0].provider /* ... */ };
      }
    }

    // ਨਿਯਮ ਰਣਨੀਤੀ 'ਤੇ ਵਾਪਸ ਜਾਓ
    return getStrategy("rules").select(pool, context);
  }
}

ਕਦੋਂ ਵਰਤਣਾ ਹੈ: ਬਹੁ-ਵਾਰੀ ਗੱਲਬਾਤਾਂ, ਜਿੱਥੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇੱਕੋ ਪ੍ਰਦਾਤਾ ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲੇ (ਉਦਾਹਰਨ ਲਈ, ਕੈਸ਼ਿੰਗ, ਸੰਦਰਭ ਨਿਰੰਤਰਤਾ, ਜਾਂ ਕੀਮਤ ਇਕਸਾਰਤਾ ਲਈ)।

ਉਪਨਾਮ: lkgp (ਕੋਈ ਉਪਨਾਮ ਨਹੀਂ)

ਕਸਟਮ ਰਾਊਟਰ ਰਣਨੀਤੀਆਂ

ਤੁਸੀਂ ਪਬਲਿਕ API ਰਾਹੀਂ ਆਪਣੀ ਖੁਦ ਦੀ RouterStrategy ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਰਜਿਸਟਰ ਕਰ ਸਕਦੇ ਹੋ:

import {
  registerStrategy,
  type RouterStrategy,
} from "@omniroute/open-sse/services/autoCombo/routerStrategy";

class MyCustomStrategy implements RouterStrategy {
  readonly name = "my-custom";
  readonly description = "My custom routing strategy";

  select(pool, context) {
    // ਤੁਹਾਡਾ ਰਾਊਟਿੰਗ ਤਰਕ ਇੱਥੇ
    return {
      provider: pool[0].provider,
      model: pool[0].model,
      strategy: this.name,
      reason: "MyCustomStrategy: ...",
      candidatesConsidered: pool.length,
      finalScore: 1.0,
    };
  }
}

registerStrategy("my-custom", new MyCustomStrategy());

ਫਿਰ ਇਸਨੂੰ ਵਰਤੋ:

{
  "strategy": "auto",
  "config": {
    "routerStrategy": "my-custom"
  }
}

ਰਾਊਟਰ ਰਣਨੀਤੀ ਚੋਣ ਗਾਈਡ

ਵਰਤੋਂ ਦਾ ਮਾਮਲਾ ਰਣਨੀਤੀ ਕਾਰਨ
ਸੰਤੁਲਿਤ ਵਰਕਲੋਡ rules ਡਿਫੌਲਟ — ਸਾਰੇ ਕਾਰਕਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ
ਲਾਗਤ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰੋ cost ਹਮੇਸ਼ਾਂ ਸਭ ਤੋਂ ਸਸਤਾ ਚੁਣਦਾ ਹੈ
ਲੇਟੈਂਸੀ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰੋ latency ਸਭ ਤੋਂ ਤੇਜ਼ ਭਰੋਸੇਯੋਗ ਪ੍ਰਦਾਤਾ ਚੁਣਦਾ ਹੈ
ਸਖ਼ਤ SLO sla-aware p95/ਗਲਤੀ/ਲਾਗਤ ਥ੍ਰੈਸ਼ਹੋਲਡਾਂ ਅਨੁਸਾਰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ
ਬਹੁ-ਵਾਰੀ ਚੈਟ lkgp ਸੈਸ਼ਨ ਸਟਿੱਕੀਨੈੱਸ

SLA-ਅਵੇਅਰ ਖੇਤਰ:

{
  "strategy": "auto",
  "config": {
    "routerStrategy": "sla-aware",
    "slaTargetP95Ms": 1500,
    "slaMaxErrorRate": 0.05,
    "slaMaxCostPer1MTokens": 5,
    "slaHardConstraints": true
  }
}

ਟਾਸਕ ਅਨੁਕੂਲਤਾ

6 ਟਾਸਕ ਕਿਸਮਾਂ (coding, review, planning, analysis, debugging, documentation) ਵਿੱਚ 30+ ਮਾਡਲਾਂ ਨੂੰ ਸਕੋਰ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਵਾਈਲਡਕਾਰਡ ਪੈਟਰਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, *-coder → ਉੱਚ coding ਸਕੋਰ)।

Auto ਵੇਰੀਐਂਟਾਂ ਦਾ ਸੰਖੇਪ

ਮੂਲ auto (ਡਿਫੌਲਟ) ਸਮੇਤ ਅਤੇ autoPrefix.ts ਵਿੱਚ ਘੋਸ਼ਿਤ 6 AutoVariant ਮੁੱਲਾਂ ਨੂੰ ਜੋੜ ਕੇ, ਕੁੱਲ 7 ਵਰਤੋਂਯੋਗ ਮਾਡਲ IDs ਹਨ:

auto, auto/coding, auto/fast, auto/cheap, auto/offline, auto/smart, auto/lkgp

(AutoVariant ਖੁਦ 6 ਮੁੱਲ ਦਰਸਾਉਂਦਾ ਹੈ; 7ਵਾਂ ਵਿਕਲਪ "ਕੋਈ ਵੇਰੀਐਂਟ ਨਹੀਂ" ਹੈ — ਮੂਲ auto — ਜਿਸਨੂੰ parseAutoPrefix() ਵੱਲੋਂ variant: undefined ਵਜੋਂ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ।)

ਟੀਅਰ Auto-Combo ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦੇ ਹਨ

16-ਫੈਕਟਰ ਸਕੋਰਿੰਗ ਫੰਕਸ਼ਨ (open-sse/services/autoCombo/scoring.ts) ਟੀਅਰ ਮੈਂਬਰਸ਼ਿਪ ਨੂੰ ਦੋ ਸੰਕੇਤਾਂ ਵਜੋਂ ਮੰਨਦਾ ਹੈ: tierPriority (0.0476) ਅਤੇ tierAffinity (0.0476)। ਪੂਰੇ DEFAULT_WEIGHTS ਸੈੱਟ ਲਈ ਉੱਪਰ ਦਿੱਤੀ ਮਿਆਰੀ ਸਕੋਰਿੰਗ ਫੈਕਟਰ ਸਾਰਣੀ ਵੇਖੋ — ਹਰ ਪੈਕ ਲਈ ਓਵਰਰਾਈਡ (ship-fast/cost-saver/quality-first/ offline-friendly) "ਹਰ ਪੈਕ ਲਈ ਵੇਟ ਪ੍ਰੋਫਾਈਲਾਂ" ਸਾਰਣੀ ਵਿੱਚ ਦਿੱਤੇ ਗਏ ਹਨ।

ਸਿਰਫ਼ ਟੀਅਰ ਹੀ Tier 1 ਨੂੰ ਪਹਿਲਾਂ ਚੁਣਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦਾ — ਜੇ Tier 1 ਦੀ ਲੇਟੈਂਸੀ ਮਾੜੀ ਹੋਵੇ ਜਾਂ ਲਾਗਤ-ਬਨਾਮ-ਗੁਣਵੱਤਾ ਉਚਿਤ ਨਾ ਹੋਵੇ, ਤਾਂ Tier 2 ਜਿੱਤਦਾ ਹੈ। ਟੀਅਰ ਕ੍ਰਮ ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਉਣ ਲਈ, ਕੌਂਬੋ ਰਣਨੀਤੀ priority ਵਰਤੋ ਅਤੇ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਟੀਅਰ ਅਨੁਸਾਰ ਵਿਵਸਥਿਤ ਕਰੋ।

Tier 1 (ਸਬਸਕ੍ਰਿਪਸ਼ਨ) ਨੂੰ ਮਜ਼ਬੂਤੀ ਨਾਲ ਤਰਜੀਹ ਦੇਣ ਲਈ, tierPriority ਵੇਟ ਵਧਾਓ:

{
  "strategy": "auto",
  "config": { "auto": { "weights": { "tierPriority": 0.3, "costInv": 0.05 } } }
}

ਟੀਅਰ ਪਰਿਭਾਸ਼ਾਵਾਂ ਅਤੇ ਪ੍ਰਦਾਤਾ ਵਰਗੀਕਰਨ ਲਈ docs/marketing/TIERS.md ਵੇਖੋ।

ਟੈਸਟਿੰਗ ਅਤੇ ਕਵਰੇਜ

ਨਿਰਧਾਰਿਤ ਰਾਊਟਿੰਗ-ਫੈਸਲਾ ਮੈਟ੍ਰਿਕਸ (npm run test:combo:matrix)

tests/integration/combo-matrix/*.test.ts ਇੱਕ ਮੌਕ ਕੀਤੇ ਅੱਪਸਟ੍ਰੀਮ ਨਾਲ ਅਸਲ ਕੌਂਬੋ ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਸਾਰੀਆਂ 19 ਜਨਤਕ ਰਣਨੀਤੀਆਂ ਦੇ ਰਾਊਟਿੰਗ ਫੈਸਲੇ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਕਵਰੇਜ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

  • ਸਾਰੀਆਂ 19 ROUTING_STRATEGY_VALUES ਰਣਨੀਤੀਆਂ (ordered, weighted, cost, context, fusion, …)।
  • quota-share (ਅੰਦਰੂਨੀ) ਐਂਡ-ਟੂ-ਐਂਡ: ਅਸਲ selectQuotaShareTarget ਸੀਮ (registerQuotaFetcher / setLKGP / __setHeadroomSaturationFetcherForTests) ਰਾਹੀਂ DRR ਨਿਰਪੱਖਤਾ + ਸੈਚੂਰੇਸ਼ਨ ਡੀਪ੍ਰਾਇਰਟੀਕਰਨ।
  • ਹਰ ਟਾਰਗੇਟ ਗਿਣਤੀ ਲਈ context-relay ਯੂਨੀਵਰਸਲ-ਹੈਂਡਆਫ਼ ਕਵਰੇਜ।

ਇਹ ਸੂਟ CI (test:integration ਜੌਬ) ਵਿੱਚ --test-concurrency=1 ਅਤੇ --test-force-exit ਨਾਲ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਨਿਰਧਾਰਿਤ ਹੈ ਅਤੇ ਇਸਨੂੰ ਲਾਈਵ ਕ੍ਰੈਡੈਂਸ਼ਲਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ।

ਗੇਟ ਕੀਤੇ ਲਾਈਵ ਸਮੋਕ ਟੈਸਟ (CI ਵਿੱਚ ਨਹੀਂ — ਅਸਲ ਪ੍ਰਦਾਤਾ)

ਕਮਾਂਡ ਇਹ ਕੀ ਕਰਦੀ ਹੈ
npm run test:combo:live RUN_COMBO_LIVE=1 ਨਾਲ ਇਨ-ਪ੍ਰੋਸੈਸ ਅਸਲ ਰਾਊਟਿੰਗ; ਲਾਈਵ OmniRoute DB ਦਾ ਸਨੈਪਸ਼ਾਟ ਲੈਂਦੀ ਹੈ
npm run test:combo:live:vps ਲਾਈਵ OmniRoute ਸਰਵਰ ਵਿਰੁੱਧ HTTP ਕਾਲਾਂ (COMBO_LIVE_BASE_URL ਸੈੱਟ ਕਰੋ)
npm run test:combo:live:vps:failover ਇਹੀ, ਜਾਣ-ਬੁੱਝ ਕੇ ਬਣਾਏ ਗਏ ਫੇਲਓਵਰ ਦ੍ਰਿਸ਼ਾਂ ਨਾਲ

ਇਹ ਸਮੋਕ ਟੈਸਟ ਅਸਲ ਵਾਇਰ ਪਾਥ (ਕੌਂਬੋ → ਪ੍ਰਦਾਤਾ → ਕੰਪਲੀਸ਼ਨ) ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ CI ਤੋਂ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਹੈ ਕਿਉਂਕਿ ਇਨ੍ਹਾਂ ਲਈ ਲਾਈਵ ਕ੍ਰੈਡੈਂਸ਼ਲਾਂ ਅਤੇ VPS ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਫ਼ਾਈਲਾਂ

ਫ਼ਾਈਲ ਉਦੇਸ਼
open-sse/services/autoCombo/scoring.ts 16-ਕਾਰਕ ਸਕੋਰਿੰਗ ਫੰਕਸ਼ਨ, DEFAULT_WEIGHTS, ਪੂਲ ਨਾਰਮ
open-sse/services/autoCombo/taskFitness.ts ਮਾਡਲ × ਟਾਸਕ ਫਿਟਨੈੱਸ ਲੁੱਕਅੱਪ
open-sse/services/autoCombo/engine.ts ਚੋਣ ਤਰਕ, ਬੈਂਡਿਟ, ਬਜਟ ਸੀਮਾ
open-sse/services/autoCombo/selfHealing.ts ਬਾਹਰ ਰੱਖਣਾ, ਪ੍ਰੋਬ, ਘਟਨਾ ਮੋਡ
open-sse/services/autoCombo/modePacks.ts 6 ਭਾਰ ਪ੍ਰੋਫ਼ਾਈਲਾਂ (ਤੇਜ਼ੀ ਨਾਲ ਭੇਜੋ, ਲਾਗਤ-ਬਚਤ, ਗੁਣਵੱਤਾ-ਪਹਿਲਾਂ, ਆਫ਼ਲਾਈਨ-ਅਨੁਕੂਲ, ਭਰੋਸੇਯੋਗਤਾ-ਪਹਿਲਾਂ, ਅਰਾਜਕਤਾ-ਮੋਡ)
open-sse/services/autoCombo/autoPrefix.ts auto/ ਪ੍ਰੀਫਿਕਸ ਪਾਰਸਰ + 6 ਰੂਪ
open-sse/services/autoCombo/virtualFactory.ts ਲਾਈਵ ਕਨੈਕਸ਼ਨਾਂ ਤੋਂ ਇਨ-ਮੈਮੋਰੀ AutoComboConfig ਬਣਾਉਂਦਾ ਹੈ
open-sse/services/autoCombo/providerRegistryAccessor.ts ਪ੍ਰੋਵਾਈਡਰ ਰਜਿਸਟਰੀ ਨੂੰ ਮੌਕ ਕਰਨ ਲਈ ਟੈਸਟ ਹੁੱਕ
src/shared/constants/routingStrategies.ts ROUTING_STRATEGY_VALUES (19 ਰਣਨੀਤੀਆਂ)
src/sse/handlers/chat.ts ਏਕੀਕਰਨ: ਆਟੋ-ਪ੍ਰੀਫਿਕਸ ਸ਼ਾਰਟ-ਸਰਕਿਟ