ሁለት የDGX Spark ደረጃ ማሽኖች፣ አንድ ሞዴል፡ በእያንዳንዱ ማሽን ላይ የተባዛ ቅጂ ከመከፋፈሉ ይልቅ

ኦፕስ2026-10-31

ለሰባት ሳምንታት የአካባቢው የቋንቋ ሞዴላችን በሁለት NVIDIA GB10 ማሽኖች ላይ በቴንሰር ፓራሌሊዝም ተከፋፍሎ ሰርቷል። በጥር 22 ቀን ይህንን በእያንዳንዱ ማሽን ላይ የሞዴሉን ሙሉ ቅጂ እና ከፊት የተቀመጠ ዝቅተኛ-ግንኙነት ፕሮክሲ በመተካት ቀይረነዋል። የመረጃ ፍሰት ከወደ 180 ወደ 210 ቶከኖች በሰከንድ ጨምሯል፣ እና አሁን ማንኛውም ማሽን ሞዴሉን ሳያጠፋ መጀመር ይችላል።

ለምን እንደተከፋፈለ

እያንዳንዱ ማሽን CPU እና GPU የሚጋሩት 128 GB ማህደረ ትውስታ አለው። በመስከረም ሞዴሉ በአንድ ማሽን ላይ ተስምቷል፣ ነገር ግን ካሺው በጣም አልተስማማም፡ የተጠቀምነው የvLLM ግንባታ የዚህን ሞዴል KV ካሺ በFP8 ማከማቸት ስላልቻለ፣ ካሺው በBF16 ነበር፣ እና አንድ ማሽን ለ499,110 ቶከኖች ቦታ ነበረው። ይህ ከሞዴሉ ሙሉ አውድ (context) 262,144 ቶከኖች ጋር ከሁለት ጥያቄዎች ያነሰ ነው። በቀጥታ የአውታረ መረብ ማገናኛ በኩል በቴንሰር ፓራሌሊዝም በሁለቱም ማሽኖች ላይ ሲከፋፈል፣ ካሺው ወደ ከሦስት ሚሊዮን ቶከኖች በላይ አደገ። ሞዴሉን የተከፋፈልነው ለፍጥነት ሳይሆን ለቦታ ነው።

የተቀየረው

የተመሳሳይ ሞዴል አዲስ 4-ቢት ግንባታ (NVFP4, በኳንታይዜሽን-አወቅ ዲስቲሌሽን የተሰራ) ወደ 71 GiB ማህደረ ትውስታ ይወስዳል፣ እና ለGB10 የሚሆን የማህበረሰብ vLLM ግንባታ (eugr/spark-vllm-b12x) ካሺውን በFP8 ያሰራል። አሁን አንድ ማሽን ሙሉውን ሞዴል እና ከ0.76 እስከ 1.08 ሚሊዮን ቶከኖች ያለውን ካሺ ይይዛል፣ ይህም ማሽኑ ምን ያህል ማህደረ ትውስታ እንደሚሰጥ በመመርኮዝ ለ2.9 እስከ 4.1 ጥያቄዎች በሙሉ አውድ ቦታ ይሰጣል። ሁለቱም ቅጂዎች የሞዴሉን የራሱ ስፔኩላቲቭ ዲኮዲንግ (MTP, አራት ድራፍት ቶከኖች) ይጠቀማሉ። ከመቀየራችን በፊት በአዲሱ ግንባታ ላይ የመሳሪያ-ጥሪ ሙከራችንን አካሄድን፡ 86 ነጥብ አግኝቷል፣ የተተካው ግንባታ 75 ነጥብ አግኝቷል።

የለካነው

አንድ ሶፍትዌር ጥቅል በራሱ፣ በአንድ ጊዜ በሚያገለግላቸው ጥያቄዎች ብዛት መሰረት፡ ከአጭር ጥያቄዎች ጋር፣ 1 ጥያቄ በሰከንድ 36 ቶከኖች ሰጠ፣ 4 ጥያቄዎች 82፣ 8 ጥያቄዎች 109 እና 16 ጥያቄዎች 150 ሰጡ። በኢሜይል ኤጀንታችን ረጅም ጥያቄዎች ጋር፣ 4 ጥያቄዎች 81፣ 8 ጥያቄዎች 113 እና 16 ጥያቄዎች 87 ብቻ ሰጡ፡ ከስምንት ጥያቄዎች በላይ ሲሆኑ፣ ተጨማሪ ጥያቄዎች ፍጥነቱን ያዘገዩታል።

ለአንድ ከሰዓት፣ አንዱ ሶፍትዌር ጥቅል በአንድ ጊዜ ከፍተኛው 12 ጥያቄዎችን ሲቀበል ሌላኛው 8 ጥያቄዎችን ተቀበለ። የመጀመሪያው በሰከንድ 91 እስከ 93 ቶከኖች አመርቶ በደቂቃ 26 እስከ 27 ጥያቄዎችን አጠናቀቀ፤ ሁለተኛው በሰከንድ 81 እስከ 83 ቶከኖች እና በደቂቃ 22 ጥያቄዎችን አመረተ። ሁለቱም አሁን 12 ጥያቄዎችን ይቀበላሉ።

የተወገደው

ቦታ። የተከፋፈለው ሞዴል ከሦስት ሚሊዮን በላይ ቶከኖች ያለው አንድ ካሽ ላቦታ ነበረው፤ ሶፍትዌር ጥቅሎቹ ግን ሁለት ትንሽ ካሽ ላቦታ አሏቸው፣ እና አንድ ጥያቄ የሚያገለግለውን ሶፍትዌር ጥቅል ካሽ ላቦታ ብቻ መጠቀም ይችላል። ኤጀንቶቻችን ብዙ አጭር እና መካከለኛ ጥያቄዎችን ይልካሉ፣ ለእነሱም ምርታማነት ይበልጥ አስፈላጊ ነበር። ጥቂት በጣም ረጅም ማዕከሎችን በአንድ ጊዜ ካገለገሉ፣ መከፋፈል ገናም የተሻለ ምርጫ ሊሆን ይችላል። የተከፋፈለውን አደረጃጀት ጠበቅን፣ ወደ ኋላ መመለስ አንድ ስክሪፕት ብቻ ይጠይቃል።

በመቀያየር ጊዜ የተሳሳተው

1. አስራ አንድ ደቂቃ ያለ ሞዴል፣ ከዚያም 30 ሰከንድ የ502 ስህተቶች። የተከፋፈለው ሞዴል ሶፍትዌር ጥቅሉ በተመሳሳይ ማሽኖች ላይ እስኪጫን ድረስ ማቆም ነበረበት፣ ስለዚህ ኤጀንቶቻችን በግምት አስራ አንድ ደቂቃ ተጠበቁ። የመጀመሪያው ሶፍትዌር ጥቅል ሲነሳ፣ ፕሮክሲው ለተጨማሪ 30 ሰከንድ "502 no live upstreams" ብሎ መልሶ ማመልሰት ቀጠለ፡ ወደ ታች ያሉትን ማሽኖች (backends) እየተሰሩ እያሉ እንደ አልተሳኩ ስለ ሰየማቸው (max_fails=3, fail_timeout=30s)፣ ጊዜው እስኪያልቅ ድረስ እንደገና አልሞከራቸውም።
2. ፕሮክሲውን ያለፈ ደንበኛ። ከባች ስራዎቻችን አንዱ የመጀመሪያውን ማሽን አድራሻ በኮንፊጉ ውስጥ ስለነበረው፣ ሙሉ ጫካው ወደ አንዱ ሶፍትዌር ጥቅል ሄዶ ሌላኛው ቦታ ሲኖረው ባዶ ቆየ። አሁን ሁሉም ደንበኞች በፕሮክሲው ውስጥ ያልፋሉ፤ የማሽኖቹ የራሳቸው አድራሻዎች ለጤና ምርመራ ብቻ ናቸው።
3. የዘለቁ መለኪያዎች። የምርታማነት ክትትል ስርዓታችን የvLLMን /metrics በፕሮክሲው በኩል ያነበበው። በሁለት ወደ ታች ያሉ ማሽኖች (backends) ሲኖሩ፣ ተከታታይ ንባቦች ከተለያዩ ሶፍትዌር ጥቅሎች ስለመጡ፣ ቆጣሪዎቹ ወደፊትና ወደ ኋላ ዘልቀው ስለተንሸራተቱ፣ ክትትል ስርዓቱ ሞዴሉ እንደተራራ ሪፖርት አደረገ። አሁን እያንዳንዱን ሶፍትዌር ጥቅል በቀጥታ ያነባል እና ይደምራቸዋል።
4. አዲሱን ቅጂ ለማቆም የሚችል የቆየ የክትትል ስርዓት። በተከፋፈለው አደረጃጀት፣ ሞዴሉ መልስ መስጠት ሲቆም አገልግሎቱን እንደገና የሚያስነሳ የክትትል ስርዓት ነበረ። አዲሱ አገልግሎት ከቆየው ጋር Conflicts= ስለሚገልጽ፣ ያ ማስነሳት አዲሱን ቅጂ ያቆመው ነበር። የእኛ የኦፕስ ንብርብር የተነቁ (enabled) ነገር ግን የማይሰሩ (not running) ዩኒቶችን ስለሚያስነሳ፣ በቀላሉ ማቆም ብቻ ሳይሆን በsystemctl disable --now ማጥፋት ነበረበት።
5. ሌላ ስራ በሚሰራበት ማሽን ላይ ያለ ማህደረ ትውስታ። አንዱ ማሽን የእኛን የውሂብ ጎታዎች እና የሳይት ግንባታዎችም ያስከራል። የ vLLM gpu-memory-utilization በ0.78 ሲሆን፣ ለሌሎች ሁሉ 5 GiB ብቻ ቀርቶ ነበር፣ ስለዚህ ወደ 0.74 ቀንሰን ሌላው ቅጂ ጫናውን እየተሸከመ ሳለ ያንን ቅጂ ብቻ እንደገና አስነስተናል። በእነዚህ ማሽኖች ላይ፣ ለ vLLM የሚሰጡት ድርሻ ከሌሎች ሁሉ ጋር ከተመሳሳይ ማህደረ ትውስታ ይወጣል።

ከእነዚህ ማሽኖች ሁለት ካሉዎት

• ሞዴሉ እና የሚያስፈልግዎት ካሽ በአንድ ማሽን ላይ ከገቡ፣ በእያንዳንዱ ማሽን ላይ አንድ ቅጂ በዝቅተኛ-ግንኙነት (least-connection) ፕሮክሲ ውስጥ ያስከሩ። አንዱ ማሽን የሚያስፈልግዎትን ካሽ ማቋቋም ካልቻለ ብቻ ሞዴሉን ይክፈሉ።
• የቡድን ስራዎችን እና የቆዩ ቅንብሮችን ጨምሮ እያንዳንዱን ደንበኛ ወደ ፕሮክሲው ያመሩ።
• ከእያንዳንዱ ቅጂ በቀጥታ መለኪያዎችን ያንብቡ።
• በእያንዳንዱ ማሽን ላይ ሌላ ምን እንደሚሰራ መሠረት አድርጎ ለእያንዳንዱ ማሽን የራሱን የማህደረ ትውስታ ድርሻ ይስጡ።
• በራስዎ ትራፊክ መሠረት አንድ ቅጂ በአንድ ጊዜ ስንት ጥያቄዎችን እንደሚያገለግል ይወስኑ፤ ለእኛ ድብልቅ፣ 12 ከ8 ይሻላል።
• ለመቀያየሩ ሞዴሉን ለአንድ ቅጂ ለማስነሳት እንደሚወስደው ጊዜ ያህል እንደሚወስድ ተጠብቀው ይዘጋጁ።

Factory Floor ለአንድ ወይም ለሁለት ማሽኖች የፕሮክሲ እና የማስነሻ ቅንብሮችን፣ ሞዴሎችን ከመቀያየራችን በፊት የምናካሄደውን የጤና ምርመራ እና የመሳሪያ አጠቃቀም ሙከራ፣ እንዲሁም ለቀሪው ማሽን የክትትል ስርዓቶችን እና የማህደረ ትውስታ የደህንነት ገደቦችን ያቀርባል።