El equipo quiere ajustar un modelo abierto en vez de llamar a una API alojada. ¿Cómo lo decidirías?

Decide en cuatro ejes: calidad en tu tarea concreta, coste a tu volumen real, requisitos de latencia y control, y restricciones de datos o de cumplimiento. Empieza con la API alojada más prompting y recuperación para fijar barato un listón de calidad. Ajusta el modelo cuando tengas una tarea estable con buenos datos etiquetados, volumen suficiente para que la economía se dé la vuelta, o el requisito de mantener los datos dentro de tu propio entorno.

Presionaría para responderlo con números en vez de con preferencias. Primero, construir la línea base alojada: un buen prompt, recuperación si la tarea necesita contexto, y un conjunto de evaluación. Eso suele llevar días y nos dice qué calidad es alcanzable, y a menudo ya es suficiente, con lo que el ajuste fino es una solución en busca de un problema. Si la calidad se queda de verdad corta, pregunto si la brecha es de conocimiento, que la arregla la recuperación, o de comportamiento y formato, que lo arregla el ajuste fino. Luego la economía. El coste alojado escala de forma lineal con los tokens; el autoalojamiento es sobre todo coste fijo de acelerador, así que hay un volumen de cruce, y lo calculo con proyecciones de tráfico reales y no con ilusiones. Por debajo del cruce, el autoalojamiento pierde antes siquiera de contar el tiempo de un ingeniero. El coste que se olvida es la propiedad: servir, autoescalado, actualizaciones, reevaluar cuando cambias de modelo base, alguien de guardia. Eso es un compromiso permanente. Donde se decide solo es en el cumplimiento. Si los datos no pueden salir de nuestro entorno, la decisión ya está tomada y la discusión es solo sobre qué modelo abierto, no sobre si sí o no.