8feea123bb
* feat(docs): mirror every docs/ page in all 65 locales Extends the documentation mirrors from the 22-page core set (#13940) to every Markdown page under docs/: 152 sources x 65 locales = 9,880 mirrors (6,208 new), language bars rewritten for the full locale list, state adopted so the blocking drift gate now covers all 152 pages. run-translation.mjs: an oversized block made only of table rows or list items (PROVIDER_REFERENCE.md 244-row table, FREE_TIERS.md 71-item list) is cut at item boundaries and rejoined without a blank line — the single 16-40 KB request outlived the backend socket for verbose scripts. 48 older mirrors whose tables had lost rows were retranslated with --force. * docs(i18n): refresh mirrors for the sources the base changed since the branch cut Section-level retranslation of the 29 docs (and README.md) whose source or mirrors moved on release/v3.8.51 during the run, then state adoption; the drift gate is green again on the merged tree.
20 KiB
Relay Backend Strategy (ქართული)
🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 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
შეჯამება
OmniRoute-ს ახლა /api/v1/relay/chat/completions-ისთვის გადამისამართების სამი რეჟიმის მხარდაჭერა აქვს:
ts: TypeScript-ის გადამისამართების მექანიზმის გამოყენება იმავე პროცესში.bifrost: Bifrost-ის კარიბჭის იძულებით გამოყენება.auto: შესაძლებლობის შემთხვევაში Bifrost-ისთვის უპირატესობის მინიჭება, ხოლო შეცდომისას TypeScript-ზე გადართვა.
როდესაც მოთხოვნების მაღალი სიხშირით მუშაობთ (ტოკენების დიდი რაოდენობა დღეში, თითქმის უწყვეტი გამტარუნარიანობა), საუკეთესო სტრატეგიაა სარეზერვო გზა ცხადი და სწრაფი იყოს, რათა ძირითადმა გზამ უმოქმედო თანმხლები პროცესის გამო არასდროს დაიბლოკოს.
რეჟიმების ქცევა
ts- ყველაზე დაბალი საოპერაციო სირთულე.
- მთელი მარშრუტიზაცია და ვალიდაცია Node-ში სრულდება.
- ხელმისაწვდომობა თანმხლებ პროცესზე დამოკიდებული არ არის.
bifrost- ყველა მოთხოვნის თანმხლები კარიბჭის გავლით იძულებით გატარება.
- ავტომატური სარეზერვო გადართვა არ ხდება.
- გამოსადეგია მხოლოდ მაშინ, როდესაც თანმხლები პროცესის გამართულობა და დაყოვნება გარანტირებულია.
auto- თანმხლები პროცესი გამოიყენება, როდესაც მასთან დაკავშირება შესაძლებელია და ის ჩართულია.
- წარუმატებელი მცდელობები ააქტიურებს სარეზერვო გადართვის სათაურებს და ტრაფიკს TS-ზე აბრუნებს, რათა მოთხოვნის წარმატება განსაზღვრულ ფარგლებში დარჩეს.
- ეს რეჟიმი წარმოებისთვის ყველაზე უსაფრთხო არჩევანია, როდესაც უწყვეტი მუშაობა უფრო მნიშვნელოვანია, ვიდრე მხოლოდ თანმხლები პროცესის გავლით მკაცრი მარშრუტიზაცია.
9router და CLIPROXYAPI დღეს
9router და CLIPROXYAPI ორივე ინტეგრაციაა, რომლებიც ისტორიულად ზედა დონის პროვაიდერებისთვის თავსებადობის გზებს უზრუნველყოფდა.
- 9router არის ზედა დონის სერვისების ორკესტრირებისა და თავსებადობის ქცევისთვის განკუთვნილი ჩაშენებული გზა.
- CLIPROXYAPI არის CLI / SDK-ის ტიპის ტრაფიკისთვის განკუთვნილი პროქსი API-ის ხიდი.
- Bifrost სტაბილიზაციის პროცესშია, როგორც გარე გზა იმ შემთხვევებისთვის, როდესაც გჭირდებათ გამოყოფილი, თანმხლები პროცესის მსგავსი შუალედური საფეხური და დაბალი დაყოვნების მქონე ლოკალური დისპეტჩერიზაცია.
თუ ამჟამად 9router-სა და CLIPROXYAPI-ს ადარებთ:
- მოთხოვნის ხელმოწერა, ნებადართული სიების შემოწმება და DB-ის პოლიტიკის საკონტროლო ეტაპები გადაცემამდე API-ის მარშრუტში დატოვეთ.
- თუ სამუშაო პროცესს თანმხლები პროცესის მკაცრი ქცევა და თითოეულ მოთხოვნაზე ნაკლები ვარიაცია სჭირდება, გამოიყენეთ
OMNIROUTE_RELAY_BACKEND=bifrost. - თუ ინციდენტების დროს თანმხლები პროცესის მდგრადობა და ფუნქციონალის თანდათანობითი შემცირება გჭირდებათ, გამოიყენეთ
OMNIROUTE_RELAY_BACKEND=auto.
ბეკენდის საზღვრის კონტრაქტი
პროდუქტის სტაბილური საზღვარი OmniRoute-ის გადამისამართების API-ია და არა საინფორმაციო პანელის იმპლემენტაცია. Next.js-ის საინფორმაციო პანელს შეუძლია ლოკალური სერვისების დაყენება, კონფიგურაცია და ზედამხედველობა, თუმცა მოთხოვნების მარშრუტიზაცია გადამისამართების API-ის გავლით უნდა შევიდეს და გადაცემა ამ საზღვრის მიღმა მოხდეს.
ბეკენდის გრძელვადიანი არჩევანი:
- TypeScript-ის გადამისამართების მექანიზმი იმავე პროცესში მოქმედ პოლიტიკისა და სარეზერვო გზის სახით შეინარჩუნეთ. ავტორიზაცია, ნებადართული სიები, მოთხოვნების ნორმალიზაცია, აღრიცხვა და უსაფრთხოების შემოწმებები ნებისმიერი ბეკენდისთვის გადაცემამდე აქ რჩება.
- Bifrost გამოიყენეთ სასურველ, მაღალი გამტარუნარიანობის Tier-1 თანმხლებ პროცესად, როდესაც განთავსებას მარშრუტიზაციის ნაკლები ვარიაცია, პროვაიდერების ცენტრალიზებული როტაცია ან OmniRoute-ის რამდენიმე რეპლიკაზე ჰორიზონტალური მასშტაბირება სჭირდება.
- 9router და CLIPROXYAPI ჩაშენებულ თავსებადობის სერვისებად შეინარჩუნეთ. ისინი ზედამხედველობის ქვეშ მყოფ ლოკალურ პროცესებად მუშაობენ და გამოსადეგია, როდესაც სასურველი ადაპტერი მათი პროვაიდერის/CLI-ის ქცევაა, თუმცა ისინი ნაგულისხმევ Tier-1 მარშრუტიზაციის ძრავად არ უნდა იქცეს.
- საინფორმაციო პანელს არ მისცეთ საშუალება, ძირითად გზას სერვისების ნებისმიერი URL გადასცეს. UI-ის მიერ მოწოდებული URL-ები კონფიგურაციის შემავალი მონაცემებია; მარშრუტიზაციის კოდმა რეგისტრირებული და გამართულობაზე შემოწმებული ბეკენდები სერვერის მხარის პარამეტრებიდან და ზედამხედველის მდგომარეობიდან უნდა განსაზღვროს.
- დღეს ზედამხედველობის ქვეშ მყოფი სერვისებისთვის უპირატესობა loopback HTTP-ს მიანიჭეთ, რადგან მართული პროცესები უკვე უზრუნველყოფს HTTP-თან თავსებად API-ებს, მარშრუტის დამცველს საზღვრის აუდიტი შეუძლია, ხოლო შეცდომისა და სარეზერვო გადართვის ქცევა მოთხოვნების ჟურნალებში ხილულია. სამომავლოდ SDK-ის ან სოკეტის ტრანსპორტის დამატება მხოლოდ მაშინ ღირს, თუ ის p99 მარშრუტიზაციის დაყოვნებას გაზომვადად შეამცირებს იზოლაციის ან სარეზერვო გადართვის სემანტიკის შესუსტების გარეშე.
ამიტომ, ძალიან მაღალი გამტარუნარიანობის მქონე განთავსებისთვის ნაგულისხმევი პასუხია auto ჩართული Bifrost-ით: ძირითად გზაზე გამოიყენეთ Go-ს თანმხლები პროცესი, ხოლო წარმატების მაჩვენებლის შესანარჩუნებლად TypeScript-ის სარეზერვო გზა შეინარჩუნეთ. bifrost გამოიყენეთ მხოლოდ მაშინ, როდესაც მხოლოდ თანმხლები პროცესის გავლით მკაცრი მუშაობა უფრო მნიშვნელოვანია, ვიდრე ფუნქციონალის თანდათანობითი შემცირება.
მაღალი გამტარუნარიანობის რეკომენდაციები
მდგრადი მაღალი RPM/RPS-ისა და წარმატების მკაცრი SLO-სთვის:
- გამოიყენეთ
autoპრაქტიკული დაყოვნების პერიოდითა და შეცდომების ტელემეტრიით. - ზედა დონის სერვისების ვალიდაცია და API-გასაღებების შემოწმება TypeScript-ის მარშრუტის საზღვარზე შეინარჩუნეთ.
- ჩართეთ ცხადი სათაურები/მთვლელები, რათა შეტყობინებების სისტემამ სარეზერვო გადართვის სიხშირე და მიზეზები დააფიქსიროს.
- თანმხლები პროცესის მოლოდინის დროები ისე მოარგეთ, რომ შეცდომა სწრაფად დაფიქსირდეს და ლოდინი უსასრულოდ არ გაგრძელდეს.
- სერვისის ავტომატური გადატვირთვა და გამართულობის ტელემეტრიის ციკლი გამართულად შეინარჩუნეთ, რათა სარეზერვო გადართვა მართლაც გამონაკლისი იყოს.
შემოთავაზებული საბაზისო კონფიგურაცია
OMNIROUTE_RELAY_BACKEND=autoBIFROST_ENABLED=1- API-გასაღებების, ნებადართული სიის, სანიტიზატორისა და სიხშირის შეზღუდვის შემოწმებები მარშრუტის დამმუშავებლებში ჩართული დატოვეთ (ისინი ყოველთვის სრულდება ქვედა დონის სერვისზე გადამისამართებამდე).
- სარეზერვო გადართვის მეტრიკები თქვენი უკუპროქსიდან და მოთხოვნების ჟურნალებიდან გაიტანეთ, რათა თანმხლები პროცესის გათიშვა ერთ წუთში გახდეს ხილული.
პროვაიდერის პლაგინის კონტრაქტი
თანმხლებმა პროცესებმა პროვაიდერის მეტამონაცემები TypeScript-ის შემსრულებლის შიდა მექანიზმებზე დამოკიდებულების ნაცვლად JSON-თან თავსებადი პროვაიდერის პლაგინის მანიფესტის მეშვეობით უნდა შემოიტანონ. თანმხლები პროცესის შესაბამისობის კონტრაქტისა და მიგრაციის ეტაპებისთვის იხილეთ პროვაიდერის პლაგინის მანიფესტი.