1.7 KiB
Hugging Face Provider And Registry Shape
Last updated: dev@e57f60b | 2026-07-20
Scope
Canonical placeholder vendor ID huggingface; download/fit metadata in
services/hwfit/; OpenAI-compatible inference providers/TGI handled as their
serving dialect. There is no dedicated Hugging Face canonical reader on
current dev.
Hub Model Shape
Hub model info can provide modelId/id, pipeline_tag, tags, config, and
card metadata. Current canonical normalization does not map pipeline_tag,
config.model_type, or Hub task/modality fields. An explicitly selected
Hugging Face vendor uses generic identity-only normalization.
This source is cookbook_hf/registry confidence, not live endpoint truth.
Free-form tags, README/card prose, repository names, and architecture names do
not automatically claim capability. A serving engine can load a model with
missing projection, different template, or disabled parser.
Serving Shape
Hugging Face routed inference and TGI can expose OpenAI-compatible endpoints; their model list may be identity-only. Keep Hub identity separate from the serving endpoint and merge only when exact revision/model identity is known.
Fallback And Safety
Hub metadata can fill a scoped registry record after provider payload fields and probes, but must not overwrite fresh endpoint-negative evidence. Treat remote code, model cards, and repository files as untrusted content.
Current Gaps
- Revision/digest linkage between downloads, Hub records, and serving endpoints is incomplete.
- Hub task/family metadata is not consumed by the canonical reader package.
- Pipeline tags can be missing or overly broad; unknown stays unknown.