Frequently asked questions.

AI inference is the process of using a trained AI model to generate outputs from new inputs — running the AI to get answers, summaries, or predictions.

Examples: asking ChatGPT a question, summarizing a 50-page document, classifying support tickets, generating product descriptions, extracting info from contracts.

Inference requires powerful GPU hardware. At scale, costs add up quickly — which is exactly the problem MicroDC.ai solves. If your business processes text or data using AI at scale, you're paying for inference. We help you pay up to 90% less.

MicroDC.ai is a distributed AI inference platform — a two-sided marketplace connecting businesses that need AI compute with individuals and organizations that have idle GPU resources.

Problem: AI inference costs are skyrocketing. Major cloud providers charge premium prices and building internal infrastructure requires significant CapEx.

Solution: We aggregate distributed GPU resources globally, providing enterprise-grade inference at up to 90% lower cost than traditional cloud, with no infrastructure management.

MicroDC.ai was founded by Ray Sisson (CEO) and Jeffrey Rivero (CTO), with Neil Quarterman serving as CFO.

• Ray Sisson — MBA from Chicago Booth, JD from Georgetown. Transportation, infrastructure, and corporate board leadership.
• Jeffrey Rivero — 25+ years in cybersecurity and AI/ML, CISSP. Built platforms handling 1M+ events/sec, AI for the US military.
• Neil Quarterman — Yale and Georgia Tech MBA. Managed financials through 140% growth and M&A across 11 entities in 8 countries.

Organizations typically see 50–90% cost reduction compared to traditional cloud GPU instances:

• Asynchronous model eliminates idle compute charges
• Zero cost for DevOps, maintenance, or scaling
• Pay-per-use — only for tokens processed
• Scale from $10 to $10,000/month seamlessly

Example: A document-processing company processing 100,000 documents/month saved 78% by switching from dedicated GPU instances to MicroDC.ai's batch processing.

Ideal: document summarization, content generation at scale, data enrichment, research/batch analytics, overnight processing, report generation.

Consider alternatives for: sub-second real-time chatbots, interactive user-facing AI, streaming responses, mission-critical real-time systems.

Simple credit-based system. 1 credit = $0.01 USD. Welcome bonus credits for new accounts. No setup or monthly fees. Per-job pricing based on model complexity and tokens processed.

Tiers: Economy (lower cost, flexible timing) · Standard (balanced) · Premium (priority).

Security is foundational. Our CTO is CISSP-certified with 25+ years in cybersecurity:

• End-to-end encryption (TLS 1.3 in transit, encrypted at rest)
• Worker isolation — workers can't see customer identities or other jobs
• Data minimization — only job payloads sent to workers
• Automatic deletion of job data within configurable retention
• Complete audit trails of all transactions and access
• JWT auth with short-lived tokens

For sensitive workloads, opt into end-to-end encrypted jobs — payloads are encrypted before they leave your machine, and results are zero-knowledge: encrypted to your public key, so no one but you (not even MicroDC) can read them. Full architecture writeup →

Current: security-first architecture from CISSP-certified leadership, regular audits and pen tests, secure development lifecycle.

Planned: SOC 2 Type II, ISO 27001, GDPR documentation. Contact us for current compliance status.

For sensitive workloads we recommend: anonymize/pseudonymize before processing, remove PII when possible, use retention settings to minimize exposure, consider end-to-end encrypted jobs (zero-knowledge results), evaluate dedicated worker pools.

For HIPAA, PCI-DSS, or regulated workloads, contact sales to discuss dedicated infrastructure options.

Yes — customized enterprise packages: volume discounts, priority processing, SLA guarantees, dedicated support, custom integration, NET-30 invoice billing for qualified customers. Email sales@microdc.ai.

Platform availability: 99.9% API uptime target.

Job processing SLA by tier:

• Economy — best-effort, typically < 4 hours
• Standard — 95% completed within 1 hour
• Premium — 99% completed within 15 minutes

Enterprise customers receive customized SLAs with credits for missed targets.

Connect resources on your schedule. Workers receive a generous revenue share. Real-time earnings dashboard. Multiple payout options (credits with bonus, PayPal cash). See the Providers page.

Available today: batch and streaming inference, embeddings, document jobs, container/Docker workloads on GPU or CPU, custom model hosting, an OpenAI-compatible endpoint, teams with shared credit pools and spend caps, and end-to-end encrypted payloads.

In progress: deeper usage analytics, result callbacks, and SOC 2 readiness.

The changelog is the authoritative record of what has actually shipped.

Yes — we provide an OpenAI-compatible Chat Completions endpoint. Point your existing openai client at https://api.microdc.ai/v1 and keep your code. Multimodal content lists supported. Works with LangChain, LlamaIndex, Instructor, and any OpenAI-shaped library.

By default, jobs are submitted in plaintext so the server can assist with routing and pricing. For sensitive workloads, use end-to-end encrypted jobs: your client encrypts the payload with AES-256-GCM before it leaves your machine, and the server stores and routes ciphertext only — it never inspects, logs, or decrypts your content. The payload key is escrowed solely to hand to the claiming worker — always a MicroDC-managed node with the admin-approved encryption capability, never a community worker — and is deleted the moment you acknowledge the result. Results are stronger still: the worker encrypts them with a one-time key wrapped to your RSA public key, so only your private key — which never leaves your machine — can decrypt them. We walk through exactly where the guarantee is cryptographic and where it's operational in the encryption deep-dive.

Yes — use the container job type. Provide image name, optional args/env, and any script files (.py, .sh, .js, .ts, .go, .rs, .java...) as inputs. Routes only to workers advertising the docker capability. Live log streaming via per-job heartbeat.

Metered pricing — GPU-hour rate × runtime, or CPU-core-hour rate × cores × runtime, plus a $2.00 platform fee per run. Minimum charges apply. CPU-only jobs default to $0.005/core-hour when the worker's CPU model isn't tier-priced.

Every job is labeled with a context tier (1–4) at submission based on prompt length. Workers declare a max_context_tier via heartbeat — your job will only be claimed by a capable worker. Transparent to your code; you don't set the tier, the server computes it.

Tier 1 = 0–1.5K chars, tier 2 = 1.5K–6K, tier 3 = 6K–24K, tier 4 = 24K+.

Three components:

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

Server: API backend, PostgreSQL, scheduler. Workers: distributed GPU nodes running inference. Client: Python SDK and REST API.

Backend: FastAPI, PostgreSQL, JWT auth, Docker.
Frontend (console): HTMX, Alpine.js, Tailwind CSS, Jinja2.
Workers: Python runtime, vLLM / llama.cpp, CUDA/ROCm GPU support.
Infra: Docker Compose (dev), Kubernetes (prod), Nginx, Redis (planned).

1. Client submits job with model requirements
2. Scheduler finds workers with required GPU/VRAM
3. Jobs ordered by priority tier and submission time
4. Best-fit selection considers worker performance history
5. Failed jobs rescheduled to a different worker

Smart retry: a failed job won't be reassigned to the same worker.

pip install microdc-client

from microdc import Client, LLMComplete

client = Client(api_key="mDC_your_api_key")

job = LLMComplete(model="llama3.3:70b")
job.set_prompt("Explain quantum computing in simple terms")

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

Use LLMChat instead of LLMComplete for multi-turn messages. Full SDK docs: gitlab.com/microdc/python-client

Authorization: Bearer mDC_your_api_key on every call.

• LLMComplete — single-turn generation with system prompt, temperature, top_p
• LLMChat — multi-turn conversational messages
• LLMEmbed — text embeddings for search and RAG
• DocumentCall — document processing jobs
• ContainerJob / WorkerJob — arbitrary Docker workloads, by image or by folder

job = LLMComplete(model="llama3.3:70b")
job.set_prompt("Process this document...")

job_id = client.send_job(job)

client.wait_for_all()          # or poll get_job_details(job_id)
print(client.get_job_details(job_id).result)

Results are pulled, not pushed — there is no outbound callback today. wait_for_all() blocks until every submitted job finishes; get_job_details(job_id) is the non-blocking check.

LLM: Llama 3.3 70B, Qwen 2.5 (72B) and Qwen 3 (32B–235B), DeepSeek-R1 (32B, 70B), Gemma 3, GPT-OSS (20B, 120B), Phi-3, and Qwen2.5-VL for vision.
Embedding: Qwen3-Embedding, all-MiniLM.

The catalog moves as providers bring hardware online. Live list with current per-token rates:

Live catalog: /models.html

Yes. Custom model hosting is available — upload weights, automatic validation, deployment to compatible workers, version control, private access. Contact us for requirements and pricing.

Most jobs complete within 30 seconds to 5 minutes. Premium tier averages under 1 minute. Factors: priority tier, model size, token count, queue depth.

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

Never commit API keys to version control. Use env vars or secrets management.

• TLS 1.3 in transit
• AES-256 at rest
• Worker isolation in Docker
• Data minimization — only necessary data sent to workers
• Automatic purging after configurable retention
• Job content not logged server-side

Default limits (raisable for enterprise):

Rate-limit headers: X-RateLimit-Remaining

AMD GPUs (ROCm) supported. CPU-only workers can handle smaller models.

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.3:70b,qwen3:32b

The worker will auto-register, download required models, and start polling for jobs. Setup guide: gitlab.com/microdc/worker

Per-job ledger entry on the JobAssignment record — your source of truth, not a drift-prone counter. Aggregated to your Earnings page in three windows: lifetime, 90-day, 30-day. Factors: model complexity, job volume, performance/reliability score, geographic latency preferences.

Less than you'd think. We support a wide range via context-tier routing — workers declare capacity and only receive jobs they can handle.

• Tier 1 (short prompts) — ARM SBCs, Orange Pi Max 16GB, old laptops, CPU-only
• Tier 2 — Entry-level GPUs (GTX 1660, RTX 3060 8GB) or high-RAM CPU rigs
• Tier 3 — Mid-range GPUs with 16GB+ VRAM (RTX 4070, A4000)
• Tier 4 — High-end GPUs with 24GB+ VRAM (RTX 4090, A100, H100)

Stable internet (~50 Mbps recommended), Linux or Windows, Docker for container jobs.

Yes. CPU-only workers heartbeat cleanly and can serve embedding jobs and small-LLM / short-prompt jobs efficiently. Embedding workloads in particular run at acceptable latency without a GPU at all.

About 5 minutes from sign-up to first heartbeat. Create an account, generate a worker token in the console, install the worker, start it. Jobs start flowing automatically.

Setup guide: gitlab.com/microdc/worker

Your choice, per payout request:

• Credits (with bonus) — instant. A bonus percentage on top. Great if you also submit jobs.
• PayPal cash — real USD to your PayPal account. Recorded as a PAYOUT transaction.

Head to the Earnings page in your dashboard (under Workers).

For each completed job the customer is charged and you receive a payout share (the platform retains a margin). Your per-job payout is recorded in the JobAssignment ledger — your source of truth. Earnings aggregated in lifetime, 90-day, and 30-day windows.

Only successfully completed jobs earn a payout. If a job fails or times out, the customer isn't charged and you aren't paid for it.

An integer (1–4) your worker advertises via heartbeat. The scheduler then only sends you jobs at or below that tier. Set it if your hardware struggles with long prompts. Don't set it if you have plenty of headroom — you'll see all jobs.

Setting a tier doesn't reduce your earning ceiling — it lets you earn consistently on jobs you can actually complete instead of timing out on oversized prompts.

Yes. Set max_concurrent_jobs > 1 in your worker config. The server will only mark you BUSY when at full capacity. Defaults to 1.

• Model mismatch — jobs route to workers advertising the requested model
• Context tier set too low — check your heartbeat payload
• Heartbeat stale — server considers you offline after missing heartbeats
• Already BUSY — at full max_concurrent_jobs capacity

Yes — use Worker Groups. Named groups ("Home-Lab", "Colo-Rack-A", "Customer-X") with aggregate stats per group including 30-day, 90-day, and all-time earnings sourced from the real ledger.

Workers stay. Group membership is just a label — deleting the group sets the FK to NULL on members. Nothing else changes.

Advertise capabilities: ["docker"] in your heartbeat. You'll start receiving customer container jobs. Each container job includes a per-job heartbeat endpoint to stream logs and reset timeouts. Metered pricing — GPU-hour or CPU-core-hour rate × runtime, plus $2.00 platform fee.

The worker runs jobs in Docker with standard container isolation. For maximum safety, run on a dedicated machine or VM. If you don't want to accept arbitrary code, simply don't advertise docker — you'll only receive LLM / embedding / document jobs.

Two gates, both required: a platform admin enables the encryption capability for your worker (currently granted only to MicroDC-managed workers), and your worker reports "encryption" in its heartbeat capabilities list to confirm it can handle encrypted jobs at runtime. Until the worker confirms, its card shows a yellow "E2E?" badge; once confirmed it turns blue "E2E". Workers without both will not see encrypted jobs in /jobs/available and are rejected if they attempt a claim.

On claim you receive the AES-256-GCM symmetric key + IV alongside the ciphertext. Decrypt in memory, run inference locally (the decrypted payload has the same structure as a plaintext one), then encrypt the result with a fresh one-time AES key wrapped with the customer's RSA public key (RSA-OAEP/SHA-256) and submit it as encrypted_output + result_iv instead of output. Never log or persist key material, decrypted payloads, or plaintext results — log sizes and metadata only. Keys are deleted on customer acknowledgment.

The zombie monitor detects stalled jobs using activity-based tracking (no progress for 10 minutes). Stalled jobs are requeued to another worker, and your worker is freed. You don't get paid for the stalled attempt. Repeated stalls (retry exhaustion) result in a FAILED job — preventing infinite retry loops.

Today: just start and stop the worker process. When running, it heartbeats and receives jobs; when stopped, it's offline. Many providers run workers overnight or during spare hours via cron, systemd timers, or Task Scheduler.

The worker's registration token is deactivated. Any further login or heartbeat receives a clear 403. Historical earnings stay in your ledger — records aren't deleted.