FELN Qwen: Train on RTX, Run on Jetson Orin
After teaching a small model to query the North Sea, I wanted to take the experiment onto a Jetson. Could I train on a powerful workstation, then move the model, application, and spatial database onto an NVIDIA Jetson Orin? And could it produce the expected FELN JSON accurately enough to be useful?
That is the experiment behind feln-qwen. The job is specific: translate a question about wells, pipelines, and discoveries into FELN. The JSON identifies the layers, their attribute filters, and the spatial relationships between them. Layer order matters. Finding pipelines near discoveries is a different request from finding discoveries near pipelines!
A huge thank you to Geodata for the beautiful NorthSea data. It gave this experiment a rich geospatial vocabulary and meaningful relationships to work with. I deeply appreciate the work and care behind this dataset.
I chose Qwen3.5-9B and first verified stock-model inference on the Orin. The target machine had to support the model before committing to a full training run. Training then used two RTX PRO 6000 Blackwell GPUs, while inference and spatial execution stayed entirely on the Orin. The Mac was the browser and SSH connection; the workstation was not an inference dependency.
The data builder reads FELN.json, Layers.json, and the Open Knowledge Format files. It validates the catalog, removes duplicates, and retains provenance. The final split contains 4,790 training, 673 validation, and 534 test examples. Related query families stay together, including literal substitutions and reordered secondary layers, so a close variant cannot slip across the split boundary.
I used BF16 LoRA with rank-32 adapters, keeping the base weights frozen and applying loss to the expected answer tokens. There was enough measured GPU memory to use this recipe without quantizing the training base. A smoke run preceded the two-epoch run, which took about 58 minutes of measured wall time. Validation selected the checkpoint. The training and deployment walkthrough records the settings and commands.
For deployment, the adapter was merged into the base model and exported to a text-only GGUF Q4_K_M file. The resulting file is about 5.63 GB, served by llama.cpp with a 4,096-token context and one request at a time. Quantization is a separate deployment decision, so I evaluated the actual exported file as well as the training checkpoint.
Now the part I was most interested in: the untuned Q4 model on Orin matched 96 of 534 expected FELNs, or 17.98%. The tuned Q4 model matched 530 of 534, or 99.25%, on the same held-out set and application prompt/grammar path. These results come from the exported GGUF tested on the Orin.
Here is the matched RTX–Orin comparison using the same tuned Q4 file and all 534 questions. These are measured model-endpoint timings, with requests sent sequentially. RTX inference used one GPU; training used both. Runtime build revisions differ and are recorded with the results.
| Measurement | RTX | Orin |
|---|---|---|
| Strict FELN matches | 530/534 (99.25%) | 530/534 (99.25%) |
| Warm median latency | 0.402 seconds | 3.221 seconds |
| Warm p95 latency | 0.644 seconds | 5.168 seconds |
| Requests per second | 2.426 | 0.303 |
RTX was about eight times faster in this workload, but the Orin retained the same accuracy. The strict comparison uses FELN.same after schema validation: equivalent SQL formatting is acceptable; a wrong field, enum value, or spatial relationship is not. The comparison and underlying reports are in the repository.
The application adds schema compilation and read-only DuckDB spatial execution. A separate 18-question sample covering the nine primary-layer/layer-count strata passed 18 of 18 end-to-end checks, with a warm median of 3.97 seconds. Sampled peak system-wide shared RAM usage was about 10.1 GiB. That is an application/database measurement and a system-memory reading, distinct from the model-only table above.
I also deployed FELN Studio on the Orin. Here it is generating the expected JSON for pipelines with a dimension over 20.0 that are within two miles of a condensate discovery. The screenshot was captured from the real application, with an exact-match verdict.
There are limits. These are held-out synthetic and source query families from one static catalog, not a production user study. Four test answers are still wrong, and complete Orin responses exceed one second. Studio provides generation and inspection; spatial GeoJSON comes from the separate application API. The services were restart-tested and subsequently stopped at my request, so the screenshot documents the verified deployment rather than a live public demo.
The code is now public under Apache 2.0 in feln-qwen, with data preparation, training, evaluation, serving, and measured results. Third-party models and data retain their own terms. I would like to test broader catalogs and more natural questions next. Fork the repository, explore the workflow, and let me know where you would take this in your GIS work. More to come!
Comments