How long do you mean when you say forever? Hours? Days? I wouldn't be surprised if it takes days.
Importing an .sql dump file is notoriously time-consuming. It is bound to be single-threaded, so you can only use one CPU core, no matter what type of CPU you have.
The I/O system is important. As you fill the 2G InnoDB log file, the dirty pages from the buffer pool must flush to disk. Using a fast directly-attached disk system like NVMe can help. Using a striping RAID-0 or RAID-10 can help. Using remote storage (for example AWS EBS) is bad for latency.
Using minimal indexes in your tables can help. Think about every row write being multiplied by the number of indexes in the table. The table itself is stored as a clustered index, and that's one write. Then each secondary index is an additional write. Unique indexes must be synchronous writes (though if you set unique_checks=off, this is relaxed). Non-unique indexes can be deferred by change buffering, but they do need to get merged into the tablespace eventually.
Instead of loading a .sql file, it could be much faster to use
LOAD DATA [LOCAL] INFILE. See my presentation Load Data Fast!. But you can't use that with .sql dump files. It's for CSV files and similar.
Loading multiple tables in parallel using
LOAD DATA [LOCAL] INFILE is probably the best you can get for bulk loading large data sets. This is the idea behind the MySQL Shell Parallel Table Import Utility.
See an evaluation of parallel table import here:
To get any faster, you'd have to resort to physical backups instead of dump files (i.e. Percona XtraBackup), or filesystem snapshots.