why is it called serverless when it is a server
Conceptually, «serverless» is a reincarnation or an evolution of the VAX VMS style cluster computing: applications running on VMS clusters see the cluster as a single computer. Adding a new cluster makes the cluster more powerful, yet the app continues to see the cluster as a single computer. Cluster nodes can be geographically distributed, appear and disappear without the app noticing it. So, serverless apps, whilst technically running on a server, actually run somewhere (on a cluster node) but the app does not know it and does not care about it.
So «serverless» in the cloud takes the concept further, slaps on the automation and makes it more accessible to mere mortals, it scales (almost) indefinitely and completely transparently from the application. It requires no setup and is easy to use (setting up VMS clusters requires an experienced and knowledgeable systems engineer, for instance).
We can agree and disagree on the semantical correctness and richness (or the lack thereof) of the term «serverless», but it has already caught on and has evolved to mean more than just cloud serverless functions.
If you are doing it on someone else computer, and that computer is a big server farm, I find it odd to use the term “serverless.” And by odd I mean literally the exact opposite of serverless.
A serverless program (often called a function) is invoked by a server on-demand instead of running all the time, and it doesn't listen for anything on any port. The client request is passed to it by the server (e.g. on standard input) and it's supposed to pass the response back to the server (e.g. through standard output) - and the server sends it to the client. Then the program halts.
Compare that to Django, Node.js or ASP.NET: A classic backend app exposes a HTTP server on a port and handles client connections itself - and thus it has to run all the time, it literally is a server (in the software sense).
If you know PHP, that's the original serverless. As opposed to the Python/ASP.NET/Node.js backends, your page.php is invoked by the Apache daemon only when someone opens that page, and there's no "server.listen(3000)" in page.php.
Serverless is cool because it allows the cloud provider to fully utilize a machine while the developer pays only for their portion of actual usage. You don't need to reserve a specific amount of compute resources and worry about up/down-scaling or about paying for unused hardware.
Serverless GPUs are about bringing that concept to the GPU as a service space - ideally you'd have a function that uses the GPU. That function could be invoked by sending a request to the platform's server, at which point the server would load and execute it, pass the client request to it and pass the response back to the client once the function is done.
1) If you don't drive much then you might be overpaying
2) You have to worry about the car infrastructure, you have to maintain it and if it breaks down you might be offline (unable to travel) until its repaired.
3) If you need bring home a washer and dryer for example you have to worry about your car having the needed capacity (scaling)
In todays world you can decide not to own a car and just use Uber or whatever vehicle sharing service is available to you. You pay only for the rides you need, you don't have to worry about infrastructure (repairs) and you can always pay for larger vehicles on demand.
That's serverless computing. Instead of paying for a physical computer or a virtual computer (compute service) you deploy the app you want to run and pay for each run of your app. Typically the app is some type of request/response or event processing app. The cloud company maintains the compute fleet and when a request comes in the will deploy your app to one of their compute nodes long enough to service the request.
Its called serverless not because there are no servers but because you don't know or care about the server it runs on. The hardware could change out between executions. You don't care about failed hardware, OS patching, etc. The lowest level you typically deal with is selecting the app language (node, java, etc).