As mentioned in previous comments and answers, there are 2 major scenarios and a few subscenarios... player hosted server and server hosted server being the major setups. However it makes little difference IMO because I feel that even for player hosted servers, the server portion of the code should be separated from the client code even on a player hosted configuration.
The next 2 questions concern how many players the server is designed to handle, and how authoritative the server is over the current state of the game. For small numbers of players (8-16) and a client authoritative design, the server can be little more than a message hub, taking in client packets and replicating them to the other players. For larger numbers of players, server hosts servers and some form of space partitioning on the server is needed so that you are only sending packets that are RELEVANT to each player. Server hosted is almost required at this point because beyond 8-16 players, even the best broadband connection to the net may not be enough for all the outbound network traffic being sent to the players... most network connections have much lower send speeds compared to receive.. for instance, my connection is 20mbits down, 2mbits up... so I can receive a lot more than I can send.
The last section talked about client authoritative design. In server authoritative designs for player hosted servers, the server code is typically very tightly integrated with the client code because the server needs access to the current state of everything that can move in the game, and needs to be at least somewhat aware of the physics of the game. For server hosted servers all of the object state, and at least some of the map state (that part required for setting up physics colliders and such) has to be replicated on the server.
You mentioned predictive motion, and that is a "feature" that can be layered on top of any of these scenarios, and basically involves having the clients and server running on a synchronized clock established when the player connects to the server.. movement update packets must have time stamps so that the client/server can say things like "if the object was HERE in the past, and is moving in this direction at a given speed, I compute where the object is NOW, and possibly where the object will be a short time in the future"... then the network layer kind of lies and tells the client code "the object is moving along this vector (direction/speed) from its current location" with that vector computed to put the object at the future computed location at the desired future time. None of the clients will see exactly the same motion of all the objects, but in general tracking will be smoother without annoying jumps because of network lag.
I found this presentation VERY informative and it might help make things more clear for you