← Volver a todos los insights

Tecnología Publicado · 26 de junio de 2026

Modelos pequeños y en dispositivo: cuando cero por consulta gana

La inferencia en dispositivo cuesta exactamente cero por consulta después de descargar el modelo. Para el 80% del tráfico de una empresa típica, la diferencia de calidad ya no justifica pagar por cada llamada.

5 min de lectura

En casi todas las arquitecturas que auditamos existe la misma ineficiencia: se llama a un modelo frontera caro para tareas que un modelo pequeño resuelve igual de bien.

No es un fallo de criterio. Es que se montó así cuando sólo existía una opción.

La economía

Los modelos pequeños que corren en tu servidor o en el dispositivo del usuario tienen una propiedad que ninguna API iguala: cuestan exactamente cero por consulta después de la descarga inicial.

Comparado con los modelos económicos de las APIs, que rondan cifras bajas por millón de tokens, parece poca diferencia. A escala deja de parecerlo. Un proceso que clasifica 200.000 documentos al mes acumula coste de forma lineal para siempre; el mismo proceso en un modelo propio tiene un coste fijo de infraestructura y un marginal de cero.

Y eso con los precios de inferencia por los suelos. El argumento no es que la API sea cara: es que para cierto tipo de tarea estás pagando por capacidad que no usas.

Para qué sirven de verdad

Un modelo pequeño no razona como uno frontera, y pretender lo contrario es la forma más rápida de fracasar. Pero hay una franja amplísima de trabajo empresarial que no necesita razonamiento profundo:

  • Clasificar. Este ticket es de facturación, este correo es una queja, este documento es un albarán.
  • Extraer. Sacar quince campos de una factura, un número de pedido de un correo, fechas de un contrato.
  • Enrutar. Decidir qué equipo, qué flujo o qué modelo grande debe atender cada caso.
  • Redactar con plantilla. Respuestas estructuradas donde el formato manda sobre la creatividad.
  • Filtrar y priorizar. Separar lo urgente de lo que puede esperar.

En una empresa mediana, esto suele ser el grueso del volumen.

El patrón que recomendamos

Un enrutador delante. Un modelo pequeño barato decide si el caso es rutinario o complejo. Lo rutinario lo resuelve él; lo complejo sube al modelo frontera.

Ventajas más allá del coste:

  • Latencia. Un modelo local responde en milisegundos, sin ida y vuelta de red.
  • Disponibilidad. Si tu proveedor tiene una caída, el 80% de tu tráfico sigue funcionando.
  • Privacidad. El dato que resuelve el modelo local no sale de tu red, lo que resuelve de golpe media docena de objeciones legales.
  • Independencia. Dejas de estar expuesto a cambios de precio o de política en la parte que más volumen mueve.

Lo que hay que presupuestar

Esto no es gratis, sólo es barato:

  • Hardware, o instancia con GPU, y quien sepa mantenerla.
  • Un set de evaluación para demostrar que el modelo pequeño rinde en tus casos. Sin esto es un acto de fe.
  • Un plan de actualización. Los modelos abiertos mejoran cada pocos meses.
  • Una ruta de escalado clara: qué pasa cuando el enrutador se equivoca y manda arriba algo que no debía, o al revés.

Cómo empezar

Coge el proceso de más volumen que tengas en producción. Saca 200 casos reales. Ejecútalos contra el modelo grande que usas hoy y contra un modelo pequeño abierto. Compara.

Si la diferencia de calidad es pequeña, acabas de encontrar el ahorro. Si es grande, has aprendido algo útil sobre tu caso de uso por el coste de una tarde.

Fuentes

Siguiente paso

¿En qué punto está tu empresa para adoptar IA?

Evalúa la madurez de tu empresa en 5 minutos y recibe recomendaciones personalizadas y gratuitas.

¿Listo para ir más allá del hype?