Infrastructure Requirements

Specifications

Internet browsers

The table below lists the supported internet browsers for each version of Hyperscience.

For the best possible user experience, we recommend browser dimensions of at least 1280 x 720 pixels.

Application servers

The requirements in this section apply to the VMs that run the Hyperscience application. For the requirements for Trainer VMs, see Trainer.

Operating system

The tables below list the supported operating systems for each version of Hyperscience.

Ubuntu

RHEL

Container environments

The table below lists the supported container environments for each operating system.

Note the following:

• The container environment should be installed on all machines.

• The container environment can be called:

  • docker-latest or docker if you are using Docker.

  • podman if you are using Podman.

• The container environment's preferred storage driver is overlay2.

We support any Docker distribution that meets the requirements above. Examples include:

• Docker Community Edition (CE):

  • In v30 and later, Hyperscience does not support Docker installed via the Snap application package or via Snap Store. Hyperscience does not impose restrictions on where users run the installation command and unpack the Bundle, while Snap-installed Docker has tighter security permissions and only allows mounting Docker containers if the install path is under /home. To learn more about the Snap application package and Snap Store, see Snapcraft's Install Docker on Ubuntu and Snap Store.

  • RHEL 7 — see Red Hat's Getting Docker in RHEL 7.

  • Ubuntu — see Docker's Install Docker Engine on Ubuntu.

  • Docker CE can be obtained from either OS distribution repository packages or Docker's download.docker.com repository.

• Docker Enterprise Edition (EE):

  • Docker EE can be purchased from Docker.

Hyperscience requires Docker Container Runtime, which we refer to as "Docker" on this site. Note that Docker offers other products, such as Docker Desktop and premium support, that are licensed by Docker but are not required for using Hyperscience. For any licensing and support arrangements for Docker, contact Docker's support team.

Local storage

Each VM's local storage requirements depend on your version of Hyperscience, as shown in the table below. These requirements are in addition to the space consumed by the OS.

Additional space is recommended to accommodate future expansion and operational flexibility.

To maximize the amount of available space, we recommend keeping no more than two bundles in your local storage.

CPU

• Intel x86_64 is a requirement.

• ARM is not supported.

VM CPU cores

The system requires a minimum of 8 CPU cores in each VM.

Definition of "CPU cores"

Note that in this article, we use the term "CPU cores" for:

• threads on Intel processors with enabled Hyper-Threading, and

• virtual CPUs (vCPUs) on compute instances in cloud providers (e.g., AWS, GCP).

For example, a VM using 4 physical cores on an Intel processor with enabled Hyper-Threading would be using 8 logical cores (i.e., 8 threads) and is considered to have 8 cores. An AWS EC2 instance or a GCE instance with 8 vCPUs is considered to have 8 cores.

GPU

Application machines with GPUs are supported in deployments of Hyperscience v41 and later. Use of GPUs with v40 or earlier is not supported.

• An application machine with a GPU is required to use ORCA VLMs.

• The use of an application machine with a GPU is supported only for ORCA use cases.

The following requirements apply only to the application VM that runs ORCA and has a GPU.

The table below lists GPUs officially supported by Hyperscience. You may also be able to use other GPUs with comparable specifications. Contact your Hyperscience representative for more information.

To learn how to set up application machines with GPUs, see our "Enabling Application Machines with GPUs" articles for Docker and Podman.

RAM

The system requires a minimum of 32 GB per VM.

Permissions

The Hyperscience application does not support the use of fapolicyd in Podman-based deployments. It does support SELinux, which provides similar security measures.

Database

Hyperscience supports the database options described below.

PostgreSQL

Hyperscience supports the community and enterprise (EnterpriseDB Postgres) editions of PostgreSQL, as well as Amazon RDS for PostgreSQL and Google Cloud SQL for PostgreSQL.

Oracle

Hyperscience supports Oracle and Amazon RDS for Oracle. All supported Oracle versions require DBMS_ALERT privileges.

Microsoft SQL Server (MSSQL)

Hyperscience supports MSSQL and Amazon RDS for SQL Server. Service Broker must be enabled.

Azure SQL Managed Instance

Azure SQL Managed Instance is supported in Hyperscience v28 and later.

Hyperscience does not support Azure SQL Database.

Because Azure SQL Database does not support Service Broker, Hyperscience does not support Azure SQL Database.

PostgreSQL and MSSQL are the recommended database options. While we do support the use of Oracle, it is the least used option, and we may remove support for it in the future if usage decreases.

Privileges required

User DDL privileges are required for table and index creation and modification. Keeping these DDL privileges is required even after installing the Hyperscience application.

HA/DR

Architectures for the database are subject to our customers' policies and are managed by them; our application supports connecting to a single database host at a time.

Migrating existing data between different database types is not supported.

File storage

Supported options

• AWS S3 bucket

• Azure Blob Storage

• Google Cloud Storage

• A networked file store (like NFS or CIFS)

HA/DR

Architectures for the file store are subject to our customers' policies and are managed by them.

Load balancer

To achieve HA/DR goals for the application, we encourage customers to deploy the application on multiple VMs and to use a load balancer for web requests. To learn more about using a load balancer to distribute web requests, see Load Balancer.

If you are configuring a load balancer, note that the application uses the HTTP_HOST from the request to generate some of its links.

Load balancer health check URLs

Hyperscience offers a Health Check Status API endpoint, which is designed to help you monitor the health of your system's components. If any component tested by the Health Check Status API is in an error state, the endpoint will return an error code. If you enter the Health Check Status endpoint as your load balancer's health check URL, an issue in one server will cause all servers to return an error code to the load balancer. This response will prevent traffic from being routed to your entire system, even if healthy servers are available. For this reason, we do not recommend using this endpoint as your load balancer's test of overall system health.

For more information on the Health Check Status endpoint, see our API documentation.

Trainer

The Hyperscience Trainer runs separately from the main application and communicates with the main application via the API. The trainer supports select long-running tasks and very large file downloads and uploads that might otherwise negatively impact document processing time.

To learn more, see Trainer Installation.

Operating system and container environment

Trainer VMs run on the same infrastructure as application servers. The operating system and container environment requirements described in Operating system also apply to trainer VMs.

Storage

Trainer VMs have the same local storage requirements as application servers. For details, see the Local Storage section of this article.

Use local storage with the trainer. Do not use shared storage, especially if you have multiple trainers of the same version. Using shared storage may cause data to be overwritten and training jobs to fail.

Database

The trainer uses its own local PostgreSQL database, which comes pre-packaged with the Hyperscience bundle. You do not need to provision an external database for trainer VMs — the requirements described in Database apply to application servers only.

VM CPU cores

We require 16 CPU cores in a trainer VM if you are processing Semi-structured documents. If you have only 8 CPU cores, you can expect 60-70% longer training times and an increased risk of out-of-memory errors during training, particularly on datasets with longer, denser documents.

RAM

The trainer needs 4 GB of RAM for each CPU core in a trainer VM. This will need to scale up proportionally when increasing Trainer CPU cores at a rate of 4GB of RAM for each additional CPU Core. Therefore, if you have a 16-core CPU, as described in VM CPU cores, you can expect maximum performance with 64 GB of RAM.

In v42.3 and later, a minimum total of 64 GB of RAM is required.

GPU

Trainers with GPUs are supported in Docker, Podman, and Kubernetes deployments of Hyperscience v41 and later. Use of GPUs with v40 or earlier is not supported.

• A trainer with a GPU is required to train Long-form Extraction models.

• While GPUs are not required to train Field Identification or Table Identification models, you can use a trainer with a GPU to train these models.

• The training of other types of models with a GPU is not supported. However, you can train them with a CPU on a trainer machine that has both a GPU and a CPU.

Trainer GPU requirements depend on the types of models you want to use with the GPU.

To learn how to set up trainers with GPUs, see our "Enabling Trainers with GPUs" articles for Docker and Podman.

Sizing the system

Exact capacity planning requires details of anticipated document flow (see below) and is usually discussed with our Deployments team.

Server capacity

The exact number of VMs required depends on the following factors:

• Peak hourly throughput

• Number of fields per page to be collected

• The split of Structured (forms) versus Semi-structured (invoices, checks, paystubs, bills, etc.) documents

Our system scales horizontally — doubling the number of machines doubles the processing capabilities. Additionally, Hyperscience is able to leverage a larger number of cores. The system will perform twice as fast on a 16-core 64 GB RAM machine as it will on an 8-core 32 GB RAM machine.

Requirements for RAM and VM CPU cores

To ensure optimal performance, the system requires a 1:4 ratio of the number of cores in a VM's CPU and the number of gigabytes of RAM in that VM. For example, if a VM has a 16-core CPU, that VM should have 64 GB of RAM.

Note that burstable-performance machines are not supported. Such machines are:

• AWS: T-series. To learn more, see Amazon's Burstable performance instances.

• Azure: B-series. To learn more, see Microsoft's B-series burstable virtual machine sizes.

• Google Cloud: shared core. To learn more, see Google's General-purpose machine family.

The Hyperscience application is designed to consume 100% of its CPUs' resources. The nature of burstable-performance machines does not allow them to constantly utilize 100% of the CPUs' resources, which results in system slowness.

Directionally, a single 8-core 32 GB RAM machine will process approximately 15,000 Structured pages, with 20 fields per page, in 12 hours. Similarly, a single 8-core 32 GB machine will process approximately 7,000 Semi-structured pages, with 20 fields per page, in 12 hours. Large production set-ups might have 4-8 machines, across two data centers for high availability.

The following table gives an example of the recommended number of machines based on a few different peak hourly volumes and ratios of Structured versus Semi-structured documents. The table assumes an 8-core 32 GB RAM machine and approximately 20 extracted fields per page.

Trainer capacity

The trainer uses the directory referenced by the HS_PATH environment variable for storage. Ensure that the directory is located on a partition with at least 100 GB of storage.

If you plan on enabling Trainer Resiliency, which creates checkpoints for Training Data and Model training, you will need to ensure that there is an additional 6 GB of storage available. To learn more about this feature, see Trainer Resiliency.

Database capacity

The size of the database store depends on:

• Daily volume of pages

• Number of fields per page to be collected

• Retention period before record deletion

  • The retention period is configurable by the user. Anywhere between 3 days and 60 days is common.

A typical set-up (15,000 TIFF files per day, deleted after 30 days) requires 30 GB of database storage. As storage is inexpensive, teams usually provision this with a buffer (100-200 GB).

File storage capacity

The size of the file store depends on:

• Daily volume of pages

• Mix of file sizes and formats

• Retention period before record deletion

Directionally, a setup of 15,000 TIFF files per day, deleted after 30 days, requires approximately 1 TB of file storage.