FunctionGemma y el auge de los modelos dedicados a llamadas de funciones

Google lanzó silenciosamente algo que importa más de lo que la mayoría se da cuenta: FunctionGemma. Es un modelo Gemma 3 con 270 millones de parámetros — no billones, millones — ajustado específica y exclusivamente para llamadas de funciones.

270M de parámetros. Eso es más pequeño que BERT. Cabe en 540MB de RAM en FP16, menos de 200MB cuantizado. Corre en una Raspberry Pi. Y su trabajo es una sola cosa: tomar un mensaje del usuario y un conjunto de schemas de herramientas, y producir la llamada de función correcta con los parámetros correctos.

Este no es un modelo de propósito general que también hace llamadas de funciones. Este es un motor de llamadas de funciones construido con un propósito específico. Y señala un cambio fundamental en cómo construimos sistemas de IA.

Qué hace realmente FunctionGemma

FunctionGemma toma dos entradas:

1. Un conjunto de definiciones de funciones (schemas de herramientas con nombres, descripciones y tipos de parámetros)
2. Un mensaje del usuario

Y produce una salida:

Una llamada de función estructurada — el nombre de la función y sus parámetros como JSON.

Eso es todo. No chatea. No resume. No escribe poesía. Mapea intención en lenguaje natural a invocaciones de funciones. Una tarea, bien hecha.

Ejemplo

Entrada:

Functions available:
- get_weather(location: string, unit: "celsius" | "fahrenheit") → Weather data for a location
- search_restaurants(city: string, cuisine: string, price_range: 1-4) → Restaurant listings

User: "What's the weather like in Berlin?"

Salida:

{"function": "get_weather", "arguments": {"location": "Berlin", "unit": "celsius"}}

Sin preámbulo. Sin explicación. Sin "Claro, estaré encantado de ayudar." Solo la llamada de función.

Por qué 270M de parámetros es un gran logro

Para apreciar lo que FunctionGemma representa, compáralo con las alternativas:

*Precisión medida en el Berkeley Function Calling Leaderboard (BFCL) en tareas estándar. Tu experiencia varía según la complejidad de las herramientas.

FunctionGemma logra 82-88% de precisión en benchmarks estándar de llamadas de funciones con 30 veces menos parámetros que Llama 3.3 8B. Usa 22 veces menos RAM. Solo en CPU, genera tokens de 10 a 15 veces más rápido que un modelo 8B.

Para herramientas de API estándar — clima, búsqueda, operaciones CRUD, consultas a bases de datos — esto a menudo es suficientemente bueno. Y "suficientemente bueno a 200MB" abre escenarios de despliegue que "excelente a 4.5GB" no puede tocar.

Qué señala esto: El fin de "un modelo para todo"

Durante los últimos tres años, el patrón dominante ha sido: elige el modelo más inteligente que puedas pagar, úsalo para todo. GPT-4 para llamadas de funciones, GPT-4 para resúmenes, GPT-4 para clasificación, GPT-4 para generación. Un modelo, una clave de API, una factura.

FunctionGemma representa la filosofía opuesta: construye (o usa) un modelo que hace una cosa, y hazlo lo más pequeño y rápido posible para esa única cosa.

Esta no es una idea nueva en ingeniería de software. No usamos un servidor de base de datos para servir archivos estáticos. No usamos un web framework para procesar trabajos ETL por lotes. La especialización es la norma en todas partes excepto en IA, donde "usa GPT-4" ha sido la respuesta a toda pregunta.

El cambio está ocurriendo porque:

1. Los modelos de pesos abiertos se volvieron suficientemente buenos para especializarse. No puedes ajustar GPT-4 en un especialista (no realmente). Sí puedes ajustar Gemma, Llama y Qwen.
2. Los costos de despliegue importan ahora. La fase de prototipado terminó. Los equipos están ejecutando más de 10K-100K consultas por día y la factura de API es una línea real en el presupuesto.
3. La latencia importa ahora. Los usuarios esperan respuestas en menos de un segundo. Un modelo de 270M responde en milisegundos. Un modelo 8B toma segundos en CPU.
4. El despliegue en el edge es real. En el dispositivo, en el navegador, en hardware embebido — necesitas modelos que quepan en entornos restringidos.

Cuándo usar FunctionGemma vs ajustar el tuyo propio

Esta es la pregunta práctica. FunctionGemma existe. ¿Deberías usarlo?

Usa FunctionGemma tal cual cuando:

Tus herramientas son estándar. Si tus schemas de funciones se parecen a APIs REST típicas — operaciones CRUD, endpoints de búsqueda, recuperación de datos — FunctionGemma probablemente ha visto patrones similares en sus datos de entrenamiento. Las herramientas estándar incluyen:

• APIs de clima, búsqueda, mapas
• Operaciones de lectura/escritura en base de datos
• Servicios de correo electrónico, calendario, notificaciones
• Procesamiento de pagos (schemas estándar)
• Operaciones de CRM (si usas nombres de campos comunes)

Una precisión de 82-88% es aceptable. Para aplicaciones no críticas, herramientas internas o sistemas con revisión humana, esta tasa de acierto funciona. El 12-18% de fallos son mayormente errores a nivel de parámetros (tipo incorrecto, campo opcional faltante) en lugar de selecciones de funciones completamente incorrectas.

Necesitas una huella de despliegue mínima. Si el modelo necesita correr en un dispositivo con 512MB de RAM, o en un navegador vía WebAssembly, o en una placa de $35, FunctionGemma es una de muy pocas opciones.

Ajusta tu propio modelo cuando:

Tus herramientas son personalizadas o específicas de dominio. APIs internas con convenciones de nombres no obvias, schemas propietarios, terminología específica de dominio. FunctionGemma nunca ha visto tu función initiate_claims_adjudication. Un modelo ajustado la ha visto cientos de veces.

Necesitas más del 95% de precisión. Para sistemas de producción donde los errores en llamadas de funciones causan problemas reales — transacciones financieras, flujos de trabajo de salud, despliegues automatizados — necesitas la precisión que viene de entrenar con tu schema exacto. Los modelos 7B ajustados rutinariamente alcanzan 95-98% en las herramientas específicas para las que fueron entrenados.

Tienes lógica de parámetros compleja. Cuando los parámetros correctos dependen de contexto que no está en la descripción de la función — "usa el almacén preferido del cliente, no el predeterminado" o "siempre establece prioridad en alta para cuentas empresariales" — los modelos genéricos no pueden aprender estas reglas. Los modelos ajustados sí.

Ajusta FunctionGemma cuando:

Esta es la opción interesante. Usa FunctionGemma como modelo base y ajústalo con tus schemas de herramientas específicos. Obtienes:

• Las ventajas arquitectónicas de un modelo construido para llamadas de funciones
• El aumento de precisión de entrenar con tus herramientas específicas
• Un modelo que sigue siendo diminuto (fine-tuning agrega 10-50MB vía LoRA)

Los resultados iniciales sugieren que FunctionGemma ajustado alcanza 90-94% de precisión en schemas de herramientas personalizadas — comparable a un modelo 3B ajustado pero a 10 veces menos tamaño. El trade-off: las secuencias complejas de múltiples herramientas todavía favorecen a los modelos más grandes.

Marco de decisión

Así es cómo elegir:

Inicio
  │
  ├── ¿Tus herramientas son APIs estándar con schemas comunes?
  │     ├── Sí → ¿Es aceptable una precisión de 82-88%?
  │     │          ├── Sí → Usa FunctionGemma tal cual
  │     │          └── No  → Ajusta FunctionGemma con tu schema
  │     └── No  → ¿Tus herramientas son altamente personalizadas/específicas de dominio?
  │                ├── Sí → Ajusta Qwen 2.5 7B o Llama 3.3 8B
  │                └── Moderado → Ajusta FunctionGemma con tu schema
  │
  ├── ¿Necesitas secuencias de múltiples herramientas (3+ herramientas encadenadas)?
  │     ├── Sí → Ajusta modelo 7B+ (FunctionGemma es para un solo paso)
  │     └── No  → FunctionGemma o FunctionGemma ajustado
  │
  └── ¿Restricción de despliegue?
        ├── Edge/dispositivo (menos de 1GB RAM) → FunctionGemma (ajustado o no)
        ├── Servidor (8-16GB RAM) → Modelo 7B ajustado
        └── Sin restricción → Elige según necesidades de precisión

Comparación: FunctionGemma vs alternativas ajustadas

La conclusión: FunctionGemma no es un reemplazo para modelos 7B ajustados en escenarios complejos. Es una nueva opción para llamadas de funciones simples a moderadas a una fracción del costo de recursos.

El panorama general: Los modelos específicos por tarea son el futuro

FunctionGemma es un dato dentro de una tendencia. Espera ver:

• Modelos de clasificación de menos de 500M de parámetros que clasifican texto en categorías más rápido y barato que hacer prompting a GPT-4
• Modelos de extracción construidos específicamente para extraer datos estructurados de texto no estructurado
• Modelos de enrutamiento que deciden qué herramienta, qué modelo o qué pipeline usar para una solicitud dada
• Modelos de validación que verifican si una salida generada cumple con un schema o estándar de calidad

La arquitectura del futuro no es un modelo grande. Es un grafo de pequeños especialistas, cada uno haciendo un trabajo:

User Request → Router (100M) → Selected Specialist
  ├── Tool Caller (270M - FunctionGemma)
  ├── Summarizer (1B)
  ├── Classifier (500M)
  └── Generator (7B - only when you need full language generation)

RAM total del sistema: quizás 6-8GB. Latencia: menos de 100ms para la mayoría de los caminos. Costo: cero por consulta.

Compara esto con enviar cada solicitud a GPT-4: $0.03 por consulta, 500-2000ms de latencia, cero capacidad de funcionar offline y dependencia completa de una API de terceros.

Qué significa esto para los usuarios de Ertas

Si ya estás ajustando modelos con Ertas, FunctionGemma te da una nueva opción en tu kit de herramientas:

Para nuevos proyectos de tool-calling: Comienza con FunctionGemma. Sube tus schemas de herramientas, genera ejemplos de entrenamiento, ajusta. Si la precisión es suficiente (prueba en tu conjunto de evaluación), despliega. Si no, sube a un modelo base 7B y ajusta ese.

Para despliegues existentes: Si tienes un modelo 7B ajustado manejando tareas simples de tool-calling junto con las complejas, considera dividir: FunctionGemma para las rutas simples, modelo 7B para las complejas. Liberas capacidad de GPU y reduces la latencia en el camino simple.

Para despliegues en el edge: FunctionGemma es el primer modelo que hace práctico el tool-calling en el dispositivo. Una app móvil, un kiosco, un gateway IoT — en cualquier lugar donde necesites un agente de IA que funcione sin acceso a internet, este es el punto de partida.

Cómo ajustar FunctionGemma en Ertas

El proceso es el mismo que para cualquier otro modelo:

1. Prepara tu dataset de tool-calling (entrada: mensaje del usuario + schemas de herramientas, salida: JSON de llamada de función)
2. Selecciona FunctionGemma como modelo base
3. Configura LoRA (rank 8-16 es suficiente dado el tamaño pequeño del modelo)
4. Entrena por 3-5 épocas (toma 5-10 minutos en una sola GPU)
5. Evalúa contra tu conjunto de prueba
6. Despliega — el modelo se sirve desde menos de 300MB de RAM

El fine-tuning es rápido porque el modelo es pequeño. Puedes iterar rápidamente: entrena, evalúa, ajusta datos de entrenamiento, reentrena. Un ciclo completo en menos de 30 minutos.

La evaluación honesta

FunctionGemma es impresionante por lo que es. No es una solución mágica. Aquí están las limitaciones reales:

• Sin razonamiento multi-turno. Maneja llamadas de funciones de un solo turno. Para agentes de múltiples pasos, todavía necesitas una arquitectura de modelo más grande o especialista.
• Ventana de contexto limitada. Con 270M de parámetros, la ventana de contexto es pequeña. Si tienes más de 20 herramientas con schemas complejos, el modelo tiene dificultades. Mejor con 3-10 herramientas por solicitud.
• Sin capacidad conversacional. No puede explicar por qué eligió una función o hacer preguntas de clarificación. Mapea entrada a salida. Para agentes conversacionales, combínalo con un modelo de chat.
• Benchmark vs mundo real. La precisión de 82-88% en benchmarks es con solicitudes limpias y bien formadas. Las entradas reales de usuarios son desordenadas. Espera una precisión de 5-10% menor en tráfico de producción sin fine-tuning.

A pesar de estas limitaciones, la existencia de FunctionGemma cambia el cálculo. La pregunta ya no es "¿pueden los modelos pequeños hacer tool-calling?" Sino "¿qué tan pequeño podemos ir para este caso de uso específico?"

Lectura adicional

• Fine-tuning de modelos pequeños vs GPT-4: Cuándo gana el modelo pequeño — el argumento más amplio a favor de modelos pequeños específicos por tarea sobre APIs de frontera de propósito general
• Mejor modelo open-source para ajustar en 2026 — dónde encaja FunctionGemma junto a Qwen, Llama, Mistral y otros modelos base
• Fine-tuning para tool calling: Cómo construir agentes de IA confiables — la guía completa para construir agentes de tool-calling con modelos ajustados