- Table of Contents
- Overview
- Why Host Your Own LLM?
- Structure
- Getting Started
- Components
- Usage
- Local Development
- Contributing
- Community
LeapfrogAI is a self-hosted AI platform designed to be deployed in air-gapped environments. This project aims to bring sophisticated AI solutions to air-gapped resource-constrained environments, by enabling the hosting all requisite components of an AI stack.
Our services include vector databases, model backends, API, and UI. These capabilities can be easily accessed and integrated with your existing infrastructure, ensuring the power of AI can be harnessed irrespective of your environment's limitations.
Large Language Models (LLMs) are a powerful resource for AI-driven decision making, content generation, and more. How can LeapfrogAI bring AI to your mission?
-
Data Independence: Sending sensitive information to a third-party service may not be suitable or permissible for all types of data or organizations. By hosting your own LLM, you retain full control over your data.
-
Scalability: Pay-as-you-go AI services can become expensive, especially when large volumes of data are involved and require constant connectivity. Running your own LLM can often be a more cost-effective solution for missions of all sizes.
-
Mission Integration: By hosting your own LLM, you have the ability to customize the model's parameters, training data, and more, tailoring the AI to your specific needs.
LeapfrogAI, built on top of Unicorn Delivery Service (UDS), which includes several features including:
- Single Sign-On
- Non-proprietary API Compatible with OpenAI's API
- Retrieval Augmented Generation (RAG)
- And More!
The LeapfrogAI repository follows a monorepo structure based around an API with each of the components included in a dedicated packages
directory. The UDS bundles that handle the development and latest deployments of LeapfrogAI are in the uds-bundles
directory. The structure looks as follows:
leapfrogai/
├── src/
│ ├── leapfrogai_api/ # source code for the API
│ ├── leapfrogai_sdk/ # source code for the SDK
│ └── leapfrogai_ui/ # source code for the UI
├── packages/
│ ├── api/ # deployment infrastructure for the API
│ ├── llama-cpp-python/ # source code & deployment infrastructure for the llama-cpp-python backend
│ ├── repeater/ # source code & deployment infrastructure for the repeater model backend
│ ├── supabase/ # deployment infrastructure for the Supabase backend and postgres database
│ ├── text-embeddings/ # source code & deployment infrastructure for the text-embeddings backend
│ ├── ui/ # deployment infrastructure for the UI
│ ├── vllm/ # source code & deployment infrastructure for the vllm backend
│ └── whisper/ # source code & deployment infrastructure for the whisper backend
├── uds-bundles/
│ ├── dev/ # uds bundles for local uds dev deployments
│ └── latest/ # uds bundles for the most current uds deployments
├── Makefile
├── pyproject.toml
├── README.md
└── ...
The preferred method for running LeapfrogAI is a local Kubernetes deployment using UDS.
Please refer to the Quick Start section of the LeapfrogAI documentation website for system requirements and instructions.
LeapfrogAI provides an API that closely matches that of OpenAI's. This feature allows tools that have been built with OpenAI/ChatGPT to function seamlessly with a LeapfrogAI backend.
The LeapfrogAI SDK provides a standard set of protobufs and Python utilities for implementing backends with gRPC.
LeapfrogAI provides a UI with support for common use-cases such as general chat and "Q&A with your documents".
LeapfrogAI provides several backends for a variety of use cases. Below is the backends support and compatibility matrix:
Backend | AMD64 | ARM64 | CUDA | Docker | Kubernetes | UDS |
---|---|---|---|---|---|---|
llama-cpp-python | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
whisper | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
text-embeddings | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
vllm | ✅ | ❌1 | ✅ | ✅ | ✅ | ✅ |
The repeater "model" is a basic "backend" that parrots all inputs it receives back to the user. It is built out the same way all the actual backends are and it is primarily used for testing the API.
To build a LeapfrogAI UDS bundle and deploy it, please refer to the LeapfrogAI Documentation Website. In the documentation website, you'll find system requirements and instructions for all things LeapfrogAI that aren't associated to local development and contributing.
For contributing and local deployment and development for each component in a local Python or Node.js environment please continue on to the next section.
Note
Please start with the LeapfrogAI documentation website prior to attempting local development
Each of the LeapfrogAI components can also be run individually outside of a Kubernetes or Containerized environment. This is useful when testing changes to a specific component, but will not assist in a full deployment of LeapfrogAI. Please refer to the above section for deployment instructions. Please refer to the next section for rules on contributing to LeapfrogAI.
First refer to the DEVELOPMENT.md document for general development details.
Then refer to the linked READMEs for each individual sub-directory's local development instructions.
All potential and current contributors must ensure that they have read the Contributing documentation, Security Policies and Code of Conduct prior to opening an issue or pull request to this repository.
When submitting an issue or opening a PR, please first ensure that you have searched your potential issue or PR against the existing or closed issues and PRs. Perceived duplicates will be closed, so please reference and differentiate your contributions from tangential or similar issues and PRs.
LeapfrogAI is supported by a community of users and contributors, including:
- Defense Unicorns
- Beast Code
- Chainguard
- Exovera
- Hypergiant
- Pulze
- SOSi
- United States Navy
- United States Air Force
- United States Space Force
Want to add your organization or logo to this list? Open a PR!
Footnotes
-
vLLM requires a CUDA-enabled PyTorch built for ARM64, which is not available via pip or conda ↩
-
The SDK is not a functionally independent unit, and only becomes a functional unit when combined and packaged with the API and Backends as a dependency. ↩
-
Please be aware that the API and UI have artifacts under 2 sub-directories. The sub-directories related to
packages/
are focused on the Zarf packaging and Helm charts, whereas the sub-directories related tosrc/
contains the actual source code and development instructions. ↩ ↩2