Data mining models are pretty lightweight in comparison to cubes or tabular models. Typically, after processing, you have a cache of processed structure data, which you can clear to eliminate if necessary. There is also a small set of metadata and statistics stored as the model content. But if you have a lot of models on a server, it could add up.

Here's the relevant information from the BOL topic on mining structures:

A mining structure is just a metadata container until it is processed. When you process a mining structure, Analysis Services creates a cache that stores statistics about the data, information about how any continuous attributes are discretized, and other information that is later used by mining models. The mining model itself does not store this summary information, but instead references the information that was cached when the mining structure was processed. Therefore, you do not need to reprocess the structure each time you add a new model to an existing structure; you can process just the model.

You can opt to discard this cache after processing, if the cache is very large or you want to remove detailed data. If you do not want the data to be cached, you can change the CacheMode property of the mining structure to ClearAfterProcessing. This will destroy the cache after any models are processed. Setting the CacheMode property to ClearAfterProcessing will disable drillthrough from the mining model.

However, after you destroy the cache, you will not be able to add new models to the mining structure. If you add a new mining model to the structure, or change the properties of existing models, you would need to reprocess the mining structure first. For more information, see Processing Requirements and Considerations (Data Mining).

Development lead Raman Iyer provided this useful tip for calculating how big this model content and metadata actually is in terms of disk storage:

As an admin, how do I calculate the total disk space taken up on the server by a mining structure?

A large part of mining structure data is stored in internal OLAP objects (system cubes and dimensions) created by Analysis Server when you create and process a mining structure. In order to calculate the total disk space used by a mining structure, you must include the space taken by these internal objects as well.

These objects have IDs beginning with the ID of the mining structure followed by “ ~MC”.

However, if the ID of the mining structure exceeds 36 characters, the mining structure’s internal ID is used instead of the ID. You can find the internal ID of a mining structure by opening the mining structure’s XML file and locating the value of the InternalID element under MiningStructure. In the example below, this file would be MyStructure.*.dms.xml.

Assuming your server’s data folder is C:\Data and the mining structure “MyStructure” is located in the “MyDB” database, you would include the following files and folders in your size computation:

C:\Data\MyDB.*.db\MyStructure.*.dms.xml

C:\Data\MyDB.*.db\MyStructure ~MC*.xml

C:\Data\MyDB.*.db\MyStructure ~MC*.xml

C:\Data\MyDB.*.db\MyStructure.*.dms\*.*

C:\Data\MyDB.*.db\MyStructure ~MC*\*.*

Note: The asterisk * represents a version number, which changes whenever a mining structure is altered.
 
Mining models contained within the mining structure “MyStructure” are stored under the “MyStructure.*.dms” folder and their storage space is included in the above computation.

Thanks to Raman for the tip. Thanks also to Ravishankar M for asking an excellent question!