Maturity and plans of asynchronous inference

1. Severity of the issue: (select one)
None: I’m just curious or want clarification.
Low: Annoying but doesn’t hinder my work.
Medium: Significantly affects my productivity but can find a workaround.
High: Completely blocks me.

2. Environment:

  • Ray version: 2.55.1
  • Python version: 2.13
  • OS: Linux
  • Cloud/Infrastructure: Kubernetes
  • Other libs/tools (if relevant): x

3. What happened vs. what you expected:

  • Expected:
  • Actual:

Hi guys,

I was looking at the asynchronous inference: Asynchronous Inference — Ray 2.57.0.
The page states that this is still in alpha (and apparently it has been for a while).

Can you give some additional info about the plans for this (is it here to stay?) and the roadmap for leaving alpha?
I’d love to use this, but if this is highly unstable, I’d rather work around this for now.

Any info would be appreciated.

Thanks!

Ray Serve’s asynchronous inference API is currently in alpha and may change before becoming stable. There is no official statement in the provided sources about when it will leave alpha or its long-term roadmap, but the feature is actively documented and maintained, suggesting ongoing development and support. For production workloads, caution is advised due to its alpha status, but it is not marked for deprecation or removal at this time.

If you need stability guarantees, consider using alternative patterns or monitor the Ray roadmap and asynchronous inference documentation for updates. Would you like more detail on current limitations or best practices for using asynchronous inference in Ray Serve?

Sources:

Hint: Mention @Herald in the post for followups.

Anyone from the team can provide additional insights on this feature and if it’s being actively developed right now?

Hi @manuel.ramblr ,

Ray Serve Async Inference is here to stay, and we’re actively working on it.

It’s currently marked Alpha because we’re looking for feedback from early users, which may lead to some API refinements. That said, the feature is already functional and expected to work as intended.

We’re also working on an additional task processor implementation, which we expect to have ready soon.

Feel free to give it a try and let us know how it goes! Any feedback is welcome and will help us refine the API and improve the overall experience.

Hi @harshit-anyscale ,

we have looked into how to use it a bit further and we ran into some issues, so I thought you may appreciate the feedback and can shine some light on what ray plans to do here.

First of all, we want to avoid using too many additional tools, so RabbitMQ is not a good option for us. Thus, we are stuck with Celery (or the upcoming integration of Taskiq).

Our use case are potentially long-running jobs (a few minutes up to a few hours).

We ran into a few issues with those:

  • Consumer heartbeat: There is none. So we have to choose a time after which the job is retried automatically, if not acked yet. We have to choose this rather large, since some of our jobs can take hours.
  • Consumer OOM or Spot-eviction protection: Since the frameworks seemingly detect fails that are to be retried on the level of a “raise”, if a node just dies for some reason, this does not go into the retry counter. This can be an issue if something goes OOM all the time → Can be infinitely stuck in the queue. So we effectively have to build a retry counter ourselves.

For failures resulting from those cases, one has to build quite a few guardrails around the system, which probably makes it easier to write a completely custom TaskProcessorAdapter.

A few other things we were wondering about:

  • Checkpointing: The docs state that this is for “long running jobs. Common use cases include video inference (such as transcoding, detection, and transcription over long videos) and document indexing pipelines that ingest, parse, and vectorize large files or batches.”. For such jobs, a retry can waste a lot of compute and (as stated in our issues) can lead to difficult configuration, so a job could end up running twice, …
    For such cases a checkpointing (which would include some progress reporting) mechanism would be helpful. It seems that ray offers nothing in this direction right now.
  • Protection against jobs running twice

There’s a few more small issues, but I won’t list them here, because they boil down to “guardrails around a brittle task-management system”.

One system we found (but have not tested yet, though on paper it solves some of those issues) is SAQ (simple async queue, GitHub - tobymao/saq: Simple Async Queues · GitHub), which seems to solve at least some of those issues.

Our way forward: We’ll very likely use ray async inference, but either with a custom TaskProcessorAdapter that adds guardrails around celery or uses SAQ.

Can you provide some information on the issues? Are you working on fixing some of them? What is your suggestion to solve those issues?

Does @Herald or anyone from the ray team have answers?

There is no official statement from the Ray team in the provided sources about when asynchronous inference will leave alpha or its long-term support status. However, maintainers have acknowledged community interest and are actively developing and documenting the feature, with ongoing discussions in GitHub issues and the roadmap, but no concrete timeline for general availability is given yet.

If you need a direct answer from the Ray team, it’s best to follow or comment on the Ray roadmap issue or the asynchronous inference documentation, where maintainers provide updates and respond to user questions. Would you like more detail on how to engage with the Ray team or track feature progress?

Sources:

Hint: Mention @Herald in the post for followups.

Can I get some additional insights from the team?

Hi @manuel.ramblr,

First of all, thank you for taking the time to share such detailed feedback on async inference and apologies for the delayed response.. Here are answers to your questions:

1. Heartbeats

Celery provides worker-level liveness checks, such as ping and worker heartbeat events, but it does not provide per-task heartbeats.

Celery supports a visibility_timeout. If a task is not acknowledged within this period, it becomes eligible for redelivery to another worker. The default varies by broker—for Redis, it is one hour. You can configure it to exceed the longest expected job duration:

CeleryAdapterConfig(
    broker_url="redis://...",
    backend_url="redis://...",
    broker_transport_options={"visibility_timeout": 6 * 3600},
)

2. Consumer OOM and infinite retries

You are correct about the possibility of an indefinitely repeating failure loop. The current implementation uses Celery’s threads worker pool. If a task causes an out-of-memory error, the entire Celery worker process can terminate before it updates the retry counter. Once the visibility timeout expires, another worker may pick up the same task, encounter the same OOM condition, and repeat the cycle.

Unfortunately, this is a limitation of Celery’s threads pool in the current implementation. We expect to address this more effectively in the upcoming Taskiq task processor. For now, if you continue using Celery, an external retry counter or another durable mechanism would be required to prevent infinite redelivery.

3. Checkpointing and progress reporting

We agree that checkpointing and progress reporting would be valuable, particularly for long-running tasks. Neither capability is currently on our roadmap, but we would welcome a contribution in this area. If you decide to work on it, we would be happy to help you understand the implementation and guide you through the contribution process.

4. Idempotency

The current Celery task processor provides at-least-once delivery. As a result, a task may be executed more than once, and idempotency must currently be implemented at the application level.

We are actively working on a Taskiq-based task processor. Here’s the list of PRs on it. Please also continue sharing any other issues you encounter with Celery - this is exactly the kind of feedback we are looking for.

If Taskiq does not address your requirements and you decide to implement another task processor, you are welcome to contribute it directly to the ray repository. We would be glad to support you through that process.