تصور کنید برنامهنویسی هستید که اکنون میتواند در کنار متن، تصاویر را نیز پردازش کند تا نمودارهای پیچیده را تحلیل کند، اسکرینشاتها را بخواند و صحنههای بصری را با استفاده از مدل deepseek-v4-flash-vision-exp توصیف کند. طبق مستندات رسمی منتشر شده در ۲۱ اوت ۲۰۲۶، این مدل از فرمتهای JPEG، PNG، GIF و WebP پشتیبانی میکند و نوع فایل را بهجای تکیه بر نام فایل یا MIME type، مستقیماً از محتوای فایل تشخیص میدهد.
قابلیتهای چندوجهی (Multimodal) — شبیه به ما که با چند حس مختلف دنیا را میخوانیم و همزمان متن، عکس و صدا را میفهمیم — دیگر مختص مدلهای غولپیکر و پیشرو (Frontier Models) نیستند و به نسخههای «فلش» (Flash) که برای سرعت بالا و بهرهوری بهینه شدهاند، منتقل شدهاند. همانطور که در تحلیلهای قبلی ما دربارهی بهینهسازی مدلهای کوچک اشاره کردیم، چالش اصلی توسعهدهندگان همواره ایجاد تعادل بین کیفیت تصویر، تأخیر در پاسخ (Latency) و هزینه توکنها بوده است. این روند تکامل مدلهای متنی به سمت درک بصری، مشابه رویکردی است که در افزودن بینایی و استدلال محلی به مدلهای کدنویسی مشاهده کردیم. دیپسیک برای حل این چالش، سه مسیر مجزا برای ورود دادههای تصویری ارائه داده است که بسته به اندازه فایل و دفعات استفاده، قابل انتخاب هستند.
سه روش ورودی تصویر
توسعهدهندگان میتوانند تصاویر را با استفاده از فرمت استاندارد Chat Completions (سازگار با OpenAI) ارسال کنند؛ در این ساختار، محتوا بهجای یک رشته متنی ساده، آرایهای از بلوکها است. آدرس پایه (base_url) برای این درخواستها https://api.deepseek.com است.
نخست، روش رمزگذاری Base64 است که در آن تصویر مستقیماً به عنوان یک Data URL در بدنه درخواست جاسازی میشود. این سریعترین مسیر برای فایلهای محلی است، هرچند که حجم آن در محدودیت ۴۸ مگابایتی بدنه درخواست محاسبه میشود. برای مثال، یک درخواست در این حالت از بلوک type: "image_url" با فرمت data:image/jpeg;base64,<BASE64_DATA> استفاده میکند.
دومین روش، پذیرش لینکهای خارجی HTTP(S) است. در این حالت، سیستم بهطور خودکار تصویر را دانلود میکند، به شرطی که طول URL کمتر از ۸,۱۹۲ کاراکتر و حجم فایل زیر ۳۲ مگابایت باشد. این فرآیند دانلود باید در کمتر از ۶۰ ثانیه تکمیل شود تا با خطای Timeout مواجه نشود. اگر طول یک لینک از حد مجاز کاراکترها فراتر رود، توسعهدهندگان تشویق میشوند که از Files API یا URLهای Base64 استفاده کنند.
برای کاربردهای صنعتی، حجیم یا مقیاسبزرگ، Files API بهینهترین گزینه است. توسعهدهندگان با یکبار آپلود تصویر و ارجاع به file_id آن (که با فرمت file-api-... است)، از آپلود مکرر یک دارایی بصری در درخواستهای متعدد جلوگیری میکنند. این روش همچنین محدودیت حجم تکتصویر را به ۶۴ مگابایت افزایش میدهد و بررسی ۳۲ مگابایتی که در سایر روشها اعمال میشود را دور میزند.
جزئیات پیادهسازی و گزینههای فنی
بسته به API مورد استفاده، ساختار بلوک تصویر متفاوت است:
- فرمت OpenAI: از
image_urlبرای لینکها و Base64، یا ازfileبه همراهfile_idبرای داراییهای آپلود شده استفاده میکند. - Files API Inline: یک بلوک فایل میتواند تصویر را بهصورت داخلی از طریق
file_data(به صورت base64) و یکfilenameحمل کند، بهجای استفاده ازfile_id. این دو فیلد (file_idوfile_data) mutually exclusive هستند و نمیتوانند همزمان استفاده شوند. - Responses API: تصاویر در بخشهای محتوایی
input_imageقرار میگیرند. این بخشها میتوانند در پیامهای کاربر/توسعهدهنده یا در آیتمهایfunction_call_outputوcustom_tool_call_outputظاهر شوند.
محدودیتهای فنی و توکنگذاری (Tokenization)
دیپسیک یک منطق تغییر اندازه (Resizing) خاص را پیاده کرده است تا هزینهها پیشبینیپذیر باقی بمانند. پیش از مرحله استنتاج (Inference) — یعنی همان لحظهای که مدل واقعاً جواب تولید میکند، شبیه به آشپزی بعد از یادگیری دستور پخت — هر تصویر بهطور خودکار بر اساس ابعادش تغییر اندازه میدهد:
- بزرگنمایی (Upscaling): تصاویری که تعداد کل پیکسلهای آنها کمتر از تقریباً ۳۸۴ در ۳۸۴ است، با حفظ نسبت ابعاد، بزرگنمایی میشوند.
- کوچکنمایی (Downscaling): تصاویر بزرگتر بهگونهای کوچک میشوند که تعداد کل پیکسلها تقریباً معادل یک تصویر ۸۰۰ در ۸۰۰ باشد، در حالی که نسبت ابعاد حفظ میشود.
این سازوکار باعث میشود یک سقف سخت (Hard Upper Bound) برای مصرف توکنها ایجاد شود: هر تصویر حداکثر ۳۸۴ توکن مصرف میکند. فرقی نمیکند شما یک تصویر ۲,۰۰۰ در ۲,۰۰۰ یا ۵,۰۰۰ در ۵,۰۰۰ آپلود کنید؛ مصرف توکن پس از تغییر اندازه یکسان خواهد بود. در درخواستهای چند-تصویری، هر تصویر بهطور مستقل تحت این قانون محاسبه و صورتحساب میشود و محاسبه جداگانهای برای کل درخواست وجود ندارد.
توسعهدهندگان همچنین میتوانند با استفاده از فیلد detail برای ورودیهای image_url و input_image عمق پردازش را کنترل کنند:
- low: تصویر پیش از استنتاج به ۵۱۲ در ۵۱۲ کاهش مییابد. این حالت سریعتر و ارزانتر است و زمانی کاربرد دارد که جزئیات بصری دقیق اهمیت ندارند.
- high: تصویر اصلی را حفظ میکند (برای سازگاری ارائه شده است).
- original: تصویر اصلی را حفظ میکند.
- auto: انتخاب خودکار است که در حال حاضر معادل حالت "original" عمل میکند.
لازم به ذکر است که فیلد detail زمانی که تصویر از طریق file_id ارائه شود، نادیده گرفته میشود.
سازگاری API و محدودیتهای سیستمی
علاوه بر نقطه اتصال سازگار با OpenAI، دیپسیک یک Endpoint سازگار با آنتروپیک (Anthropic) در مسیر /messages فراهم کرده است. این قابلیت به تیمهایی که از SDK آنتروپیک استفاده میکنند اجازه میدهد تا تنها با تغییر base_url به https://api.deepseek.com/anthropic و تنظیم ساختار بلوک تصویر، مدل خود را تغییر دهند.
در فرمت آنتروپیک، image_url جای خود را به یک بلوک image با یک شیء source میدهد. مقدار source.type میتواند base64 (که نیاز به فیلد media_type مانند image/png دارد)، url یا file باشد. ارجاع به فایل از طریق Endpoint آنتروپیک مستلزم ارسال هدر anthropic-beta: files-api-2025-04-14 است.
برای جلوگیری از خطاها، محدودیتهای سختگیرانهای اعمال شده است:
- نقش پیام (Message Role): تصاویر فقط در پیامهای کاربر (User) پشتیبانی میشوند. قرار دادن آنها در پیامهای سیستمی (System) یا دستیار (Assistant) منجر به خطای ۴۰۰ میشود.
- پشتیبانی مدل: تنها مدلهای مخصوص بینایی مانند
deepseek-v4-flash-vision-expتصاویر را میپذیرند؛ سایر مدلها خطای ۴۰۰ با متن "This model does not support image" بازمیگردانند. - توکنهای رزرو شده: اگر متن کاربر حاوی توکن رزرو شده برای جایگاه تصویر باشد، درخواست با خطای ۴۰۰ رد میشود.
خلاصه محدودیتهای سیستم
محدودیتهای API برای جلوگیری از سوءاستفاده از سیستم بهوضوح تعریف شدهاند:
- اندازه بدنه درخواست: محدودیت ۴۸ مگابایت برای تصاویر داخلی (Inline).
- اندازه تصویر: حداکثر ۳۲ مگابایت برای Base64 و URLهای خارجی؛ حداکثر ۶۴ مگابایت برای
file_idدر Files API. - حجم درخواست: تا ۶۰۰ تصویر در هر درخواست.
- اندازه کل درخواست: ۶۴ مگابایت بدون تصاویر
file_id؛ تا ۲۰۰ مگابایت در صورت استفاده از تصاویرfile_id. - ابعاد: حداکثر ۸,۱۹۲ پیکسل برای هر ضلع. این مقدار زمانی که یک درخواست شامل ۱۵ تصویر یا بیشتر باشد، به ۴,۰۹۶ پیکسل برای هر ضلع کاهش مییابد.
این زیرساخت نشان میدهد که دیپسیک مدل بینایی خود را برای کاربردهای صنعتی با توان عملیاتی بالا، مانند پردازش خودکار اسناد یا نظارت بصری لحظهای، هدفگذاری کرده است و نه صرفاً برای تعاملات ساده چت. این رویکرد صنعتی در سایر ابزارها نیز دیده میشود، برای مثال عاملهای چندوجهی Oxlo.ai از قابلیتهای مشابه برای خودکارسازی تحلیل ریشهای حوادث SRE استفاده کردهاند.
با استانداردسازی هزینههای توکن و ارائه مسیرهای مختلف آپلود، دیپسیک «اضطراب توکن» (Token Anxiety) را که معمولاً با مدلهای LLM چندوجهی همراه است، کاهش داده است. حرکت به سمت سازگاری با آنتروپیک و OpenAI همچنین اصطکاک مهاجرت برای سازمانهای سازمانی را به شدت کاهش میدهد.
گام بعدی شما
- اگر از SDK آنتروپیک استفاده میکنید، تنها با تغییر
base_urlبهhttps://api.deepseek.com/anthropicمدل را تست کنید. - برای تخمین دقیق هزینهها، از ماشینحساب توکن در صفحه DeepSeek Token Usage استفاده کنید تا هزینه ابعاد خاص تصاویر را برآورد کنید.
- در پروژههایی که تکرار تصاویر زیاد است، حتماً از Files API برای کاهش حجم ترافیک و افزایش سرعت استفاده کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو