PointAcc, the lecture summary and referencesPointAcc وملخص المحاضرة والمراجع

The roadmap on slide 110 puts PointAcc in the last row, next to TorchSparse, under the heading activation sparsity. Read the row as a pair: TorchSparse is the software answer to sparse inputs, and PointAcc is the hardware answer to the same inputs. Both start from the Sparse convolution of part 11, where a layer is driven by maps of (In, Out, Wgt) tuples and each tuple contributes f_out = f_out + f_in × W_wgt.

خريطة الطريق في الشريحة 110 تضع PointAcc في الصف الأخير، بجانب TorchSparse، تحت عنوان تناثر التفعيلات (activation sparsity). اقرأ الصف كزوج: TorchSparse هو الحل البرمجي للمدخلات المتناثرة، وPointAcc هو الحل العتادي للمدخلات نفسها. وكلاهما ينطلق من الالتفاف المتناثر (sparse convolution) في الجزء 11، حيث تُقاد الطبقة بـخرائط (maps) من ثلاثيات (In, Out, Wgt)، وتساهم كل ثلاثية بـ f_out = f_out + f_in × W_wgt.

What changes between the two is where the time goes. On a GPU, the multiplies are batched into matmuls and run well once the map exists. Building the map is the problem. A point cloud has dynamic sparsity: which coordinates are occupied depends on the scene, so the map cannot be precomputed and must be rebuilt on every input. The PointAcc paper measures that cost on PointNet++-based networks and reports that more than half of the total runtime on general-purpose hardware goes to mapping operations, and that existing neural accelerators simply do not support them, so a TPU has to ship the coordinates back to its host CPU, where data movement then takes 60 to 90 percent of the runtime (Lin et al., 2021, section 3).

ما يتغير بين الاثنين هو أين يذهب الوقت. على GPU، تُجمَّع عمليات الضرب في عمليات ضرب مصفوفات (matmul) وتعمل جيدًا بمجرد وجود الخريطة. المشكلة هي بناء الخريطة. فالسحابة النقطية لها تناثر ديناميكي (dynamic sparsity): الإحداثيات المشغولة تعتمد على المشهد، لذلك لا يمكن حساب الخريطة مسبقًا ويجب إعادة بنائها مع كل دخل. تقيس ورقة PointAcc هذه التكلفة على شبكات مبنية على PointNet++، وتذكر أن أكثر من نصف زمن التشغيل الكلي على العتاد العام يذهب إلى عمليات الربط (mapping)، وأن مسرّعات الشبكات العصبية الحالية لا تدعمها أصلًا، فيضطر TPU إلى إرسال الإحداثيات إلى المعالج المضيف (host CPU)، حيث يستهلك نقل البيانات عندها 60 to 90 percent من زمن التشغيل (Lin et al., 2021, section 3).

The pairing rule, and how to turn it into an equality testقاعدة الاقتران، وكيف نحوّلها إلى اختبار تساوٍ

A 3 × 3 kernel has nine weight offsets, W−1,−1 through W1,1. Input point p contributes to output point q through offset δ exactly when p sits at q + δ. On a GPU the natural code is a loop over outputs that asks a hash table "is there an input at q + δ?". PointAcc rewrites the same condition so that no lookup is needed.

النواة (kernel) بحجم 3 × 3 لها تسع إزاحات للأوزان، من W−1,−1 إلى W1,1. نقطة الدخل p تساهم في نقطة الخرج q عبر الإزاحة δ إذا وفقط إذا كانت p واقعة عند q + δ. على GPU يكون الكود الطبيعي حلقة على المخرجات تسأل جدول تجزئة: «هل يوجد دخل عند q + δ؟». أما PointAcc فيعيد صياغة الشرط نفسه بحيث لا يحتاج إلى أي بحث في جدول (lookup).

Subtract δ from every input coordinate and the question becomes "which shifted inputs land on an output coordinate?", which is a set intersection. If both sets are sorted, an intersection is found by merging them and looking at adjacent elements: any input and output that coincide must end up side by side. This is why slide 112 adds (−1, −1) to the inputs for W1,1 and slide 111 adds (1, 1) for W−1,−1. The shift is always −δ, so the sign flips relative to the offset name.

اطرح δ من كل إحداثي دخل، فيصبح السؤال: «أي المدخلات المُزاحة تقع على إحداثي خرج؟»، وهذا تقاطع مجموعتين (set intersection). إذا كانت المجموعتان مرتبتين، نجد التقاطع بدمجهما والنظر إلى العناصر المتجاورة: أي دخل وخرج متطابقين لا بد أن ينتهيا متجاورين. لهذا تضيف الشريحة 112 القيمة (−1, −1) إلى المدخلات من أجل W1,1، وتضيف الشريحة 111 القيمة (1, 1) من أجل W−1,−1. الإزاحة دائمًا −δ، لذلك تنقلب الإشارة مقارنةً باسم الإزاحة.

Slide 111 runs the identical procedure for the opposite corner of the kernel. The table below puts the two passes side by side. Notice the symmetry: the pairs for W1,1 are the pairs for W−1,−1 with the roles of input and output exchanged, P1 with Q0 against P0 with Q1. That is exactly what p = q + δ predicts, because if p = q + δ then q = p − δ, and with the input and output clouds sharing coordinates the same two points swap places.

تنفّذ الشريحة 111 الإجراء نفسه تمامًا للزاوية المقابلة من النواة. الجدول أدناه يضع المرورين جنبًا إلى جنب. لاحظ التناظر: أزواج W1,1 هي أزواج W−1,−1 نفسها مع تبادل دوري الدخل والخرج، أي P1 with Q0 مقابل P0 with Q1. وهذا بالضبط ما تتنبأ به p = q + δ، لأنه إذا كان p = q + δ فإن q = p − δ، وبما أن سحابتي الدخل والخرج تتشاركان الإحداثيات، تتبادل النقطتان نفسهما مكانيهما.

Why a hash table is the wrong tool for siliconلماذا جدول التجزئة أداة خاطئة للسيليكون

The GPU library that PointAcc compares against builds its maps with a hash table, and on a GPU that is a reasonable choice: memory is large and random access is cheap enough. Neither holds on chip. The paper puts two numbers on it. First, a hash table sized for a real point cloud at a sensible load factor can reach 160 MB, which no accelerator can hold in SRAM. Second, to serve N lookups in parallel the SRAM needs an N-by-N crossbar so that any lane can reach any bank, and that crossbar grows as O(N²) in area (Lin et al., 2021, section 4.1).

مكتبة GPU التي يقارن PointAcc نفسه بها تبني خرائطها بجدول تجزئة، وهذا خيار معقول على GPU: الذاكرة كبيرة والوصول العشوائي رخيص بما يكفي. ولا يصح أي من الأمرين على الشريحة (on chip). وتضع الورقة رقمين على ذلك. أولًا، جدول التجزئة المصمم لسحابة نقطية حقيقية بمعامل تحميل (load factor) معقول قد يصل إلى 160 MB، وهذا ما لا يستطيع أي مسرّع حمله في SRAM. ثانيًا، لخدمة N عملية بحث على التوازي تحتاج SRAM إلى مصفوفة توصيل (crossbar) بحجم N في N حتى يصل أي مسار (lane) إلى أي بنك (bank)، وتنمو مساحة هذه المصفوفة بمقدار O(N²) (Lin et al., 2021, section 4.1).

Merging has neither problem. The Mapping Unit feeds window-sized chunks of the two sorted lists to a fixed-size bitonic merger, a parallel comparator network, and a forwarding loop carries leftover elements into the next cycle, so the lists are read in order and never probed at random. Detecting the intersection is just as local: the paper describes feeding each pair of adjacent elements of the merged array to a comparator that checks whether their coordinates are equal. With |I| shifted inputs and |O| outputs the strip has |I| + |O| cells and |I| + |O| − 1 adjacent comparisons, all independent, so they can run in a single cycle. The Mapping unit builds this from a bitonic sorting network feeding a merger of fixed length, and the paper reports that at the same parallelism the merge-sort design is 1.4x faster than the hash-table design while saving up to 14x in area (Lin et al., 2021, section 4.1).

الدمج لا يعاني من أي من المشكلتين. وحدة الربط (Mapping Unit) تغذّي دمّاجًا بيتونيًا (bitonic merger) ثابت الحجم، وهو شبكة مقارنات متوازية، بمقاطع بحجم النافذة من القائمتين المرتبتين، وتحمل حلقة تمرير (forwarding loop) العناصر المتبقية إلى الدورة التالية، فتُقرأ القوائم بالترتيب ولا يُبحث فيها عشوائيًا أبدًا. واكتشاف التقاطع محلي بالقدر نفسه: تصف الورقة تغذية كل زوج من العناصر المتجاورة في المصفوفة المدموجة إلى مقارن يتحقق من تساوي إحداثياتهما. مع |I| دخلًا مُزاحًا و|O| خرجًا، يحتوي الشريط على |I| + |O| خلية و|I| + |O| − 1 مقارنة متجاورة، كلها مستقلة، فيمكن تنفيذها في دورة واحدة. تبني وحدة الربط (mapping unit) ذلك من شبكة فرز بيتونية (bitonic sorting network) تغذّي دمّاجًا ثابت الطول، وتذكر الورقة أن تصميم الفرز بالدمج، عند التوازي نفسه، أسرع بمقدار 1.4x من تصميم جدول التجزئة ويوفّر ما يصل إلى 14x من المساحة (Lin et al., 2021, section 4.1).

One sorting unit, four point-cloud operationsوحدة فرز واحدة، وأربع عمليات على السحب النقطية

The reason PointAcc calls this block a mapping unit rather than a convolution helper is that sorting turns out to be the common core of every irregular operation a point-cloud network needs. Kernel mapping is an equality after a shift. Building the output cloud under a stride s is quantizing coordinates to the stride grid and then deduplicating, which sorting does by putting duplicates next to each other. Farthest point sampling picks the point with the largest distance, a top-1 of a ranking. k-nearest-neighbor search is a top-k of the same ranking, and ball query is a threshold on the sorted distances. The paper lists these as the operations the single ranking-based unit implements (Lin et al., 2021, sections 2.1 and 4.1). Flip the simulator above to stride 2 to see the output construction case: the five inputs collapse to fewer outputs before any offset is tried.

السبب في أن PointAcc يسمي هذه الكتلة وحدة ربط لا مساعد التفاف، هو أن الفرز يتبيّن أنه النواة المشتركة لكل عملية غير منتظمة تحتاجها شبكة السحب النقطية. ربط النواة (kernel mapping) هو تساوٍ بعد إزاحة. وبناء سحابة الخرج مع خطوة s هو تكميم الإحداثيات إلى شبكة الخطوة ثم إزالة التكرار، والفرز يفعل ذلك بوضع المكررات بجانب بعضها. وأخذ العينات بأبعد نقطة (farthest point sampling) يختار النقطة ذات المسافة الأكبر، أي أعلى عنصر (top-1) في ترتيب. والبحث عن أقرب k جيران (k-nearest-neighbor) هو أعلى k عناصر (top-k) في الترتيب نفسه، واستعلام الكرة (ball query) هو عتبة على المسافات المرتبة. وتدرج الورقة هذه العمليات على أنها ما تنفّذه الوحدة الواحدة القائمة على الترتيب (Lin et al., 2021, sections 2.1 and 4.1). غيّر المحاكي أعلاه إلى خطوة 2 لترى حالة بناء الخرج: تنهار المدخلات الخمسة إلى مخرجات أقل قبل تجربة أي إزاحة.

Slide 113 is a pair of bar charts with three baselines, and the baselines matter more than the bars. Red is an NVIDIA RTX 2080Ti, the server GPU that already runs TorchSparse-style code well. Dark grey is an Intel Xeon Skylake host paired with a TPU V3, a dense-matmul accelerator that has to send every mapping operation back to the host. Light grey is an Intel Xeon Gold 6130 CPU alone. The right-most group, GeoMean, is the geometric mean across the eight networks, so no single network dominates the average.

الشريحة 113 زوج من المخططات الشريطية بثلاثة خطوط أساس، وخطوط الأساس أهم من الأعمدة نفسها. الأحمر هو NVIDIA RTX 2080Ti، وهو GPU خوادم يشغّل كود على نمط TorchSparse جيدًا أصلًا. والرمادي الداكن هو معالج مضيف Intel Xeon Skylake مقترن بـ TPU V3، وهو مسرّع لضرب المصفوفات الكثيفة يضطر إلى إرسال كل عملية ربط إلى المضيف. والرمادي الفاتح هو معالج Intel Xeon Gold 6130 وحده. والمجموعة في أقصى اليمين، GeoMean، هي المتوسط الهندسي عبر الشبكات الثماني، فلا تهيمن شبكة واحدة على المتوسط.

Start with the GeoMean row and read the two charts together. Against the GPU, PointAcc is 3.7x faster and 22x more energy efficient. Against the TPU system it is 53x faster and saves 210x energy. Against the CPU it is 90x faster and saves 176x (the slide prints 193x, see the errata below). The paper's abstract leads with the GPU pair, 3.7x and 22x over an RTX 2080Ti, evaluated on eight models across four applications (Lin et al., 2021).

ابدأ بصف GeoMean واقرأ المخططين معًا. مقارنةً بـ GPU، يكون PointAcc أسرع بمقدار 3.7x وأكفأ في الطاقة بمقدار 22x. ومقارنةً بنظام TPU يكون أسرع بمقدار 53x ويوفّر 210x من الطاقة. ومقارنةً بـ CPU يكون أسرع بمقدار 90x ويوفّر 176x (تطبع الشريحة 193x، انظر تصحيح الشريحة أدناه). ويبدأ ملخص الورقة بزوج GPU: 3.7x و22x مقارنةً بـ RTX 2080Ti، مع تقييم على ثمانية نماذج عبر أربعة تطبيقات (Lin et al., 2021).

The network names encode the benchmark. The PointNet++ suffixes are (c) classification, (ps) part segmentation and (s) semantic segmentation. F-PointNet++ is the frustum detector built on PointNet++. MinkNet(i) and MinkNet(o) are MinkowskiUNet on an indoor dataset (S3DIS) and an outdoor dataset (SemanticKITTI), the two sparse-convolution workloads closest to part 11 (Lin et al., 2021, Table 2).

أسماء الشبكات تشير إلى معيار القياس (benchmark). لواحق PointNet++ هي (c) للتصنيف (classification)، و(ps) لتقسيم الأجزاء (part segmentation)، و(s) للتقسيم الدلالي (semantic segmentation). وF-PointNet++ هو كاشف المخروط الناقص (frustum detector) المبني على PointNet++. وMinkNet(i) وMinkNet(o) هما MinkowskiUNet على مجموعة بيانات داخلية (S3DIS) ومجموعة بيانات خارجية (SemanticKITTI)، وهما أقرب أحمال الالتفاف المتناثر إلى الجزء 11 (Lin et al., 2021, Table 2).

Why the TPU column swings from 3.4x to 269xلماذا يتأرجح عمود TPU من 3.4x إلى 269x

The GPU column is flat, between 2.4x and 8.3x, because a GPU handles both the mapping and the matmuls in the same memory. The TPU column ranges from 3.4x on DGCNN to 269x on F-PointNet++, and the spread is the lesson of the whole part. The paper attributes the gain over the TPU mainly to supporting mapping operations on chip (Lin et al., 2021, section 5.2). The paper does not break that number down per network, so the following is a reading of the chart, not a quoted result. DGCNN's neighbor search is a pairwise-distance computation in feature space, recomputed inside every EdgeConv layer, and a dense matmul unit already runs that well, so it has the least mapping work to move on chip. F-PointNet++ and the segmentation variants of PointNet++ are dominated by sampling, neighbor search and gathering, exactly the operations the TPU must hand back to the host, so removing that round trip is worth two orders of magnitude.

عمود GPU مستوٍ تقريبًا، بين 2.4x و8.3x، لأن GPU يتعامل مع الربط وضرب المصفوفات في الذاكرة نفسها. أما عمود TPU فيتراوح من 3.4x على DGCNN إلى 269x على F-PointNet++، وهذا التفاوت هو درس الجزء كله. تنسب الورقة المكسب مقارنةً بـ TPU أساسًا إلى دعم عمليات الربط على الشريحة (Lin et al., 2021, section 5.2). ولا تفصّل الورقة هذا الرقم لكل شبكة، لذا فما يلي قراءة للمخطط وليس نتيجة منقولة. البحث عن الجيران في DGCNN هو حساب مسافات زوجية في فضاء الخصائص، يُعاد حسابه داخل كل طبقة EdgeConv، ووحدة ضرب المصفوفات الكثيفة تنفّذ ذلك جيدًا أصلًا، فيكون لديه أقل قدر من عمل الربط الذي يُنقل إلى الشريحة. أما F-PointNet++ ونسخ التقسيم من PointNet++ فتهيمن عليها عمليات أخذ العينات والبحث عن الجيران والجمع (gathering)، وهي بالضبط العمليات التي يجب على TPU إعادتها إلى المضيف، لذلك فإن إزالة هذه الرحلة ذهابًا وإيابًا تساوي رتبتين عشريتين من التحسين.

Slide 114 compresses the lecture into two bullets: automated ways to find pruning ratios, and system and hardware support for different granularities. Those two bullets are two separate questions from the five that opened the deck. The first asks how much to remove from each layer. The second asks how the zeros you created turn into time and energy actually saved. Neither is worth much without the other.

تضغط الشريحة 114 المحاضرة في نقطتين: طرق مؤتمتة لإيجاد نسب التقليم (pruning ratios)، ودعم الأنظمة والعتاد للحبيبيات المختلفة. هاتان النقطتان سؤالان منفصلان من الأسئلة الخمسة التي افتُتحت بها الشرائح. الأول يسأل كم نزيل من كل طبقة. والثاني يسأل كيف تتحول الأصفار التي صنعتها إلى وقت وطاقة موفّرين فعلًا. ولا قيمة كبيرة لأي منهما دون الآخر.

Thread one: choosing the ratioالخيط الأول: اختيار النسبة

Sensitivity analysis prunes one layer at a time across a sweep of ratios, plots accuracy against ratio, and reads each layer's rate where its curve crosses an accuracy threshold. It is cheap and transparent, and its weakness is that it ignores Layer interaction: the compounding loss when many layers are pruned together, which is why its per-layer rates are only a starting point. AMC (AutoML for Model Compression) replaces the human with a DDPG agent that sees a layer embedding and emits a continuous sparsity ratio, rewarded by accuracy under a FLOPs or latency budget. NetAdapt keeps a rule instead of a policy: cut latency by a fixed step, choose the layer whose short-term fine-tuned accuracy is highest, consult a measured latency lookup table rather than FLOPs, repeat until the budget is met, then long-term fine-tune. Whichever chooses the ratios, Fine-tuning and Iterative pruning are what recover the accuracy afterwards.

تحليل الحساسية (sensitivity analysis) يقلّم طبقة واحدة في كل مرة عبر مجموعة من النسب، ويرسم الدقة مقابل النسبة، ويقرأ معدل كل طبقة عند النقطة التي يعبر فيها منحناها عتبة الدقة (accuracy threshold). وهو رخيص وشفاف، ونقطة ضعفه أنه يتجاهل تفاعل الطبقات (layer interaction): الخسارة المتراكمة عندما تُقلَّم طبقات كثيرة معًا، ولهذا فإن معدلاته لكل طبقة ليست إلا نقطة بداية. أما AMC فيستبدل الإنسان بوكيل DDPG يرى تمثيلًا (embedding) للطبقة ويُخرج نسبة تناثر متصلة، ويُكافأ بالدقة تحت ميزانية من FLOPs أو زمن الاستجابة (latency). وNetAdapt يحتفظ بقاعدة بدلًا من سياسة: اخفض زمن الاستجابة بخطوة ثابتة، واختر الطبقة التي تكون دقتها بعد الضبط الدقيق قصير المدى (short-term fine-tuning) هي الأعلى، واستعن بجدول بحث (lookup table) لزمن الاستجابة المقيس بدلًا من FLOPs، وكرّر حتى تتحقق الميزانية، ثم طبّق الضبط الدقيق طويل المدى (long-term fine-tuning). وأيًّا كان من يختار النسب، فإن الضبط الدقيق (fine-tuning) والتقليم التكراري (iterative pruning) هما ما يستعيد الدقة بعد ذلك.

Thread two: making the zeros payالخيط الثاني: جعل الأصفار مُربحة

A pruned weight is only free if the hardware skips it. EIE (Efficient Inference Engine) skips two kinds at once: static Weight sparsity stored in CSC form across an array of processing elements, and dynamic activation sparsity caught by leading non-zero detection so that a zero activation is never broadcast. NVIDIA Ampere tensor cores accept 2:4 sparsity only, and in return the Sparse tensor core uses the two-bit metadata to select operands and doubles math throughput (Mishra et al., 2021). TorchSparse handles the sparsity of point-cloud inputs in software by trading a little padding for regular batched matmuls through Adaptive grouping, and TorchSparse++ overlaps the gather and scatter with compute. PointAcc moves the same problem into hardware, with the merge-sort mapping unit of the previous concept. The granularity is the thread joining all four: the finer the sparsity, the more bookkeeping the system must do to skip it, and the coarser the sparsity, the more the pruning method must give up to fit the pattern.

الوزن المقلَّم لا يكون مجانيًا إلا إذا تخطّاه العتاد. EIE يتخطى نوعين معًا: تناثر الأوزان (weight sparsity) الثابت المخزّن بصيغة CSC عبر مصفوفة من عناصر المعالجة (processing elements)، وتناثر التفعيلات الديناميكي الذي يُلتقط بـكشف أول قيمة غير صفرية (leading non-zero detection) بحيث لا يُبث تفعيل صفري أبدًا. وأنوية NVIDIA Ampere الموترية لا تقبل إلا تناثر 2:4، وفي المقابل تستخدم النواة الموترية المتناثرة (sparse tensor core) البيانات الوصفية ذات البتين لاختيار المعاملات (operands) وتضاعف إنتاجية الحساب (Mishra et al., 2021). ويتعامل TorchSparse مع تناثر مدخلات السحب النقطية برمجيًا، مقايضًا قليلًا من الحشو (padding) بعمليات ضرب مصفوفات منتظمة ومجمّعة عبر التجميع التكيفي (adaptive grouping)، ويُداخل TorchSparse++ عمليتي الجمع والتوزيع (gather وscatter) مع الحساب. وينقل PointAcc المسألة نفسها إلى العتاد، بوحدة الربط القائمة على الفرز بالدمج من المفهوم السابق. والحبيبية (granularity) هي الخيط الذي يربط الأربعة: كلما كان التناثر أدق، زادت المحاسبة التي يجب أن يقوم بها النظام لتخطيه، وكلما كان التناثر أخشن، زاد ما يجب أن تتنازل عنه طريقة التقليم لتلائم النمط.

The bridge to the next lectureالجسر إلى المحاضرة التالية

Pruning removes weights. Quantization shrinks the ones that stay. Slide 114 sets the order for the next lecture: first the numeric data types modern computer systems actually offer, then the basic concept of neural network quantization, then the common quantization methods. The two techniques are complementary in the deep compression sense: after pruning left AlexNet with a ninth of its connections, quantizing and coding the survivors is what pushed the total to 35x in Han et al.'s pipeline, and both will show up together in the memory and energy arguments of the next lecture (Han, Mao and Dally, 2016).

التقليم يزيل الأوزان. والتكميم يقلّص الأوزان التي تبقى. تحدد الشريحة 114 ترتيب المحاضرة التالية: أولًا أنواع البيانات العددية التي توفرها أنظمة الحاسوب الحديثة فعلًا، ثم المفهوم الأساسي لتكميم الشبكات العصبية، ثم طرق التكميم الشائعة. والتقنيتان متكاملتان بمعنى الضغط العميق (deep compression): بعد أن ترك التقليم شبكة AlexNet بتُسع وصلاتها، كان تكميم الأوزان الباقية وترميزها هو ما دفع الإجمالي إلى 35x في خط معالجة Han et al.، وستظهر التقنيتان معًا في حجج الذاكرة والطاقة في المحاضرة التالية (Han, Mao and Dally, 2016).

Slide 115 lists nineteen references. Read as a map of the lecture they fall into six groups: foundations of model compression and energy (items 1, 2, 4, 5, 6), pruning criteria (3, 12, 13, 15), structured and channel pruning (7, 10, 11, 14, 16, 17), automated ratio search (9), hardware support (8), and one-shot pruning of large language models (18), with Prof. Han's TinyML course (19) as the source the whole deck follows. The Sources block at the end of this part gives a link for each one that has an archival home.

تدرج الشريحة 115 تسعة عشر مرجعًا. وإذا قرأتها كخريطة للمحاضرة فهي تنقسم إلى ست مجموعات: أسس ضغط النماذج والطاقة (البنود 1, 2, 4, 5, 6)، ومعايير التقليم (3, 12, 13, 15)، والتقليم المهيكل وتقليم القنوات (7, 10, 11, 14, 16, 17)، والبحث المؤتمت عن النسب (9)، ودعم العتاد (8)، والتقليم دفعة واحدة (one-shot) لنماذج اللغة الكبيرة (18)، مع مقرر TinyML للبروفيسور Han (19) بوصفه المصدر الذي تتبعه الشرائح كلها. وكتلة المصادر في نهاية هذا الجزء تعطي رابطًا لكل مرجع له موطن أرشيفي.

The list is also worth checking against the slides themselves, because several of the papers this lecture leaned on hardest are cited in slide footers but never make it to the reference page. Every hardware system in the second half of the deck is in that position. If you cite from this lecture in your own writing, take the references from the Sources below rather than from slide 115.

تستحق القائمة أيضًا أن تُراجع مقابل الشرائح نفسها، لأن عدة أوراق اعتمدت عليها هذه المحاضرة أكثر من غيرها مذكورة في تذييلات الشرائح لكنها لا تصل أبدًا إلى صفحة المراجع. وكل نظام عتادي في النصف الثاني من الشرائح في هذا الوضع. وإذا استشهدت من هذه المحاضرة في كتاباتك، فخذ المراجع من المصادر أدناه لا من الشريحة 115.