Manage predictive reasoners

Predictive reasoners run the compute behind PyRel predictive reasoning workflows. This guide explains how predictive reasoners are created, how to inspect and manage them, and what to check first when predictive workflows slow down.

Before you start, make sure that:

• The RAI Native App is installed and usable in your Snowflake account.
• You can run SQL in Snowflake with an active warehouse.

What predictive reasoners do

Predictive workflows need a predictive reasoner. Predictive reasoners support PyRel predictive reasoning workflows, including Graph Neural Network (GNN) training and inference.

By default, each user gets a dedicated predictive reasoner. When a user runs a predictive workflow, PyRel uses the configured predictive reasoner, resumes it if it is suspended, or creates it if it does not exist.

This page covers the reasoner lifecycle only. For modeling, training, prediction, and run-level monitoring, refer to the predictive reasoning guides.

Which compute pools host predictive reasoners

Predictive reasoners run in app-managed compute pools. You do not create or manage these pools directly, but you do choose predictive reasoner sizes that map to them.

Compute pool	Size	Supported cloud platforms	Used for
RELATIONAL_AI_HIGHMEM_X64_S	HIGHMEM_X64_S	AWS, Azure	Small predictive workloads and the default predictive reasoner size.
RELATIONAL_AI_HIGHMEM_X64_M	HIGHMEM_X64_M	AWS, Azure	Medium predictive workloads.
RELATIONAL_AI_HIGHMEM_X64_L	HIGHMEM_X64_L	AWS only	Large CPU-based predictive workloads on AWS.
RELATIONAL_AI_GPU_NV_S	GPU_NV_S	AWS only	GPU-backed predictive workloads on AWS.
RELATIONAL_AI_GPU_NV_SM	GPU_NV_SM	Azure only	GPU-backed predictive workloads on Azure.

The Native App also manages internal-only pools such as RELATIONAL_AI_ERP_COMPUTE_POOL and RELATIONAL_AI_COMPILE_CACHE_SPCS. Those pools support app internals, not user-managed predictive reasoners.

How predictive reasoners are created

PyRel creates predictive reasoners automatically. Users can configure the name and size of the predictive reasoner that PyRel creates for them.

When a user runs a predictive workflow that needs a predictive reasoner:

• PyRel checks whether the configured reasoner exists and is READY.
• If it is READY, PyRel sends the predictive workload to that reasoner.
• If it exists but is not READY, PyRel resumes it and waits for it to become READY.
• If it does not exist, PyRel creates it using the configured size, or HIGHMEM_X64_S if no size is configured.

The default predictive reasoner settings are:

Setting	Behavior
Name	Defaults to the Snowflake username with dots replaced by underscores.
Size	Defaults to HIGHMEM_X64_S.
Auto-suspend	Defaults to 60 minutes of inactivity for newly created reasoners when you do not set a different value.

Related resources:

• Configure predictive reasoner settings
• Predictive reasoning guides

How predictive reasoners handle jobs

Predictive reasoners handle predictive jobs such as training and inference rather than normal model-query jobs. Although a predictive reasoner can process more than one predictive job at a time, concurrent jobs on the same reasoner may affect each other’s performance.

If performance issues arise, start by checking which jobs are queued or running on that reasoner before you change lifecycle settings using the APIs on this page.

Related resources:

• Manage reasoner jobs
• Scale reasoner capacity

How predictive reasoners are managed

Predictive reasoners are fully managed by PyRel, including creating them if a predictive workflow needs one. By default, each PyRel user gets a dedicated predictive reasoner.

As an admin, you can perform the following actions on predictive reasoners:

What to do	When to do it
View all predictive reasoners	When you want to confirm that a predictive reasoner exists and see its high-level state.
Verify that a predictive reasoner is ready	When you want to confirm that one specific predictive reasoner is usable with its expected size and settings.
Change a predictive reasoner’s auto-suspend settings	When you want to trade off lower cost against lower startup latency.
Manually suspend a predictive reasoner	When you want to stop it from consuming compute while it is not needed. Work sent to a suspended predictive reasoner cannot run until the reasoner is resumed again.
Manually resume a suspended predictive reasoner	When you need it available before the next predictive workflow or when you want to confirm that the reasoner itself can start normally.
Delete a predictive reasoner	When you no longer want to keep that reasoner instance or its current configuration. Deletion is stronger than suspension because it removes the reasoner entirely.

View all predictive reasoners

Requires the eng_user application role.

Use the list view when you want to confirm that a predictive reasoner exists and see its high-level state.

SELECT *
FROM relationalai.api.reasoners
WHERE TYPE = 'predictive';

Start with NAME, SIZE, STATUS, AUTO_SUSPEND_MINS, and SUSPENDS_AT. Those columns usually tell you whether the reasoner is ready to use, scheduled to suspend, or worth inspecting in more detail.

Verify that a predictive reasoner is ready

Requires the eng_user application role.

Use the detail view when you want to confirm that one specific predictive reasoner is usable with its expected size and settings.

CALL relationalai.api.get_reasoner('predictive', 'my_reasoner');

Confirm the following fields first:

• STATUS = READY
• SIZE matches the expected predictive reasoner size
• AUTO_SUSPEND_MINS matches the current inactivity setting
• RUNTIME.compute_pool matches the expected predictive reasoner pool

If the reasoner exists but is not yet READY, wait for provisioning to complete and run the check again. If it remains unavailable, continue with the troubleshooting section on this page.

Change a predictive reasoner’s auto-suspend settings

Requires the eng_admin application role.

Predictive reasoners can be configured to automatically suspend after a period of inactivity, which can help reduce costs when predictive workloads are infrequent. By default, newly created predictive reasoners suspend after 60 minutes of inactivity unless you set a different value, but you can change this setting based on your workload patterns.

Execute the following to change the auto-suspend timer for a predictive reasoner named my_reasoner to 30 minutes:

CALL relationalai.api.alter_reasoner_auto_suspend_mins('predictive', 'my_reasoner', 30);

Set the value to 0 to disable auto-suspension.

Manually suspend a predictive reasoner

Requires the eng_admin application role.

If you need to suspend a predictive reasoner immediately, rather than waiting for the auto-suspend timer, you can do so manually.

Run the following to suspend a predictive reasoner named my_reasoner:

CALL relationalai.api.suspend_reasoner('predictive', 'my_reasoner');

Use get_reasoner() to check the reasoner’s status and confirm that it has suspended successfully.

Manually resume a suspended predictive reasoner

Requires the eng_admin application role.

PyRel will automatically resume a predictive reasoner when it needs to run a predictive workflow, but you can also resume it manually if you want it available immediately.

Run the following to resume a predictive reasoner named my_reasoner:

CALL relationalai.api.resume_reasoner_async('predictive', 'my_reasoner');

It may take a few minutes for the reasoner to start up and become READY again. Use get_reasoner() to check the reasoner’s status and confirm that it has resumed successfully.

Delete a predictive reasoner

Requires the eng_admin application role.

Delete a predictive reasoner when you no longer want to keep that reasoner instance or its current configuration. Deletion is stronger than suspension because it removes the reasoner entirely.

CALL relationalai.api.delete_reasoner('predictive', 'my_reasoner');

When a reasoner is deleted, current and queued work for that reasoner is cancelled. If PyRel is still configured to use that reasoner name, it can recreate the reasoner later when needed.

Troubleshoot common issues with predictive reasoners

Use this table to match common predictive-reasoner problems to the right next action:

Symptom	Likely cause	What to do next
The expected predictive reasoner does not exist.	PyRel has not needed it yet, or the configured name does not match the reasoner you expected.	Confirm the current reasoners.predictive configuration, then trigger the workflow that should use it or create the reasoner manually.
The reasoner exists but is not READY.	Provisioning is still in progress, or startup has stalled.	Wait briefly and run get_reasoner() again. If it does not recover, check broader app status.
The predictive reasoner resumes slowly even though nothing is wrong.	The reasoner is auto-suspended and needs to start again.	Increase AUTO_SUSPEND_MINS if startup latency is the main problem.
Training or inference work backs up even though the reasoner is READY.	The bottleneck is likely queued work or reasoner capacity rather than lifecycle state.	Use Manage reasoner jobs to inspect queued or running work, then Scale reasoner capacity if the same pattern keeps recurring.