A Hefes Project · Live in Development

ccGPU

Idle-GPU Aggregation Platform — submit a workload, we run it across a pool of idle cyber-cafe and lab GPUs. Guaranteed to complete, at a fraction of cloud.

Talk to Us for Beta Access

1 · What ccGPU Is

ccGPU is a compute-aggregation platform that harvests idle time on consumer GPUs — primarily in cyber cafes (网吧), campus computer labs, and managed corporate PC fleets — and resells it as reliable AI compute. Buyers submit a workload; the platform runs it across the pool until it finishes.

Think of it as the opposite of a GPU-rental marketplace. Instead of "here's a list of boxes — bid on one, hope it stays online", ccGPU sells a durable outcome: the job runs to completion. If the machine underneath disappears (a gamer sits down), the scheduler preempts, checkpoints, and resumes elsewhere. The buyer doesn't see the shuffle — only the result.

In one line: submit-and-run compute on aggregated idle GPUs — reliable, cheap, no babysitting.

2 · Why the Supply Is Different

Most decentralized-GPU projects (io.net, Akash, Render, Vast.ai) aggregate scattered supply — one-off rigs, ex-miners, random rented boxes on the WAN. That supply cannot cluster and cannot be relied on. Our supply is structurally different, and that difference is the moat:

  • Homogeneous. A cafe floor is hundreds of the same GPU (e.g., RTX 4070 12 GB). Predictable, poolable, schedulable — not a zoo of one-off rigs.
  • Co-located on a fast LAN. Dozens of GPUs on gigabit / 10 GbE inside one cafe is a real mini-cluster. Multi-GPU training becomes feasible; scattered marketplaces cannot offer this.
  • Centrally managed. Cafe management software (Senet / Pubwin / 网维大师) and diskless master images mean one action deploys N nodes. Supply scales in fleets, not one signup at a time.
  • Idle on a schedule. Cafes empty overnight and weekday-daytime; campus labs empty on nights, weekends, and holidays. Forecastable capacity, not random churn.

The product promise = reliability. Because work is pooled, checkpointed, and rescheduled, a single machine dropping is invisible to the buyer.

3 · What Runs Where

Two components. The heavy lifting lives centrally; each GPU host runs a small agent.

  • Cafe agent — a lightweight Go binary that runs on each Windows host next to a container runtime (WSL2 + Docker + NVIDIA toolkit). It dials out (NAT-friendly), reports GPU capability, detects idle time, and executes assigned jobs. Yields instantly when a human sits down.
  • Control plane — Node.js / Postgres / Redis on a shared VM. Registry, scheduler, OpenAI-compatible inference gateway, container-job runner, billing, admin console. GPU-less; runs where any web app runs.

The platform supports three workload shapes: OpenAI-compatible LLM inference, BYO-model with encrypted weights, and raw container jobs (train, batch, notebooks). All share the same scheduler and billing rails.

4 · Two-Worlds Economics

Two ledgers, kept strictly separate:

  • Demand side. Buyers top up prepaid credits via Stripe (card / Alipay / UnionPay) or, optionally later, an international on-chain compute-credit rail. Metered per GPU-second (jobs) or per token (inference).
  • Supply side. Cafe operators earn fiat (RMB) domestically, settled monthly against the local operating entity. Operators never touch crypto — a hard product boundary that keeps the China supply side clean.

The margin between the two ledgers is the platform's revenue. Auditable, defensible, and jurisdiction-appropriate on both sides.

5 · Platform Roadmap

Where we are, in one sequenced picture. Each phase compounds on the last.

  1. Phase 0 Done

    Foundation — the substrate exists

    The ground-truth platform end-to-end on real hardware (RTX 4070):

    • Go agent (Windows service), enrollment + hardware fingerprint, GPU detect, idle/user-active detection, keep-awake.
    • Control plane (Node / Fastify / Postgres / Redis): registry, heartbeat, scheduler, OpenAI-compatible inference gateway, container jobs, per-GPU-second billing.
    • Stripe top-ups (¥ card / Alipay / UnionPay), Passport auth, admin console.
    • Scheduler primitives: idle/warm-node placement, preempt → checkpoint → requeue → resume, dataset caching, per-attempt billing.
    • Container templates, persistent notebook workspaces, fleet installer (diskless-image ready).
  2. Phase 1 Active

    Reliability — the "it just runs" guarantee

    Make the single-job experience provably reliable. This is the credibility layer that beats a listing marketplace.

    • Guaranteed completion: a job is a durable contract — retried, rescheduled, resumed until done or the user's cap.
    • Honest-compute verification: random canary tasks with known outputs + redundant re-execution on a sample; slash reputation on mismatch.
    • Pool capacity + forecasting: turn "hope a box is free" into "we have N GPU-hours available tonight."
    • Reputation & health feeding scheduling.
  3. Phase 2 Next

    Parallel fan-out — first real aggregation product

    Most GPU work is embarrassingly parallel. One submission → K independent units across the pool.

    • Sweep spec: a training command + parameter space → scheduler explodes it into K trials across K nodes; streams progress, collects artifacts, returns the leaderboard / best checkpoint.
    • Shard spec: split a big dataset (batch inference / preprocessing / eval) into N shards; results concatenated.
    • Naturally location-anonymized — each unit lands on a random node; no operator sees the whole job.
  4. Phase 3 Later

    Cafe-as-cluster — the moat

    Exploit co-location. Group nodes by cafe/LAN and form ephemeral clusters with real interconnect.

    • Topology awareness: detect co-located nodes; measure intra-cafe bandwidth.
    • Multi-GPU jobs on one LAN: torchrun / DDP across 4–8 co-located GPUs; feasible on gigabit / 10 GbE.
    • Gang scheduling: all-or-nothing placement with coordinated preempt — yield the whole group if the cafe fills.
  5. Phase 4 Later

    Aggregate big models — flagship capability

    Serve or fine-tune a model no single GPU can hold by sharding layers across the LAN (Petals-style).

    • Layer / pipeline sharding of large models across co-located GPUs (intra-cafe first; cross-cafe later).
    • "Run Llama-70B-scale inference on the pool" — a capability rental marketplaces structurally cannot sell.
    • Privacy property: no single node holds the whole model.
  6. Phase 5 Later

    Trust, money, and fleet scale — a real business

    • Privacy tiers: encryption at rest → sharding → confidential-compute / TEE as the hard ceiling.
    • Fleet onboarding at scale: master-image + cafe-management-software push (Senet / Pubwin / 网维大师), verify tooling, capacity dashboards.
    • SLA products: reserved GPU-hours, throughput guarantees, priority tiers.
    • Optional international rail: on-chain settlement / compute-credit token for cross-border buyers; operator payouts remain strictly fiat / domestic.
  7. Phase 6 Research

    Cross-WAN training — the research bet

    Communication-efficient training across cafes over the WAN (Hivemind / DiLoCo / DeMo-DisTrO). Explicitly not near-term — tracked, not promised. Intra-cafe LAN clustering (Phase 3) captures most of the value without the WAN pain.

6 · Where We Are Today

  • ✅ End-to-end verified on real hardware. Full pipeline running on RTX 4070; agent, control plane, gateway, container jobs, billing all operational.
  • ✅ Three workload shapes operational. OpenAI-compatible LLM inference; BYO-model with encrypted weights; container jobs (Colab-style).
  • ✅ Scheduler primitives shipped. Preempt → checkpoint → requeue → resume; warm-node placement; per-attempt billing.
  • ✅ Real payment rails. Stripe top-ups (¥ / card / Alipay / UnionPay), Passport auth, admin console.
  • 🔜 Reliability layer (Phase 1) in active development — turns the primitives into a public "it just runs" promise.
  • 🔜 Beta partners wanted. Schools, research groups, and cafe operators — pilot pricing, hands-on onboarding.

Next Steps

We're onboarding early buyers (schools, research groups, indie AI teams) and early supply partners (cafe operators and campus computer labs). If either sounds like you, we'd love to talk.

Contact Us for Beta Access ← Back to Hefes

ccGPU is an active Hefes project. This page describes the platform's design, current capabilities, and phased roadmap. Specific timelines and commercial terms are established per engagement.