BitDelta: एक ग्राफिक्स क्लस्टर से 14 Zen मॉडल की सेवा

सूक्ष्म-अनुकूलित मॉडल रूपों की सेवा का अर्थशास्त्र स्वभाव से प्रतिकूल है।

BF16 में एक 70B पैरामीटर मॉडल को 140GB ग्राफिक्स मेमोरी चाहिए। यदि उस मॉडल के 14 सूक्ष्म-अनुकूलित रूप हों — हर एक अलग क्षमता प्रोफ़ाइल, क्षेत्र विशेषज्ञता, या व्यवहार समायोजन — तो सीधी सेवा वास्तुकला को 14 अलग मॉडल लोड चाहिए: 1.96TB ग्राफिक्स मेमोरी, 14 अलग अनुमान प्रक्रियाएँ, और 14x अवसंरचना लागत। पहले के बाद हर रूप के लिए आप लगभग पूरी तरह दोहराए गए आधार ज्ञान की पूरी कीमत चुकाते हैं।

BitDelta (arXiv:2402.10193) इस अर्थव्यवस्था को तोड़ता है। अंतर्दृष्टि सुंदर है और गणित सरल।

गणितीय आधार

W_base को आधार मॉडल का भार मैट्रिक्स मानें और W_ft को सूक्ष्म-अनुकूलित रूप का संगत भार मैट्रिक्स। व्यवहार डेल्टा यह है:

Δ = W_ft - W_base

BitDelta इस डेल्टा को 1-बिट परिशुद्धता तक संपीड़ित करता है:

W_ft ≈ W_base + α · sign(Δ)

जहाँ α प्रति-मैट्रिक्स स्केल गुणक है, जो Δ के निरपेक्ष मान के औसत के रूप में गिना जाता है:

α = (1/n) · ||Δ||_1 = mean(|Δ_ij|)

चिह्न संक्रिया हर अदिश डेल्टा को एक बिट तक घटाती है — धनात्मक या ऋणात्मक। स्केल गुणक α परिमाण लौटाता है। साथ मिलकर, यह सन्निकटन सूक्ष्म-अनुकूलन अद्यतन की दिशात्मक जानकारी को पूर्ण-परिशुद्धता डेल्टा की संग्रह लागत के 1/32 पर पकड़ता है (प्रति पैरामीटर तत्व 1 बिट बनाम 32 बिट)।

यह क्यों काम करता है? बड़े पूर्वप्रशिक्षित मॉडल पर सूक्ष्म-अनुकूलन ऐसे डेल्टा बनाता है जो अपेक्षा में आधार भारों की तुलना में छोटे होते हैं। आधार मॉडल भाषा की प्रमुख संरचना पकड़ता है; सूक्ष्म-अनुकूलन उस संरचना के ऊपर व्यवहार संशोधन पकड़ता है। डेल्टा छोटा हो तो हर तत्व का चिह्न उस तत्व का सबसे अधिक जानकारी वाला निरूपण है — परिमाण डेल्टा मैट्रिक्स पर लगभग एकसमान रहता है, इसलिए α · sign(Δ) एक कुशल कोड है।

इसे अधिक औपचारिक रूप से कहा जा सकता है। यदि Δ_ij को स्थान 0 और स्केल b वाला लाप्लास यादृच्छिक चर मानें:

Δ_ij ~ Laplace(0, b)
|E[sign(Δ) | |Δ|]| = 1 for all nonzero Δ

चिह्न दिशात्मक जानकारी को पूरी तरह रखता है। जानकारी का नुकसान केवल परिमाण के बदलाव में है, जिसे अकेला स्केल गुणक α आंशिक रूप से वापस लाता है। जहाँ परिमाण का बदलाव कम हो (व्यवहार संशोधन, ज्ञान हस्तांतरण नहीं), सन्निकटन कसा हुआ है।

मेमोरी में कमी: BF16 में 70B मॉडल के लिए आधार भार 140GB घेरते हैं। हर सूक्ष्म-अनुकूलित रूप का डेल्टा, पूर्ण BF16 में, और 140GB जोड़ता। BitDelta प्रारूप में हर डेल्टा लगभग 8.75GB घेरता है (70B बिट = 8.75GB, और α अदिश नगण्य हैं)। 14 रूपों का क्लस्टर 14 × 140GB = 1.96TB से 140GB + 14 × 8.75GB ≈ 262GB पर आता है — 87% की कमी।

सेवा वास्तुकला

┌─────────────────────────────────────────────────────────────────┐
│                    GPU CLUSTER (8x H100, 80GB each)             │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │              BASE WEIGHTS (140GB, HBM resident)          │   │
│  │  W_base for zen4-70b: attention, FFN, embeddings, norms  │   │
│  └──────────────────────────────┬───────────────────────────┘   │
│                                 │ shared read                    │
│  ┌──────────────────────────────▼───────────────────────────┐   │
│  │           DELTA CACHE (≈8.75GB per variant)              │   │
│  │  zen4-coder:    α_coder,    sign(Δ_coder)    [8.75GB]    │   │
│  │  zen4-ultra:    α_ultra,    sign(Δ_ultra)    [8.75GB]    │   │
│  │  zen4-math:     α_math,     sign(Δ_math)     [8.75GB]    │   │
│  │  zen4-writer:   α_writer,   sign(Δ_writer)   [8.75GB]    │   │
│  │  zen4-legal:    α_legal,    sign(Δ_legal)    [8.75GB]    │   │
│  │  zen4-medical:  α_medical,  sign(Δ_medical)  [8.75GB]    │   │
│  │  ...14 total...                                           │   │
│  └──────────────────────────────┬───────────────────────────┘   │
│                                 │                                │
│  ┌──────────────────────────────▼───────────────────────────┐   │
│  │              REQUEST ROUTER                               │   │
│  │  model_id → delta_load → reconstruct W_ft → inference    │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

अनुमान के समय सेवा पाइपलाइन यह है:

1. अनुरोध model: "zen4-coder" के साथ आता है
2. राउटर zen4-coder की डेल्टा कैश प्रविष्टि पहचानता है
3. प्रभावी भार वहीं पुनर्निर्मित करें: W_eff = W_base + α_coder · sign(Δ_coder)
4. पुनर्निर्मित भारों के साथ अग्र पास चलाएँ
5. प्रतिक्रिया लौटाएँ

चरण 3 महत्वपूर्ण पथ है। पुनर्निर्माण एक फ्यूज्ड CUDA कर्नेल है जो आधार भार और डेल्टा बिट एक साथ पढ़ता है, और पूरा W_eff HBM में साकार किए बिना रजिस्टर या साझा मेमोरी में प्रभावी भार बनाता है। पुनर्निर्माण और मैट्रिक्स गुणन एक ही कर्नेल पास में फ्यूज हो सकते हैं — पुनर्निर्मित भार कभी स्वतंत्र टेंसर के रूप में पूरा अस्तित्व में नहीं आता।

# Simplified reconstruction kernel (conceptual)
def fused_bitdelta_linear(
    x: torch.Tensor,          # input activations [batch, seq, d_in]
    w_base: torch.Tensor,     # base weight [d_out, d_in] in HBM
    delta_sign: torch.Tensor, # 1-bit delta [d_out, d_in] packed as int8
    alpha: torch.Tensor,      # scale factor [d_out] or scalar
) -> torch.Tensor:
    # In practice: single CUDA kernel, no intermediate w_eff allocation
    # Conceptually equivalent to:
    delta_unpacked = unpack_bits(delta_sign).to(w_base.dtype)  # {-1, +1}
    w_eff = w_base + alpha.unsqueeze(1) * delta_unpacked
    return torch.nn.functional.linear(x, w_eff)

फ्यूज्ड कर्नेल तरीका HBM बैंडविड्थ की चरम खपत को आधार मॉडल के भारों के लगभग 1.5x पर रखता है — 2x पर नहीं, क्योंकि डेल्टा पैक्ड बिट प्रारूप में पढ़ा जाता है और फ्यूज्ड संक्रिया के दौरान तेज़ SRAM में अनपैक होता है।

विलंब प्रोफ़ाइल

व्यवहार में, 14 रूपों वाले Zen सेवा क्लस्टर पर:

रूप	P50 पहला टोकन	P99 पहला टोकन	आधार रेखा से
zen4 (आधार)	18ms	42ms	1.0x
zen4-coder	21ms	48ms	1.17x
zen4-ultra	22ms	51ms	1.22x
zen4-math	21ms	47ms	1.17x
zen4-writer	20ms	45ms	1.11x

BitDelta पुनर्निर्माण से पहले टोकन तक का अतिरिक्त समय 2-4ms है — सामान्य प्रॉम्प्ट लंबाई की प्रीफिल लागत की तुलना में नगण्य। पुनर्निर्माण कर्नेल गणना-बद्ध है, मेमोरी-बद्ध नहीं, इसलिए यह ग्राफिक्स प्रोसेसर की पीढ़ियों के साथ अच्छी तरह बढ़ता है।

उत्पादन थ्रूपुट (टोकन/सेकंड) आधार मॉडल और किसी भी BitDelta रूप के बीच समान है, क्योंकि पुनर्निर्माण केवल प्रीफिल चरण में होता है। KV कैश भरने के बाद, स्वप्रतिगामी उत्पादन चरण मानक मैट्रिक्स-गुणन पथ इस्तेमाल करता है।

गुणवत्ता: 1-बिट संपीड़न में क्या खोता है?

ईमानदार उत्तर: थोड़ी मात्रा, सावधानी से बँधी हुई।

BitDelta की गुणवत्ता गिरावट कार्य पर निर्भर है। जो कार्य सूक्ष्म-अनुकूलन डेटा में अच्छी तरह मौजूद हैं, वहाँ व्यवहार डेल्टा मजबूत है — चिह्न प्रमुख ग्रेडिएंट दिशा को भरोसे से पकड़ता है। सूक्ष्म-अनुकूलन वितरण के किनारे के कार्यों पर डेल्टा कमजोर है — सन्निकटन संकेत की तुलना में अधिक शोर लाता है।

अनुभव से, अपने लक्षित कार्य-समूहों पर आँके गए Zen मॉडलों में:

मॉडल	पूर्ण-परिशुद्धता	BitDelta	अंतर
zen4-coder (HumanEval)	72.4%	71.1%	-1.3%
zen4-math (MATH-500)	68.9%	67.8%	-1.1%
zen4-writer (WritingBench)	84.2%	83.7%	-0.5%
zen4-legal (LegalBench)	61.3%	60.1%	-1.2%

प्राथमिक कार्य-समूहों पर 1-1.3% गिरावट, 87% मेमोरी कमी की कीमत है। सभी Zen रूपों के लिए यह समझौता स्वीकार्य है — गुणवत्ता का अंतर सामान्य उपयोग में उपयोगकर्ता को दिखने वाले व्यवहार परिवर्तन की सीमा से नीचे है।

MonoSoup: SVD वाला एकल-चेकपॉइंट पूरक

MonoSoup (arXiv:2602.09689) एक पूरक समस्या लेता है: जब एक ही आधार मॉडल के कई सूक्ष्म-अनुकूलित चेकपॉइंट हों, तो उन सब को एक साथ लोड किए बिना एक चेकपॉइंट में कैसे मिलाएँ?

MonoSoup कार्य सदिश (Δ = W_ft - W_base) पर SVD लगाकर वे निम्न-रैंक घटक पहचानता है जो सबसे अधिक व्यवहार जानकारी पकड़ते हैं, फिर उन्हें चेकपॉइंटों में जोड़ता है:

For checkpoints {W_1, W_2, ..., W_k}:
  Δ_i = W_i - W_base
  [U_i, S_i, Vh_i] = truncated_SVD(Δ_i, rank=r)
  τ_i = U_i · diag(S_i) · Vh_i  # rank-r approximation

MonoSoup merge:
  W_merged = W_base + (1/k) · Σ τ_i

रैंक r पर SVD की कटौती एक शोर-हटाने का चरण है: सूक्ष्म-अनुकूलन मॉडल को भार समष्टि की कुछ उच्च-विचरण दिशाओं पर बदलता है। उन दिशाओं को कटे हुए SVD से पकड़कर मिलाना हर चेकपॉइंट का व्यवहार सार लेता है, निचली विचित्र-मान दिशाओं का शोर नहीं।

Zen के प्रशिक्षण चलनों में हम MonoSoup को चेकपॉइंट औसत के चरण की तरह इस्तेमाल करते हैं: हर 1000 ग्रेडिएंट चरण पर वर्तमान चेकपॉइंट को पिछले सर्वश्रेष्ठ के साथ MonoSoup से मिलाते हैं, सीधे औसत से नहीं। इससे प्रशिक्षण शोर घटता है और हानि वक्र अधिक चिकने होते हैं, अंतिम गुणवत्ता बेहतर होती है।

K-Merge: किनारे के लिए ऑनलाइन LoRA एडाप्टर प्रबंधन

K-Merge (arXiv:2510.13537) सेवा समस्या का दूसरा रूप हल करता है: किनारे पर, जहाँ संग्रह एक नियत बजट B GB तक बँधा है, K LoRA एडाप्टर कुशलता से कैसे परोसें?

K-Merge मिले हुए एडाप्टरों का एक पूल रखता है, इस बाधा के साथ कि कुल संग्रह B से आगे न जाए। जब ऐसा नया एडाप्टर माँगा जाए जो पूल में नहीं है:

1. नए एडाप्टर और पूल के हर मौजूदा सदस्य के बीच युग्म समानता निकालें (कार्य सदिशों पर कोसाइन समानता)
2. सबसे समान मौजूदा एडाप्टर पहचानें
3. OPCM (लंब प्रक्षेपण विलय) से नए एडाप्टर को सबसे समान वाले में मिलाएँ
4. यदि मिला एडाप्टर दोनों कार्यों पर गुणवत्ता की सीमा पार करे, तो मूल को हटाएँ और मिला रूप रखें

नीति गारंटी देती है कि पूल में अधिक से अधिक K एडाप्टर हों जो बजट B लें, और सिद्धांतयुक्त विलय से माँगे गए सभी एडाप्टरों का कवर अधिकतम हो।

Zen के किनारे परिनियोजन (Hanzo Desktop, मोबाइल) के लिए K-Merge उन मॉडल परिवारों को स्थानीय रूप से परोसने देता है जो अन्यथा उपकरण की संग्रह सीमा पार कर जाते। 16GB उपलब्ध मॉडल संग्रह वाला उपकरण 8 अलग व्यवहार प्रोफ़ाइल परोस सकता है, एक K-Merge पूल रखकर जो समान एडाप्टर माँग पर मिलाता है।

अवसंरचना विवरण

डेल्टा संग्रह प्रारूप: 1-बिट चिह्न मैट्रिक्स पैक्ड int8 टेंसर के रूप में रखे जाते हैं (प्रति बाइट 8 बिट, इसलिए 4096×4096 भार वाली 70B पैरामीटर परत 4096×512 int8 में पैक होती है)। α स्केल गुणक float32 के रूप में रखे जाते हैं, हर आउटपुट आयाम के लिए एक, कुल मिलाकर डेल्टा संग्रह का लगभग 0.1%।

कोल्ड स्टार्ट व्यवहार: जब किसी रूप का डेल्टा ग्राफिक्स SRAM कैश में नहीं है (उदाहरण के लिए उस रूप की माँग 10 मिनट से नहीं हुई), पहला अनुरोध 70B मॉडल पर लगभग 200ms का डेल्टा-लोड विलंब चुकाता है — NVMe क्रमिक पठन गति पर 8.75GB को NVMe से HBM तक ले जाने का समय। पहले अनुरोध के बाद डेल्टा ग्राफिक्स SRAM के डेल्टा कैश में रहता है, जब तक LRU नीति उसे निकाल न दे।

कैश निष्कासन नीति: अनुरोध-दर भारित LRU। उच्च अनुरोध-दर वाले रूप टिके रहते हैं; कम आवाजाही वाले रूप निकाले जा सकते हैं। व्यवहार में, आवाजाही के हिसाब से शीर्ष 6 रूप हमेशा कैश में रहते हैं; शेष 8 बची कैश जगह LRU निष्कासन के साथ बाँटते हैं।

अनुरोध मार्ग: सेवा राउटर हर रूप के चल रहे अनुरोध गिनता है और पंक्ति-शीर्ष अवरोध रोकता है: यदि zen4-coder का डेल्टा लोड हो रहा हो, तो आने वाले zen4-coder अनुरोध कतार में लगते हैं, न कि हर एक अलग लोड शुरू करता है।

परिणाम: 14 Zen मॉडल रूप 8x H100 नोड से परोसे जाते हैं, जिनके बराबर क्षमता के लिए पहले 112x H100 नोड चाहिए होते। अवसंरचना लागत की कमी क्रमिक नहीं है। BitDelta बहु-किरायेदार मॉडल परिवार को आर्थिक रूप से व्यावहारिक बनाता है।

---

Zen मॉडल zenlm.org पर उपलब्ध हैं। API पहुँच hanzo.ai पर है।