BitDelta: servir 14 modelos Zen desde un solo clúster de GPU

La economía de servir variantes de modelos con ajuste fino es hostil de entrada.

Un modelo de 70B parámetros en BF16 exige 140GB de memoria de GPU. Si tenéis 14 variantes con ajuste fino de ese modelo — cada una con un perfil de capacidad distinto, una especialización de dominio o un ajuste conductual — la arquitectura de servicio ingenua exige 14 cargas de modelo separadas: 1.96TB de memoria de GPU, 14 procesos de inferencia separados, 14x el coste de infraestructura. Por cada variante a partir de la segunda, pagáis el precio completo por lo que es casi enteramente conocimiento de base duplicado.

BitDelta (arXiv:2402.10193) rompe esta economía. La idea es elegante y las matemáticas son sencillas.

El fundamento matemático

Sea W_base la matriz de pesos del modelo de base y W_ft la matriz de pesos correspondiente en una variante con ajuste fino. La delta conductual es:

Δ = W_ft - W_base

BitDelta comprime esta delta a una precisión de 1 bit:

W_ft ≈ W_base + α · sign(Δ)

Donde α es un factor de escala por matriz, calculado como el valor absoluto medio de Δ:

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

La operación signo reduce cada delta escalar a un solo bit, positivo o negativo. El factor de escala α restituye la magnitud. En conjunto, la aproximación captura la información direccional de la actualización del ajuste fino a 1/32 del coste de almacenamiento de una delta en precisión completa (1 bit frente a 32 bits por elemento de parámetro).

¿Por qué funciona? El ajuste fino de un modelo preentrenado grande produce deltas que, en esperanza, son pequeñas respecto de los pesos de base. El modelo de base captura la estructura dominante de la lengua; el ajuste fino captura modificaciones conductuales encima de esa estructura. Cuando la delta es pequeña, el signo de cada elemento es la representación de mayor información de ese elemento: la magnitud es aproximadamente uniforme en la matriz delta, así que α · sign(Δ) es un código eficiente.

Esto puede formularse con más rigor. Si modelamos Δ_ij como una variable aleatoria de Laplace con localización 0 y escala b:

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

El signo conserva la información direccional a la perfección. La pérdida de información está solo en la variación de magnitud, que el único factor de escala α recupera en parte. En las deltas de ajuste fino donde la variación de magnitud es baja (modificación de la conducta, y no transferencia de conocimiento), la aproximación es ajustada.

Reducción de memoria: en un modelo de 70B en BF16, los pesos de base ocupan 140GB. La delta de cada variante con ajuste fino, en BF16 completo, añadiría otros 140GB. En formato BitDelta, cada delta ocupa aproximadamente 8.75GB (70B bits = 8.75GB, más los escalares α, que son despreciables). El clúster de 14 variantes pasa de 14 × 140GB = 1.96TB a 140GB + 14 × 8.75GB ≈ 262GB, una reducción del 87%.

Arquitectura de servicio

┌─────────────────────────────────────────────────────────────────┐
│                    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    │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

En el momento de la inferencia, la canalización de servicio es:

1. La petición llega con model: "zen4-coder"
2. El enrutador identifica la entrada de la caché de deltas de zen4-coder
3. Se reconstruye el peso efectivo al vuelo: W_eff = W_base + α_coder · sign(Δ_coder)
4. Se ejecuta la pasada hacia delante con los pesos reconstruidos
5. Se devuelve la respuesta

El paso 3 es la ruta crítica. La reconstrucción es un núcleo CUDA fusionado que lee a la vez los pesos de base y los bits de la delta, y reconstruye el peso efectivo en registros o en memoria compartida sin materializar el W_eff completo en HBM. La reconstrucción y la multiplicación de matrices pueden fundirse en una sola pasada del núcleo: el peso reconstruido no llega a existir por completo como tensor independiente.

# 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)

El enfoque del núcleo fusionado mantiene el consumo pico de ancho de banda HBM en aproximadamente 1.5x los pesos del modelo de base, y no en 2x, porque la delta se lee en formato de bits empaquetado y se desempaqueta en SRAM rápida durante la operación fusionada.

Perfil de latencia

En la práctica, en el clúster de servicio Zen de 14 variantes:

Variante	P50 TTFT	P99 TTFT	frente a la línea de base
zen4 (base)	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

El sobrecoste de tiempo hasta el primer token por la reconstrucción BitDelta es de 2-4ms, despreciable frente al coste de prellenado para longitudes de prompt habituales. El núcleo de reconstrucción está limitado por cómputo, no por memoria, así que escala bien con la generación en la GPU.

El caudal de generación (tokens/segundo) es idéntico entre el modelo de base y cualquier variante BitDelta, porque la reconstrucción solo ocurre en la fase de prellenado. Una vez poblada la caché KV, el paso de generación autorregresiva usa las rutas matmul estándar.

Calidad: qué se pierde en la compresión de 1 bit

La respuesta honesta: una cantidad pequeña, cuidadosamente acotada.

La degradación de calidad de BitDelta depende de la tarea. En las tareas bien representadas en los datos de ajuste fino, la delta conductual es fuerte: el signo captura de forma fiable la dirección dominante del gradiente. En las tareas de la periferia de la distribución de ajuste fino, la delta es más débil: la aproximación introduce más ruido respecto de la señal.

Empíricamente, en los modelos Zen evaluados sobre sus baterías de tareas objetivo:

Modelo	Precisión completa	BitDelta	Delta
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%

La degradación del 1-1.3% en las baterías de tareas principales es el precio de una reducción de memoria del 87%. En todas las variantes Zen, esta contrapartida es aceptable: la diferencia de calidad queda por debajo del umbral de un cambio conductual perceptible para el usuario en los casos de uso habituales.

MonoSoup: complemento SVD de un solo punto de control

MonoSoup (arXiv:2602.09689) aborda un problema complementario: cuando existen varios puntos de control con ajuste fino del mismo modelo de base, ¿cómo se fusionan en un único punto de control sin cargarlos todos a la vez?

MonoSoup aplica SVD al vector de tarea (Δ = W_ft - W_base) para identificar los componentes de rango bajo que capturan la mayor información conductual, y después los agrega entre puntos de control:

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

El truncamiento SVD en el rango r actúa como un paso de eliminación de ruido: el ajuste fino tiende a modificar un modelo a lo largo de un número pequeño de direcciones de alta varianza en el espacio de pesos. Capturar esas direcciones mediante SVD truncada y fusionarlas captura la esencia conductual de cada punto de control, sin el ruido de las direcciones de valores singulares más bajos.

Usamos MonoSoup durante las ejecuciones de entrenamiento de Zen como paso de promediado de puntos de control: cada 1000 pasos de gradiente, fusionamos el punto de control actual con el mejor anterior mediante MonoSoup, en lugar del promediado ingenuo. Esto reduce el ruido de entrenamiento y produce curvas de pérdida más suaves, con mejor calidad final.

K-Merge: gestión en línea de adaptadores LoRA para el borde

K-Merge (arXiv:2510.13537) resuelve otra variante del problema de servicio: en el borde, donde el almacenamiento está limitado a un presupuesto fijo de B gigabytes, ¿cómo se sirven K adaptadores LoRA de forma eficiente?

K-Merge mantiene una reserva de adaptadores fusionados con la restricción de que el almacenamiento total no supere nunca B. Cuando se solicita un adaptador nuevo que no está en la reserva:

1. Se calcula la similitud por pares entre el adaptador nuevo y todos los miembros existentes de la reserva (similitud del coseno sobre los vectores de tarea)
2. Se identifica el adaptador existente más similar
3. Se fusiona el adaptador nuevo en el existente más similar mediante OPCM (fusión por proyección ortogonal)
4. Si la calidad del adaptador fusionado en ambas tareas supera el umbral, se desaloja el original y se almacena la versión fusionada

La política garantiza que la reserva contiene como máximo K adaptadores que consumen el presupuesto B, a la vez que maximiza la cobertura de todos los adaptadores solicitados mediante una fusión con criterio.

Para el despliegue de Zen en el borde (Hanzo Desktop, móvil), K-Merge permite familias de modelos servidas en local que, de otro modo, superarían los límites de almacenamiento del dispositivo. Un dispositivo con 16GB de almacenamiento de modelo disponible puede servir 8 perfiles conductuales distintos manteniendo una reserva K-Merge que fusiona adaptadores similares bajo demanda.

Detalles de infraestructura

Formato de almacenamiento de la delta: matrices de signo de 1 bit almacenadas como tensores int8 empaquetados (8 bits por byte, de modo que una capa de 70B parámetros con un peso de 4096×4096 se empaqueta en 4096×512 int8). Los factores de escala α se almacenan como float32, uno por dimensión de salida, y suman aproximadamente el 0.1% del almacenamiento de la delta.

Comportamiento de arranque en frío: cuando la delta de una variante no está en la SRAM de la GPU (por ejemplo, la variante no se ha solicitado en 10 minutos), la primera petición paga una penalización de latencia de carga de la delta de aproximadamente 200ms en un modelo de 70B, el tiempo de transferir 8.75GB de NVMe a HBM a las velocidades de lectura secuencial de NVMe. Tras la primera petición, la delta permanece en la caché de deltas de la SRAM de la GPU hasta que la desaloja la política LRU.

Política de desalojo de caché: LRU con ponderación por tasa de peticiones. Las variantes con tasa de peticiones alta quedan fijadas; las de poco tráfico pueden desalojarse. En la práctica, las 6 variantes principales por volumen de tráfico residen siempre en caché; las 8 restantes comparten el espacio de caché que queda, con desalojo LRU.

Encaminamiento de peticiones: el enrutador de servicio sigue las peticiones en curso por variante e impide el bloqueo de cabeza de línea: si se está cargando la delta de zen4-coder, las peticiones entrantes de zen4-coder hacen cola, en lugar de que cada una dispare una carga independiente.

El resultado: 14 variantes de modelos Zen servidas desde nodos 8x H100 que antes habrían exigido nodos 112x H100 para una capacidad equivalente. La reducción del coste de infraestructura no es incremental. BitDelta hace viable económicamente la familia de modelos multiinquilino.

---

Los modelos Zen están disponibles en zenlm.org. Acceso a la API en hanzo.ai.