stageload के पहले नोट में सिर्फ़ एक पाइपलाइन मापी गई थी, Pixal3D। text-to-image पाइपलाइन का ढाँचा भी वैसा ही है: टेक्स्ट एनकोडर, डीनॉइज़र और इमेज डिकोडर एक के बाद एक चलते हैं। इसलिए 6 अक्टूबर को मैंने ऐसी एक पाइपलाइन मापी: diffusers में Qwen-Image-2.1, उसी 48 GB वाले Mac पर। इसका टेक्स्ट एनकोडर 16.3 GB, ट्रांसफ़ॉर्मर 13.3 GB और VAE 1.3 GB लेता है। हर रन ने एक 1024 × 1024 इमेज बनाई, 20 स्टेप में, और हर रन मेमोरी गार्ड के तहत अपने अलग प्रोसेस में चला।
eager का मतलब है आम from_pretrained(...).to("mps")। staged में पाइपलाइन के दोनों बड़े मॉडलों की जगह स्टैंड-इन रखे गए। वे .config का जवाब चेकपॉइंट से देते हैं, ताकि पाइपलाइन डीनॉइज़िंग शुरू होने से पहले कॉन्फ़िग पढ़ सके, और किसी भी दूसरे इस्तेमाल पर असली मॉडल लोड करते हैं। तीन हुक encode_prompt, prepare_latents और _unpack_latents पर स्टेज की शुरुआत बताते हैं। पाइपलाइन का कोड नहीं बदला।
एनकोडिंग और डीनॉइज़िंग के दौरान eager 31 से 33 GB पर रहा। VAE डिकोड को वज़न के ऊपर लगभग 11 GB और चाहिए, और इसी से वह 43.6 GB तक पहुँचा; स्वैप 8 GB बढ़ा और इमेज लिखने से पहले ही गार्ड ने उसे रोक दिया। staged ने डिकोड से पहले ट्रांसफ़ॉर्मर को रिलीज़ कर दिया। उसका पीक एनकोडिंग में 19.0 GB और डिकोड में 14.4 GB रहा, और उसके दोनों रन में स्वैप नहीं बढ़ा।
staged को दोनों मॉडल लोड करने में 13 सेकंड लगे। डीनॉइज़िंग में उसके पहले रन में 109 सेकंड लगे, दूसरे में 79 सेकंड, और eager में 77.5 सेकंड; पहला रन धीमा क्यों था, यह उसके ट्रेस से पता नहीं चलता।
जो मैं नहीं दिखा सका
staged के दोनों रन ने बिट दर बिट एक जैसी इमेज बनाई। इस Mac पर eager ने कोई इमेज नहीं बनाई, इसलिए ये रन यह नहीं दिखाते कि staged लोडिंग eager जैसी ही इमेज देती है। इससे पहले का एक eager रन लोडिंग भी पूरी नहीं कर पाया: वह एक वीडियो जॉब ख़त्म होने के एक मिनट बाद शुरू हुआ, और स्वैप 10 GB बढ़ने में सिर्फ़ 18 सेकंड लगे।
कोड bench/qwen_image.py में है, और ट्रेस व सारांश रिपॉज़िटरी में।