BluBridge Technologies

AI/ML/GenAIServices25 weeksDuration$5,000 - $10,000Project cost

BluTrain is BluBridge's own deep learning training framework, built in-house from first principles in standard C++ and CUDA. It is internal R&D, not client work, and the full results are published on arXiv (2606.24780). The challenge Frameworks like PyTorch trade hardware control for flexibility. Python dispatch, generic memory allocators and black-box kernel libraries limit how efficiently models train on a fixed GPU budget. What we built Every layer is native, with no dependencies beyond C++ and CUDA:    - Hand-written CUDA kernels for attention, GELU, LayerNorm, loss and AdamW    - BluBLAS, a GEMM library hand-tuned for NVIDIA Ampere and Ada GPUs    - A tensor engine with reverse-mode autograd    - A self-tuning caching allocator that reduces memory fragmentation    - DTMS, for data, tensor and context parallelism with fault recovery    - An MLIR-based compiler for JIT operator fusion Results On a 124M GPT-2 model trained in FP32 on 8x NVIDIA RTX 6000 Ada:    - 406,595 tokens/s, vs 394,663 for PyTorch eager and 402,453 for      PyTorch compile    - 22% less GPU memory: 21.48 GiB vs 27.54 GiB per GPU    - Same convergence: final validation loss 3.0675 vs 3.0695 for PyTorch On a single 48 GB GPU:    - Trains a 2.42B-parameter model at 13.6K tokens/s, where PyTorch runs out of memory in both eager and compile mode    - At 16,384-token context: 40.4 vs 47.8 GiB peak memory, 17,784 vs 14,849 tokens/s At scale:    - Tensor parallelism 19.7% faster than Megatron-LM    - Context parallelism with 30.1% more throughput than PyTorch The CUDA kernels behind these results are open source: github.com/BlubridgeAI/HyperKernels

AI/ML/GenAIServices36 weeksDuration$5,000 - $10,000Project cost

Nova is BluBridges own end-to-end deep learning compiler, built on MLIR as the compilation backend for our BluTrain framework. It is internal R&D, not client work, and the full results are published on arXiv (2608.00029). The challenge Frameworks rely on pre-compiled kernel libraries such as cuBLAS, cuDNN and FlashAttention. Each library call is a black box, so intermediate data is written to GPU memory between steps, operations cant be fused across calls, and kernels must be rebuilt for each new GPU generation. Existing compilers often fall back to these libraries or depend on autotuning searches that take hours. What we built    - A custom MLIR dialect that holds the forward and backward passes in one graph, so the whole training step is optimized together    - Progressive lowering from model operations down to PTX GPU code    - Whole-step operator fusion that keeps intermediate results in registers    - Causal attention generated by the compiler, with the score matrix never written to memory    - An Analytic Configurator that picks tile sizes and tensor-core schedules from the GPUs specifications in milliseconds, with no autotuning    - A JIT runtime that compiles once and reuses the result on every step Results  On a 124M GPT-2 model trained on 8x NVIDIA RTX 6000 Ada:    - 441,222 tokens/s, 8.8% faster than torch.compile (405,662) and 8.5% faster than BluTrain eager (406,594)    - 22.6% less GPU memory than torch.compile: 18,659 vs 24,097 MiB per GPU    - Same convergence: final validation loss 3.0679 vs 3.0694 for torch.compile At the kernel level:    - Attention, forward and backward: 1.84 ms vs 3.94 ms for a hand-written Triton FlashAttention kernel (2.1x) and 4.68 ms for PyTorch (2.5x)    - Matrix multiplication: up to 80.1 TFLOPS on GPT-2 MLP projections, vs 67.1 for cuBLAS and 67.8 for Triton    - Fused loss head: 1.26x faster on RTX 6000 Ada and 1.55x on RTX 3060, with peak memory of 1.63 GB vs 3.07 GB

AI/ML/GenAIServices16 weeksDuration$5,000 - $10,000Project cost

FLUX is BluBridges own pretraining data pipeline, built in-house in Rust to turn raw Common Crawl web data into high-quality training data for language models. It is internal R&D, not client work, and the full results are published on arXiv (2603.13972). The challenge LLM data pipelines usually force a trade-off: filter aggressively for quality and lose most of the data, or keep the volume and accept the noise. Document-level filters reject a whole page over a few bad lines. What we built    - Apex, our own HTML parser: it matched Resiliparse on token yield and ran faster (4.31 vs 6.63 hours on 10K WARC files)    - Line-level cleaning that removes noisy lines but keeps the useful rest of the page    - Bloom-filter fuzzy deduplication, global across two Common Crawl dumps    - Dual-bin FastText classification that keeps a document if either the DCLM classifier or a BETR classifier rates it highly Results  A 3B-parameter model trained on 60B tokens, evaluated on nine benchmarks:    - Aggregate score 51.92, vs 50.48 for DCLM and 48.83 for FineWeb    - MMLU 32.14%, vs 31.98% for DCLM and 29.88% for FineWeb    - Better than DCLM on 7 of 9 benchmarks, with the largest gains on ARC-Challenge and WinoGrande (+2.9pp each)    - Reaches DCLMs aggregate score with about 34.4% less training compute More data, not less:    - 50B usable tokens from one Common Crawl dump, vs 40B for DCLM (+25%)    - 365B vs 302B tokens across two dumps after deduplication (+21%) Efficiency:    - 47.3 CPU-hours per TB, vs 296.4 for DCLM (6.26x less)    - 1.03 TB processed in 1 hr 31 min