در این مقاله
Le Chonk نامی است که میسترال برای Mistral Large 4 به کار می‌برد؛ مدلی برای کارهایی مثل برنامه‌نویسی، تحلیل اسناد و استفاده در ایجنت‌ها. برای توسعه‌دهنده ایرانی، پرسش کاربردی این است که چطور مدل را به برنامه وصل کند، کیفیت آن را روی کار خودش بسنجد و هزینه اجرای واقعی را کنترل کند. در این راهنما از مسیر API شروع می‌کنیم و بعد به ارزیابی کد، ابزارها، استقرار بکاند و مقایسه با DeepSeek می‌رسیم.
در بررسی ۱۶ آبان ۱۴۰۵، مدل mistralai/mistral-large-4-0 در کاتالوگ و صفحه عمومی API هوش مصنوعی پاستا موجود بود؛ وضعیت مدل، عرضه API، قیمت‌گذاری تأییدشده و ارائه‌دهنده آن فعال بودند. این بررسی، تأیید موجودی کاتالوگ است؛ نتیجه بنچمارک مستقل، اجرای واقعی ابزار یا آزمایش کیفیت فارسی نیست. پیش از اتصال محصول، موجودی همان روز را با کلید خودتان دوباره بررسی کنید.
Le Chonk چیست و چه نسبتی با Mistral Large 4 دارد؟
میسترال ابتدا Mistral Large 4 را به‌صورت پیش‌نمایش معرفی کرد و سپس در ۲۹ اکتبر ۲۰۲۶ انتشار وزنهای نسخه بهبودیافته را اعلام کرد. در اطلاعیه رسمی Le Chonk، تمرکز اصلی روی کدنویسی ایجنتی، استدلال و کاربردهای دفاعی امنیت است. این‌ها جهت‌گیری و ارزیابی سازنده‌اند؛ برای انتخاب مدل در یک پروژه فارسی باید نمونه کار خودتان را هم آزمایش کنید.
شناسه مدل اهمیت دارد. Mistral Large قدیمی با شناسه‌هایی مثل mistral-large-2407 همان Large 4 نیست. هنگام انتخاب از فهرست مدل‌ها، نام نمایشی، شناسه عمومی، قابلیت موردنیاز و قیمت روز را کنار هم ببینید. نام برند به‌تنهایی برای اثبات نسخه یا پشتیبانی یک پارامتر کافی نیست. همچنین عرضه مدل از طریق API را معادل میزبانی وزنهای آن در داخل ایران در نظر نگیرید؛ محل اجرا را باید برای همان مدل و مسیر ارائه جدا بررسی کرد.
برای استفاده از API میسترال در پاستا چه چیزهایی لازم است؟
یک حساب پاستا، کلید API مستقل برای پروژه، بودجه مشخص و یک محیط بکاند کافی است تا آزمایش اولیه را شروع کنید. کلید را در متغیر محیطی نگه دارید و آن را داخل مرورگر، اپ موبایل، مخزن عمومی یا تصویر آموزش قرار ندهید. بهتر است محیط آزمایش و محصول دو کلید جدا داشته باشند؛ در این صورت توقف آزمایش یا تعویض یک کلید، همه برنامه‌های شما را هم‌زمان تحت تأثیر قرار نمی‌دهد.
آدرس پایه سازگار با SDK در این آموزش https://console.paasta.cloud/api/ai/v1 است. دستور نصب را در محیط مجازی پروژه اجرا کنید و بعد نسخه‌ای را که با آن آزمایش موفق داشته‌اید در فایل وابستگی‌ها ثابت کنید. یک پاسخ کوتاه، فقط اولین مرحله پذیرش است؛ اگر برنامه شما پاسخ جریانی، تصویر، خروجی ساختاریافته یا ابزار می‌خواهد، هر قابلیت را جدا با همان مسیر API بررسی کنید. راهنمای عمومی اتصال در مستندات API پاستا در دسترس است.
python -m venv .venv
# Activate the environment using the command for your operating system.
python -m pip install openai
# Set PAASTA_API_KEY in your server environment or secret settings.نمونه Python: ابتدا موجودی مدل، سپس اولین درخواست
نمونه زیر پیش از ارسال پیام، شناسه مدل را در فهرست قابل استفاده برای کلید جست‌وجو میکند. اگر مدل در دسترس نباشد، برنامه متوقف می‌شود و نام مدل دیگری را بی‌صدا جایگزین نمی‌کند. پاسخ مدل را در این مرحله روی ورودی غیرحساس آزمایش کنید. متن درخواست و خروجی پیشنهادی آموزشی‌اند و انتشار این کد به معنی اجرای درخواست پولی با کلید خواننده نیست.
import os
from openai import OpenAI
MODEL = "mistralai/mistral-large-4-0"
client = OpenAI(
api_key=os.environ["PAASTA_API_KEY"],
base_url="https://console.paasta.cloud/api/ai/v1",
timeout=60.0,
max_retries=0,
)
available = {item.id for item in client.models.list().data}
if MODEL not in available:
raise SystemExit("Selected model is not available for this key.")
reply = client.chat.completions.create(
model=MODEL,
messages=[
{"role": "system", "content": "Answer in Persian. State uncertainty."},
{"role": "user", "content": "Explain three checks before deploying a Python API."},
],
max_tokens=2048,
)
print(reply.choices[0].message.content or "No visible answer returned.")نسخه قابل دانلود همین مثال در فایل نمونه اتصال Mistral Large 4 قرار دارد. اگر پاسخ خالی است، پیش از ارسال دوباره، وضعیت پایان پاسخ، سقف خروجی و خطای درخواست را بررسی کنید. بالا بردن بی‌حساب سقف توکن راه‌حل عمومی نیست. برای یک کار ساده، ورودی کوتاه، معیار پاسخ روشن و یک سقف قابل قبول هزینه داشته باشید.
آزمایش کدنویسی را چطور طراحی کنیم؟
برای ارزیابی، یک مخزن آزمایشی با چند خطای شناخته‌شده بسازید: اعتبارسنجی ورودی ناقص، آزمون شکست‌خورده، مدیریت استثنای نامناسب یا یک تابع کند. از مدل بخواهید مسئله را توضیح دهد، تغییر محدود پیشنهاد کند و روش بررسی را بنویسد. خروجی را مستقیم روی محصول اعمال نکنید. تغییر باید در شاخه جدا دیده شود و آزمون مرتبط با همان مسئله، قبل و بعد از اصلاح اجرا شود.
مجموعه ارزیابی را پیش از دیدن پاسخ مدل‌ها ثبت کنید. برای هر مسئله، خروجی مورد انتظار، فایل‌های مجاز، محدودیت زمان و معیار پذیرش داشته باشید. اگر در میانه کار معیارها را به نفع پاسخ یک مدل تغییر دهید، مقایسه قابل اعتماد نخواهد بود. برای کارهای واقعی‌تر، نمونه‌ای از خطاهای گذشته پروژه را بدون اسرار و اطلاعات مشتری بازسازی کنید؛ یک تمرین نزدیک به محصول از چند سؤال عمومی برنامه‌نویسی اطلاعات بیشتری می‌دهد.
| کار آزمایشی | معیار پذیرش | نشانه شکست |
|---|---|---|
| رفع خطای ورودی | آزمون ورودی نامعتبر رد و ورودی معتبر پذیرفته شود | حذف اعتبارسنجی برای سبزشدن آزمون |
| اصلاح تابع موجود | رفتار قبلی حفظ و تغییر محدود باشد | بازنویسی نامرتبط فایل‌ها |
| توضیح کد فارسی | پاسخ به خطوط و رفتار واقعی کد اشاره کند | توضیح مطمئن درباره تابعی که وجود ندارد |
| تولید آزمون | آزمون، نسخه معیوب را واقعاً رد کند | آزمونی که فقط پیاده‌سازی را تکرار میکند |
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.