For the complete documentation index, see llms.txt. This page is also available as Markdown.

Model IDs

model IDs कैसे संरचित हैं और legacy project/version IDs models पर कैसे resolve होते हैं।

हर प्रशिक्षित 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 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 देख सकते हैं।

अपने project sidebar में "Models" पर क्लिक करके Models page. हर model अपने ID को "ID:" label के पास दिखाता है, और उसके पास "Copy Model ID" button होता है। वही ID और copy button model के detail view में तथा हर version page पर models table में भी दिखाई देते हैं।

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 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 उपयोग करना होगा।

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

अंतिम अपडेट

क्या यह उपयोगी था?