It sounds like you're thinking of AES-GCM-SIV as "AES-GCM with an SIV layer on top." It's not. Rather, AES-GCM-SIV is a separate encryption mode build out of similar (but not identical) components as AES-GCM, and where the components are combined in a different way. While AES-GCM-SIV is in some ways similar to AES-GCM, you can't actually implement AES-GCM-SIV as a wrapper on top of an existing library that implements AES-GCM.
What makes things a bit confusing is that there is also something called the generic
"SIV construction" that allows a nonce-misuse-resistant authenticated encryption mode to be constructed out of any conventional (non-authenticated) encryption mode meeting certain technical criteria plus any pseurodandom function (PRF) on the plaintext space. For example, AES-SIV (RFC 5297) is an instance of the SIV construction with AES-CTR as the encryption mode and CMAC* (a multi-input variant of CMAC) as the pseudorandom function, while AES-GCM-SIV is essentially an instance of the SIV construction with (again) AES-CTR as the encryption mode and POLYVAL (a variant of the AES-GCM pseudorandom function GHASH) as the PRF.
But that doesn't mean that you can just take an AES-GCM implementation and use it to implement AES-GCM-SIV, at least not without first pulling it apart into its component parts. And even then, the components of the two schemes (as standardized in their respective RFCs) differ in some details (like byte order; see RFC 8452 appendix A), so you can't just reuse the parts without modification, either.
Technically, I believe you could implement AES-GCM-SIV on top of GHASH and AES-CTR, if your crypto library exposes both of those directly. However, that would require implementing POLYVAL on top of GHASH, which, while technically possible, is somewhat awkward and inefficient due different byte orders used by the two hashes.