Papers
Topics
Authors
Recent
Search
2000 character limit reached

BaseRT: Best-in-Class LLM Inference on Apple Silicon via Native Metal

Published 1 Jul 2026 in cs.CL, cs.AI, and cs.PF | (2607.00501v1)

Abstract: We present BaseRT, a native Metal inference runtime for LLMs on Apple Silicon, and report the highest inference throughput on this hardware to date. Existing runtimes, including llama.cpp and MLX-based frameworks, incur overhead from abstractions not designed for Metal's execution model or Apple Silicon's unified memory topology. By building natively on Metal with chip-specific kernel fusion, unified memory-aware optimisation, and custom dispatch logic, BaseRT recovers performance that framework-based approaches leave on the table. BaseRT supports a wide range of model families across eight quantisation formats (Q2 to FP16) on all Apple M-series devices. In this paper, we evaluate the Qwen3, Llama 3.2, and Gemma 4 families at Q4 and Q8 quantisation on M3 and M4 Pro devices. BaseRT achieves up to 1.56x higher decode throughput than llama.cpp and up to 1.35x higher than MLX, with substantially larger margins on prefill for mixture-of-experts models, delivering consistent best-in-class throughput from sub-1B to 30B parameter models. These results establish Apple Silicon as a more capable inference platform than previously reported, with direct implications for the emerging edge inference paradigm: as privacy requirements, latency constraints, and cloud cost pressures drive inference toward on-device deployment, performance-optimised local runtimes are a critical enabling layer for this transition. BaseRT is publicly available at https://github.com/basecompute/baseRT

Summary

  • The paper introduces BaseRT, a C++ runtime that uses Apple’s Metal API with a data-driven architecture and zero-allocation decode loop to maximize LLM inference throughput.
  • It demonstrates optimized kernel fusion and custom scheduling techniques that yield up to 1.56× higher token-generation throughput on M4 Pro compared to conventional frameworks.
  • The work highlights the feasibility of private, high-performance edge LLM deployment on Apple Silicon, reducing reliance on cloud resources and mitigating latency and privacy risks.

BaseRT: Native Metal LLM Inference on Apple Silicon

Motivation and Edge Inference Paradigm

The acceleration of LLM deployment across industry is increasing inference demands at a rate outpacing the growth of centralized cloud resources. Capacity projections suggest that by 2030, AI inference will comprise 40% of global datacenter compute, making cloud-based scaling unsustainable for latency, privacy, and economic reasons. Concurrently, the hardware prerequisites for performant on-device LLMs are now met at scale, especially on Apple Silicon—whose unified memory architecture and high-bandwidth GPU present a uniquely favorable topology for running LLMs locally. The practical implications include eliminating cloud-jurisdiction data leakage risks, removing interactive latency inflation from network and queueing, and reducing cloud costs to the fixed amortization of local hardware.

Architectural Design of BaseRT

BaseRT introduces a C++ runtime targeting Apple's Metal GPU API natively—eschewing intermediate frameworks such as MLX, llama.cpp, or CoreML. Unlike prior approaches, BaseRT is architected around four principles that directly minimize sources of previously unaddressed overhead:

  • Data-Driven Architecture Descriptors: Model architecture variations are abstracted as data, not control-flow, enabling a static, non-branching, and high-throughput decode path agnostic to model family.
  • Zero-Allocation Decode Loop: All inference-phase buffers, including KV cache, are strictly pre-allocated at model load with layouts optimizing for GPU coalesced access. No runtime allocation or memory management occurs on the hot path.
  • Chip-Adaptive Kernel Fusion: Performance-critical operator sequences (e.g., within the attention and feed-forward paths) are fused at the kernel level, tailored per M-series GPU generation, minimizing the frequency of kernel launches and memory round-trips. All quantization formats (Q2–Q8, BF16, FP16) use specialized fused kernels with on-the-fly dequantization.
  • Custom Prefill and Decode Scheduling: Autoregressive decode leverages amortized CPU–GPU dispatch, reducing synchronization and command buffer overheads. Prefill implements GEMM using Metal simdgroup_intrinsics and tile-geometries tuned to sequence length and available scratch.

Empirical Evaluation and Numerical Results

Extensive benchmarking on Apple M3 and M4 Pro (covering both dense and mixture-of-experts models within the Llama 3.2, Qwen3, and Gemma 4 families) demonstrates state-of-the-art performance across quantization granularities:

  • Decode Throughput: On M4 Pro, BaseRT achieves up to 1.56× higher token-generation throughput compared to llama.cpp and up to 1.35× versus MLX on the same model weights and quantization. Gains are most pronounced on small, dense models—Qwen3-0.6B and Llama-3.2-1B—where BaseRT delivers 35–56% higher throughput. With ~1.04–1.07× on 30B MoE models, results confirm the kernel fusion and custom dispatch minimize fixed per-token overheads that dominate small-model latency.
  • Prefill Throughput: For mixture-of-experts models (Gemma-4-26B-A4B, Qwen3-30B-A3B), BaseRT outperforms llama.cpp by up to 1.81× at short prompts and maintains a substantial advantage across prompt lengths. On dense models, all engines reach near-theoretical GEMM throughput parity, verifying that prefill is compute-bound once framework overhead is removed.
  • Cross-Generation Consistency: On M3 base, relative speedups over MLX and llama.cpp remain consistent (1.13–1.34×), showing robustness to hardware scaling.
  • uzu Comparison: Against uzu, another native Metal runtime, BaseRT leads in token-generation throughput for 5 of 6 configurations (up to 1.19×), confirming the unique benefit of its decode scheduling and kernel fusion. On prefill, uzu is marginally superior, likely due to leveraging MPSGraph and ANE for high-concurrency GEMM, an avenue unexplored by BaseRT.

Technical and Practical Implications

BaseRT demonstrates the degree to which abstraction in mainstream Apple Silicon inference stacks leaves hardware capabilities unexploited—empirically establishing that previous throughput ceilings were not intrinsic to the platform but to software design. The implications for the edge inference paradigm are significant:

  • Feasibility of Private, High-Performance LLM Deployment: With BaseRT, locally run 30B MoE models are viable on Apple hardware at practical throughputs, reducing reliance on remote APIs and mitigating both privacy and availability risks in enterprise and edge agentic scenarios.
  • Unified Memory as a Performance Lever: The unified CPU–GPU memory and high-bandwidth Metal command buffer model enable optimizations (e.g., direct dequantization fusion, kernel sequence amalgamation) that are inaccessible to cross-platform or array-based runtimes. Exposing and exploiting these features is critical for future hardware-aware AI software stacks.

Limitations and Future Developments

Current limitations include lack of support for multi-device inference (no tensor parallelism, no continuous batching, no speculative decoding), and exclusive dependence on Metal, limiting deployments to Apple environments. Future work includes extending architectural coverage to multimodal and SSMs, adding CUDA and Vulkan backends for cross-platform deployment, and implementing advanced serving optimizations for latency-sensitive and multi-request workloads.

Conclusion

BaseRT sets a new benchmark for LLM inference on Apple Silicon by extracting maximal throughput via native Metal programming, kernel fusion, and architecture-neutral hot-path design. Its results reposition Apple Silicon as a top-tier edge inference target, and its architectural paradigm points toward the necessity of hardware-native, framework-free runtimes to realize the promised gains of local AI deployment. The public release of BaseRT invites further adoption and comparative evaluation against leading inference engines.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

What is this paper about?

This paper introduces BaseRT, a new, super-fast “engine” for running LLMs on Apple computers with Apple Silicon chips (like M1–M5). It’s built directly on Apple’s graphics system called Metal. The main idea: by talking to the hardware in its “native language,” BaseRT can make LLMs run faster on Macs and iPads, which is great for on-device AI that’s private, quick, and works without the internet.

What were the goals?

In simple terms, the researchers wanted to:

  • Make LLMs run faster on Apple devices than existing tools do.
  • Show that Apple Silicon is more powerful for local AI than people thought.
  • Prove that building directly on Metal (instead of using general frameworks) unlocks extra speed.

How did they do it? (Methods explained simply)

Think of running an LLM like baking lots of cookies very quickly:

  • The “ingredients” (model weights) live in memory.
  • The “ovens” are the GPU cores that do the math.
  • The “kitchen rules” are the software that tells the ovens what to do.

BaseRT speeds things up by redesigning the kitchen:

  • Native Metal “recipes”: Instead of following a general cookbook that works in many kitchens, BaseRT writes custom recipes for Apple’s kitchen (Metal). This removes extra steps that slow things down.
  • Unified memory awareness: Apple Silicon lets the CPU and GPU share one big pantry (unified memory). BaseRT lays out ingredients so the ovens can grab them efficiently, reducing back-and-forth trips.
  • Kernel fusion (combining steps): Imagine mixing and baking in one step instead of two. BaseRT fuses small GPU jobs into bigger ones, cutting down on “start/stop” overhead.
  • Zero-allocation decode loop: All bowls and trays are prepared ahead of time. During serving (token-by-token generation), BaseRT doesn’t pause to get more tools—it just keeps going, which saves time.
  • Smart scheduling: BaseRT bundles commands and syncs less often between the CPU and GPU, like coordinating batches so ovens stay busy with fewer interruptions.
  • Prefill vs. decode:
    • Prefill = reading the prompt (processing the input tokens). It’s like prepping dough in big batches; this is very math-heavy and benefits from highly tuned matrix-multiply kernels.
    • Decode = writing the answer (producing tokens one by one). It’s lots of quick steps; cutting launch overhead and keeping data close make a big difference here.

They also support different “model sizes” and “quantization” levels. Quantization is like storing numbers with fewer bits (e.g., 4-bit instead of 16-bit) to save space and move data faster—like compressing a photo so it loads quicker.

What did they test and compare?

They ran several open-source models (Qwen3, Llama 3.2, Gemma 4) in 4-bit (Q4) and 8-bit (Q8) modes on M3 and M4 Pro chips. They compared BaseRT to:

  • llama.cpp (a popular cross-platform runtime),
  • MLX (Apple’s machine learning framework),
  • uzu (another Metal-based runtime).

They measured:

  • Decode throughput: how many tokens per second during generation.
  • Prefill throughput: how fast the prompt is processed at different prompt lengths (like 128, 256, 512, 1024, 2048 tokens).

Main findings (in plain language)

  • Faster generation (decode): BaseRT is the fastest on Apple Silicon in their tests.
    • Up to about 1.56× faster than llama.cpp.
    • Up to about 1.35× faster than MLX.
    • Biggest gains appear on smaller models (where overhead matters more) and at lower precision (like Q4), because BaseRT’s low overhead shines when each step is short.
  • Fast prompt processing (prefill), especially for MoE:
    • For Mixture-of-Experts (MoE) models—think “a team of specialists” inside the model—BaseRT is much faster in prefill, with up to about 1.78× improvement over MLX at short prompts.
    • For smaller “dense” models (no specialists), BaseRT and others are closer in prefill speed, since the GPU is already maxed out by the heavy math and everyone’s using similar tricks.
  • Works across chips and sizes:
    • Consistent wins on both M4 Pro and M3.
    • Supports many model families and quantization formats (from 2-bit up to FP16).
    • Delivers strong performance from under 1B parameters up to around 30B.

Why this matters:

  • It shows Apple devices can handle local AI better than many thought.
  • Faster local AI means better privacy, lower delays, and no need to rely on the internet for every request.

Why it’s important

Running AI on your device (edge inference) has big benefits:

  • Privacy: Your data doesn’t leave your device.
  • Lower latency: No waiting for the network or a busy server.
  • Reliability: Works even without internet.
  • Cost control: Once you have the device, extra usage costs almost nothing.

BaseRT is a key building block for this future by making on-device LLMs faster and more practical.

Limits and what’s next

  • Current limits:
    • Apple-only (Metal backend); no Windows/Linux GPU backends yet.
    • Single device only; no multi-GPU or advanced batching for many users at once.
  • Future plans:
    • Add more model types (e.g., vision-language and state space models).
    • Support other platforms (CUDA for NVIDIA GPUs, Vulkan for other devices).
    • Add serving features like continuous batching and speculative decoding for even higher throughput and lower latency.

Quick recap

  • Purpose: Build the fastest LLM runtime for Apple Silicon by talking directly to Metal and the unified memory system.
  • Approach: Reduce overhead (kernel fusion, zero-allocation loops, smart dispatch), tailor kernels to Apple chips, and optimize memory use.
  • Results: Best-in-class speeds on Apple Silicon for decode, big gains for prefill on MoE models, strong support across chips, sizes, and quantization levels.
  • Impact: Makes on-device AI more private, faster, and more reliable—pushing forward the shift from cloud-only AI to powerful local AI.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The paper establishes strong throughput results for BaseRT on Apple Silicon but leaves several important questions unanswered. Future researchers could address the following concrete gaps:

  • Benchmark scope and representativeness
    • Lack of evaluation beyond M3 base and M4 Pro: no results on M1/M2, M4 Max/Ultra, or M5; unclear scaling across GPU core counts, memory bandwidth tiers, and thermal envelopes.
    • No validation on devices with constrained memory (e.g., 8–16 GB) to assess out-of-memory behavior, OS memory pressure effects, UMA paging, and swap-induced degradation.
    • No long-context benchmarks beyond 2,048 tokens; how do prefill/attention kernels scale at 8k/32k/128k contexts, including FlashAttention limits and chunking overheads?
    • Claims of running 7B–70B models are not empirically validated; largest tested models are 26B/30B MoEs at Q4. Performance and feasibility for 70B at various quantizations remain untested.
    • Results are limited to a handful of model families (Qwen3, Llama 3.2, Gemma 4); generalization to other decoder-only LLMs, encoder-decoder models, and sparse architectures is unverified.
  • Comparisons and fairness
    • Baseline configurations use “default settings”; no evidence that llama.cpp/MLX/uzu were tuned equivalently (e.g., matmul tiling, Metal backend flags, KV cache layout, threadgroup sizes) to ensure a fair, best-effort comparison.
    • No comparison with other Apple-oriented runtimes (e.g., MLC-LLM CoreML/TVM backends) or with server-class engines (e.g., vLLM-MLX in serving mode) to contextualize gains under different serving paradigms.
    • Only decode (tg128) and prefill (pp128–pp2048) are reported; time-to-first-token (TTFT) and end-to-end latency under realistic API-level request patterns (including tokenizer cost) are not benchmarked.
  • Methodological transparency and reproducibility
    • Insufficient details on the benchmarking harness: seeds, sampling configuration (greedy vs top-k/top-p), tokenization settings, input content, and warmup procedures are not specified.
    • No release of raw logs or variance across runs beyond a brief note; full reproducibility (OS version, Metal driver version, thermal state, power mode) is not documented.
    • Conversion to BaseRT’s “base weight format” may introduce numerical or memory-layout changes; absence of validation that outputs match source checkpoints (e.g., perplexity or exact logits).
  • Ablations and performance attribution
    • No ablation study isolating contributions of (a) kernel fusion, (b) unified-memory-aware layouts, and (c) custom dispatch/scheduling; unclear which components drive which gains on decode vs prefill.
    • No microbenchmarks or roofline analysis to substantiate claims of dispatch overhead removal, memory-bound vs compute-bound regimes, or bandwidth utilization.
    • Absence of per-layer/per-operator timing breakdowns (attention vs MLP vs norms vs sampling) and CPU vs GPU time splitting; the impact of “amortized CPU–GPU synchronization across tokens” is not quantified.
  • Accuracy, numerical stability, and quality trade-offs
    • Only Q4 and Q8 are evaluated; behavior for Q2/Q3/Q5/Q6/BF16/FP16 is unclear, as are the speed–quality trade-offs across formats.
    • No evaluation of numerical stability/accuracy deltas introduced by fused kernels (norms/activations) and on-the-fly dequantization; missing perplexity or task accuracy comparisons against unfused, higher-precision baselines.
    • Impact of chunked prefill on numerical accuracy and determinism (e.g., softmax/online statistics across chunks) is unreported.
  • Memory usage and KV/cache management
    • KV cache pre-allocation to max context may waste memory; no analysis of memory footprint, fragmentation, or strategies to dynamically size/evict KV for multi-turn sessions.
    • No measurements of memory traffic for different cache layouts (coalescing claims not quantified), nor sensitivity to cache size, head count, and MoE expert routing on bandwidth.
  • Mixture-of-experts specifics
    • The source of BaseRT’s prefill advantage for MoEs is not explained with measurements; no dissection of expert selection overheads, load balancing, or expert-weight streaming patterns.
    • Generality across other MoE topologies (varying expert counts/top-k routing) and stability under dynamic gating is untested.
  • Hardware utilization gaps and co-processor integration
    • BaseRT does not utilize the Apple Neural Engine (ANE); the paper hypothesizes ANE benefits for uzu in prefill but does not verify or quantify ANE’s contribution or explore GPU+ANE co-execution strategies.
    • No investigation of overlapping compute with transfers (if any), command buffer pipelining, or multi-queue dispatch to hide latency.
    • Lack of analysis on simdgroup_matrix availability/performance variations across M-series generations and its fallback behavior.
  • Concurrency, serving features, and scheduling
    • No continuous batching, parallel decoding across requests, or tensor/tiled parallelism; the impact and feasibility on Apple GPUs and UMA are open.
    • Speculative decoding is identified as future work; no assessment of how BaseRT’s dispatch mechanism and cache design would integrate with speculation/verification efficiently.
    • Latency/throughput under mixed workloads (concurrent OS/apps) and request-level QoS or admission control are not studied.
  • Energy efficiency and thermals
    • No power draw or energy-per-token measurements; claims about edge viability lack “intelligence per watt” evidence on Apple Silicon.
    • No study of thermal throttling under sustained load on laptops/desktops and its impacts on sustained throughput/jitter.
  • Portability and ecosystem integration
    • Metal-only backend limits deployment; CUDA/Vulkan backends are future work. The portability of fused kernels and dispatch strategies to other APIs/device topologies is untested.
    • Interoperability with common model formats is limited; the paper does not detail the conversion pipeline, tooling maturity, or overheads for moving from GGUF/SafeTensors to BaseRT format at scale.
  • Robustness and determinism
    • Determinism across runs/chips (given GPU reductions and fused ops) is unreported; seed control and numerical reproducibility guarantees are unclear.
    • Thread safety and multi-threaded inference behavior (even on a single request) are not described or validated.
  • Additional model classes and modalities
    • Although support for Whisper and BERT is mentioned, no benchmarks are reported; performance for encoder-only/encoder-decoder models is unknown.
    • No evaluation of vision-LLMs or (hybrid) state space models; kernels and memory strategies for non-attention architectures remain unexplored.
  • Developer and operational considerations
    • Model load times, compile/initialization overheads (e.g., pipeline state creation), and memory footprint at load are not measured.
    • Failure modes, error recovery in long-running processes, and behavior under low-memory conditions (allocation failures despite “zero-allocation” inference) are not discussed.

Practical Applications

Immediate Applications

The following applications can be deployed today using BaseRT’s publicly released runtime and reported performance on Apple Silicon. Each item notes sectors, potential tools/products/workflows, and key dependencies.

  • On-device private assistants on macOS — sectors: enterprise IT, legal, finance, healthcare, public sector
    • What: Ship macOS apps that run LLMs locally for chat, drafting, summarization, translation, contract review, or PHI/PII processing without sending data to the cloud.
    • Tools/products/workflows: Cocoa/Swift or Electron apps embedding BaseRT via its C API; offline RAG (local vector store + BaseRT); secure document analysis in air-gapped fleets; role-specific assistants for legal/finance desktops.
    • Dependencies/assumptions: Apple Silicon (M1–M5) with sufficient unified memory for chosen model and quantization; availability of model checkpoints convertible to BaseRT’s native weight format; acceptance of model accuracy at chosen precision (Q4/Q8); thermal headroom on laptops.
  • Developer productivity on laptops — sectors: software/tools, education
    • What: IDE extensions for code completion, inline explanations, and refactoring powered by small 0.6–3B models where BaseRT shows the largest decode gains.
    • Tools/products/workflows: VS Code/Xcode plugins that query a local model via BaseRT; offline unit-test generation and commit message drafting; classroom coding assistants for campus laptops.
    • Dependencies/assumptions: Smaller models meet task accuracy needs; integration via BaseRT C API; model weights quantized and converted; sufficient memory for KV cache at desired context.
  • Offline transcription and meeting notes — sectors: media, education, enterprise ops
    • What: Local speech-to-text and summarization on Macs using BaseRT’s support for Whisper and decoder LLMs.
    • Tools/products/workflows: Meeting recorder apps that transcribe and summarize locally; journalism tools for interviews; lecture capture for students.
    • Dependencies/assumptions: Whisper/LLM checkpoints supported and converted; real-time requirements depend on device class and quantization; mic/audio permissions and on-device storage constraints.
  • Field and low-connectivity operations — sectors: energy, utilities, defense, public safety, logistics
    • What: Local translation, procedures lookup, and report drafting where connectivity is intermittent or restricted.
    • Tools/products/workflows: Ruggedized Mac mini or MacBook-based kits; preloaded knowledge bases; mission logs auto-summarized in the field.
    • Dependencies/assumptions: Hardware provisioning with appropriate RAM; device hardening; offline content updates; model selection aligned with memory and latency targets.
  • Contact-center and sales “agent assist” at the edge — sectors: customer support, sales enablement
    • What: Individual reps run local assistants for knowledge lookup and response suggestion to reduce cloud latency and cost.
    • Tools/products/workflows: Desktop sidebar app querying BaseRT; CRM/RAG integration using local embeddings and context windows; hybrid mode (local first, cloud fallback).
    • Dependencies/assumptions: Single-user focus fits BaseRT’s current single-request design (no continuous batching); model sizes tuned to device RAM; compliance approval for on-device data residency.
  • Privacy-by-design analytics in regulated environments — sectors: healthcare, finance, government
    • What: Enforce data residency by keeping prompts/documents on-device, aligning with NIST AI risk guidance and cross-border restrictions.
    • Tools/products/workflows: MDM-deployed apps leveraging BaseRT; audit logs showing no network egress; policy checklists referencing on-device inference.
    • Dependencies/assumptions: Fleet is Apple Silicon; internal validation of quantized model accuracy; standardized update pipeline for weights and policies.
  • Research and teaching on systems optimization — sectors: academia (CS, systems, compilers)
    • What: Use BaseRT as a reference for unified-memory-aware design, kernel fusion, and decode/prefill scheduling in course labs or research prototypes.
    • Tools/products/workflows: Reproducible benchmarks comparing MLX/llama.cpp vs BaseRT; student assignments on Metal shader optimization; experiments with architecture descriptors.
    • Dependencies/assumptions: Familiarity with Metal and C++; access to supported checkpoints and conversion tools.
  • Edge appliances for kiosks and small offices — sectors: retail, hospitality, SMB IT
    • What: Mac mini-based inference boxes for single-session or low-concurrency chat/FAQ and form assistance without cloud reliance.
    • Tools/products/workflows: Local web UI backed by BaseRT; on-prem RAG for product catalogs; privacy-preserving guest interactions.
    • Dependencies/assumptions: Single-user or low-concurrency aligns with current lack of continuous batching; thermal and noise management; sufficient RAM for desired context length.
  • Faster prototyping for MoE prompts — sectors: model evaluation, data labeling
    • What: Exploit BaseRT’s prefill advantages on mixture-of-experts models to accelerate prompt-heavy evaluation or dataset generation.
    • Tools/products/workflows: Local eval harnesses using 26–30B MoE (Q4) for long-context tasks; prompt-tuning iterations with quicker turnarounds.
    • Dependencies/assumptions: MoE Q8 may exceed 24 GB on some devices; GPU-only path (no ANE) means some prefill-heavy cases may still favor ANE-enabled engines.

Long-Term Applications

These opportunities require additional research or engineering (e.g., new backends, batching, broader model coverage) outlined in the paper’s limitations and future work.

  • Multi-request serving on Apple edge servers — sectors: IT operations, contact centers, SaaS
    • What: Add continuous batching and speculative decoding to turn Mac mini/Studio into low-latency on-prem LLM endpoints for small teams.
    • Tools/products/workflows: Lightweight edge servers with BaseRT; autoscaling across deskside Macs; hybrid routing (local first, cloud overflow).
    • Dependencies/assumptions: Implementation of continuous batching/parallel decoding; scheduling for fairness and latency; monitoring/telemetry; thermal and power planning.
  • Cross-platform expansion (CUDA/Vulkan backends) — sectors: software, mobile, embedded
    • What: Port BaseRT’s dispatch and fused kernels to CUDA (Windows/Linux workstations) and Vulkan (Android/Linux), delivering a unified, high-performance local runtime.
    • Tools/products/workflows: Single engine powering MacBooks, Windows laptops with RTX, and Android edge devices; common weight format and conversion pipeline.
    • Dependencies/assumptions: Backend-specific kernel implementations; careful memory management on non-unified-memory platforms; validation vs TensorRT-LLM and vLLM.
  • Multimodal on-device assistants — sectors: healthcare imaging, enterprise document workflows, accessibility, education
    • What: Support vision-LLMs to enable local document OCR+QA, slide/image explanation, and accessibility captions.
    • Tools/products/workflows: Desktop apps that accept PDFs/screenshots and answer questions; lecture materials summarization with images; HIPAA-compliant image analyses.
    • Dependencies/assumptions: Extension of architecture coverage to VLMs; larger memory footprints for vision encoders; efficient image pre-processing pipelines.
  • Streaming/state-space model (SSM) workloads — sectors: real-time analytics, speech, IoT
    • What: Integrate (hybrid) SSMs for ultra-low-latency streaming tasks (dictation, sensor summarization, live copilots).
    • Tools/products/workflows: On-device live captioning and translation; continuous meeting assistants; edge telemetry summarizers.
    • Dependencies/assumptions: Kernel support for SSM primitives; scheduler improvements for persistent kernels; evaluation of accuracy/latency trade-offs.
  • Heterogeneous device utilization (GPU + ANE) — sectors: performance engineering across Apple devices
    • What: Add ANE-aware prefill paths and heterogeneous scheduling to combine GPU decode with ANE-accelerated GEMM prefill.
    • Tools/products/workflows: Mixed-pipeline inference for longer prompts; better battery life on laptops; improved throughput parity with ANE-enabled engines.
    • Dependencies/assumptions: Stable ANE APIs and kernel mapping; partitioning heuristics; correctness across mixed-precision paths.
  • Secure enterprise distribution and governance — sectors: regulated industries, public sector
    • What: Formalize deployment blueprints (MDM, notarization, audit) for on-device inference, tying to NIST AI RMF and data residency controls.
    • Tools/products/workflows: Policy packs and compliance templates; attestation that no prompt data leaves device; procurement checklists recommending on-device runtimes.
    • Dependencies/assumptions: Organizational policy alignment; standardized logging/redaction; update and key-management processes.
  • Energy-efficiency and sustainability reporting — sectors: sustainability, corporate IT
    • What: Use local inference to reduce per-query energy vs cloud; develop “intelligence per watt” dashboards for fleets.
    • Tools/products/workflows: IT dashboards estimating saved network/compute emissions; green-mode profiles that downshift quantization under battery.
    • Dependencies/assumptions: Instrumentation for energy estimates; accepted accounting methodologies; trade-offs with latency/quality.
  • Robust on-device agentic workflows — sectors: knowledge work automation, operations
    • What: Combine BaseRT with local tools (Shortcuts/AppleScript, filesystem, calendars) for agents that run offline with deterministic latency.
    • Tools/products/workflows: Triage and draft email replies; schedule coordination; file organization and report generation without network access.
    • Dependencies/assumptions: Tool-use safety guardrails; memory/context management for longer tasks; preference for local RAG stores.
  • Edge robotics and human–robot interaction — sectors: robotics, manufacturing, assistive tech
    • What: Use low-latency decode on Apple edge controllers for natural-language commands and status explanations.
    • Tools/products/workflows: ROS nodes bridging to BaseRT on Mac-based control stations; voice-to-action pipelines.
    • Dependencies/assumptions: Integration with perception/control stacks; real-time constraints; device mounting/environmental specs.
  • Ecosystem and tooling around weights and deployment — sectors: open-source, developer platforms
    • What: Model zoo, quantization/conversion CLI, and packaging SDKs for macOS apps; standardized BaseRT weight distribution.
    • Tools/products/workflows: One-command GGUF/SafeTensors → BaseRT conversion; app templates; CI pipelines for model updates.
    • Dependencies/assumptions: License compliance for distributing weights; reproducible quantization quality; versioned descriptors for architecture variants.

Notes on feasibility

  • Immediate feasibility hinges on: Apple Silicon hardware availability; model memory fit (24–128 GB tiers); acceptable accuracy at lower precisions (Q4/Q8); access to or creation of BaseRT-converted weights; willingness to operate without multi-request batching for server-like loads.
  • Long-term items depend on: implementing serving features (continuous batching/speculative decoding), adding backends (CUDA/Vulkan) and model families (VLMs/SSMs), and optionally exploiting the ANE for prefill.

Glossary

  • Air-gapped: A security setup where systems are physically isolated from unsecured networks to prevent data leakage. "enabling compliance with air-gapped and zero-trust requirements."
  • Apple Neural Engine (ANE): Apple’s on-chip neural processing unit designed to accelerate machine learning workloads. "to access both the GPU and Apple Neural Engine"
  • Architecture descriptor: A compact, data-driven specification capturing model-architecture variations used to drive a uniform inference engine. "expressed through a compact architecture descriptor"
  • Autoregressive decode: Token-by-token generation where each new token is conditioned on previously generated tokens. "measuring autoregressive decode over 128 generated tokens."
  • Coalesced GPU memory access: An access pattern where adjacent threads read contiguous memory locations, improving bandwidth utilization. "maximise coalesced GPU memory access during attention."
  • Continuous batching: A serving method that dynamically merges multiple requests into shared batches over time to improve throughput. "does not implement continuous batching"
  • Dequantisation: Converting low-precision (quantized) weights back to higher-precision values during computation. "Each kernel integrates dequantisation directly into the inner loop"
  • FlashAttention: An efficient attention algorithm that reduces memory overhead by computing attention in tiles. "A FlashAttention kernel computes attention in tiles using online softmax with running statistics"
  • GEMM (General Matrix–Matrix Multiply): A core linear-algebra operation multiplying two matrices, heavily used in neural network inference. "Prompt processing (prefill) uses GEMM rather than GEMV"
  • GEMV (General Matrix–Vector Multiply): A linear-algebra operation multiplying a matrix by a vector, common in token-by-token decode. "dedicated GEMV (decode, M=1M{=}1) and GEMM (prefill, M>1M{>}1)"
  • GGUF: A binary model-weight format used by llama.cpp for efficient loading and inference. "using GGUF-format weights"
  • Kernel fusion: Combining multiple computational operations into a single GPU kernel to reduce launch overhead and memory traffic. "chip-specific kernel fusion"
  • KV cache: Stored key and value tensors from previous tokens that enable efficient attention over long contexts. "The KV cache is likewise pre-allocated to the maximum context length"
  • Lazy evaluation: Deferring computation until results are needed, which can introduce scheduling overhead in some frameworks. "lazy evaluation and framework-level scheduling introduce overhead"
  • Metal GPU API: Apple’s low-level graphics and compute API used for writing high-performance GPU code. "built directly on Apple's Metal GPU API"
  • Mixture-of-experts (MoE): A model architecture that routes tokens through a subset of expert sub-networks to improve efficiency and capacity. "mixture-of-experts models"
  • MPSGraph: Apple’s graph-based machine learning runtime for building and executing optimized compute graphs. "MPSGraph to access both the GPU and Apple Neural Engine"
  • Prefill: The prompt-processing phase that computes activations for the input sequence before token-by-token decoding. "Prompt processing (prefill) uses GEMM rather than GEMV"
  • Quantisation: Reducing numerical precision of model parameters (e.g., to 4- or 8-bit) to save memory and improve speed. "eight quantisation formats (Q2, Q3, Q4, Q5, Q6, Q8, BF16, and FP16)"
  • RoPE (Rotary Positional Embedding): A positional encoding method that injects position information via complex rotations, commonly used in transformers. "normalization, RoPE, embedding"
  • SafeTensors: A zero-copy, memory-safe tensor serialization format for model weights. "using MLX SafeTensors-format weights"
  • simdgroup_matrix intrinsics: Metal’s low-level operations enabling efficient matrix computations within a SIMD group on the GPU. "Metal's simdgroup_matrix intrinsics"
  • Speculative decoding: A technique that proposes multiple future tokens ahead of verification to reduce latency. "continuous batching and speculative decoding are natural extensions"
  • Time-to-first-token (TTFT): The latency from request submission to emission of the first generated token. "time-to-first-token (TTFT)"
  • Unified memory architecture: A hardware design where CPU and GPU share a single high-bandwidth memory pool. "Apple's unified memory architecture removed the traditional segregation between CPU and GPU memory pools"
  • Zero-allocation decode loop: A decode process structured to avoid any dynamic memory allocations at runtime. "the decode loop allocates zero bytes."

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 3 tweets with 26 likes about this paper.