Choose a serverless model by task, not by slug

Choosing a serverless model starts with the task, not with a name that looks familiar. A catalog label may tell you what a model is called, but your application needs the exact identifier and request format that the service accepts.

Hostnot GPU lists 49 serverless AI models for chat, image and video requests. The catalog is the place to check which models are currently supported and what each is suited to. Treat its model slug as an API identifier, not as a name to reconstruct from memory.

Start with the job your application needs done

Write down the input your service receives and the output it must return. For a conversational feature, that may be a user message and a text response. An image workflow may need to interpret or generate image content. A video workflow may need to submit or process video. These are different request types; choosing a model from the right category is the first filter.

Then narrow the choice by the task itself. For chat, clarify whether the application needs a single answer, a conversational exchange, or another supported behavior. For image and video work, define what the application will send and what it expects back. Check the current model entry for capability and request details. Do not assume that two models in the same broad category accept identical inputs or return identical outputs.

Copy the slug; do not derive it

Once you have a candidate, take its model slug directly from the current Hostnot GPU catalog or documentation. A slug is the value your request uses to identify the model. It may not match the display name, and punctuation, capitalization or version details may matter. Guessing a slug from a label is a fragile shortcut: a request can fail, or target a different catalog entry than you intended.

Keep the display name and slug together in your application configuration. That makes it easier to review what you selected and to update the identifier if the supported catalog changes. Before deploying a change, check that the slug remains listed and that the model still matches the task.

Match the request format to the model

Hostnot GPU’s published chat example sends a POST request to serverless.hostnotgpu.ae/v1/inference/chat, with a bearer API key, an idempotency key and a JSON body containing a model slug and messages. In outline, the body includes a model value and a messages array. Use the documented chat contract for your selected model rather than copying this structure into an image or video workflow.

For image and video requests, consult the current API documentation and the selected model’s entry for the relevant endpoint, required fields and response format. Those details are not interchangeable with the chat example. Avoid sending guessed fields or assuming that a model slug alone determines how to format the rest of the request.

Keep credentials on your application server. Send the key as a bearer credential from server-side code, not from browser code where it can be exposed. Use a unique idempotency key for each logical request, following the API guidance, so retries can be distinguished from new work.

Test the smallest useful request

Before wiring a model into a user-facing feature, make one controlled request with a representative input. Confirm that the request identifies the intended slug, follows the matching API contract and returns the kind of output your application can handle. Test edge cases that matter to the product, such as empty input or an unusually long prompt, if the documented contract permits them.

Log the model slug and a request identifier alongside application-side results, but do not log secrets or sensitive user content unnecessarily. If the request fails, check the selected model and request shape against the current documentation before changing unrelated parts of the integration. A response that parses successfully is not enough if it does not meet the task’s quality or latency requirements; evaluate candidates with representative inputs.

Make selection an explicit application decision

Keep model choice in configuration rather than scattering literal slugs through application code. That makes it possible to compare candidates or replace one without rewriting request handling. Record why a model was selected, which inputs you tested and what output your application expects. Recheck the catalog when you revisit that decision.

If you are building a chat application, routing a LangChain chat app through serverless inference covers the application-side flow. For an image-focused service, the guide to a lightweight FastAPI vision pipeline provides related implementation context.

The practical rule is simple: choose by capability, verify the model entry, copy its exact slug and use the matching request contract. That sequence keeps selection tied to what the endpoint actually supports, rather than to an assumed naming pattern.