GitHub user CRZbulabula added a comment to the discussion: Support for Timestral and Tirex-2 in AINode
Hi @kotselidis, thanks for sharing the additional context. The inference-placement experiment sounds useful. It would help to review the AINode model adapters separately from the DataNode/TornadoVM integration. One point worth checking before merging is the distinction between inference-code licenses and pretrained-weight licenses: - TiRex-2: Both the public inference code and [model weights](https://huggingface.co/NX-AI/TiRex-2/blob/main/LICENSE) are Apache-2.0, so this looks like a good candidate for an AINode PR, subject to the usual dependency and attribution review. - Timestral: The inference code is Apache-2.0, but the weights use a [Modified MIT license](https://huggingface.co/mistralai/Timestral-209M/blob/main/LICENSE). It withholds authorization when the company’s or employer’s global consolidated revenue for the preceding month exceeds USD 20 million, including for derivatives and combined works. This is a material restriction beyond standard MIT. We should therefore avoid committing to bundled weights or making them a required dependency. An optional integration using user-supplied weights could be assessed separately against the [ASF optional-dependency rules](https://www.apache.org/legal/resolved.html#optional), with PMC/ASF Legal guidance. The Apache-2.0 licenses of jitCast and TornadoVM do not change the weights’ terms. For the performance experiment, embedded inference could reduce RPC and serialization overhead. However, comparing embedded TornadoVM against remote PyTorch changes both the execution engine and deployment location. A co-located AINode baseline would help separate those effects. Using the same checkpoints, precision, context lengths, forecast horizons and batch sizes, it would be useful to measure cold-start and warmed-up latency, throughput, forecast accuracy, and the impact on concurrent database reads and writes. Separating queueing, serialization/RPC, host-to-device transfers and model execution would make the results especially informative. AINode’s process isolation and independent resource scaling also matter when assessing the trade-offs. There is also a runtime compatibility question: jitCast currently requires JDK 22+, while IoTDB’s Java baseline is 17. That deserves a separate design discussion alongside GPU resource management and failure handling. Please feel free to open the model PRs separately, including the exact upstream package/checkpoint versions and their licenses. That would let us review TiRex-2 while resolving the Timestral licensing question independently. GitHub link: https://github.com/apache/iotdb/discussions/19270#discussioncomment-19608101 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
