Los Embeddings Locales Generalmente Hacen que tu Agente Sea Más Lento
Lo primero que necesitas saber sobre mover embeddings en dispositivo es que generalmente hace que tu agente sea más lento, no más rápido. Esto no es obvio en los benchmarks, que miden la latencia de embeddings de forma aislada. El costo real se muestra en el tiempo de reloj una vez que ejecutas el modelo en un bucle de agente.
Hoy, la mayoría de los agentes ejecutan embeddings en la nube—text-embedding-3-small de OpenAI, Cohere, o similares—porque son lo suficientemente rápidos y ortogonales a la generación. Una llamada típica a text-embedding-3-small toma 40–80ms, pero aquí está la parte crucial: esa llamada es completamente concurrente con la fase de prefill de tu LLM. Mientras tu modelo de generación quema tokens en razonamiento, la solicitud de embedding rebota hacia Anthropic u OpenAI. Para cuando se completa el prefill, los vectores están de vuelta. No pagas ninguna penalización de tiempo de reloj.
EmbeddingGemma 2 en una GPU L4 ejecuta 15–30ms por consulta. Eso es genuinamente más rápido. Pero se ejecuta en la misma GPU que tu modelo de generación. En el momento en que lo llamas, tu modelo de 7B o 13B se detiene. El trabajo de embedding se pone en cola detrás de cualquier paso de decodificación que ya esté en vuelo. Si estás agrupando generaciones en sesiones concurrentes—que deberías hacer por costo—esos embeddings ahora compiten con la inferencia activa. La métrica real no es la latencia del modelo; es la contribución de la ruta crítica. ¿Cuándo la recuperación realmente bloquea la respuesta del usuario?
En inferencia de un solo inquilino, no importa mucho. Embed, espera 20ms, genera. Pero en el momento en que te mueves a un servicio de inferencia compartido—que es lo que hacen la mayoría de los agentes a escala—los embeddings locales convierten llamadas paralelas en una cola serial. Has movido una operación concurrente a tu ruta crítica.
Lo que EmbeddingGemma 2 Realmente Cambia para los Agentes
Las ganancias genuinas son más específicas que "local es más rápido". Se trata de paridad multimodal, independencia del proveedor y determinismo.
Hoy, si quieres incrustar tanto texto como imágenes en el mismo espacio vectorial, ejecutas dos proveedores. El texto va a OpenAI. Las imágenes van al endpoint multimodal de Cohere o a las capacidades de visión de Claude como parte de la llamada de generación en sí. Eso son dos índices, dos rutas de recuperación, dos conjuntos de dolores de cabeza de versionado. EmbeddingGemma 2 pone texto e imágenes en el mismo espacio de 768 dimensiones. Un índice. Una métrica de similitud. Un lugar para depurar la deriva de recuperación.
Segundo, sin viaje de ida y vuelta a una API de proveedor para datos que ya viven en tu caja. Si tu agente procesa PDFs, imágenes o fotogramas de video en una VPC de cliente, no estás enviando vectores por la red. No estás pagando tarifas por llamada a Cohere por cada fotograma en un bucle de procesamiento. La licencia te permite enviar EmbeddingGemma 2 dentro de la infraestructura del cliente sin un medidor de uso.
Tercero, versionado determinista. OpenAI actualiza silenciosamente los modelos de embedding. Cohere envía nuevas versiones. Tu índice se desvía sin previo aviso. Con EmbeddingGemma 2, controlas la versión. Tus embeddings no cambian bajo ti a menos que explícitamente reconstruyas el índice. Para evals y reproducibilidad, eso importa.
El modelo también es ligero—alrededor de 300M parámetros—lo que significa que puedes colocar con un modelo de generación de 7–13B en la misma caja de inferencia si tienes cuidado con la cuantización. Esa es una mejora significativa sobre las alternativas multimodales hinchadas que estaban disponibles hace incluso seis meses.
Cuándo los Embeddings Locales Realmente Valen la Pena
No todos los agentes deberían cambiar a embeddings locales. Aquí está la regla de decisión que hemos encontrado.
Los bucles de recuperación de alto volumen inclinan la balanza. Si tu agente hace más de 50 llamadas de embedding por turno—piensa en reranking, recuperación multipaso, scaffolding de selección de herramientas—el costo por llamada de una API en la nube se compone rápidamente. A 50 llamadas × 2¢ por embedding, estás en $1 por interacción de usuario. EmbeddingGemma 2 alojado en una L4 compartida ejecuta la misma carga de trabajo por centavos, asumiendo que has arreglado el problema de latencia que describimos arriba.
Los agentes multimodales son una victoria más clara. Si ya estás ejecutando imagen y texto a través de proveedores de embedding separados, consolidarlos ahorra gastos operativos y costo. El mismo espacio vectorial significa una capa de recuperación, no dos.
Los despliegues restringidos por privacidad—salud, defensa, empresa local—no tienen opción. Los embeddings en la nube no funcionarán. EmbeddingGemma 2 te permite enviar RAG multimodal en redes aisladas.
La recuperación que ya es sincrónica no tiene nada que perder. Si ya estás llamando a un reranker o ejecutando lógica de selección de herramientas que bloquea en vectores, mover embeddings locales no te hará daño. Podría ayudar. A medida que las capacidades del modelo se consolidan, podrías encontrar que capas de enrutamiento completas se convierten en peso muerto—y los embeddings locales reducen el radio de explosión cuando los eliminas.
La inferencia de borde es otro caso. Si tu agente se ejecuta en un dispositivo móvil o en el borde y el viaje de ida y vuelta de la red a una API de embedding excede la latencia de embedding en sí, aloja el modelo localmente. Mide primero.
Finalmente, la deriva del proveedor que rompe tus evals. Si has ajustado tus umbrales de recuperación alrededor del espacio de embedding de OpenAI y una actualización del modelo desplaza tu recuperación en un 5%, los embeddings locales te dan control sobre ese cadencia.
El Costo Oculto: Un Modelo Más en tu Stack
Agregar EmbeddingGemma 2 a tu agente significa agregar un segundo modelo a tu infraestructura. Eso no es gratis.
Necesitas un segundo arnés de eval. Tu modelo de generación obtiene evals. Ahora tu modelo de embedding obtiene evals. ¿Recupera los documentos correctos? ¿Los vectores se desvían con el tiempo? Los leaderboards no predicen la confiabilidad del agente—y eso es cierto para los modelos de embedding también. Construirás un arnés de eval de bucle cerrado o enviarás recuperación rota a producción.
Las matemáticas de memoria de GPU se vuelven más difíciles. EmbeddingGemma 2 + tu modelo de generación de 13B + caché KV raramente cabe cómodamente en una L4 única. Necesitas cuantizar agresivamente (int8 vs fp16), y las opciones de cuantización cambian la recuperación en 2–4% en corpus reales. Pasarás una semana ajustando esto antes de enviar.
Las reconstrucciones de índice ocurren cuando actualizas el modelo de embedding. Planifica la migración antes de enviar. Las reconstrucciones parciales son tentadoras y peligrosas. Terminarás con dos espacios vectoriales en el mismo índice, puntuaciones de similitud inconsistentes y fallos silenciosos donde documentos antiguos y nuevos recuperan en umbrales diferentes.
Los modos de fallo se multiplican. Un OOM en el modelo de embedding derriba la recuperación y generación en la misma caja. No tienes un servicio de embedding separado al que recurrir. La latencia de arranque en frío y la latencia de arranque en caliente no se parecen en nada a tu línea de base en la nube. Si estás acostumbrado a 80ms p99 para embeddings de OpenAI, los embeddings locales de 15ms se ven mejor hasta que mides p99 bajo carga. La varianza de programación de GPU te sorprenderá.
La Arquitectura que Mantiene la Recuperación Asincrónica
Si decides que EmbeddingGemma 2 vale el impuesto operativo, la forma de evitar el muro de latencia es mantener los embeddings fuera de tu ruta crítica.
Ejecuta un servicio de embedding separado en su propio pod de GPU. No coloques con generación. Sí, esto agrega complejidad de infraestructura. También significa que la recuperación no detiene la generación. El costo es modesto—una L4 o H100 manejará la concurrencia de embedding a escala—y recuperas la recuperación asincrónica.
El embedding especulativo es un patrón concreto. Dispara la consulta de recuperación contra la entrada parcial del usuario antes de que terminen de escribir. Para cuando comienza la generación, los vectores están calientes y en caché. Es el comportamiento asincrónico que tenías con APIs en la nube, pero sin el viaje de ida y vuelta de la red.
El ventaneo por lotes ayuda. Agrupa solicitudes de embedding en sesiones concurrentes en lotes de 5–20ms, luego dispáralos a la GPU en una llamada. Intercambias unos pocos milisegundos de latencia por mejor rendimiento y eficiencia de caché.
Agrega un fallback. Si la profundidad de cola de embedding local excede un umbral, cambia a embeddings en la nube. Tu agente sigue respondiendo; evitas el acantilado de latencia. La varianza de latencia es lo que realmente rompe los SLAs. Un fallback colapsa la cola.
Almacena embeddings en caché agresivamente. La mayoría de las consultas de agente no son novedosas. Si has visto una entrada de usuario antes, tienes vectores. Reutilízalos. Redis con clave en hash de entrada. TTL de 24 horas. Saltarás 60–70% de llamadas de embedding en producción.
Mide la latencia de ruta crítica p95 antes y después del cambio. No la latencia del modelo. Tiempo de reloj desde la entrada del usuario hasta la respuesta del agente. Si los embeddings en la nube no están en la ruta crítica hoy, EmbeddingGemma 2 no cambiará eso. Si lo están, la refactorización gana su complejidad.
Antes de cambiar a embeddings locales, instrumenta tu ruta de recuperación actual para p95 de reloj de pared y contención de GPU durante 48 horas. Si los embeddings en la nube no están bloqueando, EmbeddingGemma 2 no hará que tu agente sea más rápido. Si lo están, el movimiento correcto es separar tu servicio de embedding y medir de nuevo. Cuéntanos en /contact si quieres hablar sobre la refactorización de sincrónico a asincrónico.