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. 합친 어댑터의 품질이 두 과제 모두에서 문턱을 넘으면, 원본을 내보내고 합친 버전을 저장한다

이 정책은 풀이 예산 B를 쓰는 어댑터를 최대 K개로 두면서, 원칙 있는 병합으로 요청된 모든 어댑터의 커버를 최대로 합니다.

Zen의 에지 배포 (Hanzo Desktop, 모바일) 에서 K-Merge는 그렇지 않으면 장치 저장 한도를 넘는 모델 가족을 로컬에서 제공하게 합니다. 모델 저장이 16GB 남은 장치는, 비슷한 어댑터를 요청 때 합치는 K-Merge 풀로 서로 다른 행동 프로필 8개를 제공할 수 있습니다.

기반 세부

델타 저장 형식: 1비트 부호 행렬은 묶인 int8 텐서로 저장합니다 (바이트당 8비트이므로, 가중치 4096×4096인 70B 파라미터 층은 4096×512 int8로 묶입니다). α 스케일 계수는 float32로, 출력 차원마다 하나씩 저장하며, 합계는 델타 저장의 약 0.1%입니다.

콜드 스타트 동작: 변종의 델타가 그래픽 처리 장치 SRAM에 캐시되어 있지 않을 때 (예를 들어 그 변종이 10분 동안 요청되지 않음), 첫 요청은 70B 모델에서 약 200ms의 델타 로드 지연을 냅니다. NVMe 순차 읽기 속도로 8.75GB를 NVMe에서 HBM으로 옮기는 시간입니다. 첫 요청 뒤 델타는 LRU 정책으로 밀려날 때까지 그래픽 처리 장치 SRAM의 델타 캐시에 남습니다.

캐시 방출 정책: 요청률 가중 LRU입니다. 요청률이 높은 변종은 고정되고, 트래픽이 낮은 변종은 방출될 수 있습니다. 실제로는 트래픽 상위 6개 변종이 항상 캐시에 상주하고, 나머지 8개는 남은 캐시 공간을 LRU 방출로 나눕니다.

요청 라우팅: 서빙 라우터는 변종별 진행 중 요청을 추적하고 선두 차단을 막습니다. zen4-coder의 델타를 로드 중이면, 들어오는 zen4-coder 요청은 각자가 독립 로드를 일으키지 않고 대기열에 섭니다.

결과: Zen 모델 변종 14개를 8x H100 노드에서 제공합니다. 같은 능력에는 이전에 112x H100 노드가 필요했습니다. 기반 비용의 감소는 점진적이지 않습니다. BitDelta는 다중 테넌트 모델 가족을 경제적으로 성립하게 합니다.

---

Zen 모델은 zenlm.org 에서 이용할 수 있습니다. API 접근은 hanzo.ai 입니다.