innodb_thread_concurrency seems evil as it enlarge table size by big factor
I suspect I will get down-voted for this Answer, but I think these things need to be said.  (And, no, I don't know the specific reasons for the strange sizes.)

Two simplified replies:


InnoDB plays a lot of games in its attempts to trade off speed and space.
Benchmarks rarely reflect anything in the real world.


Some factors (including possible explanations):


When there are multiple inserts into one table, InnoDB takes effort to minimize the impact of one insert on the other -- this may involve premature block splits, duplication of rows awaiting commits, MVCC, etc.
AUTO_INCREMENT is a bit tricky.  Your benchmark is relatively simpleminded.  In real life, there might be "burned" ids, leading to gaps in the values.  This is (I assume) a deliberate efficiency measure -- gain speed, but waste ids.  Note that there are various AI modes (see innodb_autoinc_lock_mode).
BTrees are inherently sloppy.  When a block is "split", it becomes two half-full blocks.  In the single-threaded benchmark this is not a big issue since there is no contention for the 'last' block.  And InnoDB has some optimizations for such.
BTrees are even more sloppy in the presence of MVCC -- since multiple copies of a row live for some time.
BTree blocks (in InnoDB) are not necessarily recombined promptly.
Allocation in in pages, extents, segments.  See here .  This can lead to megabytes of un-recouped space.  Furthermore, there is no 'visibility' into how much space is wasted at page/extent/segment level.
Concurrency of 100 (especially with only 12 processors) is asking for a lot of thrashing of locks in InnoDB.  Oracle, even with 5.7, does not brag above about 64.  I find that 100 leads to InnoDB stumbling over itself, and not necessarily finishing the benchmark any sooner than with a smaller number.  That is, excessive currency can lead to terrible latency without necessarily helping throughput.
10K rows may lead to an excessive use of the undo buffer (etc), thereby actually be slower than committing sooner.
Your "project will have billions of records" -- but how fast will they be inserted, and from how many different connections, and will they be batched or single-row inserted, etc.?
My take on high speed ingestion .


More (after Update 2)


innodb_buffer_pool_instances = 16
innodb_doublewrite = off  -- this may be safe since the drive and the page_size are the same.
SSDs make 150 individual inserts/sec not a problem
innodb_page_size=4k -- be aware that all tables will have to live with this.  It limits rows to under 2KB.  BTrees will be a little deeper, but I don't see that as a problem.
With the "delete after a year", I strongly recommend using PARTITION BY RANGE(TO_DAYS(...)) with 14 (monthly) or 55 (weekly) partitions.  This will make the deletes have essentially no impact.  A DELETE, even daily, would probably cause hiccups.  More discussion here .
How fast did the mysqlslap run (inserts/sec)?  Probably a lot faster than 150.  If your 150 is reasonably steady, then you will not experience concurrency=100, possibly rarely =10.  I don't see a problem ingesting your data.
If you need to 'normalize' (ex: country, etc) the data as you load it, see my ingestion link.
What are the SELECTs like?  They will be competing with the INSERTs.  I suspect 200 selects/sec, if they are point queries, could coexist with the inserts.  If you expect 1000, we need to think further.
With partitioning, if the excessive size persists, here is a fix...  REORGANIZE or REBUILD, not OPTIMIZE, a weekly partition after it is fully built.  That way, the excessive disk usage can be freed.  Be sure to use innodb_file_per_table before creating the table.