مدل V4-Pro دیپ‌سیک محدودیت توکن را نادیده می‌گیرد و هزینه‌ها را ۱۶.۷ برابر کرد

۱۵٬۸۰۹ توکن؛ این حجم از مصرف برای تنها یک فراخوانی API در مدل V4-Pro دیپ‌سیک ثبت شده است، آن هم در حالی که توسعه‌دهنده صراحتاً سقف مصرف را روی ۳٬۰۷۲ توکن تنظیم کرده بود. این شکست در اجرای پارامترها، مدل هزینه‌ای پیش‌بینی‌پذیر را به یک قمار مالی برای برنامه‌نویسانی تبدیل می‌کند که در حال ساخت اپلیکیشن‌های بلادرنگ هستند.

این مشکل درست زمانی رخ می‌دهد که مدل‌های استدلالی (Reasoning Model) — مدل‌هایی که از روش «زنجیره افکار» (Chain-of-Thought) برای حل مسائل پیچیده استفاده می‌کنند و پیش از جواب، یک قدم درنگ می‌کنند و فکر می‌کنند، شبیه شطرنج‌بازی که چند حرکت جلوتر را می‌بیند — در حال تبدیل شدن به استاندارد جدید صنعت هستند. برای توسعه‌دهندگان، توانایی محدود کردن «محاسبات زمان تست» (test-time compute) یک تجمل نیست، بلکه ضرورتی برای جلوگیری از هزینه‌های سرسام‌آور و افزایش تأخیر در محیط‌های عملیاتی است.

به نقل از گزارش فنی منتشر شده در ۱۴ اوت ۲۰۲۶ توسط یک توسعه‌دهنده مستقل، مدل deepseek-v4-pro (نسخه انتشار عملیاتی V4-Pro-0813) محدودیت‌های توکن را به‌جای دستورات سخت، صرفاً پیشنهاداتی اختیاری می‌بیند. این آزمایش‌ها مستقیماً روی نقطه اتصال (Endpoint) رسمی دیپ‌سیک انجام شده است. این نوسانات در عملکرد مدل در حالی رخ می‌دهد که گزارش‌های اخیر از جهش توانایی کدنویسی این مدل هم‌زمان با تغییرات قیمت API خبر داده بودند.

پروژه Kai! و چالش کنترل هزینه

توسعه‌دهنده در حال ساخت بازی «Kai!» بود؛ یک بازی تک‌نفره تاس‌اندازی (Liar's Dice) که در آن یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — نقش حریف را ایفا می‌کند. این یک بات ساده و اسکریپت‌شده نیست؛ حریف هوش مصنوعی از همان موتور بازی بازیکن استفاده می‌کند، اطلاعات یکسانی را می‌بیند، افکارش را پیش از هر چالش فاش می‌کند و رفتار بازیکن را در طول دورهای مختلف بازی به خاطر می‌سپارد.

از آنجایی که مدل عملاً شخصیت حریف را تعریف می‌کند، توسعه‌دهنده به کنترل‌های سخت‌گیرانه روی تأخیر و هزینه نیاز داشت. در پروژه Kai، تعویض مدل عملاً یک حریف جدید می‌سازد؛ بنابراین سرعت و هزینه هر تصمیم، یک معیار محصولی حیاتی است، نه صرفاً یک عدد در بنچمارک‌های کنجکاوانه.

شکست در مدیریت بودجه

بر اساس بررسی‌های این توسعه‌دهنده، وقتی حالت استدلال به‌طور پیش‌فرض فعال است، مدل اغلب تمام بودجه توکن را صرف «تفکر» داخلی می‌کند و پیش از آنکه حتی یک کاراکتر از پاسخ نهایی تولید شود، سقف توکن تمام می‌شود. در یک تست، سه فراخوانی متوالی با سقف ۳٬۰۷۲ توکن، سه رشته متنی خالی برگرداندند، اما کاربر هزینه تمام توکن‌های تولید شده را پرداخت کرد.

جزئیات این شکست به شرح زیر است:

• فراخوانی اول: پایان به دلیل رسیدن به سقف (finish=length)، توکن‌های تولید شده ۳٬۰۷۱، توکن‌های استدلال ۳٬۰۷۱، کاراکترهای قابل مشاهده ۰ (۵۰ ثانیه)
• فراخوانی دوم: پایان به دلیل رسیدن به سقف (finish=length)، توکن‌های تولید شده ۳٬۰۷۲، توکن‌های استدلال ۳٬۰۷۲، کاراکترهای قابل مشاهده ۰ (۴۷ ثانیه)
• فراخوانی سوم: پایان به دلیل رسیدن به سقف (finish=length)، توکن‌های تولید شده ۳٬۰۷۲، توکن‌های استدلال ۳٬۰۷۲، کاراکترهای قابل مشاهده ۰ (۴۲ ثانیه)

این وضعیت منجر به یک تشخیص اشتباه شد: اپلیکیشن رشته‌های خالی را به‌عنوان حرکات غیرقانونی تفسیر کرد و داشبورد گزارش داد که مدل در ۹۴.۴٪ از دست‌ها (بر اساس دسته‌ای از داده‌های ۱۳ اوت) «از دستورات سرپیچی کرده است». در واقع، این یک شکست فنی در بودجه توکن بود، نه یک نقص رفتاری.

وقتی توسعه‌دهنده سعی کرد از پارامتر max_completion_tokens (سازگار با OpenAI) برای رفع این مشکل استفاده کند، API کد موفقیت HTTP 200 را برگرداند اما محدودیت را کاملاً نادیده گرفت. مدل ۱۵٬۸۰۹ توکن را در ۲۲۲ ثانیه تولید کرد، انگار که هیچ پارامتری ارسال نشده است.

بلعیدن خاموش پارامترها

بحرانی‌ترین بخش این نقص، سکوت API است. توسعه‌دهنده برای تست، یک پارامتر کاملاً ساختگی و بی‌معنی به نام totally_bogus_param: true ارسال کرد و API باز هم کد موفقیت HTTP 200 را برگرداند.

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

طبق گزارش این توسعه‌دهنده، اگرچه طراحی پروتکل OpenAI بخشی از مشکل است (چون max_tokens توکن‌های استدلال و خروجی را در یک بودجه مشترک قرار می‌دهد)، اما دیپ‌سیک با نادیده گرفتن پارامتر max_completion_tokens — که دقیقاً برای مدل‌های استدلالی طراحی شده بود — عملاً «نردبان را جمع کرد». مستندات OpenAI هشدار می‌دهد که بودجه بسیار کوچک می‌تواند منجر به پاسخ خالی شود، اما نادیده گرفتن کامل سقف توسط دیپ‌سیک، توانایی برنامه‌نویس برای پیش‌بینی و تخصیص هزینه‌ها را به‌طور کامل از بین می‌برد.

موازنه هزینه و عملکرد

تأثیر مالی این رفتار شدید است. توسعه‌دهنده هزینه هر پاسخ کاربردی را در تسک بازی تاس مقایسه کرد، جایی که پرامپت برای یک تصمیم حدود ۳٬۲۰۰ کاراکتر چینی است:

• استدلال خاموش: ۰.۰۱۰۵ یوان برای هر پاسخ
• استدلال روشن (بودجه ۸٬۱۹۲): ۰.۱۷۵ یوان برای هر پاسخ کاربردی

این یعنی افزایش ۱۶.۷ برابری هزینه. در مواردی که بودجه روی ۳٬۰۷۲ توکن بود، هزینه عملاً «بی‌نهایت» شد؛ چون هیچ پاسخ کاربردی تولید نشد اما تمام فراخوانی‌ها صورت‌حساب شدند. این چالش‌های هزینه‌ای دقیقاً همان نقطه‌ای است که راهکارهای جدیدی مانند لایه مسیریابی Tokenless برای حفظ کیفیت با مدل‌های ارزان‌تر پیشنهاد شده‌اند.

از نظر قیمت‌های رسمی، نسخه انتشار عملیاتی 0813 با قیمت ۰.۴۳/۰.۸۷ دلار به ازای هر میلیون توکن ورودی/خروجی عرضه شده است، در حالی که نقطه اتصال رسمی ۳/۶ یوان (تقریباً ۰.۴۲/۰.۸۵ دلار) دریافت می‌کرد. اگرچه این قیمت روی کاغذ حدود دو-سوم ارزان‌تر از نسخه‌های قدیمی در OpenRouter (با قیمت ۱.۱۷/۲.۳۴ دلار) است، اما ضریب هزینه به‌ازای هر پاسخ کاربردی، تمام این صرفه‌جویی‌ها را می‌بلعد.

مکانیسم تأخیر و بودجه‌بندی

تست‌ها روی چهار پیکربندی مختلف نشان داد که مصرف توکن‌های استدلال به‌شدت غیرقابل‌پیش‌بینی است. در یک تسک مشابه، توکن‌های استدلال بین ۳٬۱۳۷ تا ۵٬۶۹۱ متغیر بود و در حالت نادیده گرفتن محدودیت، مصرف به ۱۵٬۷۷۴ توکن رسید.

• حساسیت بودجه: بودجه ۳٬۰۷۲ توکن معمولاً دقیقاً در همین عدد متوقف می‌شد. بودجه ۸٬۱۹۲ نیز معمولاً نزدیک به همین مقدار بود. تنها سقف ۳۲٬۷۶۸ اجازه داد مدل به‌طور طبیعی و قابل‌اعتماد متوقف شود (با مصرف بین ۳٬۲۲۰ تا ۵٬۷۸۵ توکن).
• جهش تأخیر: فراخوانی‌های بدون استدلال ۲ تا ۴ ثانیه زمان بردند، اما فراخوانی‌های با استدلال بین ۴۹ تا ۲۲۲ ثانیه طول کشیدند.

برای بازی Kai که نیاز به ریتم ۳۰ تا ۶۰ ثانیه‌ای در هر دور دارد، تأخیر مدل‌های استدلالی باعث شد تجربه محصول به‌طور کامل از کار بیفتد.

کیفیت در برابر تأخیر

با وجود افزایش شدید مصرف توکن، حالت استدلال بهبود قابل‌اندازه‌گیری در کیفیت ایجاد نکرد. توسعه‌دهنده نسخه رسمی را با یک نسخه کوانتیده قدیمی در OpenRouter مقایسه کرد تا ببیند مدل در چه درصدی چالشی می‌زند که شکستش تضمین شده است (زمانی که پیشنهاد فعلی با استفاده از تاس‌های خود مدل، تضمین شده است که درست باشد):

• نسخه قدیمی (OpenRouter، کوانتیده): نرخ شکست ۱٪ (۱ از ۷۱)
• نسخه رسمی 0813 (نقطه اتصال رسمی): نرخ شکست ۹٪ (۲ از ۲۲)

اگرچه حجم نمونه برای نتیجه‌گیری آماری کوچک بود (z=1.22)، اما هیچ سیگنالی مبنی بر بهبود کیفیت دیده نشد. این مقایسه شامل حریف‌های مختلف، دانه‌های تصادفی (random seeds) و بازبینی‌های پرامپت بود، اما جهت سیگنال‌ها به سمت بهبود نبود.

علاوه بر این، پاسخ‌های قابل مشاهده در حالت استدلال (۱۱۷ تا ۱۴۰ کاراکتر) در واقع کمی کوتاه‌تر از حالت بدون استدلال (۱۲۳ تا ۱۵۶ کاراکتر) بودند. یعنی ۴۷ برابر توکن بیشتر و ۲۲ برابر تأخیر بیشتر، منجر به پاسخ کامل‌تری نشد.

راهکار غیرفعال‌سازی استدلال

همه پارامترها نادیده گرفته نمی‌شوند. توسعه‌دهنده دریافت که تنها دو دستور خاص با موفقیت حالت استدلال را غیرفعال می‌کنند:

• reasoning_effort: "none" (نتیجه: ۱۸ توکن، ۱ ثانیه)
• thinking: {type: "disabled"} (نتیجه: ۱۸ توکن، ۱ ثانیه)

سایر تلاش‌های رایج به‌طور خاموش نادیده گرفته شدند:

• enable_thinking: false
• chat_template_kwargs: {...}
• reasoning: {max_tokens: 1024} (محدودیت سبک OpenRouter)

این وضعیت یک ریسک سیستماتیک در اکوسیستم APIهای هوش مصنوعی را نشان می‌دهد. وقتی پروتکل اجازه می‌دهد استدلال و خروجی از یک بودجه مشترک استفاده کنند، فرآیند «تفکر» می‌تواند منابع پاسخ نهایی را به‌طور کامل ببلعد.

برای توسعه‌دهندگان، تکیه بر تنظیمات پیش‌فرض مدل‌های استدلالی یک ریسک است. نبود پاسخ خطا برای پارامترهای پشتیبانی‌نشده، عیب‌یابی سریع را غیرممکن می‌کند و کاربر را مجبور می‌کند از طریق صورت‌حساب متوجه نقص‌های فنی شود. API که خطا برمی‌گرداند در ۱۰ دقیقه عیب‌یابی می‌شود، اما API که به‌طور خاموش کد ۲۰۰ می‌دهد، کاربر را مجبور می‌کند از صورت‌حساب به عقب برگردد و مشکل را پیدا کند.

اگر در حال ادغام DeepSeek در یک گردش‌کار برنامه‌نویسی هستید، باید استدلال را با پارامترهای تأییدشده غیرفعال کنید تا از هزینه‌ها و تأخیرهای غیرقابل‌پیش‌بینی جلوگیری کنید.

گام بعدی شما

• اگر از مدل‌های V4-Pro استفاده می‌کنید، فوراً پارامتر reasoning_effort: "none" را برای تسک‌های ساده اضافه کنید.
• بودجه توکن خود را در محیط تست با مانیتورینگ لحظه‌ای صورت‌حساب بررسی کنید، نه فقط با کد پاسخ API.
• برای تسک‌هایی که تأخیر در آن‌ها حیاتی است، از مدل‌های غیر استدلالی یا نسخه‌های کوانتیده استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.