Project ideas from Hacker News discussions.

Benchmarking Pocket-Scale Inference

📝 Discussion Summary (Click to expand)

Theme 1 – Hardware limits on mobile LLMs
- “Apple historically is extremely stingy when it comes to RAM and they never bothered giving iPads and iPhones more ram until fairly recently… Your covid era 10th Gen iPads only have 4GB of RAM for the base models.” – HawtAds
- “The Android ecosystem is much more liberal when it comes to RAM… but the main issue with Android is that their mid/low end … are very inefficient when it comes to single core compute performance.” – HawtAds
- “At the end of the day, the current gen of ‘pocket scale’ LLMs are still far from being able to be deployed at scale on mobile.” – HawtAds

Theme 2 – Practical mobile ML relies on tiny, transfer‑learned models
- “Current gen production mobile ML still heavily rely on traditional transfer learning like Apple's Core.ML (tiny pre trained models, with perhaps the final layer inference head swapped out).” – HawtAds
- “I would say right now 100M‑300M params is about the maximum you can do if you want any reasonable level of performance on your 'average' non flagship mobile. I would keep to sub 100M for power efficiency sake.” – HawtAds
- Example: “FUTO keyboard's transformer model for their keystroke prediction/autocorrect which operates in near real‑time.” – HawtAds

Theme 3 – Benchmark gains don’t always translate to real‑world usefulness
- “Qwen 3.5 9B scores 2‑3x higher than 4o (depending on the 4o version), on the benchmarks.” – andai
- “Whether it's actually better for the kind of things people actually use it for… the benchmarks don't really tell you that.” – andai
- “In my experience even small local models are now surprisingly good at programming and using a computer (bash), i.e. completing agentic tasks, but fall apart quickly in conversation (especially knowledge and understanding).” – andai


🚀 Project Ideas

EdgeLLM Adaptive Runtime

Summary

  • A cross‑platform inference library that automatically quantizes, layers‑caches, and optionally swaps model parts to storage to run LLMs on devices with as little as 2‑4 GB RAM.
  • Core value: developers get “plug‑and‑play” LLM integration that adapts to the device’s RAM and power budget without manual model tuning.

Details

Key Value
Target Audience Mobile app developers (iOS/Android) wanting on‑device AI features
Core Feature Dynamic model adaptation: quantization, layer caching, storage swap, and power‑aware throttling
Tech Stack Swift / Kotlin wrappers, C++ core, ONNX Runtime + custom quantization passes, optional CoreML/NPU delegates
Difficulty Medium
Monetization Hobby
#### Notes
- HN users complained about “Covid era 10th Gen iPads only have 4GB of RAM” and that “current gen production mobile ML still heavily rely on traditional transfer learning”; this runtime directly addresses that RAM bottleneck.
- Enables discussion around practical on‑device LLM limits and encourages sharing of quantization profiles, fostering a community‑driven model zoo.

MobileLLM Bench

Summary

  • An open‑source benchmark suite that runs a standardized set of prompts on any mobile device, measuring latency, RAM usage, power draw, and NPU/GPU utilization, then publishes comparable scores.
  • Core value: gives developers and researchers realistic, hardware‑specific performance data instead of flagship‑centric benchmarks.

Details

Key Value
Target Audience Mobile ML researchers, app developers, device reviewers
Core Feature Automated benchmark harness with device profiling, power measurement (via battery APIs), and optional NPU instrumentation
- Tech Stack Python (test harness), Java/Kotlin for Android agent, Swift for iOS agent, Flask/FASTAPI for result aggregation, optional Web frontend
Difficulty Low
Monetization Hobby
#### Notes
- Commenters noted the existing benchmark is “biased towards flagships” and wanted something useful for “average” non‑flagship devices; MobileLLM Bench fills that gap.
- Provides concrete data for discussions like “Is 100M‑300M params realistic on average phones?” and can drive community‑driven model selection guides.

SplitInference Proxy

Summary

  • A privacy‑preserving service that splits a transformer model between the device and an edge server, executing early layers on‑device and offloading the remaining computation, minimizing data transfer.
  • Core value: enables running models larger than the device’s RAM (e.g., 1‑3B parameters) while keeping user data local and reducing power consumption.

Details

Key Value
Target Audience Developers of privacy‑focused mobile apps (e.g., keyboards, assistants) who need larger models than the device can hold
Core Feature Automatic model partitioning, encrypted intermediate tensor transmission, adaptive offloading based on real‑time RAM/CPU metrics
Tech Stack Go/ Rust edge server, gRPC, Protobuf, optional WebAssembly fallback, iOS/Android client libraries using CoreML/GPU for early layers
Difficulty High
Monetization Revenue-ready: usage‑based pricing per GB of offloaded compute (e.g., $0.001 per GFLOP)
#### Notes
- HN users highlighted the “NPU … don’t have much memory bandwidth” and desire for “distributed/democratized/private compute”; SplitInference Proxy offers a practical middle ground.
- Sparks discussion about trade‑offs between latency, privacy, and model size, and could be paired with MobileLLM Bench to validate energy savings.

Read Later