Of course it has a "VM" (aka runtime system), providing services like thread scheduling, garbage collection, IO management and so forth. It might just not be an easily accessible standalone VM like the JVM.
> Compiles super fast
Because it doesn't do anything. Seriously, it compiles fast because the type system is so trivial. No type inference (except the really restricted (:=) thing. And I can't even have polymorphic functions -- which we've known how to type check for around 40 years now.
This is a serious drawback if you are interested in type system support for code reuse.
Virtual machines most certainly do not require bytecode.
GHC for example targets the "Spineless, tagless G machine" by compiling to native code that calls runtime services defined by the (abstract) STG machine ISA (the "primops").
Similarly, Go targets the Go runtime, by compiling to native code that calls "machine" services like collecting memory or scheduling threads. It might be a thin wrapper over the underlying processor architecture, but the compiler is clearly targeting the Go runtime as its target "machine".
The Go runtime does nothing what a machine does. Compiled Go code consists of pure, native machine code instructions, no special opcodes. It's just that some additional functionality is statically linked in.