Add possibility to provide a model in chunks

[lantiga]

While testing on of the HuggingFace models (1.3 GB), MODELSET was failing due to the fact that Redis strings are limited to 512 MB.

This PR gives the possibility to provide a large model in chunks, overcoming the limitation (at the cost of a transient allocation + memcpy of a large chunk of memory, but for now there are no alternatives):

with open(model_filename, 'rb') as f:
    model = f.read()
chunk_size = 500 * 1024 * 1024
model_chunks = [model[i:i + chunk_size] for i in range(0, len(model), chunk_size)]
ret = con.execute_command('AI.MODELSET', 'm', 'TORCH', DEVICE, 'BLOB', *model_chunks)

Note that the API has been changed. One now has to specify BLOB to signal the start of chunks:

AI.MODELSET foo TORCH CPU BLOB ...

For consistency, the same was done for SCRIPTSET, with the addition of SOURCE:

AI.SCRIPTSET foo CPU SOURCE ...

@hhsecond: we need to update the Python client both with BLOB and SOURCE, as well as chunking (detect if blob is larger than 512 MB and chunk it tansparently)

[itamarhaber]

LGTM.

• We'll need to port the docs :/
• Semi-related - it would be good to add a few tests trying to load broken models. I managed to segfault IIRC by trying to load a file that I wgetted and was actually an HTML

[lantiga]

Thank you @itamarhaber.
What do you think about adding a FILE option, in addition to BLOB, where the file is loaded by Redis in a location relative to some configurable PATH?
This would have the advantage that RDB and AOF would just reference that one, without growing 1.3GB in size upon serialization.
It would make sense for really large models.

cc @filipecosta90

[filipecosta90]

What do you think about adding a FILE option, in addition to BLOB, where the file is loaded by Redis in a location relative to some configurable PATH?
This would have the advantage that RDB and AOF would just reference that one, without growing 1.3GB in size upon serialization.
It would make sense for really large models.

cc @filipecosta90

@lantiga imho that would break the entire idea around portability of the DB files, and open the door for more complex errors that I believe should not be a responsibility of the module. The module should use the persistency options provided by redis and allow as single point of entrance for data the commandHandler/commands. What do you think?

[lantiga]

@filipecosta90 that has always been my idea too. But these models are huge, so I was thinking about possible ways to anticipate RDB/AOF serialization issues.
I'm going to merge this now and we can think about it in the future (and the API now allows for it without further backward breakages).
I suspect this will come out as a request some of the use cases.

[filipecosta90]

@filipecosta90 that has always been my idea too. But these models are huge, so I was thinking about possible ways to anticipate RDB/AOF serialization issues.
I'm going to merge this now and we can think about it in the future (and the API now allows for it without further backward breakages).
I suspect this will come out as a request some of the use cases.

agree =)