.png&w=256&q=75)
🤝 Top Collaborators
.png&w=640&q=75)
🤓 Latest Submissions
NeuralGrid
Problem: Most developers default to the largest AMD instance available to avoid job failures, wasting 3–10x the compute they actually need a small LLM inference job doesn't need a full 192GB MI300X node, but almost everyone requests one anyway because sizing GPUs correctly requires expertise most teams don't have time for. Solution: A Compute Estimator predicts VRAM requirements per job (model size, quantization, input length) before dispatch, with confidence-scored fallback logic. A scheduler then packs the job onto the smallest available AMD Instinct partition MI210 for light jobs, partitioned or full MI300X for heavier ones so cost tracks actual need instead of habit. AMD technology used: AMD Instinct MI300X (192GB HBM3) and MI210 accelerators via AMD Developer Cloud, including MI300X partitioning to serve lighter workloads without over-allocating a full node. Tech stack: Next.js/React dashboard, API service (job submission, estimator, scheduler), Postgres for job/billing state, Stripe for usage billing, AMD Developer Cloud API for provisioning. What makes it different: Existing GPU platforms make you pick the hardware yourself. NeuralGrid is the estimator + scheduler layer that removes that decision entirely and unlike marketplace aggregators, it does this natively within one cloud's fleet (AMD's), so there's no cross-vendor arbitrage, just genuinely better fleet utilization. Challenges we tackled: Building a VRAM estimator accurate enough across model families and quantization levels to trust automatically; designing fallback logic (tier-bump on low confidence) so under-sizing never silently fails a job; keeping billing accurate to the cent when instance size is chosen dynamically per job.
13 Jul 2026
