... но перекрутил.
0. Для всех СУБД нужен "запас памяти для операционки";
1. Для СУБД Firebird обычно нужен файловый кэш;
2. Стандартное наказание: "Я буду читать комментарии к параметрам из актуального firebird.conf".

Теперь идём по пунктам.

TempBlockSize - минимальный размер блока, выделяемого для временных объектов (сортировки, материализация GTT и всё такое). Выделять целый гиг по каждому чиху - так себе решение.

Далее.
Память нужна для: страничного кэша, буфера сортировок (и других временных объектов), для клиентских подключений и для файлового кэша.
Только разработчик приложения может управлять объёмом памяти, который требуется клиентскому подключению.
АБД оставляет резерв для клиентских подключений и "нужд операционки", а потом (как то) делит остальное между (общим в суперсервере) TCL и страничными кэшами каждой базы.

"Базы по нескольку гигов" означает, что под страничные кэши FB сможет "сожрать" не более суммарного размера баз плюс TCL, из которого будет занято ровно столько, сколько требуется приложениям. Ещё сколько-то будет занято клиентскими подключениями. Всё.
Следовательно, идея "мы посеем 200 Га буракив - нехай вин задавится" - остаётся такой же утопической, как в анекдоте.

Если следовать стандартному наказанию, то есть два параметра, которые (под виндой) надо явно выставить в -1.

Выставить DDCP в 200K (3,2ГБ для 16К страниц) ... У вас действительно настолько мелкие базы?

P.S.
Если не ошибаюсь, то hvlad говорил, что на быстрых (SSD) дисках можно получить некоторый выигрыш в скорости при отключении файлового кэша и после заполнения страничного.