Semantic search over your data
Embed documents and query by meaning — the same tech powering Inferix search.
See where keyword search fails and embeddings do not.
- Search Inferix for an exact model name. Keyword matching handles this perfectly well.
- Now search for a description instead — something like "model that turns speech into text" without naming Whisper.
- The second query only works if meaning is being matched rather than characters.
- Open the multilingual embedding model above and note its dimension count: that is the length of the vector each document becomes.
What you should see: Keyword search wins on exact identifiers and loses on paraphrase. Most real systems run both and merge the results, rather than choosing.
RAG with an open model
Retrieve context and ground an LLM’s answers, served on your own endpoint.
Diagnose a RAG failure properly, by separating retrieval from generation.
- Ask your system a question it gets wrong.
- Look at the chunks it retrieved, before the model saw them. Was the answer present in any of them?
- If it was absent, the fault is retrieval — fix chunking, or add a reranker to reorder candidates by relevance.
- If it was present and the model still answered wrongly, the fault is generation — tighten the prompt to forbid answering beyond the supplied context.
What you should see: Most "the LLM hallucinated" reports are retrieval failures. Looking at the retrieved chunks first tells you which half to fix, and saves rewriting prompts that were never the problem.
Fine-tune → deploy in one flow
Train a model, then deploy the result to a live endpoint.
Get a baseline you can prove the fine-tune beat.
- Before training anything, run your evaluation set against the base model and write down the score.
- Train, then run the identical evaluation against the result.
- Compare. If the gain is small, check whether a better prompt on the base model closes it — that costs nothing to serve.
- Only deploy the fine-tune if it wins on your evaluation, not on training loss.
What you should see: Training loss falling is not evidence of a better model. Without the before number you have nothing to compare against, and it cannot be recovered afterwards.
Rent a GPU for a job
Spin up a verified GPU by the minute for a training or batch run.
Size and cost a rental before starting the clock.
- Work out the VRAM you need: weights, plus optimizer state and gradients if training — these commonly triple the requirement over inference alone.
- Open the Marketplace and check what is available and its hourly rate.
- Estimate your runtime, then add margin for setup, data transfer and at least one failed attempt.
- Multiply out. Billing runs while the machine is up, including while you are debugging, so plan to tear down promptly.
What you should see: Training memory is far larger than inference memory for the same model — that surprise is the most common cause of a rental that OOMs after ten minutes of paid time.