Hi Paolo! I’m currently working on graph mode quantization (along with other people, of course), so I’ll try to shed some light on what we have in our plans.
As you noticed, quantization can be implemented as a jit pass. But we consider this as one of two modes of how quantization could be done.
The first mode is called eager mode quantization, where the user is expected to structure their model into submodules and insert quantization stubs manually. This way they completely control the quantization process and can fine-tune the results (and also it can be applied to non-scriptable models). The drawback of this approach is that the user needs to edit their model.
The second mode is called graph mode and it is based on jit. It’s more than one pass, but the idea is the same as you described: a user scripts/traces their model, passes it to some black-box quantizer and gets a quantized version of their model as a result.
In graph mode we roughly expect the following passes:

inserting instrumentation nodes for collecting runtime statistics (aka observers)
replacing quantization/dequantization nodes into the model
fusing dequantize-some_op-quantize patterns to quantize_op

There are actually more more-specific pass than these three, however these should give you an idea of what functionality would be there. As we work on those passes, we’re trying to build them on top of generic features that could be useful for other purposes as well (for instance, several months back we implemented subgraph-matcher and subgraph-rewriter to facilitate fusion of arbitrary graph patterns). We probably will add some features to facilitate transformations on module level (rather than on a graph, or function, level), but the specific details are still TBD.
I think you might help us trying out API as soon as it’s ready and letting us know if the the workflow makes sense for you and covers your use cases.
For now please stay tuned, we’re actively working on it and expect to show something soon!