Vectores multimodales en Llama.cpp y GGUF

Nota: en este punto de la canalización, tanto los 词元 de texto (<|im_start|>, user, etc.) como los 词元 de imagen (img_tok_1,img_tok_2, etc.), son vectores densos y no *tokens* de texto literales. Usamos esta forma de la secuencia para simplificar la explicación.

Al decodificar img_tok_2, el mecanismo de atención *debería* atender a todos los *tokens* anteriores, es decir:

<|im_start|>user\n<|vision_start|> img_tok_1
Copiar

Sin embargo, un error en la máscara de atención estaba causando *en cambio* que el mecanismo atendiera a toda la secuencia de la imagen, así:

 <|im_start|>user\n<|vision_start|> img_tok_1 img_tok_2 ... img_tok_last
Copiar

Después de solucionar este error, los *embeddings* de nuestro modelo llama.cpp (utilizando los *tokens* de imagen precalculados del ViT del modelo Torch) finalmente coincidieron con los *embeddings* del modelo de referencia (dentro de un pequeño margen de error).

tagCorrección #2: Procesamiento de Imágenes y *Embeddings* de Parches

El codificador ViT de llama.cpp también producía *embeddings* de imagen diferentes del modelo de referencia, con números que divergían inmediatamente después del preprocesamiento. Esto fue particularmente evidente durante el paso inicial de creación de parches, donde tanto nuestro modelo de referencia como llama.cpp dividen la imagen en bruto (valores de píxeles) en parches que se codifican a través de capas convolucionales. Las diferencias entre los parches en bruto (antes del procesamiento ViT) se pueden ver a continuación:

=== raw_patches reference === Shape: [1008, 1176]
Logging patches 0-4, dimensions 0-9
Patch 0: 0.484375 0.484375 0.500000 0.500000 0.470703 0.470703 0.470703 0.484375 0.470703 0.484375 ... (dims 10-1175)
... (patches 1-1007 not shown)
Copiar

=== raw_patches llama.cpp === Shape: [1176, 1008, 1, 1]
Logging patches 0-4, dimensions 0-9
Patch 0: 0.455895 0.455895 0.455895 0.455895 0.455895 0.455895 0.470494 0.470494 0.470494 0.470494 ... (dims 10-1175)
... (patches 1-1007 not shown)
Copiar

Nuestro modelo de referencia y llama.cpp procesan estos parches de diferentes maneras:

• El modelo de referencia agrupa los valores de los píxeles utilizando operaciones de remodelación y luego utiliza una única capa conv3d para codificar los parches de píxeles pre-agrupados.
• El modelo llama.cpp crea y codifica estos parches con dos capas conv2d

Para acercar los *embeddings* del modelo llama.cpp a los del modelo de referencia, pensamos que sería más sencillo utilizar las operaciones exactas del modelo de referencia en lugar de depurar el enfoque de llama.cpp.

Nuestro modelo de referencia genera parches de píxeles utilizando operaciones complejas de remodelación y transposición que requieren tensores de 9 dimensiones. La biblioteca de procesamiento de tensores de bajo nivel utilizada en llama.cpp — ggml — no puede soportarlos, así que para evitar esto, generamos los parches utilizando un servicio Python separado que llama al servidor llama.cpp a través de HTTP.

ggml tampoco es compatible con las capas conv3d. En nuestro modelo de referencia, la configuración de la capa conv3d se ve así:

kernel_size = [
	2,  # temporal_patch_size, 
	14, # patch_size
	14  # patch_size
]

proj = nn.Conv3d(
	3, # in_channels
	1152, # embed_dim, 
	kernel_size=kernel_size, 
	stride=kernel_size, 
	bias=False
)
Copiar

Puede ver que stride y kernel_size son iguales, lo que significa que podemos simplemente aplanar las entradas y los pesos de la capa conv3d y realizar una simple operación de multiplicación de matrices en su lugar. Para hacer esto, modificamos el script de conversión en llama.cpp (convert_hf_to_gguf.py) para exportar una versión aplanada de los pesos conv3d para la capa de proyección de parches:

if 'patch_embed.proj.weight' in name:
	c1, c2, kt, kh, kw = data_torch.shape
	# Note: this part of the script also exports other versions of this layer
	# Only showing the relevant parts
	# Flat matmul weight: row-major [out, in*kT*kH*kW] = [embed_dim, 1176]
	W_flat = data_torch.contiguous().view(c1, -1)
	outputs.append(("v.patch_embd.weight_flat", W_flat))
Copiar

Para aplicar la operación matmul en lugar de las dos capas conv2d en llama.cpp, modificamos el código que construye el grafo del Qwen2.5-VL ViT:

ggml_tensor * build_inp_raw_precomputed() {
  ggml_tensor * inp_raw = ggml_new_tensor_2d(
		ctx0, 
		GGML_TYPE_F32, 
		img.p_dim, 
		img.npx * img.npy
	);
  ggml_set_name(inp_raw, "inp_raw");
  ggml_set_input(inp_raw);
  return inp_raw;
}

ggml_cgraph * build_qwen2vl() {
	// NOTE: only showing the code we've added for using pre-arranged image patches
  const bool uses_precomputed_image = img.is_precomputed;
  ggml_tensor * inp = nullptr;
	if (uses_precomputed_image) {
      ggml_tensor * inp_raw = build_inp_raw_precomputed();
      cb(inp_raw, "inp_raw", -1);
      inp = ggml_mul_mat(ctx0, model.patch_embeddings_flat, inp_raw);
	} else {
		// Usual 2x conv2d path 
	}
	// rest of the code 
}
Copiar

Con estos cambios finales, los *embeddings* finales de la imagen estaban dentro de un margen de error del 2% en comparación con el modelo de referencia (como se puede ver en la tabla de evaluación en la siguiente sección).

tagEvaluación

Después de realizar estos cambios, evaluamos el modelo llama.cpp con nuestro modelo de referencia en tareas ViDoRe utilizando el benchmark MTEB. Puede ver el script e instrucciones para replicar estos resultados en nuestra bifurcación de llama.cpp, así como dos versiones cuantificadas.

Tarea	Modelo de referencia	llama.cpp (F16)	llama.cpp (Q4_K_M)	llama.cpp (IQ4_XS)
VidoreArxivQARetrieval	83.55	85.00	84.38	84.34
VidoreDocVQARetrieval	50.53	52.02	51.93	51.57
VidoreInfoVQARetrieval	87.77	87.31	87.61	87.28
VidoreShiftProjectRetrieval	84.07	82.25	82.56	81.73
VidoreSyntheticDocQAAIRetrieval	97.52	96.71	97.28	97.15
VidoreSyntheticDocQAEnergyRetrieval	91.22	90.34	90.47	90.30
VidoreSyntheticDocQAGovernmentReportsRetrieval	91.61	93.84	93.47	94.47
VidoreSyntheticDocQAHealthcareIndustryRetrieval	95.42	96.08	95.67	96.05
VidoreTabfquadRetrieval	94.52	94.94	94.83	94.72
VidoreTatdqaRetrieval	65.52	64.85	64.63	64.76
Promedio	84.17	84.33	84.28	84.23

Observando la tabla de resultados, en promedio, el modelo llama.cpp y sus variantes cuantificadas no divergen mucho del modelo de referencia.

Para comparar los modelos con más profundidad, utilizamos imágenes de diferentes dominios y con diferentes resoluciones, trazando la distancia entre los *embeddings* de los parches de imagen (antes de la agrupación/normalización). Cuanto más rojo es el parche, mayor es la distancia coseno entre los vectores del modelo de referencia y el modelo llama.cpp para ese parche en particular.

Nuestro objetivo era detectar cualquier patrón que fuera más allá de las diferencias de precisión numérica, patrones que pudieran revelar más errores o diferencias entre nuestros modelos. Sin embargo, no se observaron patrones particulares, excepto que el número de parches divergentes aumenta con la resolución de la imagen. Estas diferencias probablemente aparecen debido a las diferencias de backend, y no debido a ningún error particular en la implementación de Qwen2.5-VL (el modelo backbone de jina-embeddings-v4).

No obstante, debemos reiterar que estas diferencias son mínimas, y los resultados de las pruebas de referencia también reflejan este hecho. En general, los modelos llama.cpp rinden tan bien como el modelo de referencia, aunque produciendo vectores de 向量模型 ligeramente diferentes.

tagProblemas pendientes

Existen varias áreas de mejora potencial para los 向量模型 multimodales en llama.cpp:

• Cuantificar el codificador de visión. Actualmente, llama.cpp solo admite la cuantificación para 大模型, pero para lograr una mejor escalabilidad, también nos gustaría cuantificar el codificador de visión.

• Separar el codificador de visión en un servicio dedicado. Los codificadores de visión normalmente utilizan un enmascaramiento no causal, lo que significa que cualquier imagen dada debe codificarse dentro de una única llamada directa. Por lo tanto, no podemos hacer uso del procesamiento por lotes continuo. Sin embargo, podríamos considerar separar el codificador de visión en un servicio separado, que agruparía varias imágenes (incluso de fuentes separadas) y las codificaría todas en una sola pasada directa. Esto significaría mayores requisitos de vRAM, pero también sería mucho más rápido que codificar cada imagen una por una. Esta separación también significaría que podríamos escalar automáticamente el codificador de visión independientemente del modelo de lenguaje.
• Habilitar 向量模型 multi-vectoriales. En este artículo, solo hemos trabajado con 向量模型 de un solo vector. Pero para aprovechar al máximo jina-embeddings-v4, también nos gustaría habilitar 向量模型 multi-vectoriales para lograr una mayor precisión en imágenes complejas. Esta sería una adición fácil, ya que estos 向量模型 se generan con una sola capa lineal en la parte superior del modelo base.

tagConclusión

A pesar de los errores y contratiempos iniciales, la integración de 向量模型 multimodales en llama.cpp ahora arroja resultados que coinciden estrechamente con nuestro modelo de PyTorch de referencia, incluso en una variedad de tareas de evaluación comparativa. Las correcciones a la máscara de atención y al procesamiento de parches de imagen eliminaron las principales fuentes de divergencia, e incluso las variantes cuantificadas logran una precisión similar al tiempo que utilizan muchos menos recursos. Las diferencias restantes en resoluciones de imagen más altas parecen menores y probablemente se deban a variaciones de backend en lugar de a la implementación del modelo central.

De cara al futuro, extender la cuantificación al codificador de visión, habilitar el procesamiento por lotes a través de un servicio separado y admitir 向量模型 multi-vectoriales mejoraría aún más tanto la eficiencia como la precisión. Estas adiciones harían que los 向量模型 multimodales en llama.cpp fueran más escalables y más adecuados para casos de uso del mundo real.