Anyone else having trouble with GitLab CI's parallel job limits?

I've been elbows-deep in a large-scale monorepo migration for a financial services client, and we've hit a consistent pain point with GitLab CI's parallel job execution limits. While the `parallel:` matrix feature is powerful for dynamic job creation, we're butting up against the ceiling of what the platform allows, and it's causing non-linear increases in pipeline duration and cost. The core issue isn't just the documented concurrency limits of shared runners, but the systemic constraints within GitLab's architecture when you try to scale a single pipeline.

Our use case: a monorepo with ~150 microservices, each requiring a matrix of tests (e.g., `[integration, security-scan, performance]` x `[version-1, version-2]`). A naive implementation using `parallel: matrix` in a single job can easily generate 300+ individual job units. GitLab's platform limits, particularly on GitLab.com SaaS but also observable in self-managed deployments, start to choke here.

The primary bottlenecks we've measured:

* **Pipeline-level concurrency:** Even with unlimited private runners, a single pipeline's jobs are throttled. We've observed a soft queueing mechanism where jobs beyond a certain threshold (often around 150-200 concurrent jobs for a single pipeline, depending on tier) experience significant scheduler delays (5-10 minute waits are common). This isn't runner capacity—our runner pools are idle—it's internal job scheduling.
* **YAML/Config complexity:** Generating a dynamic matrix of that size can lead to a `.gitlab-ci.yml` that becomes difficult to validate and can hit internal parsing limits. The pipeline UI also becomes unusable for developers.
* **Cost on SaaS:** On GitLab Premium, you pay per CI/CD minute. When 200 jobs are queued waiting for the scheduler, you're still burning minutes for the jobs that *are* running, leading to poor utilization and inflated costs.

We've moved to a pattern of pipeline-level parallelization using the API to trigger downstream pipelines, but this fragments visibility and adds complexity. Here's a simplified snippet of our mitigation strategy:

```yaml
# Main pipeline triggers dispatcher jobs per service group
trigger-matrix:
stage: build
script:
- |
SERVICE_GROUPS=$(find ./services -maxdepth 1 -type d | tail -n +2 | split -l 10 - ./service-group-)
for GROUP in ./service-group-*; do
curl --request POST --form "token=$CI_JOB_TOKEN"
--form "ref=$CI_COMMIT_REF_NAME"
--form "variables[SERVICE_GROUP]=$(cat $GROUP)"
"https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/trigger/pipeline"
done
```

My question to the community: Is this a fundamental architectural limitation of GitLab CI's design, centered on the single, directed acyclic graph (DAG) model? Have any of you operating at a similar scale (500+ potential job units per commit) found a more elegant solution than manually sharding pipelines via the API? I'm particularly interested in benchmark numbers: what's the maximum number of *scheduled* (not just configured) parallel jobs you've successfully run in a single GitLab pipeline without scheduler-induced queueing?