Too many variables, not enough detail.  What is the nature
of these "requests," how much processing power does each need,
what kind of throughput and/or latency requirements exist, how
many CPUs are available, how much memory (relative to the amount
needed to process a request) is available, ...?

    That said, a thousand threads is certainly far out in the
fringe of unreasonability: they will chew up "a lot" of memory
in thread stacks and other structures, they will spend "a lot"
of time performing context switches, and so on.  But you have
not provided enough information for me to recommend using ten
threads, or a hundred, or one.  The only thing I can suggest is
that you decouple the thread count from the request count, so
you can adjust the former to suit the resources of the machine
of the moment rather than letting the request count govern your
life.

My guess is that of those two alternatives the second is likely to be
closer to optimal.

I imagine a more optimal solution would be a design that starts with n
threads (where n is some tunable parameter that can be selected at
program launch time). To further optimise it (if needed) I'd have some
mechanism for dropping threads that are unused for a long period and for
starting new threads when the pool becomes busy.

The above is all superficial guesswork. It shouldn't be too hard to
benchmark all three through.