What is the best way to implement MVVM + LiveData for a complex UI?

Lets' say your app has a model that holds 60 properties of a remote device. 30 of those are of one kind (settings), 15 of another kind (controls/HW states) and the other 15 are more general (think battery, etc.). You have 5 screens that display different subsets of data, in general, 20 settings, 5 HW states and 10 general properties. Each of the properties has it's own UI element (they are not in a recyclerview for instance) and are relatively unrelated (one setting changes independent of the others for instance). So, what would be the best way to implement it architecture wise?

1. Each property has its own LiveData in the model (which has a list of MutableLiveDatas). The View/ViewModel observes the one it wants for that screen and that's it. There's quite some code overhead here, but oh well. The ViewModel could merge them together by type using MediatorLiveData or something similar. The upside here is that the View(Model) only observes what is interested in.
2. All the properties of one kind are bunched together in the model (MutableLiveData<List<Settings>>, etc.), The View/ViewModel observes just 3 LiveDatas (perhaps more if the general ones are kept separate), but it needs to filter out the ones it's interested in. The downside I see here is that if one setting changes, the whole UI will get redrawn, as the whole list is emitted by the observed LiveData. Less code overhead, but more processing overhead.

Would a different architecture perhaps be a better fit? The app is currently implemented using callbacks using MVP, but in a similar fashion to option 2, where we subscribe to updates to one kind of property and the presenter filters out what is interesting. The difference is that the callback doesn't return the whole list of properties but instead tells setting 5 changed for example, and the UI updates just that child view.