
Caso de Estudio
Autoptic llegó a nosotros con un problema de lenguaje, pero no de los típicos. Su plataforma necesitaba un Large Language Model capaz de entender un lenguaje de código propietario — construido específicamente para consultar servicios de AWS y métricas de Prometheus. El modelo tenía que tomar un prompt en lenguaje natural, traducirlo a esa sintaxis interna y ajustar el código resultante a medida que el usuario refinaba su pedido.
Autoptic aprovisionaba los recursos de AWS; Renaiss se hizo cargo de la infraestructura que entrenaría, alojaría e iteraría sobre el modelo. Al mismo tiempo, y sin pausar ese frente, el cliente necesitaba que se lanzaran nuevas funcionalidades en la aplicación misma. Acá no hubo una fase uno y una fase dos: los dos frentes avanzaron juntos, y las decisiones de infraestructura de un lado tenían que sostenerse mientras el producto seguía cambiando del otro.
El primer modelo entrenado ya produce resultados precisos contra los propios datos del cliente. No es el estado final — los próximos pasos incluyen ajustar los hiperparámetros, refinar la función de loss y un nuevo deployment orientado a performance, no solo a corrección. Del lado de la aplicación, hay nuevas funcionalidades de frontend basadas en Svelte en curso, cada una ligada a llamadas de backend que mejoran la experiencia diaria del equipo del cliente.
Este es, a propósito, un caso de estudio sobre un proyecto en pleno vuelo. El valor que obtuvo Autoptic no fue un producto terminado desde el día uno — fue una base de infraestructura y de frameworks lo suficientemente sólida como para que mejorar el modelo desde acá no requiera reconstruir nada por debajo.
El propio equipo del cliente sugirió Axolotl para entrenar el modelo. Sobre el papel parecía suficiente, pero no daba ninguna forma confiable de medir qué tan bueno era realmente el modelo. Migramos a Unsloth, que sumó esa capa de medición y, en las primeras pruebas, devolvió mejores respuestas desde el arranque.
Una Training Instance con GPU se hizo cargo del trabajo pesado hasta que la secuencia de entrenamiento quedó estable. Después pasamos a una instancia limpia para sacar librerías sin uso y recuperar espacio en EBS, y finalmente introdujimos una Staging Instance más chica y barata, una vez que el modelo ya no necesitaba cómputo de nivel entrenamiento.
En lugar de mover los archivos del modelo entre instancias a mano, usamos las funciones de transferencia propias de Ollama y su repositorio de modelos como almacenamiento centralizado y versionado. Recuperar una versión anterior dejó de ser una tarea manual de buscar y copiar.
Un security group de SSH limitó el acceso a las instancias solo a usuarios autorizados — un control básico, pero fácil de saltear bajo presión de entrega y caro de agregar después.
Un security group de SSH limitó el acceso a las instancias solo a usuarios autorizados — un control básico, pero fácil de saltear bajo presión de entrega y caro de agregar después.
Modificamos el frontend de OpenWebUI con React y Svelte, y construimos nuevas funciones de backend en FastAPI, para que la interfaz de la aplicación no se quedara atrás de lo que el modelo realmente podía hacer.
Evaluación de frameworks
Axolotl cubría el entrenamiento básico pero no ofrecía forma de medir la calidad del modelo. Unsloth lo reemplazó, sumando la capa de medición que el proyecto necesitaba y mejorando la calidad de las respuestas desde el primer caso de uso.

Etapas de infraestructura
Entrenamiento, limpieza y staging corrieron cada uno en una instancia EC2 dimensionada para esa tarea, en lugar de que una sola instancia hiciera los tres trabajos con distintos niveles de eficiencia. Ollama sirvió el modelo en un entorno OpenWebUI containerizado para staging.

Versionado del modelo
Entrenamiento, limpieza y staging corrieron cada uno en una instancia EC2 dimensionada para esa tarea, en lugar de que una sola instancia hiciera los tres trabajos con distintos niveles de eficiencia. Ollama sirvió el modelo en un entorno OpenWebUI containerizado para staging.

Controles de costo y acceso
Un security group de SSH limitó la exposición, y una rutina automatizada de apagado con Lambda/EventBridge eliminó el costo recurrente de instancias ociosas — sin que nadie tuviera que acordarse de hacerlo a mano.

Capa de aplicación
React y Svelte en el frontend, FastAPI en el backend, evolucionando junto al modelo en lugar de esperar a que estuviera terminado.

Frontend y backend evolucionaron al ritmo del modelo
Modificamos el frontend de OpenWebUI con React y Svelte, y construimos nuevas funciones de backend en FastAPI, para que la interfaz de la aplicación no se quedara atrás de lo que el modelo realmente podía hacer.

Trabajamos sobre todo con bancos y empresas del mercado de capitales en proyectos de modernización tecnológica: infraestructura, sistemas core e incorporación de IA a procesos reales. También tomamos proyectos de otros sectores cuando la exigencia técnica es la misma — varios de los casos de esta sección lo son. En todos los casos, entramos como equipo técnico senior embebido, no como una mesa de soporte tercerizada.
Tenemos base en Rosario, Argentina, y trabajamos con clientes en toda Latinoamérica. Eso significa conocimiento directo del contexto regulatorio y operativo de la región — por ejemplo la normativa del BCRA para fintechs argentinas — y coordinación en el mismo huso horario, sin la fricción de trabajar con un equipo a 10 horas de diferencia.
Nuestro trabajo está en la intersección de infraestructura cloud, arquitectura de aplicaciones e IA: diseño de arquitectura cloud-native, automatización de infraestructura, plataformas, pipelines de datos e integración de GenAI. No hacemos soporte cloud genérico — construimos y operamos sistemas que necesitan escalar.
Nuestra mayor profundidad es en AWS. También trabajamos con Azure y GCP según el stack que ya tenga el cliente — el objetivo siempre es adaptarnos a tu entorno, no imponer un proveedor.
Sí — es uno de los problemas en los que más trabajamos. Modernizar una aplicación suele implicar alguna combinación de: separar un monolito en servicios, migrar a infraestructura cloud-native, reemplazar dependencias obsoletas o mejorar el pipeline de CI/CD para que el equipo entregue más rápido. Siempre arrancamos con un diagnóstico técnico antes de recomendar un camino.