IonQ کا decoder ایک CPU پر چلا، مگر quantum hardware پر نہیں

IonQ نے 22 ستمبر 2026 کے اعلان میں بتایا کہ اس کا کوانٹم خرابیوں کا decoder ایک CPU پر ایسے سرکٹس کے ساتھ آزمایا گیا جو 408 منطقی کیوبٹس تک کے نظام کی نقل کرتے تھے۔ کمپنی نے سب سے بڑے workload کے لیے 31.5 ملین سے زیادہ operations کا عدد بھی پیش کیا۔ CPU پر چلنے والا decoder حقیقی تھا، لیکن اسے خرابیوں کے اشارے کسی چلتے ہوئے کوانٹم کمپیوٹر سے نہیں ملے تھے۔

PostQuantum.com کے 23 ستمبر کے تکنیکی تجزیے نے واضح کیا کہ اشارے simulated trapped-ion نظام سے آئے اور تحقیق ابھی ہم مرتبہ جانچ سے نہیں گزری۔ یوں نتیجہ ایک مجوزہ مشین کے لیے decoder کی رفتار کے بارے میں ہے، اس پیمانے کے حقیقی کوانٹم ہارڈویئر کی کارکردگی کے بارے میں نہیں۔ یہی فرق اس اعلان کی انجینیئرنگ قدر اور اس کی موجودہ حد، دونوں کو سمجھنے کے لیے بنیادی ہے۔

Decoder کے سامنے کون سا کام رکھا گیا؟

اصل تحقیقی preprint میں تین compiled workloads درج ہیں: ایک measurement-induced phase transition سرکٹ اور Heisenberg ماڈل کے دو سرکٹس۔ انہیں IonQ کی مجوزہ Walking Cat trapped-ion architecture کے مطابق ترتیب دیا گیا، پھر circuit-level noise simulation سے وہ اشارے پیدا کیے گئے جن سے decoder کو خرابی کا اندازہ لگانا تھا۔ آزمائش کا ہدف پہلے سے جمع شدہ data کو بعد میں صاف کرنا نہیں تھا؛ decoder کو اشاروں کی مسلسل آمد کے ساتھ نتائج دینے تھے۔

سب سے بڑی ترتیب میں 68 memory blocks اور 20 magic-state factories تھے۔ memory blocks میں 408 منطقی کیوبٹس رکھے گئے تھے۔ یہ simulated نظام کی ساخت ہے، آزمائش میں موجود حقیقی کیوبٹس کی گنتی نہیں۔ چھوٹی ترتیبوں میں 102 منطقی کیوبٹس تھے، اس لیے نتائج میں ایک ہی سائز یا ایک ہی قسم کا سرکٹ بار بار نہیں دہرایا گیا۔ تاہم تینوں workloads اسی مخصوص architecture اور اس کے noise model سے وابستہ تھے؛ انہیں تمام کوانٹم مشینوں کا نمائندہ benchmark نہیں سمجھا جا سکتا۔

اس ترتیب میں دو طرح کے decoder مختلف کام کرتے تھے۔ error decoder خرابیوں کا مسلسل حساب رکھتا تھا، جبکہ outcome decoder منطقی پیمائش کے وقت جلد نتیجہ فراہم کرتا تھا تاکہ مجوزہ computation آگے بڑھ سکے۔ اس تقسیم کی اہمیت یہ ہے کہ صرف مجموعی رفتار کافی نہیں: جس پیمائش پر اگلا مرحلہ منحصر ہو، اس کا جواب مقررہ وقت میں پہنچنا بھی ضروری ہے۔ آزمائش نے ان کاموں کو ایک ہی عام processor پر ساتھ چلایا۔

31.5 ملین کی گنتی دراصل کیا ہے؟

کمپنی کے اعلان میں 31.5 ملین سے زیادہ quantum operations کی تعبیر استعمال ہوئی ہے۔ تحقیقی جدول میں سب سے بڑے workload کے سامنے 31,548,792 syndrome-extraction cycles درج ہیں، جو تمام 88 blocks پر جمع کیے گئے ہیں۔ چونکہ blocks ایک مشترک گھڑی کے ساتھ آگے بڑھتے ہیں، یہ عدد ایک سرکٹ کی اتنی ہی الگ الگ منطقی gates کی گنتی نہیں۔ کمپنی کی سرخی اور جدول کا عدد تقریباً یکساں ہیں، مگر ان کے لیے استعمال ہونے والی اصطلاح اور گننے کا طریقہ واضح رکھنا ضروری ہے۔

اسی جدول میں اس workload کے لیے 555,130 T gates اور 1,318,310 منطقی پیمائشیں الگ درج ہیں۔ دوسرے workload میں T gates کی تعداد دس لاکھ سے زیادہ تھی، لیکن اس نے 102 منطقی کیوبٹس استعمال کیے۔ اس لیے «زیادہ سے زیادہ کیوبٹس» اور «زیادہ سے زیادہ T gates» ایک ہی تجربے کی خصوصیات نہیں ہیں۔ مختلف اعداد کو ایک تصوراتی مشین کی واحد کارکردگی بنا کر پیش کرنے سے benchmark کا مطلب بدل جاتا ہے۔

CPU نے وقت کی حد کیسے پوری کی؟

Decoding ایک 2024 MacBook Pro کے Apple M4 Max processor پر چلائی گئی۔ اس کے 12 cores decoder کے لیے استعمال ہوئے: آٹھ مسلسل error decoding کے لیے اور چار منطقی پیمائشوں کے outcome decoding کے لیے۔ پیمائش میں دورانِ عمل error model بنانے اور ایک ہی chip پر متعدد decoding کاموں کی باہمی مسابقت کا وقت شامل تھا۔ اس لحاظ سے نتیجہ صرف الگ تھلگ decoding algorithm کی رفتار نہیں، بلکہ اس کے اہم software pipeline کا benchmark ہے۔

وقت کی کھڑکی خود تجربے کا مفروضہ تھی۔ دو چھوٹے workloads کے لیے ہر syndrome-extraction cycle کا دورانیہ 1 millisecond اور سب سے بڑے کے لیے 5 milliseconds رکھا گیا۔ اگر decoder مقررہ وقت سے پیچھے رہتا تو مجوزہ schedule میں خرابی جانچ کے اضافی cycles شامل ہوتے۔ اس اضافے کو stretch کہا گیا: یعنی فوری جواب دینے والے decoder کے مقابلے میں computation کتنی لمبی ہو جاتی۔ یہ حقیقی مشین پر ناپا گیا توقف نہیں، simulated schedule پر decoder کی تاخیر کا اثر ہے۔

دو-qubit gate کی فرضی error rate 10 کی منفی چوتھی طاقت رکھنے پر تینوں workloads میں stretch 0.3 فیصد سے کم رہا۔ error rate پانچ گنا کرنے پر بھی یہ 12 فیصد سے کم تھا۔ سب سے بڑے workload میں کم noise پر stretch 0.02 فیصد تھا، لیکن اسے سائز بڑھنے سے decoding آسان ہونے کا ثبوت نہیں سمجھنا چاہیے: اس workload کو ہر cycle کے لیے زیادہ وقت دیا گیا تھا۔ بڑھتے ہوئے noise کے ساتھ مشکل decoding windows زیادہ دیر بھی لے سکتی ہیں، جس سے مجموعی رکاوٹ بڑھتی ہے۔

حقیقی ہارڈویئر کے بارے میں کیا ثابت نہیں ہوا؟

اس آزمائش میں syndrome data circuit-level simulation سے بنا؛ کسی ion trap سے decoder تک براہِ راست نہیں پہنچا۔ حقیقی نظام میں control electronics سے data کی منتقلی، جسمانی readout اور decoder کے فیصلوں کا باہمی وقت بھی اہم ہوگا۔ simulation میں بعض logical-control کام شامل تھے، مگر ان کا وقت پیش کردہ decoder timings میں شامل نہیں تھا۔ اس لیے دستیاب اعداد مکمل hardware اور software نظام کی مجموعی تاخیر نہیں بتاتے۔

Simulation کی ایک اور حد factories سے متعلق ہے۔ magic-state factories کے decoding کام کو شامل کیا گیا، مگر بڑے پیمانے کی simulation ممکن بنانے کے لیے ابتدائی physical magic state کی جگہ stabilizer state استعمال ہوئی۔ cat-state factory کو مکمل طور پر simulate نہیں کیا گیا۔ یہ انتخاب decoder پر آنے والے کام کی رفتار جانچنے کے مقصد سے مطابقت رکھتا ہے، لیکن factories سے نکلنے والی states کے حقیقی معیار یا مکمل مشین کی کامیابی کی شرح کو ثابت نہیں کرتا۔

نتائج بنیادی طور پر یہ بتاتے ہیں کہ decoder مقررہ clock اور noise مفروضوں کے تحت کتنی جلدی جواب دے سکا اور تاخیر سے schedule کتنا بڑھا۔ ان مکمل workloads کے لیے computation کے درست جواب تک پہنچنے کی مجموعی شرح یا decoder کے ناکام ہو کر computation دوبارہ شروع کرانے کے مکمل اعداد پیش نہیں کیے گئے۔ تحقیق کی ہم مرتبہ جانچ بھی ابھی باقی ہے۔ اگلا فیصلہ کن ثبوت حقیقی trapped-ion hardware سے آنے والے اشاروں، data کی منتقلی، control logic اور منطقی نتائج کو ایک ہی آزمائش میں ناپنے سے ملے گا؛ موجودہ اعلان اس مرحلے تک نہیں پہنچا۔

یہ بھی پڑھیں:

• Play Books دس لاکھ کتابوں تک پہنچا—مگر دائرہ بنیادی طور پر انگریزی ہے
• AI نے ملازمین کم نہیں کیے، مگر نئی بھرتی کا دروازہ ضرور تنگ ہوا
• پاکستانی طلبہ کے لیے ایک سال کا Gemini—معاہدے میں کیا طے ہوا؟