AWS muestra cómo ejecutar llama.cpp en SageMaker y obtener probabilidades por opción

AWS Machine Learning Blog ha publicado una guía paso a paso para desplegar modelos de decisión en Amazon SageMaker AI con el motor llama.cpp. El esquema tiene dos capas. Primero se levanta un endpoint basado en el AWS Deep Learning Container oficial para llama.cpp, que ofrece chat completions compatibles con OpenAI. Después se amplía el runtime con la biblioteca SemIf, y en lugar de texto generado el modelo devuelve probabilidades por opciones declaradas de antemano. Todo ello funciona tanto en CPU como en GPU.

Es un material práctico: una guía, no el anuncio de un producto nuevo. Pero muestra cómo propone AWS cubrir uno de los escenarios corporativos más frecuentes: la clasificación y la toma de decisiones con modelos pequeños, sin una infraestructura de GPU pesada.

De qué se compone el stack

llama.cpp es un motor de inferencia de código abierto en C/C++ que puede ejecutar modelos cuantizados en formato GGUF y no requiere GPU. Por eso es popular allí donde se necesitan endpoints baratos y predecibles. AWS lo ha empaquetado en su propio Deep Learning Container para que no haya que construir la imagen a mano ni lidiar con las dependencias.

Elementos clave de la solución, según la descripción de AWS:

• Plataforma: Amazon SageMaker AI, endpoints gestionados para inferencia.
• Runtime: AWS Deep Learning Container para llama.cpp.
• Interfaz: chat completions compatibles con OpenAI, de modo que los clientes y SDK existentes se conectan sin reescribirlos.
• Extensión: SemIf, que devuelve probabilidades por las opciones declaradas.
• Hardware: CPU o GPU, la elección queda en manos del desarrollador.

La compatibilidad con el formato de OpenAI resuelve un problema práctico de migración. Si la aplicación ya consume una API de chat, pasar a un endpoint propio se reduce a cambiar la dirección y la clave.

Por qué probabilidades en lugar de texto

Un modelo de decisión responde a una pregunta con un conjunto finito de resultados: aprobar o rechazar una solicitud, enviar un ticket a facturación o a soporte técnico, marcar un mensaje como infracción o dejarlo pasar. Un LLM convencional devuelve una cadena de texto que hay que parsear. El formato de la respuesta varía, el modelo añade explicaciones y, a veces, se inventa una opción que no figura en la lista.

Según la descripción, SemIf resuelve este problema a nivel de runtime. El desarrollador declara las opciones válidas y recibe como respuesta una distribución de probabilidades sobre ellas. Se puede elegir el máximo, pero lo más interesante es otra cosa: aparece un umbral de confianza. Si la mejor opción obtiene 0,92, la acción se ejecuta automáticamente. Si obtiene 0,48, el caso pasa a una persona. Así, el modelo de lenguaje se convierte en un componente con calibración medible, que se puede integrar en un proceso de negocio corriente.

Para los ingenieros es además una cuestión de pruebas. Las probabilidades se pueden registrar en logs, comparar entre versiones del modelo y usar para construir métricas, algo imposible con texto arbitrario.

Lo que el anuncio no dice

La breve reseña no incluye benchmarks, precios, lista de modelos compatibles ni detalles de implementación de SemIf. No está claro cómo se calculan exactamente las probabilidades: a partir de los logits de los primeros tokens de las opciones o de otro modo. De ello depende cuánta confianza merecen con opciones largas o compuestas. Tampoco hay una comparación de CPU y GPU en latencia y coste por solicitud. Esos datos habrá que obtenerlos por cuenta propia.

Por dónde empezar

Orden de trabajo práctico para un equipo que quiera probar el enfoque:

• Elige una tarea acotada con entre 3 y 10 resultados posibles, por ejemplo, el enrutamiento de solicitudes.
• Toma un modelo pequeño cuantizado en GGUF y despliégalo en una instancia de CPU. Es el arranque más barato.
• Reúne una muestra etiquetada y mide en qué medida las probabilidades de SemIf se corresponden con la precisión real. Ajusta los umbrales para la decisión automática y para la escalada.
• Solo después, compara con una instancia de GPU en latencia y precio por mil solicitudes.

Si la calibración resulta mala, es mejor saberlo antes de pasar a producción. Si resulta buena, el equipo tendrá un endpoint gestionable, con una API conocida y una economía clara.