I tend to consider that if you are modelling something, it's because you have a need of some kind to be satisfied.
Since needs can be at different levels, models have different levels too.
For example, if we are trying to depict a "logical" solution to a problem (how will we solve this, maybe using package or "expected" component diagrams along with responsabilities), we will not need the nitty gritty details of the "design" of a product providing the solution (classes, sequence diagrams, text).
At one point in time, there is mapping occuring. The logical model gets mapped onto the so-called technical architecture.
This is where things get weird. It's already difficult to get this mapping to work with the real software that explaining all the details becomes really useless. The only place where detailed modeling pays off is for domain models and business logic, not for detailed technical elements, which are much more quickly done and understood in looking at the code.
On that respect, a good "model" we use successfully is a barebone code sample that everybody can look at and try before getting into the real system. This sample and its "how-to's" and sketchy diagrams becomes the design model in a way.
