C# and VB have runtimes, too. They're just DLLs... .NET MSIL assemblies. It just happens that the F# runtime is not a part of the .NET framework (it's a separate component), whereas the C# and VB runtimes are part of the framework (and thus are already installed as part of .NET).
(I don't know exactly what's in the VB runtime, I think a bunch of VB-specific functions. The C# runtime, Microsoft.CSharp.dll, is just used for dynamic, I think. The F# runtime, FSharp.Core.dll, has all kinds of stuff, like functions, lists, async, all the F# stuff that is not part of .NET proper.
Calling these things 'runtimes' is maybe a source of confusion, they're just "libraries", but without these libraries, you will be restricted to using only a subset of the language. In C#, without a runtime, you can't use dynamic. In F#, without a runtime, there is very little you can do, maybe define some classes and simple methods, but nothing using lists or higher-order functions or certain language constructs. Dunno about VB... I guess in general, a library should be labeled part of a 'language runtime' if the language's compiler will generate code that assumes that library is there. So .NET stuff like mscorlib.dll can probably be properly called part of the shared runtime of all the languages (e.g. to support things like the int keyword in C#) whereas other libraries are just there to support a specific feature of a specific language (like Microsoft.CSharp.dll to support dynamic).)
As aside-trivia, Visual Studio installs the F# Runtime because parts of the F# IDE integration in Visual Studio are written in F#, and thus VS needs F# to run. (The F# project system is partly authored in C#, partly in F#, and partly in VB.) Similarly, VS installs .NET 4.0, because a lot of VS components are written in C# and VB - there is a lot of managed code running inside VS.