MySQL 8.0.20 - Master Replica scheme, increasing delay between Source and Replica
Please remember that MySQL Replication is single threaded by nature.
It has two threads

I/O Thread transmission of binlog events from the Master into the Slave's relay logs
SQL Thread processes binlog events collected in the Slave's relay logs in the order
received

From the looks of the variables, I would recommend just two temporary changes:
SET GLOBAL sync_binlog = 0;
SET GLOBAL innodb_flush_log_at_trx_commit = 2;

This will loosen up the writes done by the SQL threads because you have binary logging on the Slave. Every transaction written on the Slave has to be logged and the binlogs flushed. Setting sync_binlog to 0 lets the OS cache/flush rather than mysqld.
You also want to loosen the strictness of ACID compliance on the Slave by setting innodb_flush_log_at_trx_commit to 2. This will cause the InnoDB storage engine with more regularity rather than flushing on each transaction commit.
You will have to set innodb_flush_method to O_DIRECT to further assign flushes of pages to mysqld rather than the OS.
I have mentioned these things before

Dec 07, 2012 : Dynamic change to innodb_flush_log_at_trx_commit
Feb 10, 2012 : Is it safe to use innodb_flush_log_at_trx_commit = 2
May 04, 2011 : Clarification on MySQL innodb_flush_method variable

Since innodb_flush_method is not dynamic, you must restart mysqld.
Please add the following variable to your my.cnf
[mysqld]
innodb_flush_method = O_DIRECT

Then, restart mysqld. After that login to mysql and run
SET GLOBAL sync_binlog = 0;
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
START SLAVE; /* If replication does not start automatically */

Replication should start catching up. Once caught up, change the variables back with
SET GLOBAL sync_binlog = 1;
SET GLOBAL innodb_flush_log_at_trx_commit = 1;

UPDATE 2021-02-16 10:12 EST
Why would one think of using these variables on a temporary basis ?
Over the years, I have had clients that would have one of the following setups:

sync_binlog=0 and innodb_flush_log_at_trx_commit=2 : This would be on read-only slaves
sync_binlog=1 and innodb_flush_log_at_trx_commit=1 : This would be for slaves you would want to become a Master should you wish to failover.

SCENARIO : Suppose you had a Master and 3 Slaves. You have the Master with sync_binlog=1 and innodb_flush_log_at_trx_commit=1. The Slave would have sync_binlog=0 and innodb_flush_log_at_trx_commit=2.
If you wish to have a failover, you would set up one of the slaves that is fully caught up (Seconds_Behind_Master=0) to have sync_binlog=1 and innodb_flush_log_at_trx_commit=1. Then point applications to the that new Slave and setup the other Slaves to replicate from the newly promoted Master.
You can use things like ProxySQL / Orchestrator to set up such steps for you.
This just one example of why these variables would be changed on a temporary basis.
CAPTAIN'S LOG : SUPPLEMENTAL
If you have the redo logs (ib_logfile0,ib_logfile1), binary logs, slow logs, or generals logs stored in the same data volume as the data, they can slow down writes to the database. How so ???
At the disk level

All Logs are written sequentially
All data is usually written in random order

Storing logs on a separate disk volume can also speed up write performance. I learned this from a Facebook Engineer's Blog. (See also How do I determine how much data is being written per day through insert, update and delete operations? and
MySQL on SSD - what are the disadvantages?)