Pengo katika usanidi (config) uliokuwa wazi kwenye kumbukumbu za mfumo (logs) ulivuja majibu 155 ya AI

Onyo lilichapishwa wakati mfumo unaanza kufanya kazi

Tarehe 26 Oktoba, Cloudflare ilichapisha ripoti yake kuhusu hitilafu ya kutenganisha wateja (tenant isolation) katika modeli ya GLM-5.3 kwenye Workers AI. Kati ya Agosti 27 na Septemba 9, majibu 155 kwa prompt (maelekezo anayopewa AI) zilizozidi tokeni 681,280 yalikuwa na data kutoka kwa maombi ya wateja wengine. Cloudflare inasema wakati na idadi ya maombi yaliyoathirika vinaendana na matumizi ya kawaida ya muktadha mrefu, na haikupata ushahidi wowote wa matumizi mabaya ya makusudi. Mtafiti wa usalama Gadi Evron wa Knostic aliripoti tatizo hilo Septemba 8; Cloudflare iliondoa modeli hiyo mtandaoni ndani ya dakika 40 baada ya kutangaza tukio hilo, na ikairudisha Septemba 9.

Jambo la kutafakari: Cloudflare inasema ilijua kuhusu kutolingana huko kabla ya uzinduzi. Modeli ilisanidiwa kwa dirisha la muktadha la tokeni 1,048,576, lakini hifadhi ya kumbukumbu (memory pool) kwenye GPU za prefill ilikuwa na tokeni 681,280 tu. Injini huchapisha ukubwa wa hifadhi hiyo wakati inapoanza na kuuonyesha kama kipimo (metric). Timu ilidhani kwamba prompt kubwa kupita kiasi zingerudisha hitilafu tu.

Jinsi hifadhi ya kumbukumbu inayoshirikiwa inavyovuja

Modeli ya lugha inaposoma prompt yako, huhifadhi matokeo ya kati, yaani KV cache, kwenye kumbukumbu ya GPU. Kumbukumbu hiyo ni hifadhi ya pamoja ya kurasa za ukubwa uliowekwa. Ombi hupewa kurasa linapokubaliwa na huzirudisha linapokamilika. Cloudflare inasema kurasa hazifutwi (kuwekwa sifuri) kati ya maombi, jambo la kawaida kwa injini nyingi za inference kwa sababu kuzifuta kunapunguza kasi. Badala yake, injini lazima ifuatilie nani anamiliki kila ukurasa.

Cloudflare huendesha GLM-5.3 kwa muundo uliogawanywa: GPU za prefill huchakata prompt na kujenga cache, kisha huikabidhi kwa GPU tofauti za decode zinazozalisha jibu. Upande wa decode hutenga kurasa kulingana na urefu wa prompt.

Hapa ndipo injini ya inference ya SGLang ilipokosea. Prompt kubwa mno kwa hifadhi iliwekwa alama ya kukataliwa na kubadilishwa na kishikilia nafasi cha tokeni moja. Lakini ukaguzi wa kukubali ombi katika hali ya disaggregated uliuliza kama ombi limekamilika, si kama limekataliwa, kwa hiyo ombi lililokataliwa lilipita. Prefill iliandika ukurasa mmoja na kuashiria kukamilika. Decode, ambayo katika mfano wa chanzo ilikuwa imetenga kurasa nane, ilidhani zote nane zimeandikwa upya na ikazitumia, ikasoma kurasa saba zilizobaki zikiwa bado na data ya watumiaji wa awali. Mteja alipokea HTTP 200 na jibu lenye mantiki.

Kwa nini majaribio yalishindwa kuliona

Cloudflare inasema majaribio yake ya muktadha mrefu kabla ya uzinduzi yalikagua misimbo ya hali ya HTTP na utendaji, si kama matokeo yalikuwa na maana. Misimbo ya mafanikio ilionekana kama ushahidi kwamba injini ilishughulikia pengo hilo. Hii ndiyo ishara muhimu: hitilafu haikuleta kosa lolote, wala kuanguka kwa mfumo, na maandishi yalionekana ya kawaida. Dalili pekee ilikuwa kwamba majibu yalifika haraka kuliko prefill kamili inavyopaswa kuchukua.

Pia ilikuwa hitilafu inayojulikana upstream (kwenye mradi mkuu). Mtumiaji mwingine wa SGLang aliiripoti kama issue #30233 tarehe 6 Julai, kabla dirisha la uvujaji kufunguka, na Cloudflare inasema ilikuwa ikiashiria masuala kama hayo tangu v0.5.10. Marekebisho yalitolewa katika v0.5.20, na maboresho ya ziada katika v0.5.21 na v0.5.22; Cloudflare inapendekeza waendeshaji wasasishe hadi v0.5.22 au toleo jipya zaidi.

Mwelekeo mpana

Inference ya wapangaji wengi (multi-tenant) sasa inategemea injini za chanzo huria zinazoendelea kwa kasi kuliko ukaguzi wake wa usalama. Ukubwa wa hifadhi huwekwa wakati wa kuanza kutokana na kumbukumbu ya GPU iliyobaki, wakati urefu wa muktadha ni mpangilio tofauti, na, kwa maneno ya Cloudflare, hakuna kinacholazimisha vyote viwili vikubaliane. Umiliki wa kurasa za kumbukumbu unashirikiwa kati ya mashine zilizounganishwa kwa RDMA, uhamishaji wa moja kwa moja wa kumbukumbu kati ya nodi. Cloudflare inasema GLM-5.3 pekee ndiyo iliyoathirika, kwa sababu usambazaji wake mwingine wa disaggregated una hifadhi kubwa kuliko madirisha yake ya muktadha. Huo ni nafasi ya ziada ya usanidi tu, si dhamana ya muundo, na Cloudflare yenyewe inaita kutegemea ukubwa wa hifadhi pekee kuwa dhaifu.

Maswali Unayopaswa Kuuliza

• Je, mtoa huduma wako wa inference huthibitisha, kutoka kwenye injini inayofanya kazi, kwamba uwezo wa cache unatosha urefu wa muktadha unaotangazwa kabla ya kila mabadiliko ya usambazaji?
• Je, majaribio yake ya kabla ya uzinduzi hukagua maudhui ya matokeo kuona kama yana mantiki na data ngeni, au misimbo ya hali na kasi (latency) tu?
• Injini ya upstream inapokuwa na ripoti ya hitilafu iliyo wazi inayogusa utenganishaji wa wateja, ni utaratibu gani wa kuipandisha ngazi kabla ya uzinduzi?
• Ikiwa prompt zako zilizidi kiwango cha tokeni 681,280 kwenye modeli hii kati ya Agosti 27 na Septemba 9, je, mtoa huduma amethibitisha kama data yako ilikuwa miongoni mwa majibu 155?
• Ni injini zipi unazoendesha mwenyewe (self-hosted) katika hali ya disaggregated, na je, ziko kwenye toleo lililorekebishwa?

Cha Kufuatilia Baadaye

Fuatilia kama watoa huduma wengine wa inference na watumiaji wa SGLang watachapisha ukaguzi wao wenyewe wa ukubwa wa hifadhi dhidi ya muktadha, na kama maboresho ya upstream yanayotajwa na Cloudflare, ikiwemo #38704, yataingia kwenye matoleo. Kielelezo kitakuwa kama ukaguzi wa uwezo wa kumbukumbu utakuwa kizuizi cha kawaida cha usambazaji kwa watoa huduma wote au utabaki kuwa marekebisho ya kampuni moja baada ya tukio.