Discrepancy in CPU time and reads in SQL Server profiler
@DanGuzman correctly pointed you to Sommarskog's excellent article, which you should read.


Then, if the below simple steps don't work, try looking at the plan cache and seeing what's in there.  Or use the Query Store, since you're on SQL 2016, to see how many different execution plans there are.

You're comparing SET STATISTICS (anything) to Profiler.  Don't do that.  It doesn't work.  Profiler and Extended Events capture relatively accurate numbers.  SET STATISTICS (anything) does NOT - as a single example, it doesn't capture function cost!
You're trying to match plans done at different times, probably with different statistics.  Stop that.
Go ahead and update statistics for ALL tables involved in the suspect query, preferably with FULLSCAN, bother to see if that changes the behavior, and before your "run it myself" tests.
Look at the query itself.


Is parameter sniffing involved?
Is it thousands of lines long once reasonably formatted, with dozens of joins, often to the same table?  If so, quit having Entity Framework try to create complex SQL statements on its own.  It does a terrible job.