Workloads

workloads are the primary way amberflo tracks ai usage and spend they represent the individual entities that consume ai resources and serve as the foundation for attribution, governance, and access control a workload can represent almost any consumer of llms, including a chatbot or virtual assistant a backend service or microservice a data processing or enrichment pipeline an internal tool a customer facing feature a specific environment such as development, qa, or production for example, you might create separate workloads for support chatbot dev support chatbot qa support chatbot drod this level of separation allows you to understand usage patterns and cost at a much finer granularity why workloads matter workloads serve two critical purposes in amberflo attribution all usage and cost flowing through the gateway is attributed to a workload this makes it easy to understand who is consuming ai resources and how much they are using governance and control each workload explicitly defines which models it is allowed to access this allows you to enforce guardrails and prevent unintended usage of specific models workloads sit between models and access keys models define what is available workloads define who can use what viewing existing workloads to manage workloads go to access management in the left hand navigation select the workloads tab this page displays all previously created workloads, including workload name workload id creation date last updated date options to edit or delete the workload this list represents all active consumers that can be granted access to llms through the gateway creating a workload to create a new workload click add workload in the upper right enter a workload name the name is a human readable label designed to help you easily identify what the workload represents workload id as you type the name, amberflo automatically generates a workload id the id must be all lowercase contain no spaces use only letters, numbers, underscores, or hyphens start and end with a letter or number you can edit the id if needed, as long as it follows these rules assigning models to a workload after setting the name and id, you will see a list of available models this list includes all models that have been configured in the gateway select the models that this workload is allowed to access you can choose one, many, or all available models depending on your use case this selection enforces model level access control for the workload saving the workload once you have selected the models, click create workload the workload will appear in the workloads list and is now ready to be used for access and attribution workloads and access creating a workload does not automatically grant access to applications workloads define what is allowed, not how access happens the next step is to create access keys for a workload access keys are what applications use to authenticate with the gateway every request made with a key is automatically attributed to the associated workload what’s next after creating a workload, continue to the access keys section to learn how to generate keys that allow applications to access models through the gateway while preserving full attribution and governance