BitDelta: ให้บริการโมเดล Zen 14 แบบจากคลัสเตอร์ประมวลผลเดียว

เศรษฐศาสตร์ของการให้บริการรุ่นโมเดลที่ปรับจูนละเอียดนั้นไม่เป็นใจมาแต่ต้น

โมเดลพารามิเตอร์ 70B ในรูป BF16 ต้องใช้หน่วยความจำประมวลผล 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 Δ

เครื่องหมายรักษาสารสนเทศเชิงทิศทางได้อย่างสมบูรณ์ การสูญเสียสารสนเทศอยู่ที่ความแปรผันของขนาดเท่านั้น ซึ่งตัวคูณสเกลเดียว α กู้คืนได้บางส่วน สำหรับเดลตาปรับจูนละเอียดที่ความแปรผันของขนาดต่ำ (การแก้พฤติกรรม ไม่ใช่การถ่ายโอนความรู้) การประมาณกระชับ

การลดหน่วยความจำ: สำหรับโมเดล 70B ในรูป BF16 น้ำหนักฐานกิน 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 ที่เร็วระหว่างการทำงานแบบหลอม

โปรไฟล์ความหน่วง

ในทางปฏิบัติ บนคลัสเตอร์ให้บริการ Zen 14 แบบ:

รุ่น	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 ใช้ SVD กับเวกเตอร์งาน (Δ = W_ft - W_base) เพื่อชี้ส่วนประกอบแรงค์ต่ำที่จับสารสนเทศเชิงพฤติกรรมได้มากสุด แล้วรวมข้ามจุดตรวจ:

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

การตัด SVD ที่แรงค์ r คือขั้นลดสัญญาณรบกวน: การปรับจูนละเอียดมักแก้โมเดลตามทิศทางความแปรปรวนสูงจำนวนน้อยในปริภูมิน้ำหนัก การจับทิศทางเหล่านั้นด้วย SVD ที่ตัด แล้วรวมเข้าด้วยกัน จับแก่นพฤติกรรมของแต่ละจุดตรวจ โดยไม่มีสัญญาณรบกวนในทิศทางค่าเอกฐานที่ต่ำกว่า

เราใช้ MonoSoup ระหว่างรันฝึก Zen เป็นขั้นเฉลี่ยจุดตรวจ: ทุก 1000 ก้าวเกรเดียนต์ เราผสานจุดตรวจปัจจุบันกับจุดตรวจที่ดีสุดก่อนหน้าผ่าน MonoSoup แทนการเฉลี่ยแบบตรงๆ ซึ่งลดสัญญาณรบกวนของการฝึก และได้เส้นโค้งการสูญเสียที่เรียบกว่า พร้อมคุณภาพสุดท้ายที่ดีกว่า

K-Merge: จัดการอะแดปเตอร์ LoRA ออนไลน์สำหรับขอบเครือข่าย

K-Merge (arXiv:2510.13537) แก้บริการอีกรูปหนึ่ง: ที่ขอบเครือข่าย ซึ่งที่เก็บถูกจำกัดด้วยงบคงที่ B GB จะให้บริการอะแดปเตอร์ LoRA จำนวน K ตัวอย่างมีประสิทธิภาพได้อย่างไร?

K-Merge รักษาพูลของอะแดปเตอร์ที่ผสานแล้ว ภายใต้ข้อจำกัดว่าที่เก็บรวมไม่เกิน B เมื่อมีการขออะแดปเตอร์ใหม่ที่ไม่อยู่ในพูล:

1. คำนวณความคล้ายเป็นคู่ระหว่างอะแดปเตอร์ใหม่กับสมาชิกทุกตัวในพูล (ความคล้ายโคไซน์บนเวกเตอร์งาน)
2. ชี้ตัวอะแดปเตอร์เดิมที่คล้ายที่สุด
3. ผสานอะแดปเตอร์ใหม่เข้ากับตัวที่คล้ายที่สุดผ่าน OPCM (การรวมด้วยภาพฉายตั้งฉาก)
4. ถ้าคุณภาพของอะแดปเตอร์ที่ผสานแล้วบนทั้งสองงานเกินเกณฑ์ ให้ถอดตัวเดิมออก แล้วเก็บรุ่นที่ผสาน

นโยบายนี้รับประกันว่าพูลมีอะแดปเตอร์ไม่เกิน K ตัวที่ใช้งบ B ขณะเพิ่มการครอบคลุมอะแดปเตอร์ที่ถูกร้องขอทั้งหมดด้วยการรวมที่มีหลักการ

สำหรับการวาง Zen ที่ขอบเครือข่าย (Hanzo Desktop และมือถือ) K-Merge ทำให้ครอบครัวโมเดลที่ให้บริการในเครื่อง ซึ่งมิฉะนั้นจะเกินขีดเก็บของอุปกรณ์ เป็นไปได้ อุปกรณ์ที่มีที่เก็บโมเดลว่าง 16GB ให้บริการโปรไฟล์พฤติกรรมต่างกัน 8 แบบได้ โดยรักษาพูล K-Merge ที่ผสานอะแดปเตอร์ที่คล้ายกันตามคำขอ

รายละเอียดโครงสร้างพื้นฐาน

รูปแบบเก็บเดลตา: เมทริกซ์เครื่องหมาย 1 บิตเก็บเป็นเทนเซอร์ int8 แบบแพ็ก (8 บิตต่อไบต์ ดังนั้นชั้นพารามิเตอร์ 70B ที่มีน้ำหนัก 4096×4096 แพ็กเป็น 4096×512 int8) ตัวคูณสเกล α เก็บเป็น float32 หนึ่งตัวต่อมิติเอาต์พุต รวมประมาณ 0.1% ของที่เก็บเดลตา

พฤติกรรมตอนเริ่มเย็น: เมื่อเดลตาของรุ่นไม่อยู่ในแคช SRAM ของหน่วยประมวลผล (เช่น ไม่มีคำขอรุ่นนั้นมา 10 นาที) คำขอแรกจ่ายค่าปรับความหน่วงการโหลดเดลตาประมาณ 200ms สำหรับโมเดล 70B — เวลาถ่าย 8.75GB จาก NVMe ไป HBM ที่ความเร็วอ่านลำดับของ NVMe หลังคำขอแรก เดลตาอยู่ในแคชเดลตาบน SRAM จนนโยบาย LRU ถอดออก

นโยบายถอดแคช: LRU ถ่วงด้วยอัตราคำขอ รุ่นที่อัตราคำขอสูงถูกปักไว้ รุ่นที่ทราฟฟิกต่ำถูกถอดได้ ในทางปฏิบัติ รุ่น 6 อันดับแรกตามปริมาณทราฟฟิกอยู่ในแคชเสมอ ที่เหลือ 8 แบบแบ่งที่แคชที่เหลือด้วยการถอดแบบ LRU

การจัดเส้นทางคำขอ: เราเตอร์ให้บริการติดตามคำขอที่กำลังทำต่อรุ่น และกันการบล็อกหัวแถว: ถ้าเดลตาของ zen4-coder กำลังโหลด คำขอ zen4-coder ที่เข้ามาเข้าคิว แทนที่แต่ละคำขอจะกระตุ้นการโหลดของตัวเอง

ผลลัพธ์: รุ่นโมเดล Zen 14 แบบให้บริการจากโหนด 8x H100 ซึ่งแต่ก่อนต้องใช้โหนด 112x H100 เพื่อความสามารถเท่ากัน การลดต้นทุนโครงสร้างพื้นฐานไม่ใช่ทีละน้อย BitDelta ทำให้ครอบครัวโมเดลหลายผู้เช่าคุ้มทางเศรษฐกิจ

---

โมเดล Zen มีที่ zenlm.org การเข้าถึง API อยู่ที่ hanzo.ai