Yes, given a random 92-bit string, you will on average need to perform $2^{92}$ MD5 calculations to find a password whose MD5 hash begins with that 92-bit string.
However, if the passwords are not salted before they're hashed, then attacking multiple password hashes in parallel is only slightly less efficient than attacking one hash. Indeed, if you only care about finding one of the passwords, having $n$ different hashes to target actually makes the attack about $n$ times faster.
Also, if the passwords are chosen by users, simply generating and testing strings that resemble common password choices will likely turn up the correct password in far less than $2^{92}$ attempts. While it's possible to generate and memorize a password with 92 bits of entropy*, few people will actually take the time to do that.
(If the hashing scheme is indeed just plain (truncated) MD5, you may also be able to just look up the prefixes in a precomputed table of MD5 hashes of common passwords, several of which can be found online.)
This, not the size of the theoretical keyspace, is the reason for the recommendation to use a key-stretching KDF (like PBKDF2 or scrypt or Argon2) for password hashing. Basically, it doesn't really matter if the hashes are 92 or 128 or 256 or 512 bits long, if the passwords they're computed from only have less than 30 bits of entropy.
*) For example, a seven word Diceware passphrase would have a little over 90 bits of entropy, while adding an eighth word would push it well over 100 bits.