AI generatedThe AI Platform is the module of Crowdee where you finetune small, open-source language models on data you already have — labels a Data Platform dataset exposes, or accepted answers a Crowd Platform job produced. It is the third of the three Crowdee platforms, sitting on top of the Crowd Platform's labelled output and the Data Platform's versioned datasets, and it is the place where a labelled entity becomes a model that you can call from your own code.
This is not a frontier-scale model training platform. It is a finetuning platform for small, open-source base models — Qwen, Ministral, Granite, Gemma, and others — that you can run on modest hardware, that you can host yourself, and that you can inspect line by line. The whole point of the AI Platform is that the model you get out is something you own: no third-party API, no opaque weights, no licensing that bites you when you scale.
The AI Platform is the answer to "I have a labelled dataset, and I want a model that I can run myself, on my own hardware, on my own data, with an audit trail that I control." If your need is "I want a hosted GPT-5 wrapper" you don't need this. If your need is "I want a reproducible, self-hostable, small open-source model finetuned on my own labels," the AI Platform is the surface that was built for that.
The AI Platform does not generate labels. It consumes labels you already have. There are two input sources, and they correspond to the two platforms that produce label data on Crowdee.
The first source is a Data Platform dataset version. When a dataset is the result of a cleaning or language-tech pipeline run, or a Crowd Platform job whose accepted answers were stitched back into the dataset, you have a versioned training set. The AI Platform reads that version, pairs the inputs with the labels, and treats the result as a finetuning corpus. The version reference is what makes the run reproducible — re-run the finetune tomorrow against the same version and you get the same model (assuming the base model and the platform haven't changed).
The second source is a Crowd Platform job's accepted answers directly. When a job is finished and the answer set is stable, you can point the AI Platform at that job and have it assemble the corpus from the answers. The same job-version audit trail applies: the finetune is reproducible against the crowd job's accepted-state.
This is the property that distinguishes the AI Platform from a generic finetuning service. The data is data you already curated on the Crowd Platform or the Data Platform; the model is a model you can pull queries from your own model registry after the run. There is no third-party data store sitting in the middle.
The AI Platform exposes six base models today, all small, all open-source, all chosen so they can be hosted on commodity hardware. Five are licensed under Apache 2.0; the sixth is under the Gemma Terms of Use, which is permissive but not Apache. All six come from established families (Qwen, Ministral, Granite, Gemma) and bring different parameter counts and context windows to the table.
The Qwen 3.5 family ships in three sizes — 0.8B, 2B, and 4B parameters — all with a 256,000-token context window. The smallest is the right starting point for short-classification tasks where you want a model that almost certainly fits on a single GPU; the 4B is the upper end of the family where you stay inside the "small open-source" envelope. The Qwen 3.5 family is the most-used base in the catalog right now.
The other three families complement it. Ministral 3 3B and Granite 4.1 3B target the same 3B-class parameter count with different training-data lineages; Gemma 4 E2B is the 2.3B Gemma variant under its own license. Each model is a deliberate choice when you commit to a finetune — the model's training data lineage, license, and context window are all material to the resulting system. The catalog entry exposes all of that; you pick the model that fits the constraint, not the one someone else picked for you.
A finetune run is a LoRA finetune: the base model is frozen, a low-rank adapter is trained on top of your data, and the resulting adapter is what you call from your model registry. The training compute is what you pay for, not the inference, and the credit cost is a flat upfront figure per run, not a metered compute bill that surprises you at the end of the month.
A run takes a few parameter inputs: the base model slug, the source dataset version or crowd job, the LoRA rank (and a few derived hyperparameters you can override), and the destination model name in your registry. The platform tracks every parameter. The catalog entry, the source version, the LoRA rank, the resulting model — all persist together, so the audit trail from "this model answered that question" back to "this is the source data and the base model it was finetuned on" is one join.
The finetune worker runs on Crowdee-operated infrastructure. The actual training happens on a separate Python worker (finetune-worker), not inline in the API, so the long-running compute is decoupled from the request path. You can monitor progress from the platform dashboard without a polling loop, and the resulting adapter is available for query the moment the run finishes.
The model that comes out of a finetune is a model you should not trust in production yet. The step that earns that trust is the same crowd-rating flow used for any AI system's output: you submit a batch of the model's outputs on a validation set, the crowd rates them on the dimensions that matter for your use case (typically clarity, evidence, actionability, and bias risk), and the aggregated score is the benchmark.
This is the property that closes the loop on the three platforms. The Crowd Platform produces the labels; the Data Platform versions the dataset; the AI Platform produces the model; the Crowd Platform, again, produces the rating that tells you whether the model is good enough to use. The same primitive — workers answering a structured survey — is the input to the finetune and the output of the benchmark. There is no new methodology to learn between the two phases.
If the benchmark scores the model well, you ship it. If not, the same audit trail that recorded the finetune tells you what to change: a different base model, a different dataset version, a different LoRA rank. Each iteration is a new finetune run with its own registry entry, and the benchmark is the same scoring flow. You are not switching tooling between iterations; you are running the same pipeline.
The AI Platform is the right surface when you have labelled data, a self-hosting requirement, or a license requirement that a hosted model can't satisfy. Compliance teams that need all model weights and inference to stay inside EU infrastructure. AI/ML teams that need a reproducible model for a downstream pipeline they own. Public-sector teams that need a model with a permissive license and a clear training-data lineage. Newsroom teams that need a model that can run on premises and never call out to a third-party API.
If your need is "use a hosted model for a one-off task," a hosted model is faster and cheaper. If your need is "I want to own the model that runs in my pipeline, and I want the data, the weights, and the audit trail to all live in my tenant," the AI Platform is the surface that was built for you.
To see the model registry on a live tenant, take a look at the AI Platform overview. To discuss a real finetune against your data, book a demo call — we'll walk through your dataset, the base model that fits it, and the LoRA setup that ships fastest.
