Memoria de IA local vs nube: benchmarks

En las herramientas de IA, lo predeterminado es la nube primero. API, servicios alojados, "nosotros gestionamos la infraestructura por ti". Para la mayoría de las cosas es la opción correcta: ejecutar la inferencia de modelos en local con la calidad que ofrecen los proveedores de la nube es realmente difícil.

La memoria de IA es la excepción.

Para los agentes de código con IA en concreto (Claude Code, Codex, Cursor, OpenCode, Gemini en modo agente), la memoria local gana con claridad. No porque la nube sea mala, sino porque el patrón de carga de la memoria de desarrollo encaja excepcionalmente bien con la inferencia local y excepcionalmente mal con las API en la nube.

Este post defiende esa idea, con números.

Tres impuestos que te cobra la memoria en la nube

Toda API de memoria en la nube te cobra tres impuestos de los que no puedes librarte:

1. El impuesto de latencia

Una llamada a memoria en la nube son dos viajes de ida y vuelta por la red: uno para generar el embedding de tu consulta y otro para recuperar las memorias que coinciden. Con banda ancha:

Llamada a la API de embeddings: 200-400ms
Llamada de búsqueda vectorial: 100-200ms
Total: 300-600ms por recuperación

Una llamada a memoria local son dos operaciones de CPU:

Embedding local: 12ms
Búsqueda vectorial en SQLite: 5ms
Total: 17ms por recuperación

La diferencia es de 20-35x. En una sola recuperación no importa. En una sesión de programación en la que recuperas memorias 50-100 veces por hora, suma varios minutos de pura latencia.

También es la diferencia entre una memoria que se siente invisible y una que parece tener pantalla de carga. El flujo interactivo muere rápido cuando cada consulta a la memoria frena la sesión.

2. El impuesto de costo

Los embeddings en la nube son baratos, pero no gratis:

OpenAI text-embedding-3-small: $0,02 por 1M de tokens
Cohere embed-english-v3.0: $0,10 por 1M de tokens
Embeddings de Voyage: $0,12 por 1M de tokens

Una sesión de programación intensa genera unos 100.000 tokens diarios de tráfico de recuperación de memoria (las consultas son cortas, pero el volumen es alto). Con 250 días laborables al año:

25M de tokens/año × $0,02 = $0,50/año/desarrollador (poco)
Más el plan de almacenamiento del servicio de memoria alojado: normalmente $20-100/mes por workspace

Para un solo desarrollador es un error de redondeo. Para un equipo de 50 es dinero de verdad, y el valor que obtienes frente a la memoria local es prácticamente cero en la carga de trabajo de la memoria de desarrollo.

3. El impuesto de privacidad

Memoria en la nube significa que tu código, las notas del proyecto, las trazas de depuración, las decisiones de diseño y (a menudo) el historial completo de conversaciones se envían a un tercero. Aunque el proveedor sea de confianza:

Es un proveedor más en tu flujo de datos
Las revisiones de cumplimiento se complican
Dependes de la política de retención del proveedor
Dependes de que el proveedor siga existiendo

Para las aplicaciones de consumo no hay problema. Para el trabajo de desarrollo en cualquier empresa que haga revisiones de cumplimiento, es un dolor de cabeza considerable.

La memoria local deja los tres impuestos en cero.

Por qué la memoria de desarrollo no es como la de producción

La memoria de IA centrada en la nube encaja muy bien con los agentes de producción: bots de atención al cliente, copilotos de ventas, asistentes de IA integrados en la aplicación. Esas cargas de trabajo tienen:

Estado centralizado (la memoria pertenece al producto, no al usuario)
Concurrencia intensa (más de 1.000 usuarios consultando la memoria a la vez)
Requisitos de consistencia entre instancias
Necesidades de cumplimiento y auditoría que se benefician de un proveedor gestionado

La memoria de desarrollo es lo contrario. Un solo usuario. Un solo dispositivo. Sin concurrencia. Sin estado entre varias instancias. La "memoria" son notas conversacionales sobre tu propio código, no datos de usuarios que tengas el deber de proteger.

Para esa carga de trabajo, la arquitectura que gana es también la más simple: un único archivo SQLite en disco + un modelo de embedding de 22MB que corre en CPU. SynaBun viene exactamente con eso. Mem0 self-hosted se acerca. OpenMemory usa un patrón similar. Los productos centrados en la nube (Mem0 alojado, Letta Cloud, Zep Cloud) pagan por una infraestructura que no necesitan para este caso de uso.

Benchmark: local vs. nube, prueba de 100 consultas

El mismo MacBook Air M1, el mismo corpus de 12.000 memorias, las mismas 200 consultas de evaluación. Tres configuraciones:

Configuración	Modelo de embedding	Almacén vectorial	Latencia media	Recall@5
SQLite local	all-MiniLM-L6-v2	sqlite-vec	17ms	78%
Mem0 self-hosted	OpenAI v3-small	Qdrant + Postgres	95ms	83%
Mem0 en la nube	OpenAI v3-small	Mem0 SaaS	280ms	83%
Zep en la nube	OpenAI v3-small	Zep SaaS	240ms	81%
Letta self-hosted	OpenAI v3-small	pgvector	110ms	80%

La diferencia en calidad de recuperación (78% frente a 83%) es de 5 puntos porcentuales. La diferencia de latencia es de 6-16x.

Para la memoria de desarrollo, no hay mucho que pensar. El 5% de diferencia en recuperación se traduce en «a veces tengo que formular la consulta de otra manera». La diferencia de 16x en latencia se traduce en «la memoria parece rota» frente a «la memoria se siente nativa».

Lo que local-first NO significa

Tres ideas equivocadas sobre la «memoria de IA local-first»:

No significa que solo funcione sin conexión. SynaBun, Mem0 self-hosted y Letta self-hosted funcionan bien sin conexión, pero también se sincronizan con remotos de git, S3 o lo que les indiques si quieres copias de seguridad.
No significa renunciar a la calidad de búsqueda. Los modelos pequeños modernos (all-MiniLM-L6-v2, bge-small, gte-small) quedan a un 5-7% de OpenAI v3 en la mayoría de los benchmarks. La brecha se reduce cada 6 meses.
No significa renunciar a la interfaz. SynaBun incluye una Neural Interface en 3D para explorar la memoria en local. Mem0 tiene un panel self-hosted. Que la interfaz solo exista en la nube es una decisión, no una limitación.

Cuándo la nube es la respuesta correcta

No soy dogmático con esto. Usa memoria en la nube si:

Estás creando un producto con múltiples inquilinos donde la memoria pertenece al producto, no al desarrollador
Tu equipo tiene una regla estricta de «nada de SQLite en producción» (más común de lo que imaginas)
Necesitas replicación entre regiones lista para usar
Quieres que un servicio gestionado se encargue de las copias de seguridad y del escalado
Trabajas sobre una infraestructura que no puede alojar un modelo pequeño (raro en 2026)

Para todo lo demás, lo local es la respuesta más simple.

Además, la instalación cuesta menos

Mucha gente da por hecho que «self-hosted» implica una instalación compleja. En el caso concreto de la memoria de desarrollo, es al revés.

Instalación de SynaBun:

npm install -g synabun
synabun

Eso es todo. SQLite se crea en el primer uso. El modelo de embedding se descarga una vez y queda en caché. Sin Postgres. Sin Qdrant. Sin Docker compose.

Instalación de Mem0 self-hosted:

docker compose up -d  # starts Qdrant + Postgres + Mem0 API
# configure connection strings in .env
# wire MCP server

Funciona, pero pesa más.

Instalación de Letta self-hosted:

docker compose up -d  # Postgres + Letta API + agent runtime
# configure model provider
# wire MCP wrapper

La complejidad no viene de «local o nube», sino de la arquitectura de almacenamiento y servicios que eligió cada proyecto. Que SynaBun haya elegido SQLite es la verdadera razón por la que se instala con un solo comando.

Lo que construiría si empezara hoy

Si fuera a crear un nuevo servidor de memoria MCP en 2026, copiaría estas decisiones al pie de la letra:

SQLite + sqlite-vec. Sin tareas de administración. Fácil de respaldar. Se puede integrar. Se puede comparar con diff.
all-MiniLM-L6-v2 o bge-small-en-v1.5 por defecto. Gratis, local y rápido. Ofrece un adaptador de OpenAI/Voyage para quien lo quiera.
Nativo de MCP, no un wrapper. Sé un servidor MCP de verdad. Implementa las herramientas por completo.
Memoria por categorías. Los vectores por sí solos son demasiado planos. Categorías + proyectos + etiquetas + importancia permiten navegar la memoria de verdad.
Interfaz local. En el navegador, servida desde el mismo proceso de Node. Sin una aplicación de Electron aparte y sin inicio de sesión obligatorio en la nube.

Esa es, a grandes rasgos, la arquitectura de SynaBun. También describiría una versión más limpia de OpenMemory o un Mem0 self-hosted reducido a lo esencial.

El sector se mueve hacia lo local

Observa los próximos 12 meses. Las tendencias son claras:

Los modelos de embedding pequeños siguen mejorando. bge-large-en-v1.5 ya queda a un 1-2% de OpenAI v3 en la mayoría de los benchmarks, con 320MB.
Las extensiones vectoriales de SQLite (sqlite-vec, usearch-sqlite) son cada vez más rápidas.
MCP se sigue estandarizando. Los wrappers de servicios en la nube perderán terreno frente a los servidores MCP nativos que tratan la memoria como un concepto de primera clase.
Los equipos que cuidan la privacidad ya piden explícitamente herramientas de IA local-first. En 2024 era una petición marginal. En 2026 es lo habitual.

Los productos de memoria de IA centrados en la nube no van a desaparecer: dominarán los agentes en producción y las aplicaciones con múltiples inquilinos. Pero para el trabajo de desarrollo, lo local ya ganó. La mayoría de los desarrolladores simplemente no ha cambiado todavía porque cuesta salir de la opción por defecto.

Cierre

Si usas una API de memoria en la nube para tu workflow de programación con IA, prueba una local durante una semana. La diferencia de latencia es de esas cosas que, una vez que las notas, no puedes dejar de notar. Cuando la memoria se vuelve invisible, volver a un indicador de carga de 300ms en cada recuperación se siente peor de lo que suena.

SynaBun es la opción local-first que construí yo. OpenMemory es una alternativa seria. Letta y Zep son excelentes si necesitas sus funciones específicas, pero las pagas en latencia.

Elige local. Tu ritmo de trabajo te lo agradecerá.

Lecturas relacionadas:

Memoria de IA self-hosted: por qué lo local supera a la nube para los agentes de código