Projects Contribute Support About GitHub →
Open collective · Java ecosystem

Machine Learning Cabinet

A small group of engineers working to make large language models a natural part of the Java world — not a foreign dependency bolted on from the outside.

See our work GitHub →
0Python processes
355+Unit tests
9Isolated modules
64GBVRAM from 16× 4 GB GPUs
Projects
What we're building

Each project is independent — a focused tool that stands on its own.

Active

Juno

Distributed LLM inference engine, fully on the JVM. Reads GGUF models directly, runs the transformer forward pass in pure Java, shards across commodity GPU nodes via gRPC. No Python, no JNI wrappers, no subprocess.

Documentation → GitHub

At a glance

  • 16 × 4 GB GPUs = 64 GB VRAM — no single expensive card needed
  • LLaMA · Mistral · Gemma · Zephyr chat templates built in
  • Q4 / Q6_K / Q8 quant; F16 / INT8 activation wire formats
  • Session KV cache — turn latency stays flat with history length
  • 355+ unit tests; timing-regression anchors; GPU opt-in via -Pgpu
Contribute
How to get involved

Code

Pick an open issue, send a PR. All modules have their own test suite — contributions keep them green. Java 25+, Maven 3.9. github.com/ml-cab/juno

Benchmarks

GPU numbers on real hardware are the most useful thing right now. If you have CUDA access, run the integration suite and report results in an issue.

Feedback

Tried Juno on your cluster? Found a rough edge? Open an issue or start a discussion. Specific reports are more useful than general opinions.

Documentation

The architecture doc is thorough but dense. Better guides, worked examples, and diagrams for specific use-cases are genuinely welcome.

Support

Keep the work going

This is volunteer work. Infrastructure, GPU time for testing, and time itself cost something. If Juno is useful to your organization, consider supporting its development.

About
Who we are

ML Cabinet is an informal group of engineers with a shared premise: the Java ecosystem deserves production-quality ML tooling, not wrappers around Python libraries.

We're not a company. There's no roadmap committee or product manager. Projects start because someone has a real problem and grow because others find them useful.

The name is the idea of a cabinet of tools — each made carefully for one purpose, all interoperable.

  • No framework religion. No Spring Boot. Javalin when REST is needed. gRPC when the wire matters. Plain Java otherwise.
  • Tests before features. A module without a test suite is a module that can't be trusted.
  • Commodity hardware. If it requires expensive specialized gear, it's not really open.
  • Honest documentation. Known gaps, open issues, real benchmarks — not marketing copy.