برای اولین بار در تاریخ، هزینه‌ی انسان از نرم‌افزار کمتر شده است

این دو نمودار در واقع بخشی از مقاله‌ی George Sivulka (بنیان‌گذار Hebbia) در خبرنامه a16z هستند با عنوان:
You Just Hired a Million Bad Employees — For the first time in history, humans are cheaper than software
«تبریک! شما یک میلیون کارمندِ کم‌بازده استخدام کرده‌اید؛ و برای اولین بار در تاریخ، هزینه‌ی انسان از نرم‌افزار کمتر شده است.»

تز اصلی مقاله این است که:

اگر AI را مثل یک میلیون کارمند تازه‌استخدام‌شده ببینی، مشکل اصلی دیگر کیفیت مدل نیست؛ مشکل مدیریت، هماهنگی و orchestration آن‌هاست. همان‌طور که با بزرگ شدن راه‌آهن، شغل "مدیر" به وجود آمد، حالا هم با انفجار Agentها، لایه‌ی جدیدی از مدیریت AI لازم می‌شود.

طبق داده‌های Ramp روی ده‌ها هزار شرکت آمریکایی، شرکت‌هایی که در سنگین‌ترین ۱٪ مصرف‌کنندگان AI قرار دارند، حالا سالانه نزدیک ۹۰ هزار دلار به ازای هر کارمند فقط برای AI خرج می‌کنند؛ و اگر همین نرخ رشد ادامه پیدا کند، این عدد تا پایان سال می‌تواند از هزینه‌ی سالانه‌ی یک Software Engineer هم عبور کند.
این یعنی برای اولین بار، در بعضی شرکت‌ها نرم‌افزار دارد به اندازه‌ی نیروی انسانی هزینه می‌سازد.
اما بخش جالب‌تر ماجرا نمودار دوم است.
شرکت‌هایی که بیشترین سرمایه‌گذاری روی AI را داشته‌اند، طی دو سال بعد از پذیرش AI حدود ۱۰٪ رشد نیروی انسانی داشته‌اند؛ در حالی که شرکت‌های کم‌مصرف تقریباً بدون تغییر مانده‌اند.
البته این رابطه‌ی علّی را ثابت نمی‌کند.
ممکن است شرکت‌های در حال رشد، طبیعتاً بیشتر هم روی AI خرج کنند.
اما یک تصور رایج را زیر سؤال می‌برد:
«هوش مصنوعی آمد تا آدم‌ها را حذف کند.»
حداقل فعلاً، داده‌ها بیشتر دارند چیز دیگری می‌گویند.
شاید مسئله‌ی اصلی، کم شدن تعداد نیروی انسانی نباشد؛
بلکه این باشد که هر انسان، حالا باید ارتشی از Agentها را مدیریت کند.
و اگر این روند ادامه پیدا کند، شاید مهارت ارزشمند چند سال آینده دیگر صرفاً Prompt Engineering یا حتی Coding نباشد.
بلکه مدیریت هزاران دلار مصرف توکن، هماهنگ کردن Agentها و جلوگیری از هدررفت آن‌ها باشد.

پ.ن: نویسنده جورج سیوولکا است، بنیان‌گذار Hebbia؛ استارتاپی که بسیاری آن را از پیشروترین شرکت‌های AI Agent برای تحلیل اسناد و گردش‌کارهای دانشی در سازمان‌ها می‌دانند.
یکی از جدی‌ترین استارتاپ‌های AI سازمانی که امروز در قلب وال‌استریت و بازار مالی آمریکا استفاده می‌شود.

چندباری از دیشب دیدم که به این نکته اشاره میکنند.
مدل kimi 3 اون همه guardrailهای دست و پاگیر مدلهای غربی رو نداره و خیلی کارهایی که fable و codex جلوگیری می‌کنند رو راحت انجام میده.

🚨از انتشار آسیب‌پذیری تا گرفتن شل؛ فقط چند ساعت!

چند روز پیش یک آسیب‌پذیری بحرانی به اسم WP2Shell در هسته‌ی وردپرس منتشر شد؛ از نوع Pre-Auth RCE. یعنی روی نسخه‌های آسیب‌پذیر، بدون لاگین، بدون پلاگین خاص و فقط با یک درخواست HTTP می‌شه به اجرای کد روی سرور رسید.
اما چیزی که برای من ترسناک‌تر از خود آسیب‌پذیری بود، سرعت تبدیل‌شدنش به حمله بود.
خیلی تفریحی با یه ایجنت هوش مصنوعی روی دو تا سرور تست کردم؛ هر دو شل دادن😎. نکته جالب‌تر اینکه روی یکی‌شون، قبل از من یکی دیگه شلش رو آپلود کرده بود 🥲🥲😐😐
هنوز ۲۴ ساعت از انتشار آسیب‌پذیری نگذشته بود!
چیزی که قبلاً برای اکسپلویت‌کردنش دانش فنی، ابزار و زمان می‌خواست، الان یک ایجنت می‌تونه در چند دقیقه تحلیل، آماده و اجراش کنه.
قصه فقط وردپرس یا WP2Shell نیست؛ هوش مصنوعی فاصله‌ی بین «افشای یک آسیب‌پذیری» و «شروع حملات گسترده» رو از چند روز و چند هفته، به چند ساعت رسونده.
دورانی که بعد از انتشار یک باگ چند روز برای آپدیت‌کردن وقت داشتیم، احتمالاً تموم شده.

هوش مصنوعی اخیراً ۱۶ مسئله ریاضی را حل کرده است:۹ مورد با پادمثال (۵۶٫۳٪)
۷ مورد با اثبات (۴۳٫۸٪)
۱۰ مورد دارای اثبات رسمی (۶۲٫۵٪)
۸ مورد دارای شاهد یا گواهی دقیق و محدود (۵۰٪)

از ۱۱ مسئله‌ای که تاریخ مطرح شدن‌شان مشخص است، به‌طور متوسط ۴۷ سال باز مانده بودند!جدول همراه، این مسائل را با سطح تأثیر (۱ تا ۵) فهرست کرده؛ از حدس‌های گراف و هندسه گسسته گرفته تا مسائل معروف اردوش. مثلاً حدس Cycle Double Cover با اثبات و تأثیر ۵.

اینقدر چند روز اخیر ترند پیدا کردن مساله و دادت به gpt 5.6 sol در تایملاین ترند شده که تعداد مسائل حل شده به ۲۷ رسیده است.
منبع

نمونه‌ای از یک مساله حل شده در رمزنگاری کوانتومی که ۶ سال حل نشده بود.

سایت بسیار کاربردی و باحال که رفته لیست تمام مسائل ریاضی که با AI حل شده رو در آورده.
• حوزه‌ی مختلف رو دسته بندی کرده.
• و مشخص کرده کدوم مساله با کدوم مدل حل شده.


تا کنون ۲۱۷ مساله ریاضی با AI حل شده!

معمار ۱۷ ساله‌ی 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.

امسال در کنفرانس ICLR 2027
، سیاست‌هایی وضع شده که طبق آن‌ها بازبینی‌کنندگان (reviewers) ملزم هستند:
(a) ابزارهای هوش مصنوعی که برای کمک به نوشتن بازبینی همتا استفاده کرده‌اند را افشا کنند، و
(b) ارزیابی اصلی و خودنوشته‌شان به همراه هرگونه تعامل با LLM را گزارش دهند.ترجمه بخش‌های هایلایت‌شده در تصویر (سیاست ICLR):

«اگر از LLMها برای تولید یا ویرایش هر بخشی از بازبینی (یا متا-بازبینی) خود استفاده کنید، ملزم خواهید بود که ارزیابی اصلی و خودنوشته مقاله و هرگونه تعامل با LLM را در یک جعبه متن جداگانه گزارش دهید. (با انجام این کار، به فکر پرش از LLM و ارسال مستقیم متن اصلی خود باشید! ما و نویسندگان، خیلی بیشتر به افکار ویرایش‌نشده شما علاقه‌مند هستیم تا آنچه یک LLM می‌گوید.)»

این مربوط به باز‌بینی‌کنندگان و به تعبیر عامی نادقیق داوران است، اما سیاست نگارش مقاله با 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 کنفرانس مورد نظر را چک کنید. هدف اصلی حفظ اصالت، دقت علمی و مسئولیت انسانی است.

در حالی که همه از کاهش قیمت مدل‌های چینی حرف می‌زنند، نکته مهم و کمتر گفته‌شده اینه که OpenAI امروز قیمت GPT-5.6 Luna رو ۸۰٪ و Terra رو ۲۰٪ کاهش داد + حالت Fast برای Sol با ۲٫۵ برابر سرعت. Auto-review هم با Luna حدود ۱۰ برابر ارزان‌تر شده. این حرکت‌ها نتیجه بهینه‌سازی‌هایی هست که خودشون با GPT-5.6 Sol روی مدل‌هاشون انجام دادن. یعنی رقابت فقط از سمت چین نیست؛ OpenAI هم داره مرز قیمت-عملکرد رو با قدرت جلو می‌بره و هوش پیشرفته رو ارزان‌تر و در دسترس‌تر می‌کنه.

گروک build اومده یه پلاگین اضافه کرده به اسم resume claude
یعنی هر موقع آستانه مصرف‌ت تموم شد منتظر نمون من رو به عنوان بک‌آپ خودت در نظر بگیر و من همون session رو ادامه میدم.
بازار یابی از طریق یک پلاگین ساده:)

واسه اینکه کار به اینجا نکشه خیلی درس خوندیم، سرنوشت قشنگی نبود:)))

با ChatGPT شوخی نکنید

چند روز پیش داشتم با 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 زدم، ماجرا را توضیح دادم و چند ساعت بعد اکانت را باز کردند و رسماً هم گفتند که غیرفعال‌سازی اشتباه بوده است.

نسبت پارامترهای فعال مدل‌ها به کل پارامترها کمتر از ۵ درصده. و انگار داره استنتاج اسپارس و تنک تر میشه. این هزینه‌ی استنتاج رو ارزون میکنه.

قیمت ورودی و خروجی بیشتر پروایدرها تقریباً همان قیمت مستقیم 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 حذف شده.