Refactor the llama.cpp interface

[rlouf]

In this PR I refactor the interface to the models provided by llama-cpp-python for the release of Outlines' v1.0. A few notable changes:

• I removed the lora method as it has been deprecated in llama-cpp-python
• We follow the init API of the library, with the default requiring a model path, and a from_pretrained classmethod that takes a repo name and filename.
• We don't try to normalize the arguments either to initialization or to text generation. Users can pass the same arguments as their would pass to the original model.

TODO

• Update the tests
• See if the class can inherit from Llama would make llama-cpp-python a hard dependency
• Update the LlamaCpp documentation
• Update the OpenAI documentation
• Update the Gemini documentation
• Update the Anthropic documentation

[rlouf]

@torymur this is ready for review

[torymur]

You only manipulating with self.output_description and don't assign self.model = model, which would fully redefine class attrs in __init__ and could be okay, but for such partial redefinition in @dataclass case I see people suggest __post_init__, which will be called after __init__? But I'm not sure here.

Overall, took me a second to understand this fork: APIModel <-> output type, Model <-> processor. I can't put my finger on it with a proper design idea, but the fact that we have two good matching pairs suggests a good potential for separation? Or not, if uniting is what's its for.

There is also a simplification of code, but it doesn't help to get the idea of what's happening (your example is much clearer on why), so I'm going to leaving it here just in case:

if isinstance(model, get_args(APIModel)) or output_type is None:
    self.output_description = output_type
else:
    regex_string = output_type.to_regex()
    self.output_description = RegexLogitsProcessor(regex_string, model.tokenizer)

[rlouf]

Yeah I agree, maintain a single interface for API-based models and local models is annoying.

One possible way out of this design issue is to have models build and hold the LogitsProcessor but it does feel unintuitive. The other solution is to add a Generator building function that dispatches to an APIGenerator and a LogitsProcessorGenerator, but I feel the duplication of code is not necessarily justified. It might be more a case of documenting the behavior better?

I'll see if I can come up with something better.

[torymur]

The other solution is to add a Generator building function that dispatches to an APIGenerator and a LogitsProcessorGenerator, but I feel the duplication of code is not necessarily justified.

Actually, this might be enough, I'd vote for duplications like this to make design more self-descriptive rather than bringing it on a higher level of clarifications in docs

[rlouf]

I made the change. It actually does not look like duplication so much, and makes the code much easier to follow.

[torymur]

It was worth it, crystal clear now 🔥

[torymur]

Sorry for delay!
Nice to see The Generator in docs & in the code 🔥 Left some minor comments, but overall LGTM! 🚀