It seems to me that you are a little confused about the terminology from different patterns.
If we consider OOP patterns of APPLICATIONS (MVC, MVP, MVVM), then in them View is the GUI, and the Model is a layer working with real data, processing it, containing Business Logic.
This layer is universal and independent of the type of GUI used, and even of its presence or absence.
From the point of view of these patterns, any action with real data (including saving it) is a function of the Model.
But the Model itself is not one specific type, but a whole Application layer, which can even be implemented separately within the other Application (for example, a service running in the background without any GUI).
Therefore, the Model itself can be implemented in the form of many additional types: a core with Business Logic (it is under it that they most often mean the Model in the narrow sense of the term), Repository, services, etc.
A little confusion here is introduced by the fact that in some patterns (ADO, EF, etc.) the term Model is also used to denote some entities.
Let's say this is often used to denote the type EF reflecting a record in the database table.
From the point of view of MVC / MVP / MVVM patterns, these are not models, but entities: Database Entity, EF Entity, Business Entity, etc.
The model provides consumers not with real data (that is, not Business Entities), but already some kind of reflection of them (very often these are immutable DTOs).
Therefore, the answer to your question: Saving data is a function that MUST be implemented only in the Model. "Inside itself" the Model can deligate this to some of its separate parts, for example, the Repository.
ViewModel is also a MODEL. But it is designed to work with a certain type of View, so it must take into account the peculiarities of this type of View, its requirements.
For example, a ViewModel for WPF (this is almost always the case), must provide the Data necessary for the View in its properties, notify about a change in its state using the INotifyPropertyChanged, INotifyCollectionChanged, Icommand, IDataErrorInfo interfaces and other requirements.
In this case, the "real" Model serves as the data provider for the ViewModel.
Therefore, the ViewModel does not work with real data, but with its abstract reflection.
And "knowledge" about real data (including how and where to store it) is not available for the ViewModel.
Since you need to provide the user in the GUI with a way to explicitly save data, this must be implemented as a command in the ViewModel, which calls the required Model method in its executing method.
In this case, the Model means the entire corresponding layer.
That is, it is not necessarily the main part of the Business Logic Model.
It can be, for example, some kind of service that is part of the Model layer.
It should be understood that very often in practice deviate from the ideal MVVM implementation. Therefore, in practice, you can often see leakage in the ViewModel of non-specific functionality, both from the View side and from the Model side.
Even if you have to do this to simplify the implementation, then you must clearly understand that this is a deviation from MVVM, and although you implement some specific function in the ViewModel, in fact it is a function of the Model (or View).
On your second question.
The MVVM pattern is hierarchical: the top level is View, below it is the ViewModel, and at the bottom level is Model.
In such a hierarchical structure, the overlying layer possesses knowledge only about the underlying one.
That is, the View is "familiar" only with the ViewModel, and the ViewModel only with the Model.
And the Model, in general, does not "know" anyone.
The application itself (the App class) is not part of the MVVM pattern.
It is located, as it were, above all the layers and therefore "knows about everyone."
Usually, in application (maybe not in the App class, but at this level), layers are initialized, dependencies are created and injected, and other tasks are common for the entire application.
"Notice" in .Net refers to events.
To receive notifications from someone, you need to subscribe to the event of this object.
And for this you need to be "familiar" with it, that is, to have a link to it.
But the underlying layers are not familiar with the overlying ones.
Therefore, neither the ViewModel, let alone the Model, can subscribe to View events.
But there is no need for such a notice for the View.
Notifications are needed where the object wants to provide information about its change, but it does not know who needs it.
Those who want to receive such information subscribe to the events of the object themselves.
But the View "knows" who it wants to notify - this is the ViewModel.
Therefore, the View simply calls the required ViewModel method and passes the required parameters to it.
This is most commonly done in WPF by binding to a command-property in the ViewModel.
P.S. The article "The Model-View-ViewModel Pattern" presents a point of view that is very close to the one I have stated here, but in much more detail.
You may find it helpful to read it.
Quoting from this article:
Model
Model classes are non-visual classes that encapsulate the app's data. Therefore, the model can be thought of as representing the app's domain model, which usually includes a data model along with business and validation logic. Examples of model objects include data transfer objects (DTOs), Plain Old CLR Objects (POCOs), and generated entity and proxy objects.
Model classes are typically used in conjunction with services or repositories that encapsulate data access and caching.
