At my past work the QA team's size was about 30-50 people. However, the QAs were distributed to development teams. So we averaged about 2 QAs per 3-4 developers. On average the ratio was 1 QA per 2 developers.
The QAs were mostly manual (~99%). They did prove to be a sufficient bottleneck (although they hated being called that). We had a separate "automation team" that provided automated testing for the "entire company" based on the most critical features of the product.
So, to answer your question: I'd start by identifying how much of a bottleneck is QA (if at all)? That should inform you about the QA size more effectively (irrespective of whether they are manual or automated).
For example, since QA was manual on our teams, the dev capacity of work was 2x that of QA. However, the QA work in theory was almost 1:1 with respect to "amount of time/effort to do the job". It's possible we could've done better with 1:1 dev:QA ratio, but budget wouldn't allow it. The communication overhead too would've been too much. However, we never tested this hypothesis. I'm not sure if there are any studies on this, but empirically this is what we found.
I'd strongly suggest finding out the QA pace of work - how long does work take to go into the QA team and out of it. Using that info and comparing against feature delivery efficiency, you could have a good judgment on the potential size of the QA team. You may have to experiment if you don't have the budget - e.g., get some devs to be QAs for a bit or have the QA managers to chime in to increase the resource pool, hire contractors etc., or just get creative!