Spark requests for more core than asked when calling POST livy batch api in azure synapse

I have an azure synapse spark cluster with 3 nodes of 4 vCores and 32 GB memory each. I am trying to submit a spark job using azure synapse Livy batch APIs. The request looks like this,

curl --location --request POST 'https://<synapse-workspace>.dev.azuresynapse.net/livyApi/versions/2019-11-01-preview/sparkPools/<pool-name>/batches?detailed=true' `
--header 'cache-control: no-cache' `
--header 'Authorization: Bearer <Token>' `
--header 'Content-Type: application/json' `
--data-raw '{
    "name": "T1",
    "file": "folder/file.py",
    "driverMemory": "1g",
    "driverCores": 1,
    "executorMemory": "1g",
    "executorCores":1,
    "numExecutors": 3
}'

The response I get is this,

{
    "TraceId": "<some-guid>",
    "Message": "Your Spark job requested 16 vcores. However, the pool has a 12 core limit. Try reducing the numbers of vcores requested or increasing your pool size."
}

I cannot figure out why is it asking for 16 cores. Shouldn't it ask for 4 (3 * 1 + 1) cores?

Update: I tried changing the node pool size to 3 nodes each of 8 vCores and 64 GB memory. And, with this configuration,

{
    "name": "T1",
    "file": "folder/file.py",
    "driverMemory": "1g",
    "driverCores": 1,
    "executorMemory": "1g",
    "executorCores": 1,
    "numExecutors": 6
}

It requests for 28 cores (even for executorCores 2,3,4). And if I change executorCores to 5,6,7 or 8, it will request for 56 cores.

The logic used by Livy for calculating vcore usage is not the same as it is in yarn. Livy appears to be "rounding" up your driverCores and executorCores in multiples of 4 or 8 without telling us. This unexpected behavior seems like a bug, whenever a customer encounters it.

Whereas the YARN cluster manager would have accepted smaller jobs, the small ones aren't able able to get past the door of the custom Livy implementation (it is all home-grown code from the Synapse-Spark team).

On 9/27/2023 I received the following update from CSS. I wish I could share the ICM # or BUG # but those are fairly hard to come by. I believe the "PG" which is mentioned here is referring to the "jobs-service" engineers within the Synapse Spark team.

"We have an update from the PG team that the microservice responsible for rounding off the cores to the nearest available size has been modified to accommodate smaller container sizes, we have also deployed the new bits and currently the release has reached the east us region, so it will be complete shortly and you will be able to see the improvements."

To make a long story short, it is possible that Livy will start behaving better, when submitting jobs for arbitrarily-sized executors and drivers. It is also possible that this will cause the spark pool to auto-size up to the max number of nodes (via Yarn). I am not holding my breath, until I see it happening myself. Hope this makes sense. I will try to update my answer after my deployments and tests are completed.