Support non-Llama models

[terrytangyuan]

🚀 Describe the new functionality needed

We currently have a workaround to support non-Llama models through the remote vLLM provider but it would be great to support this officially.

For inline vLLM provider, this is work-in-progress: #880

Let's use this issue to discuss any proposals and technical considerations.

[sanderjson]

@sanderjson Stay tuned. until now we have exclusively supported llama models only, but we will be making a few changes to enable other models soon -- as early as next couple days. (last week)

#721 (comment)

[nathan-weinberg]

Should include updates to the Philosophy section here as well: https://llama-stack.readthedocs.io/en/latest/introduction/index.html#our-philosophy

[bbrowning]

Maybe enabling the usage of non-Llama generally as simple as removing the ValueError thrown here:

llama-stack/llama_stack/providers/utils/inference/model_registry.py

Lines 74 to 77 in df864ee

	raise ValueError(
	f"Model '{model.provider_resource_id}' is not available and no llama_model was specified in metadata. "
	"Please specify a llama_model in metadata or use a supported model identifier"
	)

At that point in the code we've checked the model aliases across the providers, didn't find a matching alias, so instead of raising the error we could just fallback to using the provided model.provider_resource_id and assume the user knows enough to register a model id that matches something valid in their backend provider.

That would let us still take advantage of the aliases for all well-known Llama models, but let users attempt to use other models that their providers support without throwing an error.

[terrytangyuan]

Non-Llama models are supported now in several inference providers (including remote vLLM) after merging #1200.