Awesome Free LLM APIs IR

API رایگان LLM؛ راهنمای فنی انتخاب مدل زبانی برای پروژه

راهنمای فنی مقایسه APIهای رایگان مدل زبانی بزرگ برای چت، کدنویسی، RAG و متن فارسی؛ همراه با سهمیه، قابلیت، امنیت و معماری قابل‌تعویض.

آخرین بازبینی: 2026-07-19

پاسخ سریع: برای انتخاب API رایگان LLM فقط نام مدل یا مقدار RPM را نبینید. نوع سهمیه رایگان، کیفیت مدل در وظیفه واقعی، طول Context، پشتیبانی از Streaming و Tool Calling، سازگاری با OpenAI SDK، سیاست نگهداری داده و وضعیت دسترسی شبکه باید هم‌زمان بررسی شوند. یک Provider مناسب برای چت ممکن است برای RAG، Agent یا خروجی ساخت‌یافته انتخاب خوبی نباشد.

آخرین داده‌های تاریخ‌دار سرویس‌ها در کاتالوگ رایگان LLM قرار دارد. برای بررسی فایل‌های منبع، Schema، تاریخچه تغییرات و ثبت گزارش می‌توانید از مخزن GitHub پروژه استفاده کنید.

LLM API چه کاری انجام می‌دهد؟

مدل زبانی بزرگ یا LLM متنی را دریافت می‌کند و براساس دستور، Context و پارامترهای تولید پاسخ می‌سازد. API این قابلیت را در اختیار نرم‌افزار قرار می‌دهد. برنامه می‌تواند پیام‌های چت، متن سند، ساختار ابزارها یا داده‌های بازیابی‌شده را ارسال کند و پاسخ متنی، JSON، Tool Call یا Embedding بگیرد.

رابط وب برای استفاده دستی طراحی شده است، اما API امکان خودکارسازی، کنترل نسخه مدل، ثبت متریک، Retry، اتصال به دیتابیس و ساخت محصول را فراهم می‌کند. به همین دلیل انتخاب Provider باید مانند انتخاب یک وابستگی زیرساختی انجام شود، نه صرفاً انتخاب یک چت‌بات.

انواع رایگان‌بودن در APIهای LLM

اصطلاح Free API چند قرارداد متفاوت را پوشش می‌دهد:

  • سهمیه ثابت درخواست در دقیقه یا روز؛
  • سهمیه توکن ورودی و خروجی؛
  • مجموعه‌ای از مدل‌های رایگان در کنار مدل‌های پولی؛
  • Credit ماهانه یا یک‌باره؛
  • Trial محدود به زمان؛
  • دسترسی Community با ظرفیت مشترک؛
  • Endpoint ناشناس با محدودیت شدید؛
  • دسترسی پژوهشی یا آزمایشی که برای Production تضمین نشده است.

این تفاوت روی معماری اثر دارد. Trial برای دمو مناسب است، اما اگر برنامه باید چند ماه کار کند، یک سهمیه دوره‌ای یا مسیر مهاجرت روشن لازم دارید. مدل رایگان نیز ممکن است بدون اخطار جایگزین یا حذف شود.

معیار اول: قرارداد API

OpenAI-compatible

بسیاری از سرویس‌ها Endpoint مشابه OpenAI ارائه می‌کنند. مزیت اصلی آن کاهش هزینه مهاجرت است. با یک Adapter می‌توان Provider را با تغییر تنظیمات عوض کرد. با این حال سازگاری کامل فرض نشود. ممکن است Provider فقط Chat Completions را پشتیبانی کند و Endpointهای Responses، Assistants، Embeddings یا Audio را نداشته باشد.

نمونه تنظیم قابل‌تعویض:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["LLM_API_KEY"],
    base_url=os.environ["LLM_BASE_URL"],
)

result = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[
        {"role": "system", "content": "خروجی را به زبان فارسی و به شکل JSON بده."},
        {"role": "user", "content": "سه ریسک استفاده از API رایگان را فهرست کن."},
    ],
    temperature=0.2,
)

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

در Production بهتر است یک Interface داخلی تعریف کنید تا کد دامنه به SDK خاص وابسته نشود. تبدیل خطاها، نام مدل، Timeout و Retry نیز در همان لایه انجام شود.

API بومی Provider

برخی سرویس‌ها قرارداد اختصاصی دارند. API بومی ممکن است قابلیت‌های بیشتری ارائه کند، اما هزینه مهاجرت بالاتر است. پیش از انتخاب بررسی کنید SDK رسمی نگهداری می‌شود، نمونه‌های خطا روشن‌اند و نسخه‌بندی Endpoint وجود دارد.

معیار دوم: محدودیت مصرف

محدودیت‌ها باید جدا خوانده شوند:

  • RPM: تعداد درخواست در دقیقه؛
  • RPD: تعداد درخواست در روز؛
  • TPM: تعداد توکن در دقیقه؛
  • TPD یا TPH: سقف توکن در روز یا ساعت؛
  • Concurrent requests: تعداد درخواست هم‌زمان؛
  • Context limit: مجموع ورودی و خروجی قابل پردازش؛
  • Output limit: حداکثر خروجی هر پاسخ.

برای مثال ممکن است Provider صدها درخواست روزانه بدهد، ولی TPM پایین باعث شود پردازش سند طولانی ممکن نباشد. یا مدل Context بزرگ داشته باشد، اما Free Tier فقط خروجی کوتاه اجازه دهد. بار واقعی را به درخواست و توکن تبدیل کنید و سپس سهمیه را بسنجید.

معیار سوم: کیفیت در وظیفه واقعی

رتبه کلی مدل به‌تنهایی کافی نیست. یک مجموعه Prompt کوچک اما نماینده بسازید. برای پروژه فارسی موارد زیر را آزمایش کنید:

  • درک دستور فارسی رسمی و محاوره‌ای؛
  • حفظ نیم‌فاصله و اعداد؛
  • خلاصه‌سازی متن طولانی؛
  • استخراج فیلدها در JSON؛
  • پاسخ به Context بازیابی‌شده؛
  • تولید و اصلاح کد؛
  • پرهیز از ساخت اطلاعات؛
  • ثبات پاسخ در چند اجرا.

پاسخ‌ها را با Rubric ثابت امتیازدهی کنید. کیفیت باید جدا از سرعت و نرخ موفقیت گزارش شود.

معیار چهارم: RAG و Embedding

برای RAG فقط وجود مدل چت کافی نیست. باید Endpoint Embedding، ابعاد بردار، Batch size، قیمت یا سهمیه، سقف توکن و کیفیت چندزبانه بررسی شود. اگر Provider Embedding ندارد، می‌توانید Embedding را از سرویس دیگری بگیرید و تولید پاسخ را به LLM جداگانه بسپارید.

در معماری RAG، داده بازیابی‌شده ممکن است حساس باشد. قبل از ارسال اسناد، سیاست Privacy و Retention را بررسی کنید. متن کامل دیتابیس را بدون فیلتر به Gateway ناشناس نفرستید.

معیار پنجم: Agent و Tool Calling

Agent به پاسخ متنی ساده محدود نیست. مدل باید بتواند ابزار را با نام و آرگومان معتبر فراخوانی کند. این موارد را تست کنید:

  • پشتیبانی واقعی از Tool Calling؛
  • چند Tool Call در یک پاسخ؛
  • خروجی JSON معتبر؛
  • رفتار هنگام خطای ابزار؛
  • امکان Streaming همراه Tool Call؛
  • محدودیت تعداد Schema یا اندازه تعریف ابزار؛
  • ثبات نام پارامترها.

هر Tool Call باید سمت سرور اعتبارسنجی شود. هرگز به مدل اجازه اجرای مستقیم Shell، SQL یا درخواست مالی بدون Policy و کنترل دسترسی ندهید.

معیار ششم: دسترسی و Region

Reachability وب‌سایت، موفقیت ثبت‌نام و Inference واقعی سه لایه جدا هستند. ممکن است Docs باز شود ولی ساخت حساب نیازمند شماره خارجی باشد. ممکن است API Endpoint پاسخ 401 بدهد، اما این فقط نشان می‌دهد مسیر شبکه قابل دسترسی است؛ ثابت نمی‌کند کاربر می‌تواند Credential معتبر بگیرد.

برای کاربران ایران، صفحه Provider و Evidence تاریخ‌دار را بررسی کنید. تغییر Route، ISP یا سیاست سرویس می‌تواند نتیجه را عوض کند. از ارائه دستور دورزدن محدودیت‌ها خودداری کنید و فقط روش‌های مجاز را ثبت کنید.

معیار هفتم: امنیت کلید

API Key یک Secret است. قواعد پایه:

  • کلید را در کد Frontend قرار ندهید؛
  • .env را Commit نکنید؛
  • برای هر پروژه کلید جدا بسازید؛
  • Scope را حداقل نگه دارید؛
  • مصرف و خطا را مانیتور کنید؛
  • در صورت نشت، Rotate انجام دهید؛
  • کلید را در Screenshot، Log یا Issue عمومی قرار ندهید.

اگر برنامه Browser-based است، درخواست باید از Backend شما عبور کند. Rate limit، Authentication کاربر و Budget control را در همان Backend اعمال کنید.

معماری پیشنهادی برای تعویض Provider

یک ساختار مقاوم می‌تواند این اجزا را داشته باشد:

  1. Interface داخلی برای Chat، Embedding و Tool Calling؛
  2. Adapter جدا برای هر Provider؛
  3. تنظیم مدل و Endpoint در Environment؛
  4. Timeout و Retry با Backoff؛
  5. Circuit Breaker برای خطاهای متوالی؛
  6. Fallback فقط برای وظایف قابل تکرار؛
  7. ثبت متریک بدون ذخیره متن حساس؛
  8. تست Contract برای هر Adapter؛
  9. Feature Flag برای تغییر مدل؛
  10. Budget و Rate limiter سمت برنامه.

Fallback کورکورانه خطر دارد. اگر درخواست مالی یا عملیاتی دوباره اجرا شود ممکن است اثر تکراری ایجاد کند. برای عملیات مهم از Idempotency Key و وضعیت تراکنش استفاده کنید.

سناریوهای انتخاب

چت‌بات فارسی

کیفیت زبان، Context، Latency اولین توکن و Privacy اولویت دارند. Streaming تجربه کاربری را بهتر می‌کند، اما باید قطع اتصال و پاسخ ناقص مدیریت شود.

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

کیفیت کد، Context فایل‌ها، Tool Calling و خروجی ساخت‌یافته مهم‌اند. مدل را با زبان‌ها و Frameworkهای پروژه خود آزمایش کنید.

پردازش دسته‌ای

برای خلاصه‌سازی یا طبقه‌بندی تعداد زیادی سند، TPM، Batch و هزینه پس از پایان Free Tier مهم‌تر از Latency یک درخواست است.

نمونه اولیه

سادگی ثبت‌نام و مستندات اهمیت دارد، ولی از ابتدا Adapter بسازید تا Trial یا مدل رایگان به قفل زیرساختی تبدیل نشود.

خطاهای رایج

  • استفاده از مدل قدیمی یا حذف‌شده؛
  • فرض یکسان‌بودن همه Endpointهای سازگار؛
  • نادیده‌گرفتن TPM؛
  • Retry نامحدود روی 429؛
  • ثبت Prompt حساس در Log؛
  • اعتماد به JSON بدون Schema Validation؛
  • استفاده از یک تست شبکه به‌عنوان مدرک دسترسی کامل؛
  • ساخت محصول روی Trial بدون مسیر جایگزین؛
  • نگهداری کلید در Repository؛
  • انتخاب مدل براساس تبلیغ به‌جای Benchmark داخلی.

پرسش‌های متداول

آیا API رایگان LLM برای Production مناسب است؟

برای بار محدود و غیرحیاتی ممکن است مناسب باشد، اما سهمیه، پشتیبانی و SLA باید بررسی شوند. برای سرویس حیاتی بهتر است برنامه مهاجرت یا قرارداد پرداختی داشته باشید.

کدام API برای فارسی بهتر است؟

پاسخ ثابت وجود ندارد. مدل‌ها را با Promptهای فارسی نماینده، Rubric و چند اجرای تکراری مقایسه کنید. نتیجه عمومی بدون ذکر مدل و تاریخ کافی نیست.

آیا می‌توان یک SDK را برای چند Provider استفاده کرد؟

اگر Endpoint سازگار باشد معمولاً بله، ولی قابلیت‌ها و فرمت خطا تفاوت دارند. Adapter و تست Contract ضروری است.

چگونه سهمیه را مدیریت کنیم؟

مصرف توکن و درخواست را اندازه بگیرید، Queue و Backoff داشته باشید، پاسخ‌های قابل Cache را ذخیره کنید و برای 429 Retry-After را رعایت کنید.

راهنماهای مرتبط

جمع‌بندی

API رایگان LLM بهترین ابزار برای آزمایش و ساخت سریع است، به شرطی که قرارداد فنی و محدودیت آن دقیق فهمیده شود. Provider را براساس وظیفه واقعی، سهمیه، کیفیت، Region، Privacy و قابلیت مهاجرت انتخاب کنید. برای داده به‌روز به کاتالوگ زنده مراجعه کنید و تغییرات مستند را در GitHub پروژه ثبت کنید.