Preguntas frecuentes.

La inferencia de IA es el proceso de usar un modelo de IA ya entrenado para generar resultados a partir de nuevas entradas: ejecutar la IA para obtener respuestas, resúmenes o predicciones.

Ejemplos: hacerle una pregunta a ChatGPT, resumir un documento de 50 páginas, clasificar tickets de soporte, generar descripciones de productos, extraer información de contratos.

La inferencia requiere hardware GPU potente. A escala, los costos se acumulan rápidamente, y ese es exactamente el problema que resuelve MicroDC.ai. Si su empresa procesa texto o datos con IA a escala, está pagando por inferencia. Nosotros le ayudamos a pagar hasta un 90% menos.

MicroDC.ai es una plataforma distribuida de inferencia de IA: un mercado de dos lados que conecta a empresas que necesitan cómputo de IA con personas y organizaciones que tienen recursos de GPU inactivos.

Problema: los costos de la inferencia de IA se están disparando. Los grandes proveedores de nube cobran precios premium y construir infraestructura interna exige una inversión de capital considerable.

Solución: agregamos recursos de GPU distribuidos en todo el mundo y ofrecemos inferencia de nivel empresarial con un costo hasta un 90% menor que la nube tradicional, sin gestión de infraestructura.

MicroDC.ai fue fundada por Ray Sisson (CEO) y Jeffrey Rivero (CTO), con Neil Quarterman como CFO.

• Ray Sisson — MBA por Chicago Booth, JD por Georgetown. Transporte, infraestructura y liderazgo en consejos de administración.
• Jeffrey Rivero — Más de 25 años en ciberseguridad e IA/ML, CISSP. Ha construido plataformas que procesan más de 1M de eventos por segundo e IA para las fuerzas armadas de EE. UU.
• Neil Quarterman — MBA por Yale y Georgia Tech. Gestionó las finanzas durante un crecimiento del 140% y fusiones y adquisiciones en 11 entidades de 8 países.

Las organizaciones suelen ver una reducción de costos del 50 al 90% en comparación con las instancias de GPU de la nube tradicional:

• El modelo asíncrono elimina los cargos por cómputo inactivo
• Costo cero en DevOps, mantenimiento o escalado
• Pago por uso: solo por los tokens procesados
• Escale de $10 a $10,000 al mes sin fricciones

Ejemplo: una empresa de procesamiento documental que procesa 100,000 documentos al mes ahorró un 78% al pasar de instancias de GPU dedicadas al procesamiento por lotes de MicroDC.ai.

Ideales: resumen de documentos, generación de contenido a escala, enriquecimiento de datos, investigación y analítica por lotes, procesamiento nocturno, generación de informes.

Considere alternativas para: chatbots en tiempo real con respuesta inferior a un segundo, IA interactiva de cara al usuario, respuestas en streaming, sistemas críticos en tiempo real.

Sistema sencillo basado en créditos. 1 crédito = $0.01 USD. Créditos de bienvenida para las cuentas nuevas. Sin cuotas de alta, mensuales ni de plataforma. Precio por trabajo según la complejidad del modelo y los tokens procesados.

Niveles: Economy (menor costo, plazos flexibles) · Standard (equilibrado) · Premium (prioridad).

La seguridad es la base. Nuestro CTO tiene la certificación CISSP y más de 25 años en ciberseguridad:

• Cifrado de extremo a extremo (TLS 1.3 en tránsito, cifrado en reposo)
• Aislamiento de los workers: no pueden ver la identidad de los clientes ni otros trabajos
• Minimización de datos: solo se envía la carga útil del trabajo a los workers
• Eliminación automática de los datos del trabajo dentro de un periodo de retención configurable
• Registros de auditoría completos de todas las transacciones y accesos
• Autenticación JWT con tokens de corta duración

Para cargas de trabajo sensibles, active los trabajos cifrados de extremo a extremo: las cargas útiles se cifran antes de salir de su máquina y los resultados son de conocimiento cero, cifrados con su clave pública, de modo que nadie salvo usted (ni siquiera MicroDC) puede leerlos. Descripción completa de la arquitectura →

Actualmente: arquitectura con la seguridad como prioridad bajo una dirección con certificación CISSP, auditorías y pruebas de penetración periódicas, ciclo de desarrollo seguro.

Planificado: SOC 2 Type II, ISO 27001, documentación de GDPR. Contáctenos para conocer el estado actual de cumplimiento.

Para cargas de trabajo sensibles recomendamos: anonimizar o seudonimizar antes de procesar, eliminar la información personal cuando sea posible, usar la configuración de retención para minimizar la exposición, considerar los trabajos cifrados de extremo a extremo (resultados de conocimiento cero) y evaluar grupos de workers dedicados.

Para HIPAA, PCI-DSS u otras cargas de trabajo reguladas, contacte con ventas para analizar opciones de infraestructura dedicada.

Sí. Paquetes empresariales a medida: descuentos por volumen, procesamiento prioritario, garantías de SLA, soporte dedicado, integración personalizada y facturación a 30 días (NET-30) para clientes que cumplan los requisitos. Escriba a sales@microdc.ai.

Disponibilidad de la plataforma: objetivo del 99.9% de disponibilidad de la API.

SLA de procesamiento de trabajos por nivel:

• Economy — mejor esfuerzo, normalmente < 4 horas
• Standard — 95% completados en 1 hora
• Premium — 99% completados en 15 minutos

Los clientes empresariales reciben SLA personalizados con créditos por objetivos no cumplidos.

Conecte sus recursos según su propio horario. Los workers reciben una participación generosa en los ingresos. Panel de ganancias en tiempo real. Varias opciones de pago (créditos con bonificación, efectivo por PayPal). Consulte la página de Proveedores.

Estamos desarrollando una integración con blockchain orientada a la transparencia, la confianza y los pagos descentralizados:

• Verificación transparente de trabajos: registro inmutable del trabajo completado y de los pagos
• Pagos por contrato inteligente: pagos automatizados y sin intermediarios a los proveedores
• Reputación descentralizada: puntuaciones de los workers en cadena
• Incentivos basados en tokens: posible token de utilidad por participación
• Pagos transfronterizos mediante criptomonedas

Los métodos de pago tradicionales seguirán disponibles junto a cualquier función basada en blockchain.

• Cómputo auditable: prueba criptográfica del trabajo para fines de cumplimiento
• Transparencia de costos: precios verificables
• Resolución de disputas: arbitraje por contrato inteligente
• Liquidación global sin demoras bancarias
• Registros a prueba de manipulación de todas las interacciones con la plataforma

Ahora: inferencia por lotes, más de 100 modelos, sistema de créditos, panel web.

Próximamente: respuestas en streaming, alojamiento de modelos personalizados, analítica mejorada.

Futuro: verificación en cadena, pagos con tokens, expansión global.

Sí. Ofrecemos un endpoint de Chat Completions compatible con OpenAI. Apunte su cliente openai existente a https://api.microdc.ai/v1 y conserve su código. Se admiten listas de contenido multimodal. Funciona con LangChain, LlamaIndex, Instructor y cualquier biblioteca con la forma de OpenAI.

De forma predeterminada, los trabajos se envían en texto plano para que el servidor pueda ayudar con el enrutamiento y la fijación de precios. Para cargas de trabajo sensibles, use trabajos cifrados de extremo a extremo: su cliente cifra la carga útil con AES-256-GCM antes de que salga de su máquina, y el servidor almacena y enruta únicamente texto cifrado; nunca inspecciona, registra ni descifra su contenido. La clave de la carga útil se deposita en custodia con el único fin de entregarla al worker que reclama el trabajo (siempre un nodo administrado por MicroDC con la capacidad encryption aprobada por un administrador, nunca un worker de la comunidad) y se elimina en el momento en que usted confirma la recepción del resultado. Los resultados están aún más protegidos: el worker los cifra con una clave de un solo uso envuelta con su clave pública RSA, de modo que solo su clave privada, que nunca sale de su máquina, puede descifrarlos. Explicamos exactamente dónde la garantía es criptográfica y dónde es operativa en el análisis detallado del cifrado.

Sí. Use el tipo de trabajo container. Indique el nombre de la imagen, args/env opcionales y cualquier archivo de script (.py, .sh, .js, .ts, .go, .rs, .java...) como entradas. Se enruta solo a workers que anuncian la capacidad docker. Transmisión de registros en vivo mediante un heartbeat por trabajo.

Precio medido: tarifa por hora de GPU × tiempo de ejecución, o tarifa por núcleo-hora de CPU × núcleos × tiempo de ejecución, más una tarifa de plataforma de $2.00 por ejecución. Se aplican cargos mínimos. Los trabajos solo de CPU usan por defecto $0.005 por núcleo-hora cuando el modelo de CPU del worker no tiene precio por nivel.

Cada trabajo se etiqueta con un nivel de contexto (1–4) al enviarse, según la longitud del prompt. Los workers declaran un max_context_tier mediante el heartbeat; su trabajo solo será reclamado por un worker capaz de atenderlo. Es transparente para su código: usted no define el nivel, lo calcula el servidor.

Nivel 1 = 0–1.5K caracteres, nivel 2 = 1.5K–6K, nivel 3 = 6K–24K, nivel 4 = 24K+.

Tres componentes:

Client (SDK/API)     Server (Hub)         Workers (Compute)
      |                   |                     |
      |  Submit Job       |                     |
      |------------------>|                     |
      |                   |  Queue Job          |
      |                   |-------------------->|
      |                   |                     |
      |                   |  Poll for Jobs      |
      |                   |<--------------------|
      |                   |                     |
      |                   |  Return Results     |
      |                   |<--------------------|
      |  Get Results      |                     |
      |<------------------|                     |

Servidor: backend de la API, PostgreSQL, planificador. Workers: nodos GPU distribuidos que ejecutan la inferencia. Cliente: SDK de Python y API REST.

Backend: FastAPI, PostgreSQL, autenticación JWT, Docker.
Frontend (consola): HTMX, Alpine.js, Tailwind CSS, Jinja2.
Workers: entorno de ejecución Python, vLLM / llama.cpp, compatibilidad con GPU CUDA/ROCm.
Infraestructura: Docker Compose (desarrollo), Kubernetes (producción), Nginx, Redis (planificado).

1. El cliente envía un trabajo con los requisitos de modelo
2. El planificador localiza workers con la GPU/VRAM necesaria
3. Los trabajos se ordenan por nivel de prioridad y hora de envío
4. La selección por mejor ajuste tiene en cuenta el historial de rendimiento del worker
5. Los trabajos fallidos se reprograman en otro worker

Reintento inteligente: un trabajo fallido no se reasigna al mismo worker.

pip install git+https://gitlab.com/microdc/python-client.git

from microdc import Client, LLMCall

client = Client(api_key="mDC_your_api_key")

job = LLMCall(model="llama3.3")
job.add_user_message("Explain quantum computing in simple terms")

job_id = client.send_job(job)
result = client.wait_for_job(job_id)
print(result.output)

Documentación completa del SDK: gitlab.com/microdc/python-client

URL base: https://api.microdc.ai/v1 — Authorization: Bearer mDC_your_api_key

• LLMCall — generación de texto, chat completions, prompts de sistema, temperature/top_p
• EmbedCall — embeddings de texto para búsqueda/RAG, embeddings por lotes, varios modelos
• ImageGeneration — Stable Diffusion, dimensiones personalizadas, prompts negativos
• CustomJob / Container — cargas de trabajo personalizadas y flexibles, cargas útiles Docker arbitrarias

job = LLMCall(model="llama3.3")
job.add_user_message("Process this document...")

job_id = client.send_job(
    job,
    callback_url="https://your-api.com/webhook/microdc"
)

# Your webhook will receive POST with:
# { "job_id": "uuid", "status": "completed", "result": {...} }

O use sondeo con client.wait_for_job(job_id).

Más de 100 modelos de código abierto.

LLM: Llama 3.3 (8B, 70B), Mistral (7B, Mixtral), Qwen 2.5, DeepSeek, Phi-3, Gemma 2.
Embeddings: BGE, E5, GTE, Nomic Embed.
Imagen: Stable Diffusion XL, SDXL Turbo, Flux.

Catálogo en vivo: /models.html

Sí. El alojamiento de modelos personalizados está disponible: carga de pesos, validación automática, despliegue en workers compatibles, control de versiones y acceso privado. Contáctenos para conocer requisitos y precios.

La mayoría de los trabajos se completan en entre 30 segundos y 5 minutos. El nivel Premium promedia menos de 1 minuto. Factores: nivel de prioridad, tamaño del modelo, cantidad de tokens y profundidad de la cola.

export MICRODC_API_KEY="mDC_your_api_key"

client = Client()  # auto-reads from env
# or
client = Client(api_key="mDC_...")

# HTTP header:
Authorization: Bearer mDC_your_api_key

Nunca incluya claves de API en el control de versiones. Use variables de entorno o un gestor de secretos.

• TLS 1.3 en tránsito
• AES-256 en reposo
• Aislamiento de los workers en Docker
• Minimización de datos: solo se envían a los workers los datos necesarios
• Purga automática tras un periodo de retención configurable
• El contenido de los trabajos no se registra en el servidor

Límites predeterminados (ampliables para clientes empresariales):

Cabeceras de límite de tasa: X-RateLimit-Remaining

Se admiten GPU AMD (ROCm). Los workers solo de CPU pueden atender modelos más pequeños.

git clone https://gitlab.com/microdc/worker.git
cd worker
pip install -r requirements.txt
export MICRODC_WORKER_TOKEN="mdc_wrk_your_token"
python worker.py --models llama3-8b,mistral-7b

El worker se registrará automáticamente, descargará los modelos necesarios y empezará a sondear en busca de trabajos. Guía de instalación: gitlab.com/microdc/worker

Un asiento contable por trabajo en el registro JobAssignment: su fuente de verdad, no un contador propenso a desviarse. Se agrega en su página de Ganancias en tres ventanas: histórico, 90 días y 30 días. Factores: complejidad del modelo, volumen de trabajos, puntuación de rendimiento y fiabilidad, y preferencias de latencia geográfica.

En evaluación: L2 de Ethereum (Arbitrum, Optimism), Solana, Polygon y una cadena propia basada en Cosmos SDK. Criterios de selección: comisiones bajas, alto rendimiento, ecosistema de desarrollo y claridad regulatoria.

• Custodia de pagos — bloqueados y liberados al verificarse la finalización
• Prueba de trabajo — verificación criptográfica
• Sistema de reputación — puntuaciones de los workers en cadena
• Resolución de disputas — arbitraje descentralizado

Estamos explorando un token de utilidad: moneda de pago, staking para workers, gobernanza, descuentos en comisiones y recompensas. La economía del token está en desarrollo. Los pagos tradicionales en moneda fiduciaria siempre serán compatibles.

Despliegue por fases: Fase 1 — aceptar pagos con stablecoins (USDC/USDT). Fase 2 — pruebas en cadena de la finalización de trabajos. Fase 3 — descentralización completa, lanzamiento del token, staking y gobernanza.

Menos de lo que imagina. Admitimos una amplia gama gracias al enrutamiento por nivel de contexto: los workers declaran su capacidad y solo reciben trabajos que pueden atender.

• Nivel 1 (prompts cortos) — placas ARM, Orange Pi Max 16GB, portátiles antiguos, solo CPU
• Nivel 2 — GPU de entrada (GTX 1660, RTX 3060 8GB) o equipos de CPU con mucha RAM
• Nivel 3 — GPU de gama media con 16GB+ de VRAM (RTX 4070, A4000)
• Nivel 4 — GPU de gama alta con 24GB+ de VRAM (RTX 4090, A100, H100)

Internet estable (~50 Mbps recomendados), Linux o Windows, y Docker para trabajos de contenedor.

Sí. Los workers solo de CPU envían heartbeats sin problemas y pueden atender con eficiencia trabajos de embeddings y trabajos de LLM pequeños o con prompts cortos. Las cargas de embeddings, en particular, se ejecutan con una latencia aceptable sin ninguna GPU.

Unos 5 minutos desde el registro hasta el primer heartbeat. Cree una cuenta, genere un token de worker en la consola, instale el worker e inícielo. Los trabajos empiezan a llegar automáticamente.

Guía de instalación: gitlab.com/microdc/worker

Usted elige, en cada solicitud de pago:

• Créditos (con bonificación) — al instante. Con un porcentaje adicional. Ideal si usted también envía trabajos.
• Efectivo por PayPal — dólares reales a su cuenta de PayPal. Se registra como una transacción PAYOUT.

Vaya a la página Ganancias de su panel (en Workers).

Por cada trabajo completado se cobra al cliente y usted recibe una participación del pago (la plataforma retiene un margen). Su pago por trabajo queda registrado en el libro JobAssignment: su fuente de verdad. Las ganancias se agregan en ventanas de histórico, 90 días y 30 días.

Solo los trabajos completados con éxito generan un pago. Si un trabajo falla o agota el tiempo de espera, no se cobra al cliente y usted no recibe pago por él.

Un entero (1–4) que su worker anuncia mediante el heartbeat. El planificador solo le envía entonces trabajos de ese nivel o inferior. Configúrelo si su hardware tiene dificultades con prompts largos. No lo configure si tiene margen de sobra: así verá todos los trabajos.

Definir un nivel no reduce su techo de ganancias: le permite ganar de forma constante con trabajos que realmente puede completar, en lugar de agotar el tiempo de espera con prompts demasiado grandes.

Sí. Defina max_concurrent_jobs > 1 en la configuración de su worker. El servidor solo le marcará como BUSY cuando esté a plena capacidad. El valor predeterminado es 1.

• Modelo no coincidente — los trabajos se enrutan a los workers que anuncian el modelo solicitado
• Nivel de contexto demasiado bajo — revise la carga útil de su heartbeat
• Heartbeat obsoleto — el servidor le considera desconectado tras varios heartbeats perdidos
• Ya en estado BUSY — a plena capacidad de max_concurrent_jobs

Sí. Use los grupos de workers. Grupos con nombre ("Home-Lab", "Colo-Rack-A", "Customer-X") con estadísticas agregadas por grupo, incluidas las ganancias a 30 días, 90 días e históricas, obtenidas del libro contable real.

Los workers permanecen. La pertenencia a un grupo es solo una etiqueta: eliminar el grupo pone la FK a NULL en sus miembros. Nada más cambia.

Anuncie capabilities: ["docker"] en su heartbeat. Empezará a recibir trabajos de contenedor de los clientes. Cada trabajo de contenedor incluye un endpoint de heartbeat por trabajo para transmitir registros y reiniciar los tiempos de espera. Precio medido: tarifa por hora de GPU o por núcleo-hora de CPU × tiempo de ejecución, más una tarifa de plataforma de $2.00.

El worker ejecuta los trabajos en Docker con el aislamiento de contenedores estándar. Para máxima seguridad, ejecútelo en una máquina o VM dedicada. Si no quiere aceptar código arbitrario, simplemente no anuncie docker: solo recibirá trabajos de LLM, embeddings o documentos.

Dos requisitos, ambos obligatorios: un administrador de la plataforma habilita la capacidad encryption para su worker (actualmente concedida solo a workers administrados por MicroDC), y su worker informa "encryption" en la lista capabilities de su heartbeat para confirmar que puede gestionar trabajos cifrados en tiempo de ejecución. Hasta que el worker lo confirme, su tarjeta muestra una insignia amarilla "E2E?"; una vez confirmado, pasa a una insignia azul "E2E". Los workers que no cumplan ambos requisitos no verán trabajos cifrados en /jobs/available y serán rechazados si intentan reclamarlos.

Al reclamar el trabajo, recibe la clave simétrica AES-256-GCM + IV junto con el texto cifrado. Descifre en memoria, ejecute la inferencia localmente (la carga útil descifrada tiene la misma estructura que una en texto plano) y luego cifre el resultado con una clave AES nueva de un solo uso envuelta con la clave pública RSA del cliente (RSA-OAEP/SHA-256), y envíelo como encrypted_output + result_iv en lugar de output. Nunca registre ni persista material de claves, cargas útiles descifradas ni resultados en texto plano; registre únicamente tamaños y metadatos. Las claves se eliminan cuando el cliente confirma la recepción.

El monitor de trabajos zombi detecta los trabajos estancados mediante un seguimiento basado en actividad (sin progreso durante 10 minutos). Los trabajos estancados se vuelven a encolar en otro worker y su worker queda liberado. No se le paga por el intento estancado. Los estancamientos repetidos (agotamiento de reintentos) dan lugar a un trabajo FAILED, lo que evita bucles de reintento infinitos.

Hoy: simplemente inicie y detenga el proceso del worker. Mientras se ejecuta, envía heartbeats y recibe trabajos; cuando está detenido, figura como desconectado. Muchos proveedores ejecutan los workers por la noche o en horas libres mediante cron, temporizadores de systemd o el Programador de tareas.

El token de registro del worker se desactiva. Cualquier inicio de sesión o heartbeat posterior recibe un 403 explícito. Las ganancias históricas permanecen en su libro contable: los registros no se eliminan.