هوش مصنوعی اخیراً ۱۶ مسئله ریاضی را حل کرده است:۹ مورد با پادمثال (۵۶٫۳٪)
۷ مورد با اثبات (۴۳٫۸٪)
۱۰ مورد دارای اثبات رسمی (۶۲٫۵٪)
۸ مورد دارای شاهد یا گواهی دقیق و محدود (۵۰٪)
از ۱۱ مسئلهای که تاریخ مطرح شدنشان مشخص است، بهطور متوسط ۴۷ سال باز مانده بودند!جدول همراه، این مسائل را با سطح تأثیر (۱ تا ۵) فهرست کرده؛ از حدسهای گراف و هندسه گسسته گرفته تا مسائل معروف اردوش. مثلاً حدس Cycle Double Cover با اثبات و تأثیر ۵.
۷ مورد با اثبات (۴۳٫۸٪)
۱۰ مورد دارای اثبات رسمی (۶۲٫۵٪)
۸ مورد دارای شاهد یا گواهی دقیق و محدود (۵۰٪)
از ۱۱ مسئلهای که تاریخ مطرح شدنشان مشخص است، بهطور متوسط ۴۷ سال باز مانده بودند!جدول همراه، این مسائل را با سطح تأثیر (۱ تا ۵) فهرست کرده؛ از حدسهای گراف و هندسه گسسته گرفته تا مسائل معروف اردوش. مثلاً حدس Cycle Double Cover با اثبات و تأثیر ۵.
🔥6👍1
Dev Tweet
هوش مصنوعی اخیراً ۱۶ مسئله ریاضی را حل کرده است:۹ مورد با پادمثال (۵۶٫۳٪) ۷ مورد با اثبات (۴۳٫۸٪) ۱۰ مورد دارای اثبات رسمی (۶۲٫۵٪) ۸ مورد دارای شاهد یا گواهی دقیق و محدود (۵۰٪) از ۱۱ مسئلهای که تاریخ مطرح شدنشان مشخص است، بهطور متوسط ۴۷ سال باز مانده…
اینقدر چند روز اخیر ترند پیدا کردن مساله و دادت به gpt 5.6 sol در تایملاین ترند شده که تعداد مسائل حل شده به ۲۷ رسیده است.
منبع
منبع
X (formerly Twitter)
Jake Brukhman (@jbrukh) on X
Number of solved problems here went to 27, and there are probably more.
16 counterexamples, 10 proofs, and 1 exact computation.
16 counterexamples, 10 proofs, and 1 exact computation.
🔥4
Dev Tweet
اینقدر چند روز اخیر ترند پیدا کردن مساله و دادت به gpt 5.6 sol در تایملاین ترند شده که تعداد مسائل حل شده به ۲۷ رسیده است. منبع
نمونهای از یک مساله حل شده در رمزنگاری کوانتومی که ۶ سال حل نشده بود.
X (formerly Twitter)
Noam Brown (@polynoamial) on X
This was one of the bigger open questions in quantum cryptography
🔥4👍1
معمار ۱۷ سالهی Kimi K3
در ضمیمهی گزارش فنی Attention Residuals، تیم Kimi توضیح دربارهی ترتیب نویسندگان داده است: اسامی بر اساس اهمیت contribution مرتب شدهاند و افراد دارای نقش project leadership در انتهای فهرست آمدهاند.
نام اول فهرست Guangyu Chen است. کنار نام او، Yu Zhang و Jianlin Su علامت equal contribution دیده میشود. Guangyu Chen چن گوانگیو، دانشآموز ۱۷ سالهی چینی است. دو نویسندهی اول مشترک دیگر نیز آدمهای کمسابقهای نیستند: Zhang نویسندهی اول معماری Kimi Linear است و Su را با ابداع RoPE میشناسیم.
چهار ماه بعد از آن مقاله، Kimi مدل K3 را معرفی کرد؛ یک MoE با ۲.۸ تریلیون پارامتر که طبق توضیح رسمی شرکت، backbone آن بر دو بهروزرسانی معماری بنا شده است:Kimi Delta Attention برای جریان اطلاعات در امتداد sequence و Attention Residuals برای جریان اطلاعات در امتداد depth.
چن یکی از مشارکتکنندگان اصلی در طراحی یکی از primitives معماری K3 است.
سهم او دقیقاً چه بود؟
ایدهی Attention Residuals از یک ایراد ساده در residual stream شروع میشود. در Transformerهای متداول، خروجی لایهها با وزن ثابت روی هم جمع میشود. AttnRes این accumulation یکنواخت را با attention روی representationهای لایههای قبلی عوض میکند؛ بنابراین هر لایه میتواند یاد بگیرد که برای ورودی فعلی، اطلاعات کدام depth را بیشتر بازیابی کند.
وبلاگ K3 تا اینجا استفاده از AttnRes را تأیید کرده و جزئیات دقیق implementation را به technical report مدل سپرده است.
زنجیرهی مستند فعلی چنین است: چن یکی از سه نویسندهی اول مشترک AttnRes و یکی از دو طراح Block AttnRes بوده است.
مسیری که چن تا طراحی معماری کیمی طی کرد
چن متولد ۲۰۰۹ است و ورود جدیاش به پژوهش ML به سال ۲۰۲۵ برمیگردد. در فوریهی همان سال با پروژهای به نام ThirdArm در یک هکاتون دانشآموزی شرکت کرد؛ ایدهای دربارهی یک «دست سوم» کمکی برای انسان. آشناییهای همان رویداد، جهت کار او را به سمت فناوریهای frontier برد. پس از آن، شروع به خواندن paperها با کمک مدلهای زبانی و دنبالکردن پروژههای open-source در GitHub کرد.
نوشتههای فنیاش در شبکههای اجتماعی توجه مدیر یک استارتاپ کوچک در سیلیکونولی را جلب کرد. بعد از گذراندن آزمون ورودی، تابستان ۲۰۲۵ برای یک دورهی هفتهفتهای به آن تیم پیوست. در نوامبر همان سال نیز وارد Kimi شد؛
برخی گزارشها میگویند تیم Kimi او را از طریق فعالیتش در جامعهی open-source مربوط به Flash Linear Attention پیدا کرده بود. چهار ماه بعد، نامش بهعنوان co-first author گزارش Attention Residuals منتشر شد.
صفحهی شخصی او بیشتر شبیه homepage یک هکر است تا رزومهی رسمی یک پژوهشگر. خودش را «Guangyu Chen, aka Nathan» معرفی کرده، روی model architecture، optimization و continual learning کار میکند و میان علایقش از elegant kernels، CLI، open source، named hosts در SSH و asking LLMs first نام برده است.
فوریهی ۲۰۲۵ یک هکاتون دانشآموزی، تابستان همان سال یک دورهی هفتهفتهای در سیلیکونولی، نوامبر ورود به Kimi، مارس ۲۰۲۶ نویسندگی اول مشترک Attention Residuals و چهار ماه بعد حضور همان primitive در backbone مدل K3.
در ضمیمهی گزارش فنی Attention Residuals، تیم Kimi توضیح دربارهی ترتیب نویسندگان داده است: اسامی بر اساس اهمیت contribution مرتب شدهاند و افراد دارای نقش project leadership در انتهای فهرست آمدهاند.
نام اول فهرست Guangyu Chen است. کنار نام او، Yu Zhang و Jianlin Su علامت equal contribution دیده میشود. Guangyu Chen چن گوانگیو، دانشآموز ۱۷ سالهی چینی است. دو نویسندهی اول مشترک دیگر نیز آدمهای کمسابقهای نیستند: Zhang نویسندهی اول معماری Kimi Linear است و Su را با ابداع RoPE میشناسیم.
چهار ماه بعد از آن مقاله، Kimi مدل K3 را معرفی کرد؛ یک MoE با ۲.۸ تریلیون پارامتر که طبق توضیح رسمی شرکت، backbone آن بر دو بهروزرسانی معماری بنا شده است:Kimi Delta Attention برای جریان اطلاعات در امتداد sequence و Attention Residuals برای جریان اطلاعات در امتداد depth.
چن یکی از مشارکتکنندگان اصلی در طراحی یکی از primitives معماری K3 است.
سهم او دقیقاً چه بود؟
ایدهی Attention Residuals از یک ایراد ساده در residual stream شروع میشود. در Transformerهای متداول، خروجی لایهها با وزن ثابت روی هم جمع میشود. AttnRes این accumulation یکنواخت را با attention روی representationهای لایههای قبلی عوض میکند؛ بنابراین هر لایه میتواند یاد بگیرد که برای ورودی فعلی، اطلاعات کدام depth را بیشتر بازیابی کند.
وبلاگ K3 تا اینجا استفاده از AttnRes را تأیید کرده و جزئیات دقیق implementation را به technical report مدل سپرده است.
زنجیرهی مستند فعلی چنین است: چن یکی از سه نویسندهی اول مشترک AttnRes و یکی از دو طراح Block AttnRes بوده است.
مسیری که چن تا طراحی معماری کیمی طی کرد
چن متولد ۲۰۰۹ است و ورود جدیاش به پژوهش ML به سال ۲۰۲۵ برمیگردد. در فوریهی همان سال با پروژهای به نام ThirdArm در یک هکاتون دانشآموزی شرکت کرد؛ ایدهای دربارهی یک «دست سوم» کمکی برای انسان. آشناییهای همان رویداد، جهت کار او را به سمت فناوریهای frontier برد. پس از آن، شروع به خواندن paperها با کمک مدلهای زبانی و دنبالکردن پروژههای open-source در GitHub کرد.
نوشتههای فنیاش در شبکههای اجتماعی توجه مدیر یک استارتاپ کوچک در سیلیکونولی را جلب کرد. بعد از گذراندن آزمون ورودی، تابستان ۲۰۲۵ برای یک دورهی هفتهفتهای به آن تیم پیوست. در نوامبر همان سال نیز وارد Kimi شد؛
برخی گزارشها میگویند تیم Kimi او را از طریق فعالیتش در جامعهی open-source مربوط به Flash Linear Attention پیدا کرده بود. چهار ماه بعد، نامش بهعنوان co-first author گزارش Attention Residuals منتشر شد.
صفحهی شخصی او بیشتر شبیه homepage یک هکر است تا رزومهی رسمی یک پژوهشگر. خودش را «Guangyu Chen, aka Nathan» معرفی کرده، روی model architecture، optimization و continual learning کار میکند و میان علایقش از elegant kernels، CLI، open source، named hosts در SSH و asking LLMs first نام برده است.
فوریهی ۲۰۲۵ یک هکاتون دانشآموزی، تابستان همان سال یک دورهی هفتهفتهای در سیلیکونولی، نوامبر ورود به Kimi، مارس ۲۰۲۶ نویسندگی اول مشترک Attention Residuals و چهار ماه بعد حضور همان primitive در backbone مدل K3.
👏7
امسال در کنفرانس ICLR 2027
، سیاستهایی وضع شده که طبق آنها بازبینیکنندگان (reviewers) ملزم هستند:
(a) ابزارهای هوش مصنوعی که برای کمک به نوشتن بازبینی همتا استفاده کردهاند را افشا کنند، و
(b) ارزیابی اصلی و خودنوشتهشان به همراه هرگونه تعامل با LLM را گزارش دهند.ترجمه بخشهای هایلایتشده در تصویر (سیاست ICLR):
، سیاستهایی وضع شده که طبق آنها بازبینیکنندگان (reviewers) ملزم هستند:
(a) ابزارهای هوش مصنوعی که برای کمک به نوشتن بازبینی همتا استفاده کردهاند را افشا کنند، و
(b) ارزیابی اصلی و خودنوشتهشان به همراه هرگونه تعامل با LLM را گزارش دهند.ترجمه بخشهای هایلایتشده در تصویر (سیاست ICLR):
«اگر از LLMها برای تولید یا ویرایش هر بخشی از بازبینی (یا متا-بازبینی) خود استفاده کنید، ملزم خواهید بود که ارزیابی اصلی و خودنوشته مقاله و هرگونه تعامل با LLM را در یک جعبه متن جداگانه گزارش دهید. (با انجام این کار، به فکر پرش از LLM و ارسال مستقیم متن اصلی خود باشید! ما و نویسندگان، خیلی بیشتر به افکار ویرایشنشده شما علاقهمند هستیم تا آنچه یک LLM میگوید.)»
Dev Tweet
امسال در کنفرانس ICLR 2027 ، سیاستهایی وضع شده که طبق آنها بازبینیکنندگان (reviewers) ملزم هستند: (a) ابزارهای هوش مصنوعی که برای کمک به نوشتن بازبینی همتا استفاده کردهاند را افشا کنند، و (b) ارزیابی اصلی و خودنوشتهشان به همراه هرگونه تعامل با LLM…
این مربوط به بازبینیکنندگان و به تعبیر عامی نادقیق داوران است، اما سیاست نگارش مقاله با AI در کنفرانسها و مجلات چگونه است. در پست بعد ببینید
Dev Tweet
این مربوط به بازبینیکنندگان و به تعبیر عامی نادقیق داوران است، اما سیاست نگارش مقاله با AI در کنفرانسها و مجلات چگونه است. در پست بعد ببینید
سیاست نگارش مقاله با هوش مصنوعی در کنفرانسهای ۲۰۲۶-۲۰۲۷
سیاست اکثر کنفرانسهای بزرگ AI/ML در مورد استفاده از AI (مانند LLMها) برای نوشتن مقالات:سیاست کلی رایج (ICLR، NeurIPS، ICML و غیره):استفاده مجاز است، اما افشای (Disclosure) الزامی است.
نویسندگان باید به طور صریح توضیح دهند که از LLMها چگونه استفاده کردهاند (مثلاً برای ایدهپردازی، نوشتن بخشها، ویرایش گرامر، تولید جدول و غیره).
این افشا معمولاً هم در متن مقاله (در یک بخش جداگانه که در شمارش صفحات حساب نمیشود) و هم در فرم ارسال مقاله انجام میشود.
نویسندگان کاملاً مسئول محتوای مقاله هستند. اگر LLM باعث توهم (hallucination)، سرقت ادبی، یا اطلاعات غلط شود، ممکن است مقاله desk reject شود یا نقض اخلاقی محسوب گردد.
نمونههای سیاستنامهای در مورد استفاده از LLMها در نگارش مقاله از چند کنفرانس معروف:
(بهروز ۲۰۲۶-۲۰۲۷):ICLR 2027: افشای دقیق استفاده از LLM الزامی است.
مسئولیت کامل با نویسندگان است.
بخش AI Policy جداگانه برای نویسندگان و بازبینیکنندگان وجود دارد.
کنفرانس NeurIPS:استفاده از LLM برای آمادهسازی مقاله مطلوب است.
اگر بخشی از روششناسی (methodology) باشد، باید توصیف شود.
برای ویرایش گرامر و formatting معمولاً نیازی به اعلام نیست.
سایر کنفرانسها (CVPR، ICML، AAAI و غیره):روند مشابه: استفاده مجاز + افشا + مسئولیت کامل نویسندگان.
برخی کنفرانسها (مانند AAAI) نسبت به متن کاملاً تولیدشده توسط LLM سختگیرترند، اما ویرایش و polishing مجاز است.
نکته مهم: سیاستها هر سال ممکن است تغییر کند، پس همیشه صفحه Call for Papers و AI Policy کنفرانس مورد نظر را چک کنید. هدف اصلی حفظ اصالت، دقت علمی و مسئولیت انسانی است.
سیاست اکثر کنفرانسهای بزرگ AI/ML در مورد استفاده از AI (مانند LLMها) برای نوشتن مقالات:سیاست کلی رایج (ICLR، NeurIPS، ICML و غیره):استفاده مجاز است، اما افشای (Disclosure) الزامی است.
نویسندگان باید به طور صریح توضیح دهند که از LLMها چگونه استفاده کردهاند (مثلاً برای ایدهپردازی، نوشتن بخشها، ویرایش گرامر، تولید جدول و غیره).
این افشا معمولاً هم در متن مقاله (در یک بخش جداگانه که در شمارش صفحات حساب نمیشود) و هم در فرم ارسال مقاله انجام میشود.
نویسندگان کاملاً مسئول محتوای مقاله هستند. اگر LLM باعث توهم (hallucination)، سرقت ادبی، یا اطلاعات غلط شود، ممکن است مقاله desk reject شود یا نقض اخلاقی محسوب گردد.
نمونههای سیاستنامهای در مورد استفاده از LLMها در نگارش مقاله از چند کنفرانس معروف:
(بهروز ۲۰۲۶-۲۰۲۷):ICLR 2027: افشای دقیق استفاده از LLM الزامی است.
مسئولیت کامل با نویسندگان است.
بخش AI Policy جداگانه برای نویسندگان و بازبینیکنندگان وجود دارد.
کنفرانس NeurIPS:استفاده از LLM برای آمادهسازی مقاله مطلوب است.
اگر بخشی از روششناسی (methodology) باشد، باید توصیف شود.
برای ویرایش گرامر و formatting معمولاً نیازی به اعلام نیست.
سایر کنفرانسها (CVPR، ICML، AAAI و غیره):روند مشابه: استفاده مجاز + افشا + مسئولیت کامل نویسندگان.
برخی کنفرانسها (مانند AAAI) نسبت به متن کاملاً تولیدشده توسط LLM سختگیرترند، اما ویرایش و polishing مجاز است.
نکته مهم: سیاستها هر سال ممکن است تغییر کند، پس همیشه صفحه Call for Papers و AI Policy کنفرانس مورد نظر را چک کنید. هدف اصلی حفظ اصالت، دقت علمی و مسئولیت انسانی است.
در حالی که همه از کاهش قیمت مدلهای چینی حرف میزنند، نکته مهم و کمتر گفتهشده اینه که OpenAI امروز قیمت GPT-5.6 Luna رو ۸۰٪ و Terra رو ۲۰٪ کاهش داد + حالت Fast برای Sol با ۲٫۵ برابر سرعت. Auto-review هم با Luna حدود ۱۰ برابر ارزانتر شده. این حرکتها نتیجه بهینهسازیهایی هست که خودشون با GPT-5.6 Sol روی مدلهاشون انجام دادن. یعنی رقابت فقط از سمت چین نیست؛ OpenAI هم داره مرز قیمت-عملکرد رو با قدرت جلو میبره و هوش پیشرفته رو ارزانتر و در دسترستر میکنه.
ماه قبل از من NueralWatt یک اشتراک ۵۰ دلاری گرفتم
با پنجاه دلار به اندازهی ۱۳۰ دلار تونستم خرج کنم(یعنی اگر اون میزان توکنی که صرف کردم رو بصورت API Key مستقیم میخریدم میشد ۱۳۰ دلار)
و حدود یک میلیارد توکن مصرف کنم
البته نورالوات بیزینس مدل کاملا متفاوتی داره و به شما توکن نمیفروشه بلکه توان مصرفی رو میفروشه به بیان ساده بر حسب برق مصرفی برای شما فاکتور میکنه.
هر کیلووات رو ۵ دلار میفروشه.
در پلن ماه قبل با ۵۰ دلار ۱۶ کیلو وات میفروخت که واسهی GLM5.2 که من استفاده میکردم شد نزدیک یک میلیارد توکن
الان دیگه نمیصرفه!
هر ۱۰۰ دلارش شده ۱۳ کیلووات! از دوبرابر هم گرونتر شده.
الان صرفه با DeepSeek Flash V4 0731 هست!
همه جور providerای خوبه ولی InfraX تا ۲۰ آگوست تخفیفهای خوبی داره.
با پنجاه دلار به اندازهی ۱۳۰ دلار تونستم خرج کنم(یعنی اگر اون میزان توکنی که صرف کردم رو بصورت API Key مستقیم میخریدم میشد ۱۳۰ دلار)
و حدود یک میلیارد توکن مصرف کنم
البته نورالوات بیزینس مدل کاملا متفاوتی داره و به شما توکن نمیفروشه بلکه توان مصرفی رو میفروشه به بیان ساده بر حسب برق مصرفی برای شما فاکتور میکنه.
هر کیلووات رو ۵ دلار میفروشه.
در پلن ماه قبل با ۵۰ دلار ۱۶ کیلو وات میفروخت که واسهی GLM5.2 که من استفاده میکردم شد نزدیک یک میلیارد توکن
الان دیگه نمیصرفه!
هر ۱۰۰ دلارش شده ۱۳ کیلووات! از دوبرابر هم گرونتر شده.
الان صرفه با DeepSeek Flash V4 0731 هست!
همه جور providerای خوبه ولی InfraX تا ۲۰ آگوست تخفیفهای خوبی داره.
❤5
با ChatGPT شوخی نکنید
چند روز پیش داشتم با Hermes روی سرور، یکسری تست باگبانتی انجام میدادم. با خیال راحت فکر میکردم مدل فعال DeepSeek است؛ چون خودم Hermes را برای استفاده از یک پروایدر رایگان DeepSeek روی Infrex تنظیم کرده بودم.
وسط کار دو بار پیام مربوط به Cyber Abuse گرفتم، ولی خیلی جدی نگرفتم. چند ساعت بعد این ایمیل آمد:
اکانت شما بهدلیل فعالیت مرتبط با سوءاستفاده سایبری غیرفعال شده و دیگر قابل استفاده نیست.
نکته اینجا بود که تقریباً تمام استفادهی من از ChatGPT شامل پژوهش دکتری روی graph learning و fMRI، کدنویسی، تنظیم Kubernetes و سرور، تمرین زبان و سؤالهای روزمره دربارهی بچه بود.
تازه یک روز قبلش هم دوباره ۱۰۰ دلار برای ChatGPT Pro پرداخت کرده بودم!
بعد که دقیقتر بررسی کردم، فهمیدم چه اتفاقی افتاده است.
قبلاً به Codex لوکال خودم گفته بودم Hermes را روی سرور کانفیگ کند. Codex هم ظاهراً تصمیم گرفته بود هر جایی که امکان دارد، خودش را وارد تنظیمات کند؛ از جمله بهعنوان fallback مدل اصلی:
پروایدر DeepSeek من رایگان بود و وقتی لود زیاد میشد یا سرویس پاسخ نمیداد، Hermes بدون اینکه من متوجه شوم، از مدل اصلی خارج میشد و روی Codex با GPT-5.5 میرفت.
یعنی من فکر میکردم دارم تستهای باگبانتی را با DeepSeek انجام میدهم، ولی هر بار که DeepSeek جواب نمیداد، Codex خیلی نایس و مسئولیتپذیر وارد صحنه میشد و جواب میداد!
در واقع مسیر failover هرمس طوری بود که روی rate limit، خطای موقت پروایدر، قطعی سرویس یا تمام شدن retryها، بهصورت خودکار fallback فعال میشد.
خلاصه Codex آنقدر خوب Hermes را کانفیگ کرده بود که حتی وقتی قرار نبود از خودش استفاده شود، باز هم خودش را بهعنوان نیروی ذخیره گذاشته بود!
اعتراض زدم و توضیح دادم که ماجرا یک سوءاستفاده عمدی نبوده و هنگام تست ابزارها، بدون اطلاع من مدل از DeepSeek به GPT تغییر کرده است.
خوشبختانه بعد از بررسی جواب دادند:
پس اگر از agentها، مدلروترها، fallbackها یا ابزارهایی مثل Hermes استفاده میکنید، فقط به اسم مدلی که بالای ترمینال نوشته شده اعتماد نکنید. حتماً تنظیمات fallback و لاگ درخواستها را هم بررسی کنید؛ شاید فکر کنید دارید با یک مدل رایگان تست میکنید، ولی پشت صحنه GPT دارد جواب میدهد و همزمان برایتان پروندهی Cyber Abuse تشکیل میشود!
و البته باید اعتراف کنم:
البته انصافاً OpenAI در رسیدگی به اعتراض خیلی نایستر از Anthropic بود. یک appeal زدم، ماجرا را توضیح دادم و چند ساعت بعد اکانت را باز کردند و رسماً هم گفتند که غیرفعالسازی اشتباه بوده است.
چند روز پیش داشتم با Hermes روی سرور، یکسری تست باگبانتی انجام میدادم. با خیال راحت فکر میکردم مدل فعال DeepSeek است؛ چون خودم Hermes را برای استفاده از یک پروایدر رایگان DeepSeek روی Infrex تنظیم کرده بودم.
وسط کار دو بار پیام مربوط به Cyber Abuse گرفتم، ولی خیلی جدی نگرفتم. چند ساعت بعد این ایمیل آمد:
اکانت شما بهدلیل فعالیت مرتبط با سوءاستفاده سایبری غیرفعال شده و دیگر قابل استفاده نیست.
نکته اینجا بود که تقریباً تمام استفادهی من از ChatGPT شامل پژوهش دکتری روی graph learning و fMRI، کدنویسی، تنظیم Kubernetes و سرور، تمرین زبان و سؤالهای روزمره دربارهی بچه بود.
تازه یک روز قبلش هم دوباره ۱۰۰ دلار برای ChatGPT Pro پرداخت کرده بودم!
بعد که دقیقتر بررسی کردم، فهمیدم چه اتفاقی افتاده است.
قبلاً به Codex لوکال خودم گفته بودم Hermes را روی سرور کانفیگ کند. Codex هم ظاهراً تصمیم گرفته بود هر جایی که امکان دارد، خودش را وارد تنظیمات کند؛ از جمله بهعنوان fallback مدل اصلی:
fallback_model:
provider: openai-codex
model: gpt-5.5
پروایدر DeepSeek من رایگان بود و وقتی لود زیاد میشد یا سرویس پاسخ نمیداد، Hermes بدون اینکه من متوجه شوم، از مدل اصلی خارج میشد و روی Codex با GPT-5.5 میرفت.
یعنی من فکر میکردم دارم تستهای باگبانتی را با DeepSeek انجام میدهم، ولی هر بار که DeepSeek جواب نمیداد، Codex خیلی نایس و مسئولیتپذیر وارد صحنه میشد و جواب میداد!
در واقع مسیر failover هرمس طوری بود که روی rate limit، خطای موقت پروایدر، قطعی سرویس یا تمام شدن retryها، بهصورت خودکار fallback فعال میشد.
خلاصه Codex آنقدر خوب Hermes را کانفیگ کرده بود که حتی وقتی قرار نبود از خودش استفاده شود، باز هم خودش را بهعنوان نیروی ذخیره گذاشته بود!
اعتراض زدم و توضیح دادم که ماجرا یک سوءاستفاده عمدی نبوده و هنگام تست ابزارها، بدون اطلاع من مدل از DeepSeek به GPT تغییر کرده است.
خوشبختانه بعد از بررسی جواب دادند:
مشخص شد اکانت شما بهاشتباه غیرفعال شده است. دسترسی شما بازگردانده شد و بابت مشکلی که ایجاد شده عذرخواهی میکنیم.
پس اگر از agentها، مدلروترها، fallbackها یا ابزارهایی مثل Hermes استفاده میکنید، فقط به اسم مدلی که بالای ترمینال نوشته شده اعتماد نکنید. حتماً تنظیمات fallback و لاگ درخواستها را هم بررسی کنید؛ شاید فکر کنید دارید با یک مدل رایگان تست میکنید، ولی پشت صحنه GPT دارد جواب میدهد و همزمان برایتان پروندهی Cyber Abuse تشکیل میشود!
و البته باید اعتراف کنم:
البته انصافاً OpenAI در رسیدگی به اعتراض خیلی نایستر از Anthropic بود. یک appeal زدم، ماجرا را توضیح دادم و چند ساعت بعد اکانت را باز کردند و رسماً هم گفتند که غیرفعالسازی اشتباه بوده است.
👍6
Dev Tweet
قیمت ورودی و خروجی بیشتر پروایدرها تقریباً همان قیمت مستقیم DeepSeek است: ورودی ۰.۱۴ دلار و خروجی ۰.۲۸ دلار. اما توکن کششده را ۰.۰۲۸ دلار حساب میکنند؛ درحالیکه خود DeepSeek همان توکن را ۰.۰۰۲۸ دلار میفروشد. یعنی دقیقاً ۱۰ برابر.
در باب اهمیت فراوان قیمت cache در هزینه مصرف
بیشتر ما هنگام مقایسه قیمت API مدلها فقط دو ستون را میبینیم: Input Price و Output Price
در این جدول هم تقریباً همهچیز عادی به نظر میرسد. خود DeepSeek و چند پروایدر دیگر، ورودی را حدود ۰.۱۴ دلار و خروجی را حدود ۰.۲۸ دلار بهازای هر یک میلیون توکن قیمتگذاری کردهاند.
اما ستون مهمتر برای مصرف واقعی Agentها، ستون سوم است: Cache Read Price
خود DeepSeek برای هر یک میلیون توکن cache hit فقط ۰.۰۰۲۸ دلار میگیرد؛ اما تعدادی از پروایدرها همان cache read را ۰.۰۲۸ دلار قیمت زدهاند.
فقط یک صفر جابهجا شده، اما قیمت دقیقاً ۱۰ برابر شده است.
اهمیت این موضوع وقتی مشخص میشود که ببینیم Agentها چطور مصرف میکنند. در یک ابزار کدنویسی، هر درخواست کاملاً مستقل نیست. بخش بزرگی از prompt بارها تکرار میشود:
پرامپتsystem prompt، تعریف ابزارها، تاریخچه مکالمه، فایلهای قبلی، ساختار repository و context طولانی پروژه.
اگر prefix درخواست ثابت بماند، مدل لازم نیست همه این توکنها را دوباره از ابتدا پردازش کند. آنها از KV cache خوانده میشوند و قرار است بسیار ارزانتر حساب شوند.
اینجا مزیت قیمتگذاری DeepSeek مشخص میشود:
• ورودی input عادی: ۰.۱۴ دلار
•کش cache read: ۰.۰۰۲۸ دلار
یعنی cache hit در API مستقیم DeepSeek حدود ۵۰ برابر ارزانتر از input عادی است.
اما وقتی یک پروایدر cache read را ۰.۰۲۸ دلار میفروشد، تخفیف کش از ۵۰ برابر به فقط ۵ برابر کاهش پیدا میکند. در ظاهر قیمت ورودی و خروجی را دست نزده، ولی بخش مهمی از مزیت اقتصادی DeepSeek را حذف کرده است.
البته این به آن معنا نیست که کل قبض ۱۰ برابر میشود. این افزایش فقط مربوط به توکنهایی است که cache hit شدهاند.
مثلاً اگر ۹۰ درصد input از کش خوانده شود:
هزینه ورودی مستقیم DeepSeek حدود ۰.۰۱۶۵ دلار بهازای هر میلیون توکن میشود، اما نزد پروایدری با cache read برابر ۰.۰۲۸ دلار، همین مقدار به حدود ۰.۰۳۹۲ دلار میرسد.
یعنی هزینه بخش input حدود ۲.۴ برابر میشود، نه ۱۰ برابر. با اضافهشدن هزینه output، اختلاف کل صورتحساب از این هم کمتر خواهد شد.
بااینحال، در workloadهایی مثل coding agent، research agent، پردازش repository و سشنهای طولانی، این اختلاف اصلاً حاشیهای نیست. هرچه نسبت cache hit بالاتر باشد، قیمت cache بیشتر از قیمت اسمی input اهمیت پیدا میکند.
روترها و پروایدرهای ثالث میتوانند بابت fallback، دسترسی یکپارچه، محدودیت کمتر، latency بهتر یا availability بالاتر ارزش واقعی ایجاد کنند. اما مقایسه آنها فقط با دو عدد input و output ناقص است.
برای انتخاب یک پروایدر باید حداقل اینها را کنار هم دید:
قیمت cache read، نرخ واقعی cache hit، کیفیت و quantization مدل، throughput، latency و پایداری routing.
در مدلهای ارزان، گاهی گرانترین عدد جدول آن عددی نیست که بزرگتر دیده میشود؛ همان صفر کوچکی است که در ستون cache حذف شده.
بیشتر ما هنگام مقایسه قیمت API مدلها فقط دو ستون را میبینیم: Input Price و Output Price
در این جدول هم تقریباً همهچیز عادی به نظر میرسد. خود DeepSeek و چند پروایدر دیگر، ورودی را حدود ۰.۱۴ دلار و خروجی را حدود ۰.۲۸ دلار بهازای هر یک میلیون توکن قیمتگذاری کردهاند.
اما ستون مهمتر برای مصرف واقعی Agentها، ستون سوم است: Cache Read Price
خود DeepSeek برای هر یک میلیون توکن cache hit فقط ۰.۰۰۲۸ دلار میگیرد؛ اما تعدادی از پروایدرها همان cache read را ۰.۰۲۸ دلار قیمت زدهاند.
فقط یک صفر جابهجا شده، اما قیمت دقیقاً ۱۰ برابر شده است.
اهمیت این موضوع وقتی مشخص میشود که ببینیم Agentها چطور مصرف میکنند. در یک ابزار کدنویسی، هر درخواست کاملاً مستقل نیست. بخش بزرگی از prompt بارها تکرار میشود:
پرامپتsystem prompt، تعریف ابزارها، تاریخچه مکالمه، فایلهای قبلی، ساختار repository و context طولانی پروژه.
اگر prefix درخواست ثابت بماند، مدل لازم نیست همه این توکنها را دوباره از ابتدا پردازش کند. آنها از KV cache خوانده میشوند و قرار است بسیار ارزانتر حساب شوند.
اینجا مزیت قیمتگذاری DeepSeek مشخص میشود:
• ورودی input عادی: ۰.۱۴ دلار
•کش cache read: ۰.۰۰۲۸ دلار
یعنی cache hit در API مستقیم DeepSeek حدود ۵۰ برابر ارزانتر از input عادی است.
اما وقتی یک پروایدر cache read را ۰.۰۲۸ دلار میفروشد، تخفیف کش از ۵۰ برابر به فقط ۵ برابر کاهش پیدا میکند. در ظاهر قیمت ورودی و خروجی را دست نزده، ولی بخش مهمی از مزیت اقتصادی DeepSeek را حذف کرده است.
البته این به آن معنا نیست که کل قبض ۱۰ برابر میشود. این افزایش فقط مربوط به توکنهایی است که cache hit شدهاند.
مثلاً اگر ۹۰ درصد input از کش خوانده شود:
هزینه ورودی مستقیم DeepSeek حدود ۰.۰۱۶۵ دلار بهازای هر میلیون توکن میشود، اما نزد پروایدری با cache read برابر ۰.۰۲۸ دلار، همین مقدار به حدود ۰.۰۳۹۲ دلار میرسد.
یعنی هزینه بخش input حدود ۲.۴ برابر میشود، نه ۱۰ برابر. با اضافهشدن هزینه output، اختلاف کل صورتحساب از این هم کمتر خواهد شد.
بااینحال، در workloadهایی مثل coding agent، research agent، پردازش repository و سشنهای طولانی، این اختلاف اصلاً حاشیهای نیست. هرچه نسبت cache hit بالاتر باشد، قیمت cache بیشتر از قیمت اسمی input اهمیت پیدا میکند.
روترها و پروایدرهای ثالث میتوانند بابت fallback، دسترسی یکپارچه، محدودیت کمتر، latency بهتر یا availability بالاتر ارزش واقعی ایجاد کنند. اما مقایسه آنها فقط با دو عدد input و output ناقص است.
برای انتخاب یک پروایدر باید حداقل اینها را کنار هم دید:
قیمت cache read، نرخ واقعی cache hit، کیفیت و quantization مدل، throughput، latency و پایداری routing.
در مدلهای ارزان، گاهی گرانترین عدد جدول آن عددی نیست که بزرگتر دیده میشود؛ همان صفر کوچکی است که در ستون cache حذف شده.
👍3❤1
سرورهای GPU رومیزی مثل DGX Spark کمکم دارند از یک اسباببازی گرانقیمت به زیرساختی واقعاً جدی تبدیل میشوند.
در این تست، دو DGX Spark مدل DeepSeek V4 Flash 0731 را با پشتیبانی از کانتکست یکمیلیونی، روی یک درخواست به حدود ۹۶ توکنبرثانیه و روی دو درخواست همزمان به ۱۵۲ توکنبرثانیه تجمیعی رساندهاند.
این عدد از API رسمی DeepSeek سریعتر نیست؛ API خود DeepSeek در تستهای مستقل حدود ۱۰۴ توکنبرثانیه خروجی میدهد. جذابیت واقعی ماجرا چیز دیگری است: یک سیستم رومیزی حالا میتواند مدلی در این ابعاد را با سرعتی نزدیک به زیرساخت ابری، کاملاً لوکال و تحت کنترل خودتان اجرا کند.
تا قبل از مدلهایی مثل DeepSeek، خرید چنین سختافزاری برای استفاده شخصی چندان معقول نبود؛ اما مدلهای MoE کوچکتر، کوانتایز بهتر و speculative decoding دارند کمکم این معادله را تغییر میدهند.
اگر مدلی با کیفیت نزدیک به DeepSeek V4 روی یک Spark با چنین سرعتی اجرا شود، آنوقت خرید این دستگاهها واقعاً میتواند برای توسعهدهندهها و تیمهای کوچک وسوسهکننده شود.
اگر پولش را داشتم، جدی به خریدش فکر میکردم :)
در این تست، دو DGX Spark مدل DeepSeek V4 Flash 0731 را با پشتیبانی از کانتکست یکمیلیونی، روی یک درخواست به حدود ۹۶ توکنبرثانیه و روی دو درخواست همزمان به ۱۵۲ توکنبرثانیه تجمیعی رساندهاند.
این عدد از API رسمی DeepSeek سریعتر نیست؛ API خود DeepSeek در تستهای مستقل حدود ۱۰۴ توکنبرثانیه خروجی میدهد. جذابیت واقعی ماجرا چیز دیگری است: یک سیستم رومیزی حالا میتواند مدلی در این ابعاد را با سرعتی نزدیک به زیرساخت ابری، کاملاً لوکال و تحت کنترل خودتان اجرا کند.
تا قبل از مدلهایی مثل DeepSeek، خرید چنین سختافزاری برای استفاده شخصی چندان معقول نبود؛ اما مدلهای MoE کوچکتر، کوانتایز بهتر و speculative decoding دارند کمکم این معادله را تغییر میدهند.
اگر مدلی با کیفیت نزدیک به DeepSeek V4 روی یک Spark با چنین سرعتی اجرا شود، آنوقت خرید این دستگاهها واقعاً میتواند برای توسعهدهندهها و تیمهای کوچک وسوسهکننده شود.
اگر پولش را داشتم، جدی به خریدش فکر میکردم :)
👍6❤1
Zoomit | زومیت
درآمد بخش دیتاسنتر AMD با تکیه بر تقاضای بالای زیرساختهای هوش مصنوعی به ۶٫۷ میلیارد دلار رسید که نسبت به ۳٫۲ میلیارد دلار در مدت مشابه سال گذشته، بیش از دو برابر شده است. مجموع درآمد این شرکت با ۵۰ درصد رشد سالانه به ۱۱٫۵ میلیارد دلار افزایش یافت و بخش دیتاسنتر ۵۸ درصد از این موفقیت را به خود اختصاص داد.
Telegram
Dev Tweet
همه جا حرف از Nvidia است. پس AMD کجای بازی است؟
در حالی که انویدیا (Nvidia) با ارزش بازاری خیرهکننده و تسلط مطلق بر فضای رسانهای، به "پادشاه بلامنازع" عصر هوش مصنوعی تبدیل شده است، در لایههای زیرین زیرساختهای پردازشی دنیا، اتفاقات متفاوتی در حال رخ دادن…
در حالی که انویدیا (Nvidia) با ارزش بازاری خیرهکننده و تسلط مطلق بر فضای رسانهای، به "پادشاه بلامنازع" عصر هوش مصنوعی تبدیل شده است، در لایههای زیرین زیرساختهای پردازشی دنیا، اتفاقات متفاوتی در حال رخ دادن…
ارزانتر از DeepSeek؛ اما با چه قیمتی؟!
متا نسخه جدید Muse Spark 1.2 را منتشر کرده؛ یک آپدیت متمرکز بر کدنویسی و کارهای Agentic که برای تولید و دیباگ کد، درک کدبیسهای بزرگ و انجام تسکهای طولانی مهندسی نرمافزار بهینه شده است. این مدل کانتکست یکمیلیونتوکنی دارد و موتور مدل جدید Muse Code، ایجنت ترمینالی متا برای انجام پروژههای نرمافزاری، هم هست.
اما شاید جالبترین بخش انتشار آن، نه خود مدل، بلکه مدل قیمتگذاریاش باشد:
متا میگوید اگر اجازه بدهید درخواستها و توکنهای شما برای بهبود محصولاتش استفاده شوند، قیمت API بهشدت کاهش پیدا میکند؛ آنقدر که Muse حتی از DeepSeek-V4-Flash هم ارزانتر درمیآید.
مدل Muse Spark 1.2 Contributor
ورودی بدون کش: $0.10
ورودی کششده: $0.002
خروجی: $0.20
مدل DeepSeek-V4-Flash
ورودی بدون کش: $0.14
ورودی کششده: $0.0028
خروجی: $0.28
یعنی پلن Contributor متا در هر سه بخش تقریباً ۲۹ درصد از DeepSeek ارزانتر است.
البته این تخفیف رایگان نیست؛ در واقع متا دارد بخشی از ارزش دادههای usage شما را با کاهش قیمت API پس میدهد. بهتر است هم نگوییم الزاماً «روی تکتک توکنها train میکند»؛ عبارت دقیقتر این است که دادهها میتوانند برای بهبود محصولات متا استفاده شوند.
جالبتر اینکه فاصله میان دو پلن خود متا بسیار زیاد است:
مدل Muse Spark 1.2 معمولی
(دادهها برای بهبود محصولات استفاده نمیشوند.)
ورودی بدون کش: $1.25
ورودی کششده: $0.15
خروجی: $4.25
در مقایسه با پلن Contributor:
ورودی ۱۲.۵ برابر
ورودی کششده ۷۵ برابر
خروجی بیش از ۲۱ برابر
گرانتر است!
ظاهراً توکن ارزانتر شده؛ اما اینبار بخشی از هزینه را بهجای پول، با داده پرداخت میکنید.
رقابت دیگه فقط بر سر کیفیت مدل نیست؛ رقابت بر سر اقتصاد inference و ارزش دادههای کاربران است.
متا نسخه جدید Muse Spark 1.2 را منتشر کرده؛ یک آپدیت متمرکز بر کدنویسی و کارهای Agentic که برای تولید و دیباگ کد، درک کدبیسهای بزرگ و انجام تسکهای طولانی مهندسی نرمافزار بهینه شده است. این مدل کانتکست یکمیلیونتوکنی دارد و موتور مدل جدید Muse Code، ایجنت ترمینالی متا برای انجام پروژههای نرمافزاری، هم هست.
اما شاید جالبترین بخش انتشار آن، نه خود مدل، بلکه مدل قیمتگذاریاش باشد:
متا میگوید اگر اجازه بدهید درخواستها و توکنهای شما برای بهبود محصولاتش استفاده شوند، قیمت API بهشدت کاهش پیدا میکند؛ آنقدر که Muse حتی از DeepSeek-V4-Flash هم ارزانتر درمیآید.
مدل Muse Spark 1.2 Contributor
ورودی بدون کش: $0.10
ورودی کششده: $0.002
خروجی: $0.20
مدل DeepSeek-V4-Flash
ورودی بدون کش: $0.14
ورودی کششده: $0.0028
خروجی: $0.28
یعنی پلن Contributor متا در هر سه بخش تقریباً ۲۹ درصد از DeepSeek ارزانتر است.
البته این تخفیف رایگان نیست؛ در واقع متا دارد بخشی از ارزش دادههای usage شما را با کاهش قیمت API پس میدهد. بهتر است هم نگوییم الزاماً «روی تکتک توکنها train میکند»؛ عبارت دقیقتر این است که دادهها میتوانند برای بهبود محصولات متا استفاده شوند.
جالبتر اینکه فاصله میان دو پلن خود متا بسیار زیاد است:
مدل Muse Spark 1.2 معمولی
(دادهها برای بهبود محصولات استفاده نمیشوند.)
ورودی بدون کش: $1.25
ورودی کششده: $0.15
خروجی: $4.25
در مقایسه با پلن Contributor:
ورودی ۱۲.۵ برابر
ورودی کششده ۷۵ برابر
خروجی بیش از ۲۱ برابر
گرانتر است!
ظاهراً توکن ارزانتر شده؛ اما اینبار بخشی از هزینه را بهجای پول، با داده پرداخت میکنید.
رقابت دیگه فقط بر سر کیفیت مدل نیست؛ رقابت بر سر اقتصاد inference و ارزش دادههای کاربران است.
Muse Spark 1.2 | Meta
Optimized for real coding workflows, with higher first-attempt accuracy and more reliable tool calling. Muse Spark 1.2 on Meta Model API with 1M token context.
❤4