In the credit card processing context, iframe solutions refer to a setup where your web site uses an iframe to cause customers to interact with your processor's site when entering their credit card details. So it's not so much a solution you'd implement yourself, as a way that you'd open a window from your site to your processor's implementation for accepting credit card data.
That means that the credit card details go to your processor, not to you. As such, you generally also need some form of tokenization, otherwise the processor is just making that card data accessible back to you for the purposes of repeated payments, recurring payments, chargebacks, &c. &c. (and if they share that back to you, your PCI scope is un-reduced). Tokenization is their way of allowing you to leverage the card data they gather without putting your systems into scope.
So, iframes and tokenization go hand in hand. You can have one without the other, but if you do, you don't get the level of scope reduction you wanted in the first place.
Now, these questions that you're asking, they can only really be answered by your processor. Your processor should be able to tell you how to integrate with their iframe (or equivalent*) solution, and what the costs are for that and the costs for tokenization. It may just be me, but the tone of your question suggests you're wondering how to implement this yourself, when you can't - the whole purpose of these solutions is to shift your PCI scope off to your processor. QED, you need to work with your processor to find out what they offer and how to implement it.
P.S. You'll still need to complete the SAQ A, even with one of these solutions - you'll never "need not worry about PCI compliance at all", you always have to worry about PCI compliance if you accept credit card payments. You'll just have a 15-ish question questionnaire to fill out instead of a 300-ish.