آموزش کامل NVIDIA Nemotron 3 Ultra؛ مدل قدرتمند Reasoning و AI Agent با API درواره

NVIDIA Nemotron 3 Ultra یکی از قدرتمندترین مدل‌های خانواده Nemotron است که برای استدلال پیچیده، برنامه‌نویسی، Tool Calling، پردازش Context طولانی و اجرای وظایف چندمرحله‌ای AI Agent طراحی شده است.

این مدل با ۵۵۰ میلیارد پارامتر کلی و حدود ۵۵ میلیارد پارامتر فعال از معماری Mixture of Experts یا MoE استفاده می‌کند. در این معماری لازم نیست تمام پارامترهای مدل برای پردازش هر Token فعال شوند؛ در عوض، تنها بخش‌های مرتبط با ورودی در هر مرحله فعال می‌شوند.

Nemotron 3 Ultra برای پاسخ‌دادن به سؤال‌های کوتاه روزمره ساخته نشده است. مزیت اصلی آن در وظایفی دیده می‌شود که به موارد زیر نیاز دارند:

• استدلال عمیق و چندمرحله‌ای
• بررسی تعداد زیادی سند یا فایل
• برنامه‌ریزی و اجرای وظایف Agentic
• استفاده مکرر از ابزارها
• تحلیل Repositoryهای بزرگ
• طراحی و بررسی معماری نرم‌افزار
• تولید گزارش‌های تحلیلی دقیق
• حفظ هدف در فرایندهای طولانی
• هماهنگی میان چند Agent
• اجرای Workflowهای سازمانی پیچیده

توسعه‌دهندگان ایرانی می‌توانند با استفاده از API درواره به این مدل متصل شوند و آن را از طریق یک API سازگار با OpenAI در پروژه‌های Python، JavaScript، TypeScript، PHP و سایر زبان‌ها به کار بگیرند.

برای مشاهده وضعیت ارائه و قیمت به‌روز مدل به صفحه مدل‌های درواره مراجعه کنید.

مشخصات NVIDIA Nemotron 3 Ultra

جزئیات مسیرهای فعال، Context قابل استفاده و محدودیت خروجی ممکن است براساس نحوه ارائه مدل متفاوت باشد. پیش از استقرار Production، مشخصات فعال را در فهرست مدل‌های درواره بررسی کنید.

خانواده NVIDIA Nemotron چیست؟

Nemotron نام خانواده‌ای از مدل‌های هوش مصنوعی NVIDIA است که برای کاربردهای Agentic، Reasoning، برنامه‌نویسی، بازیابی اطلاعات و پردازش وظایف طولانی توسعه یافته‌اند.

مدل‌های این خانواده معمولاً در سه سطح اصلی دسته‌بندی می‌شوند:

Nemotron 3 Ultra در بالاترین سطح این خانواده قرار دارد. بنابراین استفاده از آن برای تمام درخواست‌ها از نظر هزینه و Latency منطقی نیست. بهترین معماری معمولاً ترکیبی از مدل‌های مختلف است:

• مدل کوچک برای استخراج و طبقه‌بندی
• مدل متوسط برای Tool Calling معمول
• مدل Ultra برای برنامه‌ریزی، بررسی نهایی و مسائل پیچیده

معماری Nemotron 3 Ultra چگونه کار می‌کند؟

برای درک مزیت‌های این مدل باید چهار مفهوم اصلی معماری آن را بشناسیم:

1. Mixture of Experts
2. معماری Hybrid Mamba-Transformer
3. Latent MoE
4. Multi-Token Prediction

Mixture of Experts یا MoE چیست؟

در مدل‌های Dense، تقریباً تمام پارامترهای مدل برای پردازش هر Token استفاده می‌شوند. در مدل Mixture of Experts، شبکه از چند Expert تخصصی تشکیل شده و یک Router تعیین می‌کند کدام Expertها برای هر ورودی فعال شوند.

Nemotron 3 Ultra حدود ۵۵۰ میلیارد پارامتر کلی دارد، اما تنها حدود ۵۵ میلیارد پارامتر در هر مرحله فعال می‌شوند.

این طراحی تلاش می‌کند دو هدف را هم‌زمان دنبال کند:

• ظرفیت دانشی و استدلالی یک مدل بسیار بزرگ
• کاهش محاسبات نسبت به فعال‌کردن تمام پارامترها

عبارت 550B-A55B در نام مدل نیز به همین ویژگی اشاره دارد:

550B = تعداد تقریبی کل پارامترها
A55B = تعداد تقریبی پارامترهای فعال

معماری Hybrid Mamba-Transformer چیست؟

Transformerها در پردازش روابط پیچیده میان Tokenها بسیار قدرتمندند، اما Attention روی Contextهای بسیار طولانی می‌تواند هزینه محاسباتی و حافظه زیادی داشته باشد.

Mamba از خانواده State Space Model است و برای پردازش Sequenceهای طولانی با کارایی بهتر طراحی شده است.

معماری Hybrid تلاش می‌کند مزایای هر دو را ترکیب کند:

• لایه‌های Transformer برای Attention و روابط سراسری
• لایه‌های Mamba برای پردازش کارآمد توالی‌های طولانی
• MoE برای فعال‌کردن بخش‌های مرتبط مدل

این معماری برای Agentهای طولانی اهمیت دارد؛ زیرا تاریخچه گفتگو، خروجی ابزارها، اسناد و تصمیم‌های قبلی می‌توانند Context را به‌سرعت بزرگ کنند.

Latent MoE چیست؟

در معماری MoE معمولی، Tokenها مستقیماً به Expertهای مختلف هدایت می‌شوند. Latent MoE از نمایش فشرده‌تر اطلاعات برای Routing استفاده می‌کند تا پردازش میان Expertها کارآمدتر شود.

هدف این طراحی کاهش هزینه محاسباتی در کنار حفظ ظرفیت استدلالی مدل است.

برای توسعه‌دهنده‌ای که از API استفاده می‌کند، نیازی به مدیریت Expertها وجود ندارد. Routing داخلی بخشی از معماری مدل است و به‌صورت خودکار انجام می‌شود.

Multi-Token Prediction چیست؟

مدل‌های زبانی معمولاً Token بعدی را پیش‌بینی می‌کنند. Multi-Token Prediction یا MTP تلاش می‌کند اطلاعات لازم برای پیش‌بینی چند Token بعدی را نیز در فرایند آموزش و استنتاج به کار بگیرد.

این قابلیت می‌تواند به بهبود موارد زیر کمک کند:

• سرعت تولید خروجی
• پیوستگی پاسخ
• کیفیت برنامه‌نویسی
• استفاده بهتر از الگوهای طولانی
• Speculative Decoding

اثر عملی آن به زیرساخت استنتاج و نحوه ارائه مدل وابسته است.

Context Window مدل Nemotron 3 Ultra چقدر است؟

در این بخش باید میان Context بومی و Context توسعه‌یافته تفاوت قائل شویم.

براساس مستندات استقرار Nemotron 3 Ultra، Context بومی مدل برابر با ۲۶۲٬۱۴۴ Token یا حدود 256K است.

در استقرارهایی که تنظیمات و منابع کافی دارند، می‌توان Context را تا حدود یک میلیون Token توسعه داد. اما خود NVIDIA تأکید می‌کند که استفاده فراتر از Context بومی باید از نظر کیفیت، حافظه و توان عملیاتی ارزیابی شود.

افزایش Context ممکن است باعث شود:

• حافظه KV Cache بیشتری مصرف شود.
• تعداد درخواست‌های هم‌زمان کاهش یابد.
• Latency افزایش پیدا کند.
• هزینه پردازش بیشتر شود.
• کیفیت در انتهای Context نیاز به ارزیابی داشته باشد.

بنابراین بهتر است در مقاله، محصول و رابط کاربری خود بدون بررسی مسیر فعال، وعده قطعی Context یک میلیون توکنی ندهید.

Nemotron 3 Ultra برای چه کاربردهایی مناسب است؟

۱. ساخت AI Agent سازمانی

Agent سازمانی باید بتواند:

• هدف کاربر را تحلیل کند.
• اطلاعات موردنیاز را شناسایی کند.
• ابزار مناسب را انتخاب کند.
• نتیجه ابزار را بررسی کند.
• در صورت شکست، مسیر جایگزین بسازد.
• محدودیت‌های سازمان را رعایت کند.
• نتیجه نهایی را همراه با شواهد ارائه دهد.

Nemotron 3 Ultra می‌تواند به‌عنوان مغز استدلالی چنین سیستمی عمل کند. اجرای واقعی ابزارها باید توسط Backend کنترل شود.

نمونه ابزارهای یک Agent سازمانی:

search_documents
query_database
get_customer_record
calculate_metrics
create_report
get_project_status
search_internal_api
send_for_approval

۲. طراحی سیستم Multi-Agent

در معماری Multi-Agent، چند Agent تخصصی روی بخش‌های مختلف یک مسئله کار می‌کنند.

برای مثال، یک سیستم تحلیل محصول ممکن است شامل این Agentها باشد:

• Research Agent
• Data Analysis Agent
• Product Agent
• Technical Agent
• Reviewer Agent

Nemotron 3 Ultra می‌تواند در نقش‌های زیر استفاده شود:

Planner

وظیفه اصلی را به زیرمسئله‌ها تقسیم می‌کند و کارها را میان Agentها توزیع می‌کند.

Reviewer

خروجی Agentهای دیگر را بررسی و تناقض‌ها را پیدا می‌کند.

Synthesizer

نتایج چند Agent را به یک گزارش منسجم تبدیل می‌کند.

Escalation Model

فقط زمانی فراخوانی می‌شود که مدل‌های کوچک‌تر نتوانند مسئله را حل کنند.

استفاده از Ultra برای تمام Sub-Agentها هزینه زیادی ایجاد می‌کند. معمولاً بهتر است Sub-Agentهای سبک از مدل‌های ارزان‌تر استفاده کنند و Ultra در نقش Planner یا Reviewer قرار گیرد.

۳. برنامه‌نویسی در سطح Repository

Nemotron 3 Ultra می‌تواند برای وظایفی استفاده شود که تغییرات آن‌ها به یک فایل محدود نیست:

• افزودن قابلیت جدید
• Refactoring چندماژوله
• مهاجرت Framework
• تغییر قرارداد API
• تولید تست‌های گسترده
• تحلیل وابستگی‌ها
• بررسی Architectural Boundary
• رفع باگ‌های چندسرویسی
• تحلیل Performance
• تهیه برنامه مهاجرت

برای نتیجه مناسب باید ابزارهای خواندن فایل، جست‌وجوی کد، اجرای تست و اعمال Patch در اختیار Agent قرار بگیرند.

۴. تحلیل اسناد طولانی

مدل می‌تواند مجموعه بزرگی از مستندات را بررسی کند و:

• خلاصه مدیریتی تولید کند.
• تصمیم‌های مهم را استخراج کند.
• تناقض‌ها را پیدا کند.
• الزامات را دسته‌بندی کند.
• چند نسخه سند را مقایسه کند.
• جدول ریسک و اقدام بسازد.
• پرسش‌های بدون پاسخ را مشخص کند.
• برنامه اجرایی پیشنهاد دهد.

Context بزرگ مفید است، اما در سیستم‌های سازمانی همچنان باید از RAG، Metadata، دسترسی سطح‌بندی‌شده و Citation استفاده شود.

۵. تحقیق عمیق

یک Agent تحقیقاتی مبتنی بر Nemotron می‌تواند:

1. پرسش را به زیرموضوع‌ها تقسیم کند.
2. Queryهای جست‌وجو بسازد.
3. منابع را جمع‌آوری کند.
4. کیفیت منابع را ارزیابی کند.
5. ادعاهای متناقض را مقایسه کند.
6. شکاف اطلاعاتی را تشخیص دهد.
7. گزارش نهایی همراه با منابع تولید کند.

مدل به‌تنهایی اطلاعات لحظه‌ای ندارد. جست‌وجو و دریافت صفحات باید توسط ابزارهای خارجی انجام شود.

۶. تحلیل داده با ابزارهای خارجی

مدل نباید عملیات عددی حساس را صرفاً با تولید متن انجام دهد. روش مناسب این است که به ابزارهای محاسباتی متصل شود:

• اجرای SQL
• اجرای Python
• محاسبه شاخص‌ها
• تولید Pivot Table
• تحلیل سری زمانی
• تولید نمودار
• بررسی کیفیت داده
• محاسبه سناریوها

مدل مسئله را تحلیل می‌کند، ابزار مناسب را فراخوانی می‌کند و نتیجه واقعی ابزار را توضیح می‌دهد.

۷. ساخت دستیار فنی سازمان

یک دستیار فنی می‌تواند به این منابع متصل شود:

• مستندات داخلی
• Runbookها
• کد منبع
• API Catalog
• سیستم Ticket
• Logهای سرویس
• وضعیت سرویس‌ها
• پایگاه دانش
• تاریخچه Incident

Nemotron 3 Ultra می‌تواند پاسخ را براساس چند منبع ترکیب کند و در صورت نبود اطلاعات کافی، درخواست ابزار دیگری بدهد.

۸. بررسی معماری نرم‌افزار

مدل می‌تواند یک طرح معماری را از جنبه‌های زیر بررسی کند:

• مقیاس‌پذیری
• Coupling
• Fault Tolerance
• Consistency
• Observability
• هزینه زیرساخت
• Migration Path
• Operational Complexity
• Backward Compatibility
• Testability

برای نتیجه بهتر، حجم ترافیک، محدودیت تیم، SLO، فناوری‌های فعلی و بودجه باید در Prompt مشخص شوند.

مزایای Nemotron 3 Ultra

Reasoning قدرتمند

Ultra برای وظایفی طراحی شده که دقت استدلال از سرعت پاسخ کوتاه مهم‌تر است.

ظرفیت بالای مدل

۵۵۰ میلیارد پارامتر کلی ظرفیت بالایی برای یادگیری الگوهای پیچیده فراهم می‌کند؛ درحالی‌که MoE تنها بخشی از مدل را برای هر Token فعال می‌کند.

مناسب برای Long-Running Agent

معماری Hybrid برای Workflowهایی مناسب است که تاریخچه، خروجی ابزار و تصمیم‌های زیادی تولید می‌کنند.

Tool Calling

مدل می‌تواند ابزار مناسب را انتخاب و آرگومان‌های لازم را تولید کند.

توانایی برنامه‌نویسی

تحلیل کد، Refactoring، تولید تست و بررسی پروژه از کاربردهای مهم مدل است.

مناسب معماری Multi-Agent

مدل می‌تواند به‌عنوان Planner، Reviewer یا Orchestrator در سیستم چندعاملی استفاده شود.

Streaming

برای پاسخ‌های طولانی می‌توان خروجی را به‌تدریج به کاربر نمایش داد.

محدودیت‌های Nemotron 3 Ultra

مدل بسیار بزرگی است

برای درخواست‌های ساده، استفاده از Ultra می‌تواند بیش از نیاز باشد.

Latency بیشتر

استدلال پیچیده و خروجی طولانی ممکن است زمان پاسخ را افزایش دهد.

هزینه استفاده

ورودی بزرگ، خروجی طولانی و Agent Loop چندمرحله‌ای می‌توانند هزینه را افزایش دهند. قیمت روز را از صفحه مدل‌های درواره بررسی کنید.

Context توسعه‌یافته محدودیت عملی دارد

استفاده از Context فراتر از 256K ممکن است به استقرار و ظرفیت ارائه‌دهنده وابسته باشد. کیفیت آن نیز باید برای کاربرد واقعی ارزیابی شود.

احتمال تولید پاسخ نادرست

مدل قدرتمند همچنان ممکن است:

• اطلاعاتی را حدس بزند.
• API غیرواقعی بسازد.
• کد ناقص تولید کند.
• محدودیت پروژه را نادیده بگیرد.
• نتیجه ابزار را اشتباه تفسیر کند.

نیاز به طراحی Agent مناسب

یک مدل قوی نمی‌تواند ضعف‌های زیرساخت Agent را به‌طور کامل جبران کند:

• ابزارهای مبهم
• Context نامرتبط
• نداشتن معیار پایان
• نبود Validation
• نداشتن محدودیت هزینه
• State Management ضعیف

استفاده از Nemotron 3 Ultra با API درواره

برای شروع در درواره ثبت‌نام و API Key دریافت کنید.

تنظیمات اتصال:

Base URL: https://api.darvareh.ir/v1
Model ID درواره: nvidia/nemotron-3-ultra-550b-a55b

API Key را فقط در Backend نگه دارید و آن را در کد Frontend یا Repository عمومی قرار ندهید.

نمونه درخواست با cURL

curl https://api.darvareh.ir/v1/chat/completions \
  -H "Authorization: Bearer YOUR_DARVAREH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "nvidia/nemotron-3-ultra-550b-a55b",
    "messages": [
      {
        "role": "system",
        "content": "You are a principal software architect. Produce evidence-based, practical and testable recommendations."
      },
      {
        "role": "user",
        "content": "معماری یک سامانه پردازش سفارش با PostgreSQL، Kafka و چند سرویس مستقل را طراحی کن. idempotency، retry، ordering، observability و failure recovery را دقیق توضیح بده."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 6000
  }'

اتصال Nemotron 3 Ultra به Python

ابتدا SDK را نصب کنید:

pip install openai

کلید API را در متغیر محیطی قرار دهید:

export DARVAREH_API_KEY="YOUR_DARVAREH_API_KEY"

نمونه کد:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1"
)

response = client.chat.completions.create(
    model="nvidia/nemotron-3-ultra-550b-a55b",
    messages=[
        {
            "role": "system",
            "content": """
You are a principal backend engineer.

Rules:
- State assumptions explicitly.
- Prefer maintainable solutions.
- Consider failure modes.
- Include validation and testing strategy.
- Do not invent unavailable project details.
"""
        },
        {
            "role": "user",
            "content": """
برای یک سامانه پرداخت، الگوی Outbox را طراحی کن.

فناوری‌ها:
- Python
- FastAPI
- PostgreSQL
- Kafka
- SQLAlchemy

نیازمندی‌ها:
- از دست نرفتن Event
- جلوگیری از اثر تکراری
- Retry کنترل‌شده
- مانیتورینگ Backlog
- تست هم‌زمانی
- برنامه مهاجرت بدون Downtime
"""
        }
    ],
    temperature=0.2,
    max_tokens=7000
)

print(response.choices[0].message.content)

اتصال Nemotron 3 Ultra به JavaScript

نصب SDK:

npm install openai

نمونه Node.js:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DARVAREH_API_KEY,
  baseURL: "https://api.darvareh.ir/v1",
});

const response = await client.chat.completions.create({
  model: "nvidia/nemotron-3-ultra-550b-a55b",
  messages: [
    {
      role: "system",
      content: `
You are a principal TypeScript engineer.
Produce explicit, maintainable and testable solutions.
Identify assumptions and operational risks.
      `,
    },
    {
      role: "user",
      content: `
برای NestJS یک سرویس دریافت Webhook طراحی کن.

الزامات:
- signature verification
- idempotency
- concurrent delivery handling
- retry
- dead-letter processing
- structured logging
- تست با Vitest و Testcontainers
      `,
    },
  ],
  temperature: 0.2,
  max_tokens: 6000,
});

console.log(response.choices[0].message.content);

استفاده از Streaming

برای پاسخ‌های طولانی و تحلیل‌های معماری بهتر است Streaming فعال شود.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1"
)

stream = client.chat.completions.create(
    model="nvidia/nemotron-3-ultra-550b-a55b",
    messages=[
        {
            "role": "user",
            "content": (
                "برای مهاجرت یک Monolith به معماری Modular Monolith "
                "یک برنامه مرحله‌به‌مرحله و کم‌ریسک تهیه کن."
            )
        }
    ],
    temperature=0.2,
    max_tokens=6000,
    stream=True
)

for chunk in stream:
    content = chunk.choices[0].delta.content

    if content:
        print(content, end="", flush=True)

Streaming لزوماً زمان کل تولید را کاهش نمی‌دهد، اما کاربر پاسخ را زودتر مشاهده می‌کند.

Tool Calling با Nemotron 3 Ultra

فرض کنید می‌خواهیم یک Agent بررسی وضعیت پروژه بسازیم. ابزارهای آن می‌توانند شامل دریافت وضعیت Taskها و محاسبه شاخص‌ها باشند.

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_project_tasks",
            "description": (
                "Return project tasks and their current status."
            ),
            "parameters": {
                "type": "object",
                "properties": {
                    "project_id": {
                        "type": "string"
                    },
                    "status": {
                        "type": "string",
                        "enum": [
                            "all",
                            "open",
                            "in_progress",
                            "blocked",
                            "done"
                        ]
                    }
                },
                "required": ["project_id"],
                "additionalProperties": False
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "get_project_metrics",
            "description": (
                "Return delivery, quality and workload metrics."
            ),
            "parameters": {
                "type": "object",
                "properties": {
                    "project_id": {
                        "type": "string"
                    },
                    "period_days": {
                        "type": "integer",
                        "minimum": 1,
                        "maximum": 365
                    }
                },
                "required": [
                    "project_id",
                    "period_days"
                ],
                "additionalProperties": False
            }
        }
    }
]

درخواست مدل:

response = client.chat.completions.create(
    model="nvidia/nemotron-3-ultra-550b-a55b",
    messages=[
        {
            "role": "system",
            "content": """
You are a project analysis agent.

Rules:
- Use tools to obtain current project information.
- Do not invent metrics.
- Separate facts from interpretations.
- Explain the evidence behind each risk.
- Return actionable recommendations.
"""
        },
        {
            "role": "user",
            "content": (
                "وضعیت پروژه PRJ-104 را در ۳۰ روز گذشته "
                "تحلیل و ریسک‌های تحویل را مشخص کن."
            )
        }
    ],
    tools=tools,
    tool_choice="auto",
    temperature=0.1,
    max_tokens=4000
)

مدل ابزار را اجرا نمی‌کند. Backend باید Tool Call را دریافت، اعتبارسنجی و اجرا کند.

ساخت Agent Loop در Python

import json
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1"
)


def get_project_tasks(
    project_id: str,
    status: str = "all"
) -> dict:
    return {
        "project_id": project_id,
        "status_filter": status,
        "tasks": [
            {
                "id": "T-101",
                "status": "blocked",
                "title": "Payment integration",
                "blocked_days": 5
            },
            {
                "id": "T-102",
                "status": "in_progress",
                "title": "Invoice API",
                "blocked_days": 0
            }
        ]
    }


def get_project_metrics(
    project_id: str,
    period_days: int
) -> dict:
    return {
        "project_id": project_id,
        "period_days": period_days,
        "cycle_time_days": 8.2,
        "blocked_tasks": 4,
        "reopened_tasks": 6,
        "completed_tasks": 18
    }


tools = [
    {
        "type": "function",
        "function": {
            "name": "get_project_tasks",
            "description": "Get current project tasks.",
            "parameters": {
                "type": "object",
                "properties": {
                    "project_id": {"type": "string"},
                    "status": {
                        "type": "string",
                        "enum": [
                            "all",
                            "open",
                            "in_progress",
                            "blocked",
                            "done"
                        ]
                    }
                },
                "required": ["project_id"],
                "additionalProperties": False
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "get_project_metrics",
            "description": "Get project delivery metrics.",
            "parameters": {
                "type": "object",
                "properties": {
                    "project_id": {"type": "string"},
                    "period_days": {
                        "type": "integer",
                        "minimum": 1,
                        "maximum": 365
                    }
                },
                "required": [
                    "project_id",
                    "period_days"
                ],
                "additionalProperties": False
            }
        }
    }
]

handlers = {
    "get_project_tasks": get_project_tasks,
    "get_project_metrics": get_project_metrics
}

messages = [
    {
        "role": "system",
        "content": (
            "Use tools for current facts. "
            "Do not invent data. "
            "Separate evidence, inference and recommendation."
        )
    },
    {
        "role": "user",
        "content": (
            "پروژه PRJ-104 را تحلیل و ریسک‌های تحویل را مشخص کن."
        )
    }
]

for step in range(8):
    response = client.chat.completions.create(
        model="nvidia/nemotron-3-ultra-550b-a55b",
        messages=messages,
        tools=tools,
        tool_choice="auto",
        temperature=0.1,
        max_tokens=3000
    )

    assistant_message = response.choices[0].message
    messages.append(assistant_message)

    if not assistant_message.tool_calls:
        print(assistant_message.content)
        break

    for call in assistant_message.tool_calls:
        name = call.function.name

        try:
            arguments = json.loads(
                call.function.arguments
            )
            handler = handlers[name]
            result = handler(**arguments)
        except KeyError:
            result = {
                "ok": False,
                "error": "Unknown tool"
            }
        except Exception as exc:
            result = {
                "ok": False,
                "error": str(exc)
            }

        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": json.dumps(
                result,
                ensure_ascii=False
            )
        })
else:
    raise RuntimeError(
        "Agent exceeded the maximum number of steps"
    )

کنترل ابزارهای Agent

ابزارهای Agent باید محدود، مشخص و قابل‌بررسی باشند.

تعریف دقیق ابزار

به‌جای ابزار مبهم:

manage_project

ابزارهای کوچک و شفاف تعریف کنید:

get_project_tasks
get_project_metrics
create_project_report
request_task_update

اعتبارسنجی آرگومان‌ها

تمام پارامترهای Tool Call باید با JSON Schema، Pydantic یا Zod اعتبارسنجی شوند.

محدودیت سطح دسترسی

کاربر فقط باید بتواند ابزارهایی را فراخوانی کند که مجوز استفاده از آن‌ها را دارد.

جداسازی ابزار خواندن و نوشتن

ابزارهای Read-Only را از ابزارهای تغییردهنده جدا کنید. برای عملیات تغییردهنده بهتر است مرحله تأیید انسانی وجود داشته باشد.

محدودیت تعداد مراحل

برای هر Agent این محدودیت‌ها را تعریف کنید:

• max_steps
• max_tool_calls
• max_duration
• max_input_tokens
• max_output_tokens
• max_cost

معماری Multi-Agent با Nemotron 3 Ultra

یک معماری کاربردی می‌تواند شامل یک Orchestrator و چند Sub-Agent باشد.

Orchestrator

• هدف را تحلیل می‌کند.
• وظایف را تقسیم می‌کند.
• Agent مناسب را انتخاب می‌کند.
• نتیجه‌ها را ترکیب می‌کند.

Research Agent

• اسناد را جست‌وجو می‌کند.
• شواهد را استخراج می‌کند.
• منابع را ثبت می‌کند.

Coding Agent

• Repository را بررسی می‌کند.
• Patch تولید می‌کند.
• تست اجرا می‌کند.

Data Agent

• Query می‌سازد.
• محاسبات را با ابزار انجام می‌دهد.
• نتیجه عددی را برمی‌گرداند.

Reviewer Agent

• تناقض‌ها را پیدا می‌کند.
• معیارهای پذیرش را بررسی می‌کند.
• کیفیت نتیجه را ارزیابی می‌کند.

Nemotron 3 Ultra را می‌توان به‌عنوان Orchestrator و Reviewer استفاده کرد و Sub-Agentهای ساده‌تر را به مدل‌های اقتصادی‌تر سپرد.

نمونه State برای سیستم Multi-Agent

{
  "goal": "Assess migration from monolith to modular architecture",
  "constraints": [
    "No service downtime",
    "Public API must remain compatible",
    "Team size is eight engineers"
  ],
  "tasks": [
    {
      "id": "architecture-review",
      "agent": "technical",
      "status": "completed"
    },
    {
      "id": "dependency-analysis",
      "agent": "coding",
      "status": "in_progress"
    },
    {
      "id": "migration-risk",
      "agent": "reviewer",
      "status": "pending"
    }
  ],
  "evidence": [],
  "open_questions": [],
  "final_status": "running"
}

State بهتر است خارج از تاریخچه پیام‌ها در PostgreSQL، Redis یا یک Workflow Engine نگهداری شود.

پرامپت‌نویسی برای Nemotron 3 Ultra

یک Prompt حرفه‌ای برای Reasoning بهتر است شامل این قسمت‌ها باشد:

نقش

تو یک معمار ارشد نرم‌افزار با تجربه سیستم‌های توزیع‌شده هستی.

هدف

برای جداکردن ماژول پرداخت از Monolith یک برنامه مهاجرت طراحی کن.

Context

سامانه روزانه ۲۰۰ هزار درخواست دارد.
PostgreSQL پایگاه داده اصلی است.
استقرار با Kubernetes انجام می‌شود.
تیم شامل ۸ توسعه‌دهنده است.

محدودیت‌ها

Downtime پذیرفته نیست.
API عمومی نباید تغییر کند.
Dual Write دائمی مجاز نیست.

معیار پذیرش

امکان Rollback وجود داشته باشد.
داده از دست نرود.
هر مرحله قابل مانیتور باشد.

فرمت پاسخ

1. فرضیات
2. معماری فعلی استنباط‌شده
3. گزینه‌ها
4. تصمیم پیشنهادی
5. مراحل مهاجرت
6. ریسک‌ها
7. برنامه Rollback
8. تست و مانیتورینگ

نمونه Prompt کامل برای تحلیل معماری

نقش:
تو Principal Software Architect هستی.

هدف:
معماری پردازش سفارش را برای تحمل افزایش ۱۰ برابری ترافیک بازطراحی کن.

وضعیت فعلی:
- Backend با NestJS
- PostgreSQL
- Redis
- یک Worker برای پردازش سفارش
- میانگین روزانه ۵۰ هزار سفارش
- Peak برابر ۲۰ درخواست در ثانیه

محدودیت‌ها:
- تیم فقط ۶ توسعه‌دهنده دارد.
- مهاجرت باید مرحله‌ای باشد.
- Downtime مجاز نیست.
- هزینه عملیاتی باید قابل کنترل بماند.

معیارهای پذیرش:
- تحمل حداقل ۲۰۰ درخواست در ثانیه
- جلوگیری از ثبت سفارش تکراری
- امکان Retry
- قابلیت مشاهده وضعیت هر سفارش
- Rollback مرحله‌ای

خروجی:
1. فرضیات و اطلاعات ناقص
2. گلوگاه‌های معماری فعلی
3. حداقل سه گزینه
4. جدول مقایسه گزینه‌ها
5. معماری پیشنهادی
6. مراحل مهاجرت
7. Failure Modeها
8. SLI و SLO پیشنهادی
9. تست بار
10. برنامه Rollback

قانون:
هیچ عدد یا قابلیت ناموجودی را قطعی فرض نکن.

Prompt مناسب برای Code Review

این Pull Request را در نقش یک Staff Engineer بررسی کن.

تمرکز:
- correctness
- concurrency
- backward compatibility
- maintainability
- test coverage
- operational risks

قوانین:
- فقط مشکلات قابل استنباط از Diff را گزارش کن.
- تغییر سلیقه‌ای را Bug اعلام نکن.
- هر Finding باید شامل فایل، بخش کد، دلیل و راه‌حل باشد.
- Severity را از میان Critical، High، Medium و Low انتخاب کن.
- اگر Context کافی نیست، سؤال لازم را مطرح کن.
- در پایان نتیجه را به Approve، Comment یا Request Changes دسته‌بندی کن.

Structured Output

اگر پاسخ قرار است توسط Backend پردازش شود، خروجی JSON از متن آزاد مناسب‌تر است.

نمونه Schema بررسی معماری:

{
  "summary": "string",
  "decision": "approve | revise | reject",
  "risks": [
    {
      "title": "string",
      "severity": "low | medium | high | critical",
      "evidence": "string",
      "impact": "string",
      "recommendation": "string"
    }
  ],
  "missing_information": [
    "string"
  ],
  "next_steps": [
    {
      "title": "string",
      "owner_role": "string",
      "priority": 1
    }
  ]
}

پشتیبانی دقیق JSON Schema یا Response Format را برای مدل فعال در درواره بررسی کنید. حتی با خروجی ساختاریافته، Validation سمت Backend ضروری است.

تنظیم Temperature

مقدار مناسب را باید با Evaluation روی وظایف واقعی خود تعیین کنید.

مدیریت Context طولانی

Context بزرگ زمانی مفید است که ساختاریافته باشد. اطلاعات را می‌توان به چهار بخش تقسیم کرد:

دستور ثابت

• نقش مدل
• قواعد
• ابزارها
• محدودیت‌های سازمان

هدف جاری

• مسئله کاربر
• معیارهای پذیرش
• خروجی مورد انتظار

Evidence

• محتوای فایل
• نتیجه Query
• خروجی تست
• سند بازیابی‌شده
• پاسخ API

State

• مراحل انجام‌شده
• تصمیم‌های قبلی
• خطاهای باز
• اقدام بعدی
• وضعیت هزینه و زمان

خلاصه‌سازی تاریخچه Agent

پس از چند مرحله، خروجی‌های قدیمی ابزار را به State خلاصه تبدیل کنید:

{
  "objective": "Fix duplicate order creation",
  "confirmed_facts": [
    "Queue delivery is at-least-once",
    "Order table has no unique event constraint"
  ],
  "completed_actions": [
    "Reviewed consumer",
    "Reviewed database schema",
    "Executed concurrency test"
  ],
  "test_results": {
    "before_fix": "duplicate orders reproduced",
    "after_fix": "not executed"
  },
  "open_risks": [
    "Existing duplicate data must be cleaned"
  ],
  "next_action": "Implement unique constraint and conflict handling"
}

خلاصه نباید جایگزین شواهد حیاتی شود. اطلاعات لازم برای اثبات نتیجه را نگه دارید.

استفاده از RAG در کنار Nemotron 3 Ultra

حتی در مدل Long Context، RAG همچنان مزایای مهمی دارد:

• انتخاب اسناد مرتبط
• کاهش هزینه ورودی
• کنترل دسترسی
• ارائه Citation
• به‌روزرسانی سریع دانش
• حذف اطلاعات نامرتبط
• مدیریت تعداد زیاد اسناد

الگوی مناسب:

پرسش کاربر
تشخیص هدف
بازیابی اسناد
Reranking
ساخت Context
ارسال به Nemotron
اعتبارسنجی پاسخ
ارائه پاسخ همراه با منابع

برای دقت بهتر، می‌توانید از Hybrid Search و Reranking استفاده کنید.

معماری Production پیشنهادی

API Layer

• احراز هویت
• Rate Limiting
• Validation
• Request ID
• محدودیت اندازه ورودی

Model Router

• تشخیص پیچیدگی
• انتخاب مدل
• Fallback
• محدودیت بودجه

Context Builder

• ساخت Prompt
• بازیابی اسناد
• خلاصه‌سازی تاریخچه
• حذف اطلاعات تکراری

Tool Executor

• اعتبارسنجی ابزار
• کنترل سطح دسترسی
• Timeout
• ثبت Audit

State Store

• نگهداری وضعیت Agent
• مدیریت Jobهای طولانی
• بازیابی پس از شکست

Output Validator

• بررسی JSON
• کنترل Citation
• بررسی معیار پذیرش
• تشخیص خروجی ناقص

Observability

• Latency
• Token مصرفی
• هزینه
• تعداد Tool Call
• خطاها
• نرخ تکمیل وظیفه

Model Routing برای Nemotron 3 Ultra

مدل Ultra را فقط برای وظایف پیچیده Route کنید:

ULTRA_MODEL = "nvidia/nemotron-3-ultra-550b-a55b"


def select_model(task: dict) -> str:
    if task.get("role") in {
        "orchestrator",
        "final_reviewer"
    }:
        return ULTRA_MODEL

    if task.get("complexity") == "high":
        return ULTRA_MODEL

    if task.get("requires_deep_reasoning"):
        return ULTRA_MODEL

    if task.get("requires_long_context"):
        return ULTRA_MODEL

    if task.get("type") in {
        "architecture_review",
        "complex_debugging",
        "repository_refactor",
        "multi_agent_synthesis"
    }:
        return ULTRA_MODEL

    return "YOUR_LIGHTWEIGHT_MODEL_ID"

Model ID مدل سبک‌تر را براساس فهرست فعال درواره انتخاب کنید.

کاهش هزینه استفاده

• درخواست‌های ساده را به مدل کوچک‌تر ارسال کنید.
• Ultra را به مرحله برنامه‌ریزی یا بررسی نهایی محدود کنید.
• Context نامرتبط را حذف کنید.
• خروجی ابزارها را خلاصه کنید.
• پاسخ‌های ثابت را Cache کنید.
• تعداد Tool Callها را محدود کنید.
• max_tokens را بیش از نیاز افزایش ندهید.
• از RAG و Reranking استفاده کنید.
• تاریخچه Agent را فشرده کنید.
• هزینه هر نتیجه موفق را اندازه بگیرید.
• درخواست‌های تکراری را با Idempotency کنترل کنید.

برای اطلاع از قیمت روز از صفحه مدل‌های درواره استفاده کنید.

Retry و Timeout

درخواست‌های مدل ممکن است با خطای موقت مواجه شوند. Retry باید فقط برای خطاهای قابل تکرار انجام شود.

import random
import time


def call_with_retry(operation, attempts: int = 4):
    for attempt in range(attempts):
        try:
            return operation()
        except Exception:
            if attempt == attempts - 1:
                raise

            delay = min(2 ** attempt, 8)
            jitter = random.uniform(0, 0.5)

            time.sleep(delay + jitter)

در Production باید خطاها را دسته‌بندی کنید:

• خطای موقت سرویس: Retry
• Timeout: Retry محدود
• Rate Limit: رعایت زمان انتظار
• ورودی نامعتبر: بدون Retry
• API Key نامعتبر: بدون Retry
• Model ID نامعتبر: بدون Retry

ارزیابی Nemotron 3 Ultra

انتخاب مدل نباید صرفاً براساس تعداد پارامتر یا Benchmark عمومی انجام شود. یک Evaluation Set واقعی بسازید.

معیارهای Reasoning

• درستی نتیجه
• رعایت محدودیت‌ها
• کیفیت فرضیات
• توانایی تشخیص اطلاعات ناقص
• پایداری پاسخ
• کیفیت مقایسه گزینه‌ها

معیارهای Coding

• درصد تست‌های پاس‌شده
• صحت Patch
• تغییرات غیرضروری
• Backward Compatibility
• نرخ APIهای ساختگی
• کیفیت تست تولیدشده
• زمان حل مسئله

معیارهای Agent

• انتخاب صحیح ابزار
• صحت آرگومان ابزار
• تعداد مراحل
• مدیریت خطای ابزار
• حفظ هدف
• تشخیص پایان
• هزینه هر وظیفه موفق

معیارهای Long Context

• بازیابی اطلاعات از ابتدای Context
• بازیابی اطلاعات از میانه Context
• بازیابی اطلاعات از انتهای Context
• اتصال چند شاهد پراکنده
• تشخیص تناقض
• دقت Citation
• مقاومت در برابر اطلاعات نامرتبط

مقایسه Nemotron 3 Ultra با مدل کوچک‌تر

اشتباهات رایج

استفاده از Ultra برای همه درخواست‌ها

بخش زیادی از وظایف با مدل کوچک‌تر قابل انجام است. Model Routing هزینه را کاهش می‌دهد.

ارسال تمام اطلاعات موجود

Context بزرگ مجوز ارسال اطلاعات نامرتبط نیست.

نداشتن معیار پایان Agent

Agent باید بداند چه زمانی وظیفه تکمیل شده است. Backend نیز باید محدودیت قطعی داشته باشد.

اعتماد به ادعای اجرای تست

فقط خروجی واقعی ابزار تست معتبر است.

اجرای Tool Call بدون Validation

نام ابزار، آرگومان و سطح دسترسی باید پیش از اجرا بررسی شوند.

نداشتن State مستقل

ذخیره تمام وضعیت فقط در Message History، بازیابی و Debug را دشوار می‌کند.

قراردادن API Key در Frontend

API Key درواره فقط باید در سرور نگهداری شود.

فرض یک میلیون Token برای تمام مسیرها

ظرفیت واقعی Context را برای Model ID فعال بررسی کنید.

پرسش‌های متداول درباره Nemotron 3 Ultra

NVIDIA Nemotron 3 Ultra چیست؟

Nemotron 3 Ultra یک مدل زبانی بزرگ از NVIDIA برای Reasoning، Coding، Tool Calling و اجرای Agentهای پیچیده و طولانی است.

Nemotron 3 Ultra چند پارامتر دارد؟

این مدل حدود ۵۵۰ میلیارد پارامتر کلی و حدود ۵۵ میلیارد پارامتر فعال در هر مرحله دارد.

عبارت 550B-A55B به چه معناست؟

550B تعداد تقریبی کل پارامترها و A55B تعداد تقریبی پارامترهای فعال در زمان پردازش را نشان می‌دهد.

Context Window مدل چقدر است؟

Context بومی مدل حدود ۲۶۲ هزار Token است. در استقرارهای پشتیبانی‌شده می‌توان آن را تا حدود یک میلیون Token توسعه داد. ظرفیت فعال در API درواره را در صفحه مدل بررسی کنید.

آیا Nemotron 3 Ultra برای برنامه‌نویسی مناسب است؟

بله. تحلیل Repository، Code Review، Refactoring، رفع باگ و تولید تست از کاربردهای مهم آن هستند.

آیا Nemotron 3 Ultra از Tool Calling پشتیبانی می‌کند؟

بله، این مدل برای Tool Calling و Workflowهای Agentic طراحی شده است. اجرای واقعی ابزار باید توسط Backend انجام شود.

آیا Nemotron 3 Ultra برای Multi-Agent مناسب است؟

بله. می‌توان از آن به‌عنوان Orchestrator، Planner، Reviewer یا Synthesizer استفاده کرد.

Model ID درواره چیست؟

nvidia/nemotron-3-ultra-550b-a55b

برای تأیید شناسه و وضعیت مدل، صفحه مدل‌های درواره را بررسی کنید.

Base URL درواره چیست؟

https://api.darvareh.ir/v1

آیا می‌توان مدل را در Python استفاده کرد؟

بله. با تنظیم Base URL درواره و Model ID می‌توانید آن را از Backend پایتون فراخوانی کنید.

آیا می‌توان Nemotron را در Node.js استفاده کرد؟

بله. API درواره را می‌توان با SDKهای JavaScript و TypeScript سازگار فراخوانی کرد.

آیا Nemotron 3 Ultra برای چت‌بات ساده مناسب است؟

قابل استفاده است، اما احتمالاً برای چت کوتاه بیش از نیاز خواهد بود. یک مدل سبک‌تر می‌تواند سریع‌تر و اقتصادی‌تر باشد.

قیمت Nemotron 3 Ultra چقدر است؟

قیمت ممکن است تغییر کند. اطلاعات به‌روز را در صفحه مدل‌های درواره ببینید.

جمع‌بندی

NVIDIA Nemotron 3 Ultra مدلی قدرتمند برای پروژه‌هایی است که به Reasoning عمیق، Context طولانی، Tool Calling و اجرای وظایف چندمرحله‌ای نیاز دارند.

معماری Hybrid Mamba-Transformer MoE، ظرفیت ۵۵۰ میلیارد پارامتری و فعال‌شدن حدود ۵۵ میلیارد پارامتر در هر مرحله، تلاش می‌کند دقت یک مدل بسیار بزرگ را با استنتاج کارآمدتر ترکیب کند.

این مدل به‌خصوص برای کاربردهای زیر مناسب است:

• Agentهای سازمانی
• سیستم‌های Multi-Agent
• تحلیل Repository
• برنامه‌ریزی معماری
• تحقیق عمیق
• تحلیل اسناد طولانی
• Code Review
• Orchestration ابزارها
• بررسی نهایی خروجی مدل‌های دیگر

بااین‌حال، استفاده موفق به انتخاب مدل محدود نمی‌شود. مدیریت Context، تعریف ابزارهای دقیق، نگهداری State، Validation، Evaluation و Model Routing بخش‌های ضروری یک سیستم Production هستند.

برای شروع:

1. در درواره ثبت‌نام کنید.
2. API Key دریافت کنید.
3. وضعیت و قیمت مدل را در صفحه مدل‌ها بررسی کنید.
4. Base URL را روی https://api.darvareh.ir/v1 قرار دهید.
5. از Model ID درواره یعنی nvidia/nemotron-3-ultra-550b-a55b استفاده کنید.
6. مدل را روی وظایف واقعی محصول خود ارزیابی کنید.
7. برای کنترل هزینه از Model Routing استفاده کنید.

مقالات مرتبط

• راهنمای جامع مدل‌های هوش مصنوعی و انتخاب مدل مناسب
• راهنمای کامل AI Agent
• راهنمای AI Agent، ابزارها، Skills و MCP
• مقایسه بهترین SDKهای ساخت AI Agent
• راهنمای Tool Calling برای اتصال مدل به ابزارها
• آموزش Function Calling در مدل‌های هوش مصنوعی
• Context Window چیست و چگونه مدیریت می‌شود؟
• ساخت حافظه AI Agent با PostgreSQL، Redis و Vector Database
• معماری چندمدلی و چندارائه‌دهنده هوش مصنوعی
• انتخاب و مسیریابی مدل برای Coding Agent
• راهنمای AI Router و انتخاب خودکار مدل
• راهنمای ساخت RAG با LangChain و LlamaIndex
• Hybrid Search با BM25 و Vector Search
• Reranking و Cross-Encoder در سیستم RAG
• ساخت API هوش مصنوعی آماده Production