Tool-Calling: Cuándo un Modelo de Pocos Millones de Parámetros le Gana a un LLM Completo
Decidir qué función ejecutar y con qué argumentos no es redacción abierta: es una decisión de espacio acotado. Tratarla como si necesitara el mismo modelo que un chatbot conversacional paga latencia y costo por una capacidad que esa decisión nunca usa.
Un Tool-Call es una Clasificación, no una Redacción
En una arquitectura agéntica, cada paso que decide "qué función llamar y con qué argumento" se suele resolver con el mismo LLM grande que redacta la respuesta final al usuario. Es la ruta de menor esfuerzo de implementación — y la más cara de operar.
El problema no es de calidad, es de arquitectura: un LLM de propósito general está optimizado para generar texto en un espacio de salida prácticamente infinito. Elegir una función de un catálogo finito y completar un esquema de argumentos ya definido es un problema estructuralmente más chico — y pagar el modelo grande por cada una de esas decisiones, en un agente que puede dar decenas de pasos por sesión, multiplica latencia y costo por algo que el tamaño del modelo no está resolviendo.
El costo que no se ve en la demo
Una demo con 3 tool-calls no expone el problema. Un agente en producción, con reintentos y pasos intermedios, puede ejecutar cientos de estas decisiones por sesión — ahí el costo marginal de usar un modelo grande para enrutar se vuelve visible en la factura, no en la latencia percibida de una sola llamada.
El Espacio de Decisión Acotado, y las Cuatro Variables que lo Confirman
Un modelo chico funciona bien cuando el espacio de salida está acotado por un esquema de función bien definido — la precisión ahí no depende del tamaño del modelo, depende de cuán bien delimitado está el catálogo de opciones. Para decidir si una decisión de tool-calling es candidata a un modelo pequeño, evaluamos cuatro variables del proceso.
| Variable | Qué mirar | Por qué importa |
|---|---|---|
| Precisión exigida | ¿El error dispara una acción real o solo un texto raro? | Un tool-call mal enrutado ejecuta la función equivocada, no genera una frase torpe. |
| Volumen | Cuántas decisiones de este tipo por sesión de agente. | El costo de enrutar con un modelo grande se multiplica por cada paso, no por sesión. |
| Latencia tolerada | ¿La decisión bloquea una interacción en vivo o corre en batch? | Un usuario esperando la respuesta no tolera el mismo presupuesto que un proceso nocturno. |
| Gravedad del error | Qué hace la función si se llama mal: ¿lee, escribe, cobra, borra? | Define si además del modelo chico hace falta un umbral de confianza con hand-off a la nube. |
Es la misma lógica que aplicamos al elegir entre APIs de IA por tamaño de tarea, no por preferencia de marca — ver la comparativa de APIs. Ahí evaluamos en banco propio Needle (Cactus), un modelo de solo 26 millones de parámetros especializado en tool-calling on-device: resuelve en milisegundos la decisión de qué función llamar y con qué argumento, dentro de un catálogo acotado.
Router Local vs. Function-Calling en la Nube
El patrón de arquitectura detrás de un router como Needle no es solo "modelo chico": es un modelo chico que declara su propia incertidumbre. Cada decisión sale acompañada de un puntaje de confianza; bajo un umbral, el sistema deriva el caso a un LLM grande en la nube en vez de ejecutar una función a ciegas.
| Dimensión | Function-calling en la nube (LLM grande) | Router on-device (modelo chico) |
|---|---|---|
| Latencia | Round-trip de red + inferencia del modelo completo | Local, del orden de milisegundos |
| Costo marginal por decisión | Tokens de un modelo grande, cada tool-call cuenta | Marginal ~0, corre en el dispositivo |
| Privacidad del payload | La decisión y sus argumentos salen del dispositivo | No sale del dispositivo salvo hand-off |
| Precisión fuera del catálogo | Alta, generaliza a casos ambiguos | Baja por diseño — para eso existe el hand-off |
| Dependencia de hardware | Ninguna, corre en el servidor del proveedor | Real — el motor nativo necesita i8mm o cae a un runtime genérico |
Los números de motor (tokens/segundo, tiempo al primer token) que publica Cactus para su runtime varían fuerte según el silicio, no son una constante del modelo. El detalle de qué procesadores lo soportan a velocidad completa está en el reporte de hardware, sección siguiente.
i8mm decide si el motor nativo compila a velocidad completa o cae a un runtime genérico — con la tabla completa de qué CPU/SoC lo traen y cuáles no.
- 19GPU comparadas
- i8mmEl flag que decide todo
El Resultado no es un Número Único, es un Criterio de Decisión
No hay un porcentaje de ahorro genérico que aplique a cualquier agente — depende de cuántas decisiones de tool-calling ejecuta por sesión y de qué tan acotado está su catálogo de funciones. Lo que sí es reproducible es el criterio para decidir qué mueve y qué se queda en el LLM grande.
Espacio de decisión acotado
Router chico + hand-off
Catálogo de funciones finito, esquema de argumentos bien definido, volumen alto de llamadas por sesión. El modelo chico decide y adjunta confianza; bajo el umbral, deriva.
Espacio abierto o ambiguo
LLM grande, sin atajo
Razonamiento sobre casos no vistos, redacción, o un catálogo de funciones que todavía no está bien delimitado. Ahí el modelo chico no tiene de dónde sacar precisión.
Dónde Este Patrón No Aplica
- Esquema de función ambiguo: un catálogo mal documentado rompe la precisión del modelo chico igual que rompería a cualquier clasificador — el acotamiento tiene que ser real, no aspiracional.
- Umbral de confianza mal calibrado: demasiado permisivo ejecuta acciones equivocadas sin hand-off; demasiado conservador deriva casi todo a la nube y se pierde el ahorro que justificaba el diseño.
- Tareas de razonamiento abierto: este patrón resuelve enrutamiento, no reemplaza al modelo grande en generación de prosa o análisis de casos ambiguos.
- Benchmark de fabricante, no independiente: los números de velocidad y precisión de motores como Cactus son los que publica el propio fabricante — evaluarlos en el caso propio antes de dimensionar sobre ellos.
La Arquitectura Híbrida, Pieza por Pieza
- Catálogo de funciones con esquema estricto: cada función define su nombre, argumentos y tipos — el acotamiento del espacio de decisión nace acá, no en el modelo.
- Motor de inferencia nativo en el dispositivo: el router chico corre embebido — como SDK móvil o binario local — con el requisito de hardware que exige correr rápido (i8mm real, ver reporte de hardware).
- Umbral de confianza configurable por dominio de riesgo: una función que lee datos tolera un umbral más bajo que una que cobra o borra — el umbral no es un valor único para todo el catálogo.
- Hand-off al LLM grande: el caso derivado no repite la decisión desde cero — llega con el contexto ya acotado por el intento fallido del router, así el modelo grande resuelve solo la fracción ambigua.
El Tamaño del Modelo lo Decide la Forma de la Decisión
Un catálogo de funciones bien acotado, con volumen alto y latencia interactiva, es candidato a un router chico con hand-off. Confundir esto con "todo tool-calling necesita el modelo más grande disponible" es pagar de más por una capacidad que esa decisión puntual no usa.
¿Estás diseñando o auditando la arquitectura de un agente con tool-calling en producción? Antes de escalar el volumen de llamadas, conviene revisar qué decisiones realmente necesitan el modelo grande.
Contenido relacionado
Hardware Local para IA: la Tabla Completa de GPU y el Nodo Edge Económico
El router chico de este reporte solo corre rápido con el silicio correcto — 19 GPU comparadas por VRAM y la tabla completa de qué procesadores soportan i8mm.
Ver la comparativa - Sweet Spot RTX 3090Qué API de IA Usar en tu Proyecto: la Arquitectura Correcta, no la Más Cara
Las cuatro variables para elegir el tamaño de modelo correcto por proceso — incluye la evaluación en banco propio del router de tool-calling que origina este reporte.
Leer diagnóstico - Parámetros de Needle¿Dónde Vive tu IA? Self-Host vs. API Gestionada: el Costo Real
El router local de este reporte es un caso particular de una decisión más amplia: cuándo el costo real justifica sacar la inferencia de la nube.
Ver la comparativa - Más Barato que API RealtimeModelo de Lenguaje Propio para tu Empresa
El servicio que aterriza esta arquitectura: diseño e implementación de tu stack de tool-calling y modelo de lenguaje propio, self-hosted o vía API.
Ver la solución - Modelo de Lenguaje Propio