1 тэрбум гаруй ChatGPT хэрэглэгчид үйлчлэх онлайн хадгалалтыг хурдацтай өргөтгөсөн нь

Хэн нэгэн нэвтрэх, Codex тохиргоогоо шалгах эсвэл ChatGPT‑д шинэ яриа эхлүүлэх эсэхээс үл хамааран OpenAI-ийн бүтээгдэхүүн бүр өгөгдөлд хурдан, найдвартай хандахаас хамаардаг. Бүтээгдэхүүн хариу өгөхөөс өмнө эдгээр үйлдэл тус бүр олон тусдаа өгөгдөл хайх шаардлагатай байж болно. Эдгээр хүсэлт удаан бол бүтээгдэхүүн удаан мэт санагдана. Эдгээр хүсэлт бүтэлгүйтвэл бүтээгдэхүүн бүрэн ажиллахаа болино.

Habitat бол OpenAI-ийн бүтээгдэхүүнүүд шаардлагатай мэдээлэлдээ хурдан, найдвартай хандахад зориулан бидний бүтээсэн онлайн хадгалалтын платформ. Habitat одоо бараг 40 газарзүйн бүсэд долоо хоног бүр нэг тэрбум гаруй хүний ашигладаг бүтээгдэхүүнийг дэмжиж, секундэд 70 сая гаруй хүсэлт боловсруулдаг. Habitat анх DevDay 2023 дээр GPT‑үүдийг дэмжихээр, нэг өгөгдлийн сантай холбогдсон энгийн Python клиент сан хэлбэрээр нэвтэрсэн. Өнөөдөр энэ нь 500 гаруй петабайт өгөгдөл үйлчилдэг нийлмэл тархмал систем болсон.

Ийм цар хүрээний дэд бүтцийг байгуулах, ажиллуулах амаргүй ч өөрөө онцгой хэцүү зүйл биш. Манай нөхцөл байдлыг онцгой болгосон зүйл нь төлөвшсөн платформыг зэрэгцүүлэн байгуулж байхдаа асар их хэрэглэгчийн өсөлт, бүтээгдэхүүний эрэлтийг дэмжихээр урьд өмнө байгаагүй хурдаар өргөжих шаардлага байв. Системийн инженерүүд ихэвчлэн 10 дахин өсөлтөд зориулан бүтээж, дараагийн 10 дахинд бэлтгэх зуур хэдэн жил даана гэж найддаг. Харин бид сүүлийн гурван жилийн турш жилд 10 гаруй дахин илүү өссөн. Тиймээс Habitat-ыг байгуулах, ажиллуулах явц тактикийн шийдвэр ба дарааллын цуврал болсон: одоогийн стекээсээ дээд зэргийн үр ашиг авахын тулд бүрэлдэхүүн бүрийг хамгийн доод түвшинд ойлгож, суурь хөрөнгө оруулалтад хугацаа хожихын тулд хадгалалт, тооцооллын багтаамжийн хомсдолтой тэмцсэн.

OpenAI өсөхийн хэрээр Habitat дагаж өсөх шаардлагатай болсон: эхлээд нэн чухал бүтээгдэхүүний урсгалд хангалттай найдвартай, дараа нь дэлхийн хэрэглэгчдэд хангалттай хурдан, эцэст нь асар их цар хүрээнд чадварлаг ажилладаг болсон. Энэ нийтлэл онлайн хадгалалтаа хэрхэн өргөтгөсөн тухай хоёр хэсэгт цувралын эхнийх юм. Энд Habitat хэрхэн хөгжсөн, яагаад сангаас үйлчилгээ болгосон, мөн үйлчилгээний стект түгээмэл бус Python хэлээр бичсэн үйлчилгээг хэрхэн найдвартай хадгалалтын платформын давхарга болгосноо хуваалцана.

Дараагийн нийтлэлд олон түрээслэгчтэй орчны найдвартай байдлыг өргөн цар хүрээнд хэрхэн хангасан, унших гүйцэтгэлийг оновчлох давхаргат стратеги, урьд өмнө байгаагүй эрэлтийг найдвартай даахын тулд Azure Cosmos DB-тэй түншлэлээ хэрхэн өргөжүүлснийг дэлгэрэнгүй өгүүлнэ.

Habitat энгийн санаанаас эхэлсэн: бүтээгдэхүүний инженерүүд өгөгдлийн сангийн удирдлагад санаа зовох ёсгүй. Habitat анх DevDay 2023 дээр GPT‑үүдийг дэмжихээр ChatGPT‑ийн үндсэн сервертэй харилцдаг жижиг Python сан хэлбэрээр нэвтэрсэн. Энэ нь цаанаа Azure Cosmos DB өгөгдлийн сангийн аппликейшнд буулгасан цөөн үйлдлийг дэмждэг байв.

Сангийн үүрэг нь бүтээгдэхүүний багуудад суурь нарийн ширийнийг эзэмших шаардлагагүйгээр өгөгдөл хадгалах, татах энгийн арга өгөх байв. Habitat өгөгдлийн төрөл, хаанаас ирэх эсвэл хаашаа очих, хүсэлт зөвшөөрөгдсөн эсэх зэрэг шаардлагатай ажлыг хариуцдаг байв.

Бүтээгдэхүүний инженерүүд схем хайх, чиглүүлэх, зөвшөөрөл, шифрлэлт, цувралжуулалт, хүсэлт хэлбэржүүлэх, холболт нэгтгэхэд санаа зовох шаардлагагүй. Өгөгдөл Azure Cosmos DB, кэш эсвэл өөр төрлийн хадгалалтын алинаас ирэхийг ч бодох шаардлагагүй байв.

Өөртөө үйлчлэх Postgres болон Azure Cosmos DB-ээс татгалзуулах төвлөрсөн түлхэц байгаагүй ч Python сан сайн ажиллаж, OpenAI-ийн бүтээгдэхүүний инженерүүд Habitat-ыг хурдацтай нэвтрүүлсэн.

Бүтээгдэхүүний хэрэгцээ өөрчлөгдөхөд хөгжүүлэгчид клиент талын кэш, шахалт, шифрлэлт зэрэг боломжийн дэмжлэгийг хамтын санд хялбархан нэмж чаддаг байв.

2025 оны дунд үе гэхэд Habitat клиент талын хэрэгжүүлэлтийнхээ хязгаарт хүрсэн. Habitat давхарга нийлмэл болж, OpenAI-ийн үйлчилгээний тоо нэмэгдэхийн хэрээр өмнөх хувилбартай нийцтэй протоколын өөрчлөлт хийх боломжгүй болсон.

Нэг удаа бид хамгийн чухал өгөгдлийн багцуудаа бүс нутгаар тархсан Azure Cosmos DB бүртгэлүүд рүү шилжүүлж, аль нэг бүсийн тасалдлын нөлөөллийн хүрээг багасгахыг хүссэн. Үүний тулд функцийн тугийн ард идэвхгүй нэмэлт чиглүүлэлтийн логикийг клиентэд оруулж, бүх клиентэд нэвтрүүлээд тугийг идэвхжүүлэх шаардлагатай байв.

Олон арван үйлчилгээний нэвтрүүлэлтийг уялдуулж, баг бүртэй хамтран хэрэгжүүлэхэд хэдэн өдөр зарцуулсан. Үүнийг идэвхжүүлэхээс өмнө хуваалтын логик зөв ажиллахыг баталгаажуулахын тулд хүсэлт сүүдэрлэх хэрэгтэйг ойлгосон. Үүнийг нэвтрүүлэхэд дахиад хэдэн өдөр орсон. Буруу байсныг нь ойлгосон зүйлд алдааны засвар хийх үү? Дахиад хэдэн өдөр. Эцэст нь тугийг идэвхжүүлэхэд бэлэн болсон ч нэг баг хамааралгүй шалтгаанаар үйлчилгээгээ өмнөх алдаатай клиент рүү буцааснаар бидний тэгтлээ хичээн зайлсхийсэн тасалдал гарсан.

Клиент сангийн өөрчлөлт олон арван үйлчилгээг төвөгтэй уялдуулахыг шаарддаг байсан бөгөөд энэ үйл явц улам хэврэг, үр ашиггүй, ажиллагааны доголдолд өртөмтгий болсон. Ирээдүйн нэвтрүүлэлтийн ажиллагааны тархалтыг багасгахын тулд Habitat-ыг бие даасан үйлчилгээ болгохоор шийдсэн.

Хадгалалтын логикийг бие даасан үйлчилгээ болгон салгаснаар нэвтрүүлэлт, ажиглалт, платформын сайжруулалтыг хянах нэг төв бий болгосон. Тус тусын шинэчлэл удирдахын оронд сайжруулалтыг төвлөрсөн байдлаар хэрэгжүүлж, OpenAI-ийн бүх бүтээгдэхүүнд шууд үр өгөөж өгч чаддаг болсон.

Төвлөрсөн үйлчилгээ нь өгөгдлийн аюулгүй байдал, нууцлалын хамгийн хүчтэй суурь механизмыг хэрэгжүүлэх нэг хяналтын цэг болдог. Habitat үйлчилгээнд хандалтын хяналтын бодлогыг төвлөрүүлэн хэрэгжүүлж, аудитын бүртгэл хөтлөн, Azure Cosmos DB зэрэг суурь хадгалалтын нөөцөд хандахыг хязгаарлаж болно. Habitat нь хэрэглэгчийн өгөгдлийг хамгаалж, гаднын, дотоодын болон агент оролцогчдын зөвшөөрөлгүй хандалтаас сэргийлэхэд чухал үүрэгтэй.

Бидэнд үйлчилгээ хэрэгтэйг мэдэж байсан ч Python-ыг үйлчилгээ болгон ажиллуулах нэмэлт зардалтай байсан ч тэр даруй өөр хэл рүү шилжихийг хүсээгүй. Нэвтрүүлэх чадамж өндөртэй үйлчилгээнд Python ашиглах нь локал сан ажиллуулахаас илүү сүлжээний саатал, CPU болон санах ойг өргөтгөх зардлыг ихээхэн нэмэгдүүлсэн. Түүнчлэн Python-ын үр ашиггүй байдал 100 дахин том цар хүрээнд хүлээн зөвшөөрөгдөхгүй тул эцэст нь дахин бичих нь бараг гарцаагүйг бид ойлгосон.

Гэхдээ бид үүнийг техникийн өрийг стратегийн зорилгоор түр нэмэгдүүлсэн хэрэг гэж үзсэн. Тэр үед бидний гол зорилго зардал, нөөцийг оновчлох бус, бүтээгдэхүүн хөгжүүлэгчдийн саадыг арилгаж, платформын тогтвортой байдлыг хангах явдал байв. Python үйлчилгээний гүйцэтгэлийн сул талыг богино хугацаанд хүлээн зөвшөөрснөөр бид тулгамдсан асуудлуудаа түрүүлж шийдэн, үндсэн API-уудаа тогтоож, бат бөх дэд бүтэц байгуулж чадсан.

Мөн өөрсдийн кодчиллын загварууд хурдацтай сайжирснаар ирээдүйн техникийн шилжилт хялбар болно гэж тооцоолон бооцоо тавьсан. Python-оос бүрэн шилжих шаардлага гарах үед Codex болон GPT уг шилжилтийг боломжтой болгоно гэж бид үзсэн. Энэ таамаг эцэстээ зөв байсан.

Habitat-ыг Python үйлчилгээ болгон ажиллуулах нь гүйцэтгэлийн хувьд оновчгүй ч зайлшгүй сонголт байв. Python бидэнд хурдан ажиллах боломж өгсөн ч болгоомжоо бүрэн орхиж, мэдэгдэхүйц их саатлыг хүлээн зөвшөөрч болохгүй байв. Хэрэглэгчийн дундаж хүсэлт өгөгдлийн санд хэдэн зуун дуудлага үүсгэхэд хэрэглэгч хамгийн удаан дуудлагын саатлыг мэдэрдэг. Ийм цар хүрээнд Python үйлчилгээ ажиллуулахын гол сорилт нь төгсгөлийн саатлуудыг удирдах явдал гэдгийг бид тогтоосон.

Asyncio нь Python-д I/O-оос хамааралтай ачааллыг зэрэг гүйцэтгэхэд тусалдаг ч Python GIL-ийг тойрч, CPU-ийн зэрэгцээ ажиллагааг хангаж чаддаггүй. Habitat нь I/O ихтэй хүсэлт дамжуулахаас гадна чиглүүлэлт, шахалт, шифрлэлт, хяналтын нийлбэр, доод системийн эрүүл мэндийн шалгалт, хүсэлт сүүдэрлэлт, давхар хүсэлт зэрэг CPU их шаарддаг олон үүрэг, дэвсгэр даалгаврыг гүйцэтгэдэг.

Манай үйлчилгээнд CPU их шаарддаг ачаалал, дэвсгэр даалгавар олон тул asyncio-ийн хуваарилалтын саатал хүсэлтийн төгсгөлийн саатлын гол хэсэг болж амархан хувирдаг. Анхны нэвтрүүлэлтийн тохируулгаас өмнө p99 ба түүнээс их сааталтай хүсэлтийн мөрдөлтөөс доод хадгалалт хурдан хариулсан ч хариуг задлах coroutine дахин хуваарилагдахыг хүлээн хүсэлтүүд байнга гацаж байсныг харсан.

OpenAI дахь Python үйлчилгээнд санах ой, CPU, сүлжээ, дискний стандарт ашиглалт ба ханалтын хэмжүүрээс гадна asyncio давталт хэр ачаалалтайг хянаж, зохих ёсоор тохируулах нь нэн чухал.

Дэвсгэр даалгаврыг тогтмол хуваарилж, хүлээгдсэн ба бодит гүйцэтгэлийн цагийн зөрүүг бүртгэснээр үйл явдлын давталтын хуваарилалтын саатлыг бодит цагт хэмждэг. Ашиглалт өндөр, өртөгтэй даалгавар олонтой үед процесс бүрд цөөн зэрэгцээ хүсэлт байхад ч хуваарилалтын хэлбэлзэл хэдэн зуун миллисекунд, зарим онцгой тохиолдолд хэдэн секунд хүрдэг.

Тиймээс процесс бүрээр цөөн зэрэгцээ хүсэлт үйлчлүүлж, оронд нь Python ажиллагч процессын тоог асар ихээр нэмэгдүүлдэг.

Анхны нэвтрүүлэлтийн үеэр шууд үйлчилгээний CPU профайлаар asyncio-ийн их саатлын нэг үндсэн шалтгааныг олсон: функцийн туг удирдаж, A/B туршилт зэрэгт ашигладаг Statsig-аар дамжуулан тохиргооны JSON-ыг тогтмол задлах явдал байв.

Анхдагчаар Statsig шинэ тохиргоог минут тутам хэлбэлзэлгүй татахаар тохируулагдсан бөгөөд тохиргоонд бүх үйлчилгээний үйлдвэрлэлийн бүх дүрэм багтдаг байв. Мөн CPU ашиглалтыг нэмэгдүүлж, саатлыг багасгахын тулд pod бүрд найм хүртэл Python процесс ажиллуулах архитектурын шийдвэр гаргасан байв. Үүний улмаас минут тутам pod бүрийн бүх ажиллагч явж буй хүсэлтээ боловсруулахаа түр зогсоож, асар том тохиргооны файлыг CPU-ээр задлах мөч гардаг болсон.

CPU профайлаар үндсэн шалтгааныг олсны дараа засвар нь энгийн байв: жижиг, зорилтот тохиргоо нэвтрүүлэх, шинэчлэх интервалыг уртасгах, ийм дэвсгэр даалгаварт хэлбэлзэл нэмэх.

asyncio саатлыг бага байлгахын тулд хүсэлтийг серверийн процессуудын хооронд сайн тэнцвэржүүлэх нь чухал; тохируулахгүй бол холболтын сан үүнд харшилж болно.

Клиент талын холболтын сантай үед олон зэрэгцээ хүсэлт гаргадаг ганц клиент процесс цөөн серверийн холболт үүсгэж, бүх ачааллаа цөөн процесс руу илгээж болно. Ачаалал тэнцвэржүүлэлтийг засахаас өмнө үйлчилгээний ашиглалт их хэлбэлзэж, зарим захын процесс дунджаас 5–10 дахин олон зэрэгцээ хүсэлт үйлчилдэг байв.

Үйлчилгээний нэг хэсгийг хэт ачаалж байсан клиентийг зогсоосон ч зарим процесс огцом урсгал өнгөрснөөс хойш удаан хугацаанд муу хэвээр байсан санамсаргүй тохиолдлоор үүнийг илрүүлсэн. Үнэндээ тэдгээр процесс дахин эхлүүлэх хүртэл улам олон хүсэлт хүлээн авч, хяналтгүй доройтож байсныг анзаарсан. Pod хэт ачаалагдмагц ямар нэг зан төлөв илүү их урсгалыг түүн дээр тогтоон барьж байв. Энэ нь манай зарим багийнхны өмнөх ажлаасаа сайн мэддэг доголдлын төрөл байв: мета-тогтвортой доголдол⁠(шинэ цонхонд нээгдэнэ).

Холболтын санг буруутай гэж сэжиглэн холболтыг дахин ашиглах дээд хугацааг хязгаарлахад доройтол үнэхээр багасаж, шалгалтын чиглэл зөвийг баталсан. Цааш шалгахад Python-ын aiohttp TCPConnector анхдагчаар LIFO холболт дахин ашигладаг буюу хамгийн сүүлд буцсан холболтыг дараагийн хүсэлтэд сонгодог нь тогтоогдсон. Энэ нь ердийн үед зохистой: сүүлийн холболтыг дахин ашигласнаар огцом урсгалд зориулан үүссэн нэмэлт холболтууд сул хугацааны хязгаараар хаагдаж, тэдгээрийг хадгалах зардал буурна. Харин энэ тохиолдолд мета-тогтвортой доголдол үүсгэсэн. Огцом их хүсэлтийн үед удаан, хэт ачаалсан серверийн хүсэлтүүд холболтоо санд хожуу буцааснаар дараагийн хүсэлтүүд тэдгээрийг илүү олон сонгож, аль хэдийн ачаалалтай pod-ууд дээр урсгалыг аажмаар төвлөрүүлсэн. Холболтын санг FIFO дахин ашиглахаар нөхсөнөөр энэ эргэх холбоог тасалж, тогтвортой төлөвийн хүсэлтийн хэлбэлзлийг ч бууруулсан.

Өнөөдөр бид OpenAI-ийн дэд бүтцэд холболтын сан болон серверийн ачааллыг илүү сайн харгалзах тэнцвэржүүлэлтийг Istio, Envoy-д голчлон даатгаж, энэ асуудлаас бүрэн зайлсхийдэг.

asyncio саатлыг багасгахаар тохируулж, олон Python процесстой болсны нэг дагавар нь асар олон холболтоор доод хамаарлуудыг маш амархан дарах явдал юм. Үүнийг "нүргэлсэн сүрэг" гэдэг.

Өдөр тутмын энгийн нэвтрүүлэлтийг удаанаар явуулахаар тохируулаагүй бол холболтууд солигдсоноор CPU-ийн ачаалал ихээхэн хэлбэлзэж болно. Эсвэл холболтын алдагдал NAT гарцыг хангаж, сүлжээг бүхэлд нь унагаж болно. Эдгээр нь бусад үйлчилгээнд ч түгээмэл асуудал боловч процессын тоо арав дахин ихэссэнээр өдөөх босго эрс буурч, цэвэр нэвтрүүлэх чадамжид тулгуурлан клиентүүд тогтвортой үед даана гэж тооцоогүй сүлжээний нөөцийг хангадаг.

Мөн холболтуудыг хамгийн ихээр нэгтгэхийн тулд Envoy-д тулгуурладаг. Үүнийг Python-ын HTTP/1 холболтыг HTTP/2 болгон ахиулж мультиплексийн давуу талыг ашиглах, дараа нь холболтуудыг нэгтгэн ашиглалтын хугацааг уртасгахад хэрэглэдэг. Envoy нь тусдаа Python процесс бүрд хэрэгжүүлбэл үр нөлөө багатай хурдны хязгаарлалт, хэлхээ таслагчийг төвлөрүүлэн хэрэгжүүлэх боломж ч өгдөг.

Python-ыг ийм хэмжээнд өргөтгөж чадсан нэг шалтгаан нь хүсэлтийн зардлыг урьдчилан таамаглах боломжтой байлгадаг Habitat-ын хязгаарлагдмал API юм. Үйлчлүүлэгчдэд том хүснэгт уншуулах эсвэл олон хүснэгт холбох дурын SQL хүсэлт үүсгэх боломж өгөхийн оронд Habitat энгийн NoSQL API санал болгодог. Хүчирхэг API-гаас татгалзсан нь Habitat-ын загварын зориудын буулт юм.

Бид энгийн, таамаглах боломжтой, тогтмол хэмжээний ажилтай хүсэлтийг оновчлохыг зорьдог. Бидний туршлагаар ийм системийг өргөтгөх нь хавьгүй хялбар бөгөөд буруу ашиглахад бэрх. Таамаглашгүй салаалалттай хүсэлт ажиллагааны хувьд аюултай: тусгаарлалт, ачаалал тэнцвэржүүлэлтийг төвөгтэй болгож, үйлчилгээ болон үйлчлүүлэгчдийн өргөтгөлд хүндрэлтэй огцом саатал үүсгэдэг.

Habitat болон Azure Cosmos DB-д шилжихээс өмнө OpenAI-ийн онлайн өгөгдлийн ихэнхийг Postgres-д хадгалдаг байв. Тухайн үед үйлдвэрлэлд нэвтрүүлэхээс өмнө бүх хүсэлт, схемийн өөрчлөлтийг шалгаж, зөв ажиллах болон индексжүүлсэн өгөгдөл ашиглахыг баталгаажуулахад хялбар байв. Баг, бүтээгдэхүүнүүд өсөхөд үүнийг удирдах боломжгүй болж, ачаалалтай зам дахь ганц өртөгтэй шинэ хүсэлт өгөгдлийн санг унагаан тасалдал үүсгэх нь элбэг болсон.

Энд асуудал нь зардлын тэнцвэргүй байдал: ажиллуулахад өртөгтэй, хэцүү SQL хүсэлтийг бичихэд хямд, хялбар. Habitat үүнээс зайлсхийж, өртөгтэй хүсэлтийг үйлчлүүлэгч талд маш тодорхой болгодог. Habitat-ыг хэт ачаалах хязгааргүй хүсэлт байхгүй; нийлмэл холболт, график дамжилтын хүнд ажлын хэсгийг бүтээгдэхүүний багууд гүйцэтгэдэг нь илүү үр ашигтай загварыг дэмждэг.

Habitat нь TAO⁠(шинэ цонхонд нээгдэнэ)-оос санаа авсан, үйлчлүүлэгчийн тодорхойлсон объект ба ирмэгийн төрөлд тулгуурласан NoSQL API санал болгодог. Үйлчлүүлэгчид объект, ирмэг болон тэдгээрийн харилцааг урьдчилан тодорхойлдог ч төрөл бүрийн агуулгыг тодорхойлдоггүй. Үүссэн харилцаа графтай төстэй ч Habitat нь тодорхой объектын шууд ирмэгийг асуухаас бусад ердийн график дамжилтын хүсэлтийг дэмждэггүй.

Бид графыг объект болон холбогдох ирмэгүүд нь хадгалалтын түвшний нэг хуваалтад байхаар хуваадаг ч объект, ирмэгээр заасан алсын объектуудыг өгөгдлийн сангийн түвшинд хамт байрлуулах тусгай арга хэмжээ авдаггүй. Ингэснээр загварыг хэвтээ өргөтгөлд хялбар хуваадаг ч объект хоорондын нэг алхам өөр бүсэд хадгалсан хоёр тусдаа Azure Cosmos DB бүртгэлээс татах шаардлагатай байж болох тул граф дамжилт үр ашиггүй.

Илүү нийлмэл хүсэлт хэрэгтэй үйлчлүүлэгчдэд Rockset-ээр нэвтрэх Habitat-ын офлайн хоёрдогч харагдац өгдөг. Өөрчлөлтийн өгөгдөл барих (CDC) аргаар онлайн хадгалалтын өөрчлөлтийг бараг бодит цагт тусгаарлагдсан Rockset тохиолдол руу урсгадаг. Үйлчлүүлэгч баг бүр нийлмэл хүсэлтийн хэрэгцээндээ зориулж өөрийн Rockset тохиолдлыг өргөтгөх үүрэгтэй.

Rockset бэлтгэх нь үйлчлүүлэгчдэд нэмэлт төвөг учруулдаг ч одоогоор зөв буулт гэж үздэг: энгийн хүсэлтийг анхдагч болгож, нийлмэл хүсэлт хэрэгтэй хүмүүст өөр гарц өгөх. Энэ загвар онлайн хадгалалтыг уншилт ихтэй аналитик болон хайлтын ачааллаас тусгаарладаг.

Python-оор дахин бичихийг нэг жил хойшлуулснаар эрчимтэй өсөлтийн үед илүү яаралтай, үр нөлөөтэй сорилтуудад төвлөрсөн. Платформ төлөвшиж, өсөлт улам хурдассан бөгөөд үндсэн цөмийн тоогоор OpenAI-ийн хоёр дахь том үйлчилгээ, Envoy ашиглалтаар дөрөвт орсон тул Python-оос шилжих цаг болсон. Оргил үедээ Python секунд тутам 20 сая гаруй хүсэлт үйлчлэхэд тусалсан.

2026 оны II улиралд ердөө хоёр инженер Codex болон GPT‑5.5‑ийн тусламжтай үйлчилгээг бүхэлд нь Rust-аар дахин бичиж чадсан. Шинэ Rust үйлчилгээ одоо үйлдвэрлэлийн хүсэлтийн 95%-ийг боловсруулж байна; ирэх долоо хоногуудад Python-ыг бүрэн хална. Өгөгдлөөс үзэхэд Rust үйлчилгээ Python хувилбараас CPU-ийн хувьд 6 дахин, санах ойн хувьд 15 дахин үр ашигтай бөгөөд дундаж болон төгсгөлийн саатал мэдэгдэхүйц бага. Цаашдын нийтлэлээр илүү олон сургамжаа хуваалцахаар төлөвлөж байна.

Python, одоо Rust үйлчилгээ нь Habitat-ын зөвхөн нэг тал юм. ChatGPT‑ийн нэг тэрбум гаруй хэрэглэгчид үйлчлэх онлайн хадгалалтаа хэрхэн хурдацтай өргөтгөсөн тухай цувралын II хэсэгт хадгалалтын давхарга болон Habitat 500 гаруй петабайт өгөгдөл, секундэд 70 сая гаруй хүсэлтийг хэрхэн үйлчилдгийг өгүүлнэ.

Хил хязгаарын цар хүрээний OLTP систем дээр ажиллаж, ийм инженерчлэл сонирхож байвал манай багийн нээлттэй ажлын байрыг үзнэ үү⁠.