System requirements


Before you deploy BMC AMI Platform, make sure that your environment meets the recommended hardware requirements, cluster architecture, and networking specifications. This topic includes system requirements for an RKE2 Kubernetes cluster, Red Hat OpenShift recommendations, and deployment prerequisites.

Success
Best practice

We recommend that you use the configuration options described in this topic for best performance and LLM outputs.

System requirements

You can deploy BMC AMI Platform on an RKE2 Kubernetes cluster and Red Hat OpenShift.

Cluster topology guidelines

The following table displays recommendations for Control Plane and Worker nodes:

Node type Requirement
Control Plane 
  • Deployment: Must be deployed across at least two Availability Zones
  • Role duality: Can perform dual roles (manager and worker), but this is not recommended for performance-critical environments
  • Recommendation: Isolate control plane functions from workload run for optimal performance and stability
Worker 
  • Overprovisioning: Additional 20–30 percent computing capacity to support:
    • Rolling updates
    • Node failure or eviction scenarios
  • Deployment: Must be distributed across multiple Availability Zones for fault tolerance and service continuity
  • Scalability: Cluster should support horizontal scaling based on workload demands

Recommended cluster topologies

For RKE2 Kubernetes and Red Hat OpenShift, the availability and workload handling require as follows:  

  • A minimum of three Control Planes
  • A minimum of four Worker nodes  

RKE2 and Red Hat OpenShift security and compliance capabilities

  • Focus on security and compliance, including alignment with U.S. Federal Government requirements
  • Support for FIPS 140-2 compliant cryptographic modules
  • Continuous vulnerability scanning of platform components (For example, CVE detection using tools like Trivy or integrated platform scanners)
  • Secure-by-default configurations, including hardened components and restricted access controls

Node sizing guidelines

The following table displays the node sizing requirements for RKE2 Kubernetes:

Node type Component Requirement
Control Plane CPU 8+ vCPU (modern x86-64 or ARM architecture) 
RAM 24+ GB (for application requirements) 
Storage Minimum 100-GB SSD with high IOPS and container storage 
WorkerCPU 32+ vCPU (to handle container workloads) 
RAM 64+ GB (depends on container memory requirements) 
Storage 100+ GB SSD (based on container requirements) 

LLM GPU 

GPU-specific hardware and cloud requirements for the Recommended configuration option:

Supported LLM 

Meta-Llama-3.1-8B-instruct 4K Quantized 

Granite-3.1-8B-Instruct

Mixtral8x7b-instruct Quantized

On-premises hardware GPU memory: 36 GB  
GPU: NVIDIA 4 × A10G or 1 × A100 
AWS g5.12xlarge (4 × A10G) 
Azure Standard_NC24ads_A100_v4 (1 × A100) 
Embedding service GPU (vLLM)

Minimum GPU‑specific hardware and cloud requirements to run the Embedding service:

On-premises hardware

GPU memory: 24 GB

GPU: 1 × NVIDIA L4

AWSg6.2xlarge (1 × L4)

The following table displays the node sizing requirements for Red Hat OpenShift:

Node type Component Requirement
Control Plane CPU 8+ vCPU (modern x86-64 or ARM architecture) 
RAM 24+ GB (for application requirements) 
Storage Minimum 100-GB SSD with high IOPS and container storage 
WorkerCPU 32+ vCPU (to handle container workloads) 
RAM 64+ GB (depends on container memory requirements) 
Storage Minimum 100-GB SSD (based on container requirements) 

LLM GPU 

GPU-specific hardware and cloud requirements for the Recommended configuration option:

Supported LLM 

Meta-Llama-3.1-8B-instruct 4K Quantized 

Granite-3.1-8B-Instruct

Mixtral8x7b-instruct Quantized

On-premises hardware GPU memory: 36 GB  
GPU: NVIDIA 4 × A10G or 1 × A100 
AWS g5.12xlarge (4 × A10G) 
Azure Standard_NC24ads_A100_v4 (1 × A100) 
Embedding service GPU (vLLM)

Minimum GPU‑specific hardware and cloud requirements to run the Embedding service:

On-premises hardware

GPU memory: 24 GB

GPU: 1 × NVIDIA L4

AWSg6.2xlarge (1 × L4)

Recommended deploying options for knowledge hub

Knowledge hub supports multiple deployment configurations to address varying concurrency requirements. Each deployment option defines the number of OCR and Knowledge Hub service instances and determines the maximum number of documents that can be processed concurrently.

Option 1 (Default)
  • 1 OCR + 1 Knowledge Hub
  • Supports: 1 PDF + 7 non-PDF documents concurrently
Option II (Recommended)
  • 2 OCR + 1 Knowledge Hub
  • Supports: 2 PDFs + 6 non-PDF documents concurrently
Option III
  • 2 OCR + 2 Knowledge Hub
  • Supports: 2 PDFs + 14 non-PDF documents concurrently
Option IV
  • 4 OCR + 3 Knowledge Hub
  • Supports: 4 PDFs + 20 non-PDF documents concurrently
Option V
  • 4 OCR + 4 Knowledge Hub
  • Supports: 4 PDFs + 28 non-PDF documents concurrently

Service resource requirements

The following table lists the resource requirements for each service instance.

ServiceCPU Limits (cores)Memory Limits (Gi)CPU Requests (cores)Memory Requests (Gi)
OCR8886
Knowledge kub12321024
Warning
Important

Service scaling must be performed in accordance with the performance tiers defined in the deployment options table. Selecting any deployment option other than the default configuration increases compute and memory requirements. To support the selected deployment option, additional Kubernetes worker nodes must be provisioned as required. Refer to the Service resource requirements table for the exact CPU and memory specifications for the OCR and knowledge hub services.

The following is an example of how to scale the services:

kubectl -n bmcami-prod-user-management scale deploy/bmcamiplatform-amiai-ocr --replicas=2

Recommended models for services

ServicesRecommended models
BMC AMI AssistantLlama-3.1-8B-Instruct 
Code Insights Explain

Language

Model

Limitations

Cobol

Granite-3.1-8B-Instruct 

None

PLI

Granite-3.1-8B-Instruct 

None

Assembler

Granite-3.1-8B-Instruct 

Macros are not supported.

JCL

Granite-3.1-8B-Instruct 

Conditions (If-Else) are sometimes not detected correctly or give incorrect explanations. We plan to provide better results in future maintenance.

Code ConversionGranite-3.1-8B-Instruct
Ops Insight Explain Probable CauseLlama-3.1-8B-Instruct 

Software requirements

The following table displays the software requirements for RKE2 Kubernetes and Red Hat OpenShift:Ed

ComponentRequirement
OSUbuntu LTS 22.x and 24.x or RHEL 8.x and 9.x
Python

Version 3.x

AnsibleVersion 2.14.x and above

Docker Engine

Latest stable version (minimum 28.0.x) 
HelmVersion 3.6

Storage requirements

The following table displays the storage requirements for RKE2 Kubernetes and Red Hat OpenShift:Ed

 Platform  Requirements
RKE2 Kubernetes

version 1.33.5

Red Hat OpenShift versions 

4.19.1

4.18.1

4.12.86

Requires an NFS server with a pre-created export folder with a size of at least 1 TB. 

Warning
Important

Make sure that NFS is reachable from all cluster nodes.

Directory permissions must allow service write access (UID/GID 1000 or 0777).  

During installation, provide:  

  • NFS server (host or IP)  
  • NFS export path  
  • Local mount path (for example, /mnt/nfs/data
Warning
Important

If you are installing version 4., then you must set up the security settings added. For more information, see To set up security settings to install BMC AMI Platform on OpenShift version 4.12.86.

 

SSH accessibility requirements

To deploy the LLM model from the UI, the system must securely connect to the Control Plane node.
The provided PEM (SSH private key) enables this secure, authenticated connection, allowing the deployment process to transfer files, run setup commands, and complete the installation safely and automatically.

Warning
Important

The SSH key must belong to the root user who has sufficient permissions to run the kubectl commands on the Kubernetes cluster. See To provide kubectl access to an RKE2 Kubernetes cluster.

Information
Example for creating and configuring the SSH key
  1. Generate a new RSA private key in PEM format:
    ssh-keygen -t rsa -b 4096 -m PEM -f sshkey.pem
  2. Add the public key to the authorized keys of the target user:
    cat $KEY_PATH/sshkey.pem.pub >> /root/.ssh/authorized_keys

Cluster-wide configuration

The public key created as a part of the SSH accessibility requirement must be added to the authorized_keys file on all nodes in the cluster.

Information

Example for configuration

  1. Copy the public key to each node.
  2. Run the following command on every node:
    cat $KEY_PATH/aikey.pem.pub >> /root/.ssh/authorized_keys

SSL and TLS requirements

To enable HTTPS communication for the web application, you must provide your own SSL and TLS certificate and private key. Place both files in the prerequisites directory on the Control Plane node before running the Ansible script. While running, the Ansible script prompts you to provide the paths to the certificate and key files.

Warning
Important

You can use certificates issued by your organization’s Certificate Authority (CA).

Infrastructure and security requirements

The following table displays the infrastructure and security requirements for RKE2 Kubernetes and  Red Hat OpenShift
E

Requirement Details
Registry access All nodes must access your container registry. 
Ansible and PythonThe Control Plane or Manager node must have Python 3.x and Ansible installed.
Warning
Important

If you are running on cloud with a load balancer, set Connection Idle Timeout to 1800 seconds (30 minutes) to match the AI external proxy timeout.

Supported versions for CES, BMC AMI DevX Code Insights, and BMC AMI DevX Workbench for VS Code products for Code ExplainEdit

The following table outlines the supported versions for the Code Explain feature across CES, Workbench for Eclipse and Code Insights, and Workbench for VS Code products.

BMC AMI PlatformCESWorkbench for Eclipse/Code InsightsWorkbench for VS Code
2.023.04.02 or later23.07.07 and 25.02.0225.10.10 or later
1.623.04.02 or later23.07.03 or later24.04.1 or later
1.423.04.02 or later23.06.01 or later24.04.0 or later

Product compatibility matrix

 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC AMI Platform 2.2