> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/roboflow/roboflow-hi/train/model-ids.md).

# Model IDs

हर प्रशिक्षित model का एक model ID होता है जो उसे पहचानता है जब आप उसे deploy करते हैं, inference चलाते हैं, या Workflow model block में उसे चुनते हैं। यह पृष्ठ model IDs की वर्तमान संरचना का वर्णन करता है, साथ ही यह भी कि कुछ परिस्थितियों में ID का एक पिछला (legacy) format अभी भी कैसे समर्थित है।

## Model ID संरचना

एक model ID का रूप होता है `{workspace}/{model-slug}`. पहला भाग आपका Workspace URL slug है। दूसरा भाग, model slug, workspace के भीतर मॉडल की पहचान करता है और हाइफ़न से जुड़े चार भागों से बना होता है:

```
{project}-{version}-{architecture}-t{n}
```

* `project`: उस project का URL slug, जिससे मॉडल संबंधित है। उदाहरण: `construction-safety-xpv3w`.
* `संस्करण`: dataset version का नंबर, जिस पर मॉडल प्रशिक्षित किया गया था। उदाहरण: `12`.
* `architecture`: प्रशिक्षण के लिए उपयोग की गई model architecture। उदाहरण: `rfdetr-small`.
* `t{n}`: उस version के लिए एक training counter। version पर शुरू हुई पहली training t1 होती है, दूसरी t2, और इसी तरह आगे।

उदाहरण के लिए, URL slug वाले किसी project के version 3 पर दूसरी RF-DETR Small training `construction-safety-xpv3w` workspace में `my-workspace` इस model ID को उत्पन्न करती है `my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2`.

model slug training शुरू होने पर असाइन किया जाता है, इसलिए आप यह ID देख सकते हैं कि किसी model का क्या होगा, जबकि वह अभी training में ही हो। Training counter suffixes कभी दोबारा उपयोग नहीं किए जाते: अगर कोई training विफल हो जाती है या रद्द कर दी जाती है, तो उसका नंबर छोड़ दिया जाता है और version पर अगली training को अगला नंबर मिलता है।

एक [Neural Architecture Search](/roboflow/roboflow-hi/train/neural-architecture-search.md) training कई candidate models उत्पन्न करता है। NAS candidate model IDs अन्य model IDs जैसे दिखते हैं, लेकिन अंत में एक double hyphen और 6-अक्षरों का hash जोड़ा जाता है (उदा.: `my-workspace/construction-safety-xpv3w-3-rfdetr-nas-t1--9589f2`). v2 trainings endpoints में, एक NAS training अपना `modelType` के रूप में `rfdetr-nas-parent`, जबकि उसके प्रत्येक candidate model में `rfdetr-nas`.

## Model ID खोजें

आप web UI, REST API, या Roboflow MCP Server के माध्यम से किसी भी प्रशिक्षित model का ID देख सकते हैं।

{% tabs %}
{% tab title="Web UI" %}
अपने project sidebar में "Models" पर क्लिक करके [Models page](/roboflow/roboflow-hi/train/view-trained-models.md). हर model अपने ID को "ID:" label के पास दिखाता है, और उसके पास "Copy Model ID" button होता है। वही ID और copy button model के detail view में तथा हर version page पर models table में भी दिखाई देते हैं।
{% endtab %}

{% tab title="REST API" %}
यह [Project Models सूचीबद्ध करें](/developer/rest-api/list-project-models.md) endpoint project में प्रशिक्षित हर model को लौटाता है। `url` response की प्रत्येक entry का field model ID होता है:

```
GET https://api.roboflow.com/{workspace}/{project}/models?api_key=YOUR_API_KEY
```

```json
[
  {
    "url": "my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2",
    "version": "3",
    "modelType": "rfdetr-small",
    "train": { "status": "finished" },
    ...
  },
  ...
]
```

किसी विशिष्ट version पर प्रशिक्षित models खोजने के लिए, v2 trainings endpoints का उपयोग करें। किसी version की trainings सूचीबद्ध करने पर हर training उसके द्वारा उत्पन्न models के IDs के साथ उसकी `modelIds` field में लौटाई जाती है। legacy single-model version पर, training का `id` इस रूप का एक path होता है `{workspaceId}/{version}/training/0` (नीचे दिखाए गए hash के बजाय), और `modelIds` version के [legacy ID](#legacy-model-ids) इसके बजाय:

```
GET https://api.roboflow.com/{workspace}/{project}/{version}/v2/trainings?api_key=YOUR_API_KEY
```

```json
{
  "trainings": [
    {
      "id": "0a1b2c3d4e5f67890abc",
      "versionId": "3",
      "status": "finished",
      "modelType": "rfdetr-small",
      "modelIds": ["my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2"],
      ...
    },
    ...
  ]
}
```

एक single training प्राप्त करने पर per-model details मिलती हैं, जिनमें प्रत्येक model का ID उसकी `modelId` field में `models` list. आप `trainingId` को छोड़ सकते हैं जब version में केवल एक training हो, लेकिन यदि version में multiple trainings हों, तो ऐसा अनुरोध 409 error के साथ विफल हो जाता है।

```
GET https://api.roboflow.com/{workspace}/{project}/{version}/v2/trainings/get?api_key=YOUR_API_KEY&trainingId={trainingId}
```

```json
{
  "trainingId": "0a1b2c3d4e5f67890abc",
  "versionId": "3",
  "status": "finished",
  "modelType": "rfdetr-small",
  "modelCount": 1,
  "models": [
    {
      "modelId": "my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2",
      "modelType": "rfdetr-small",
      "status": "finished",
      "metrics": { ... }
    }
  ],
  ...
}
```

{% endtab %}

{% tab title="MCP" %}
यह [Roboflow MCP Server](/developer/mcp-server.md) ऐसे tools प्रदान करता है जो model IDs लौटाते हैं। `models_list` एक project के प्रशिक्षित models की सूची देता है (workspace connection की credentials से आता है, और project को `project_id`) के रूप में पास किया जाता है, और प्रत्येक model का ID उसके `url` field में लौटाता है, version या NAS run द्वारा वैकल्पिक filtering के साथ। `trainings_get` और `trainings_list` हर training द्वारा बनाए गए models के IDs लौटाते हैं। Agents इन IDs को अन्य tools, जैसे `models_infer`.
{% endtab %}
{% endtabs %}

## Legacy Model IDs

पहले, Roboflow dataset versions पर केवल एक training run हो सकता था, इसलिए models की विशिष्ट पहचान इस रूप के ID से होती थी `{project}/{version}`.

उदाहरण के लिए, `construction-site-safety/3` से संकेत करता था *उस* project के version 3 पर प्रशिक्षित model। पहला भाग project URL slug है, workspace नहीं, और दूसरा भाग version number है। पुराने SDKs, code snippets, और Inference installations यही format उपयोग करते हैं (उदा.: `model_id="construction-site-safety/3"`).

चूंकि अब [एक से अधिक training](/roboflow/roboflow-hi/train/versions-trainings-and-models.md) dataset version पर, इसलिए legacy-format IDs अब पसंदीदा नहीं हैं। यदि आप 30 जून 2026 के बाद शुरू की गई नई trainings के लिए ऐसे IDs का उपयोग करने की कोशिश करते हैं, तो वे पर्दे के पीछे नए style के ID में resolve हो जाएंगे।

## Legacy IDs कैसे resolve होते हैं

Legacy-format IDs aliases के माध्यम से काम करते रहते हैं। जब किसी version पर शुरू हुई पहली training सफलतापूर्वक पूरी हो जाती है, तो Roboflow version के legacy `{project}/{version}` ID को नए model ID से लिंक करता है। जो requests legacy ID का उपयोग करती हैं, including older Inference installations से weights downloads, वे स्वतः उसी model पर resolve हो जाती हैं।

alias केवल *पहली* training द्वारा बनाया जाता है और बाद में नहीं बदलता:

* यदि पहली training सफलतापूर्वक पूरी होती है, तो legacy ID स्थायी रूप से उसी model को संदर्भित करती है, भले ही आप उसी version पर और models train करें। बाद के models को उनके अपने model IDs से संदर्भित करें।
* यदि पहली training विफल हो जाती है या रद्द कर दी जाती है, तो कोई alias नहीं बनाया जाता, और version पर बाद की trainings भी कोई alias नहीं बनातीं।

जिस version के पास alias नहीं है, उसे फिर भी उसके legacy ID से संदर्भित किया जा सकता है, बशर्ते उसमें ठीक एक model हो। यदि उसमें कई models हों और कोई alias न हो, तो legacy ID का उपयोग करने वाली requests विफल हो जाती हैं क्योंकि reference अस्पष्ट होता है, और आपको model का अपना ID उपयोग करना होगा।

{% hint style="info" %}
Legacy IDs पिछड़ी संगतता के लिए मौजूद हैं। नई integrations में पूरे model IDs को प्राथमिकता दें: वे स्पष्ट होते हैं और version पर हर model के लिए काम करते हैं।
{% endhint %}