If you are set on doing this, the ideal solution seems to me to use a Bloom filter of the known "bad passwords".
The advantage is that even in a compromise, you only leak information about the passwords of known/suspected bad actors, and you never directly leak any password hashes. In addition, a dense Bloom filter is very fast to search and can be sized to have a low false positive rate. Also, if the Bloom filter is sized for a 1 in a million false positive rate, then even an attacker who has been able to steal your Bloom filter will find all of the real "bad passwords" plus one out of a million of his/her random password guesses.
Let's say you have a 65,536 entry Bloom filter using 8 different hash functions. This will require just 8 kilobytes to store, and will hold more than exp(ln(1e-6)/8) * 65536 / 8 = 1,457 "bad" passwords before you hit a 1 in a million false positive rate.
The downside is that after you mark an account as bad, you'll need to wait until the next login into that account to add the password to the Bloom filter (this only time you see cleartext passwords), and after you add a "bad password" to the Bloom filter, you won't discover other accounts sharing the "bad password" until the next time they login.
The first problem can be easily overcome by expiring the cryptographic tokens/login cookies of a bad account, tricking the attacker into logging in immediately. Crypto tokens/login cookies should always contain a message-authentication-code-protected creation timestamp. This allows you to force periodic login and also keep a per-user earliestValidToken timestamp that you can bump up to the current time when they change their password (or if you need to expire their existing tokens for some other reason).
The second problem can be overcome using a combination of several methods. (1) It's good to make users login every 2 weeks to keep them from forgetting their passwords (2) you probably mostly care about new account creation using "bad passwords" (3) assuming most accounts become spammy soon after creation, when you discover a spammy account, you can expire the crypto tokens/login cookies of all accounts created in the past N days (or maybe all accounts created after the spammy account).
As far as how to get your 8 hash functions, you need 8 16-bit hashes, or 128 bits of hash output to cut into 16-bit chunks. You'll want your hash functions to use site-specific keys, to minimize the possibility of cross-site use of a stolen Bloom filter. Two invocations of Siphash-2-4 using two different keys is probably the fastest way to get your 128 bits of hash values. SHA-1 HMAC (truncate MAC to 128 bits) or AES CMAC are also perfectly acceptable.