There's no way to know how exactly how much space an object will take in the platform cache with 100% confidence. This is because we are not gifted with any sort of tools that would be useful that way. We can't make an object into a Blob, for example, which would give us a crude byte count, nor can we depend on serialization to JSON being an accurate representation of the size-- in fact, I bet that JSON would drastically over-estimate the cost for any non-trivial object.
While writing this answer, I toyed with the idea of observing heap sizes before and after allocation, but I found that those values are dependent on things like if you use references versus copies, and the fact that the heap doesn't seem to respond as quickly as we'd like to (i.e. Limits.getHeapLimit() is merely a representation of a quick estimate of allocated memory including dead objects), so different means of allocating the object will result in different sizes being reported.
For example, I created an account three different ways, one by allocating strings directly into the object, one by allocating string references into the object, and one by JSON round-trip, and got the values 24, 37, and 102, respectively (two fields, one with 4 characters and the other with 9 characters). Some simple testing suggests that an empty account is 4 bytes of allocation, plus 6 bytes of allocation per standard field, and 15 bytes of allocation per custom field, and 4 more bytes for each non-null string reference. It'd be complicated to test any non-trivial object. It's way too easy to mess up the calculation of heap use once you start doing things like recursive method calls, etc.
Besides that point, I'm pretty sure that there's some special magic that occurs during serialization to the cache, so even if you had a precise count of in-memory bytes that an object consumed, that value would probably still be incorrect for the actual data amount consumed in the cache. For example, we don't know what other associated metadata would be stored with the object, if any sort of compression occurs, etc.
Honestly, I'd just go with @Ram's solution provided in the comments (to get the JSONified string length and consider that an estimate). Trying to get any more precise than that is probably impossible. I'd imagine that the JSONification process will probably add about 10-20% to the "true" size of the object as it would appear in the cache, since strings are not necessarily efficient, and there's lots of padding, quoting, etc that obviously isn't part of the memory of an object.