Cómo hacer tu primera llamada a Nebius Token Factory API

En pocas palabras: Nebius Token Factory API es compatible con el SDK openai de Python: solo hay que cambiar el base_url a https://api.tokenfactory.nebius.com/v1/ y la api_key. Un tutorial del 8 de noviembre de 2026 en dev.to muestra el setup con uv y el modelo Nemotron-3.5-Lightning de Nvidia.

Nebius Token Factory API es la plataforma de Nebius que deja usar modelos opensource con llamadas compatibles con el SDK openai de Python. Un tutorial publicado el 8 de noviembre de 2026 en dev.to muestra, paso a paso, cómo hacer la primera llamada con uv, python-dotenv y el modelo Nemotron-3.5-Lightning de Nvidia. Más allá del paso a paso, lo que importa para alguien que ya tiene código corriendo contra OpenAI es entender qué cambia y qué no cuando se apunta a un proveedor compatible: eso es lo que repasamos en esta nota, con algunos criterios para decidir si conviene migrar o no.

Nebius Token Factory API es un servicio de inferencia que expone modelos de lenguaje opensource (como los de Nvidia) a través de endpoints con la misma especificación que usa OpenAI. Esto significa que cualquier código que ya tenga el SDK openai de Python puede apuntar a Token Factory cambiando solo el base_url y la api_key, sin tocar la lógica de negocio.

¿Qué es Nebius Token Factory API y para qué sirve?

Nebius Token Factory API es un servicio que permite hacer llamadas a modelos opensource alojados por Nebius usando la misma interfaz que ya conocés si trabajaste con OpenAI. El objetivo es que no tengas que aprender un SDK nuevo para probar modelos de distintos proveedores.

El post de dev.to que dispara esta nota es, de hecho, el primero de una serie pensada para principiantes. El autor, bajo el seudónimo networkandcode, lo plantea así: “en este post beginner friendly vamos a ver cómo hacer una llamada a la API de Nebius Token Factory y obtener una respuesta a nuestro prompt, y también vamos a cubrir algunos básicos de Python”, según el post original. Ojo: esto no es un curso completo de Python, es un primer contacto con la plataforma.

¿Por qué importa la compatibilidad con openai? Porque te ahorra reescribir integraciones existentes. Lo explicamos a fondo en la diferencia entre API y MCP.

¿Cuándo conviene migrar a Token Factory y cuándo no? Criterios de decisión

La compatibilidad con el SDK de openai resuelve el problema técnico de la migración, pero no responde la pregunta de fondo: ¿tiene sentido para tu caso? A partir de lo que muestra el tutorial, hay algunas señales concretas que ayudan a decidir:

• Si ya tenés código productivo con el SDK openai y solo querés probar un modelo opensource distinto, el cambio de base_url es casi gratis: no hay que reescribir prompts, parseo de respuestas ni manejo de clientes. Este es el escenario que mejor cubre el tutorial.
• Si necesitás manejo de errores, reintentos o streaming desde el día uno, el post de referencia no lo cubre (ni lo promete): es un ejemplo mínimo de una sola llamada. Antes de meter esto en producción hay que sumar esa capa por tu cuenta.
• Si tu prioridad es elegir entre varios modelos opensource sin comprometerte a uno, el catálogo de endpoints públicos de Token Factory tiene sentido como capa de prueba, dado que el routing key se consigue directo desde la tarjeta del modelo sin tocar código salvo ese string.
• Si necesitás conversación con historial (multi-turno), el propio tutorial aclara que eso queda para la siguiente entrega de la serie: al 8 de noviembre de 2026 solo está probado el caso de un mensaje único por llamada.

Ejemplo hipotético (ilustrativo, no basado en una prueba real): pensemos en un equipo que ya tiene un backend con el SDK openai apuntando a client.chat.completions.create() para generar descripciones de producto. Si quisieran comparar esa salida contra un modelo opensource como Nemotron-3.5-Lightning sin tocar el resto del backend, el camino que muestra el tutorial sería: duplicar el cliente OpenAI con el base_url de Token Factory, copiar el routing key exacto desde el catálogo y correr el mismo prompt por los dos clientes en paralelo. La lectura de la respuesta (output_text o el equivalente en chat.completions) se mantiene igual en ambos casos, así que lo único que cambiaría en el código es el cliente usado, no la lógica de negocio. Esto es una proyección sobre lo que permite la compatibilidad declarada en el SDK, no un resultado verificado por esta nota.

¿Cómo se configura el entorno de Python con uv?

Se configura con un solo comando: uv init try-tokenfactory crea la carpeta del proyecto con toda la estructura necesaria. uv es un gestor de paquetes y proyectos para Python que viene reemplazando combos más viejos de pip y venv, y el tutorial lo usa de punta a punta.

Después de correr cd try-tokenfactory/ y listar el contenido con ls -1a (el flag -1 muestra todo en formato lineal y la a incluye archivos ocultos), aparecen estos elementos: .git, .gitignore, .python-version, .venv, main.py, pyproject.toml, README.md y uv.lock. Es la estructura típica de cualquier proyecto Python moderno armado con uv, nada exótico.

Tomalo con pinzas si venís de otro gestor: el .venv y el uv.lock los genera uv solo, no hace falta tocarlos a mano.

¿Cómo se obtiene y guarda la API key de Token Factory?

La API key se genera desde el panel de Token Factory y se guarda en un archivo .env como variable NEBIUS_API_KEY. El propio ejemplo del tutorial muestra el formato esperado: NEBIUS_API_KEY="<REDACTED>", un detalle chico pero que evita el error clásico de subir la key al repo sin querer. Tema relacionado: cuánto cuesta realmente usar estas APIs.

Con la key guardada, faltan dos dependencias. Se agregan con uv add, fijando versión exacta: uv add openai==3.46.0 para la librería que hace las llamadas, y uv add python-dotenv==1.2.4 para cargar las variables de entorno desde el .env. Fijar versiones así (en vez de dejar que uv resuelva lo que quiera) es una buena práctica que se nota poco pero evita sorpresas cuando alguien más clona el proyecto.

¿Cómo se estructura el código para llamar a la Nebius Token Factory API?

La lógica se reduce a cuatro piezas: cargar la variable de entorno con la key, instanciar un cliente OpenAI apuntando al endpoint de Nebius, elegir un routing key de modelo y leer la respuesta. Si ya hiciste esto mismo contra la API de OpenAI directa, lo único nuevo acá es el base_url; el resto es prácticamente idéntico.

El código completo que muestra el post es este:

• import os: módulo interno para interactuar con el sistema operativo, se usa para leer la variable de entorno
• from dotenv import load_dotenv: función que carga el contenido del .env a las variables de entorno del proceso
• from openai import OpenAI: la clase principal del SDK, en PascalCase como corresponde a toda clase en Python
• client = OpenAI(base_url=”https://api.tokenfactory.nebius.com/v1/”, api_key=os.environ.get(“NEBIUS_API_KEY”)): acá está la clave de todo, el base_url apunta a Token Factory en vez de a OpenAI directamente

Con esas cuatro piezas armadas, agregás la llamada con el prompt y corrés uv run main.py. En teoría ya tenés respuesta del modelo, sin instalar nada más y sin configurar un servidor propio. Eso sí, todo esto corre en tu máquina local: si después necesitás exponer un endpoint propio para un servicio en producción, ahí entra en juego otra conversación sobre dónde alojarlo.

¿Qué modelo se usó en el ejemplo y cómo se elige uno?

El tutorial elige Nemotron-3.5-Lightning de Nvidia, cuya routing key es nvidia/Nemotron-3_5-Lightning. Ese routing key es el valor que va en el parámetro model de la llamada, y se obtiene mirando los endpoints públicos disponibles en el catálogo de Token Factory. Ya lo cubrimos antes en todo sobre el modelo Sora de OpenAI.

¿Hay que memorizar el nombre exacto del modelo? No, alcanza con entrar al catálogo, hacer clic en la tarjeta del modelo que te interesa y copiar el routing key tal cual aparece ahí. El post lo resume así: “elijo Nemotron-3.5-Lightning, podemos hacer clic en esa tarjeta y obtener la routing key”. Un detalle que conviene mirar con atención: el guión bajo en “3_5” en vez del punto que usa el nombre visible del modelo. Es el tipo de cosa que rompe una llamada si la copiás mal a mano.

¿Qué respuesta devuelve la API y cómo se lee?

La respuesta se lee con response.output_text, el atributo que trae el texto generado por el modelo. En el ejemplo del post, el prompt pide “un dato interesante de fauna que los chicos puedan entender fácilmente” y el modelo responde con el dato de que las mariposas saborean con las patas, porque tienen sensores de gusto en las piernas que les permiten reconocer si una planta es comestible apenas se paran sobre ella.

¿Y si querés ver qué más trae el objeto response? Con print(dir(response)) aparecen todos los atributos disponibles, output_text es solo uno de varios. El tip vale la pena, sobre todo cuando necesitás metadata adicional (tokens usados, id de la respuesta, lo que sea) y no sabés bien dónde está guardada.

¿Qué limitaciones tiene este primer tutorial de la serie?

La limitación principal es que solo cubre un mensaje por llamada, no una conversación con historial. El propio autor lo aclara al cierre del post: “en este post dimos solo un mensaje como input, pero normalmente sería multimensaje por input, eso lo vamos a ver en el próximo post”. Es un ejemplo introductorio, no de chat completo. Más contexto en cómo se evalúa la seguridad de los agentes.

Tampoco entra en detalles de manejo de errores, rate limits ni streaming de respuestas. Para un primer contacto con cómo migrar código existente de openai a Token Factory alcanza y sobra, pero si estás pensando en algo productivo vas a necesitar bastante más que estas cuatro líneas de código.

Errores comunes al arrancar con Nebius Token Factory

• Subir el .env al repo: si el .gitignore no está bien configurado (uv lo genera por defecto, pero conviene chequearlo), la API key termina en GitHub. Revisá que .env esté listado antes de hacer el primer commit.
• Copiar mal el routing key del modelo: el nombre visible en el catálogo (Nemotron-3.5-Lightning) no es igual al routing key real (nvidia/Nemotron-3_5-Lightning). Copiá siempre el valor exacto desde la tarjeta del modelo, no lo escribas a mano.
• No fijar versiones de las librerías: instalar openai o python-dotenv sin especificar versión puede traer cambios de API entre releases. El tutorial fija openai==3.46.0 y python-dotenv==1.2.4 por una razón.
• Confundir client.responses.create con client.chat.completions.create: son dos formas distintas de llamar al modelo dentro del mismo SDK, con estructuras de respuesta diferentes. Si copiás código viejo de otro proyecto, fijate cuál de las dos estás usando.

Preguntas Frecuentes

¿Qué es Nebius Token Factory?

Nebius Token Factory es una plataforma de Nebius para hacer llamadas API a modelos opensource con la misma interfaz que usa el SDK de OpenAI. Expone un catálogo de endpoints públicos (como Nemotron-3.5-Lightning de Nvidia) a los que se accede cambiando solo el base_url y la api_key en el código. Lo complementamos en por qué los tokens necesitan un dueño visible.

¿Cómo hago mi primera llamada a la API de Token Factory?

Creás un cliente OpenAI apuntando a https://api.tokenfactory.nebius.com/v1/ con tu NEBIUS_API_KEY, y llamás a client.responses.create() pasando el routing key del modelo y tu prompt en el parámetro input. La respuesta se lee con response.output_text.

¿Token Factory es compatible con la librería openai de Python?

Sí, Token Factory es compatible con el SDK openai de Python. Solo hace falta instanciar la clase OpenAI con un base_url distinto, el resto del código se mantiene igual.

¿Qué modelos opensource puedo usar en Token Factory?

Podés usar cualquiera de los endpoints públicos listados en el catálogo de Token Factory, entre ellos Nemotron-3.5-Lightning de Nvidia, el que usa el tutorial de referencia. Cada modelo tiene su propio routing key, que se obtiene desde la tarjeta del modelo en el catálogo.

¿Cómo instalo y configuro uv para un proyecto de Python?

Instalás uv siguiendo las instrucciones de su documentación oficial y después corrés uv init nombre-del-proyecto para generar la estructura base. uv crea automáticamente main.py, pyproject.toml, .venv, .gitignore y uv.lock, y las dependencias se agregan con uv add nombre-paquete==versión.

Conclusión

Lo que deja este primer post de la serie es un punto de entrada sin fricción: si ya tenés código con openai, migrarlo a Nebius Token Factory API es cambiar dos líneas, no reescribir nada. Eso, para cualquiera que esté evaluando modelos opensource sin querer aprender un SDK nuevo, es un punto a favor real, y es justamente el criterio que más pesa a la hora de decidir si vale la pena probarlo: cuánto código existente podés reusar tal cual.

Lo que no responde este tutorial es igual de importante: no hay manejo de errores, no hay conversación multimensaje, no hay nada sobre límites de uso o costos por token (las fuentes consultadas no traen esa información, así que no lo vamos a inventar acá). Si vas a probarlo, arrancá con el ejemplo tal cual está, confirmá que la llamada funciona con tu propia API key, y después sumá de a poco el manejo de errores y el streaming antes de pensar en algo productivo.

Fuentes

• Token Factory series: Getting started – post original en dev.to con el código completo del tutorial