هوش مصنوعی ارزان است؛ پس چرا زیرساختش گران تمام می‌شود؟
هزینه هوش مصنوعی فقط قیمت هر درخواست نیست. برق، داده، بازبینی انسانی و نگهداری را برای مقایسه اجرای محلی با API و هزینه هر نتیجه قابل قبول بررسی می‌کنیم.
نقطه شروع این تحلیل: گزارش Energy and AI از آژانس بین‌المللی انرژی، منتشرشده در سال ۲۰۲۵. این گزارش نقش انرژی در توسعه هوش مصنوعی و رشد مصرف برق مراکز داده را بررسی می‌کند. برآوردهای جهانی آن، صورتحساب یک شرکت مشخص نیستند. ادامه مطلب، تحلیل تألیفی درباره هزینه اجرای یک کاربرد سازمانی است؛ نه ترجمه گزارش یا پیش‌بینی قیمت بازار.
فرض کنید نسخه آزمایشی یک دستیار داخلی با هزینه کمی راه افتاده است. پس از گسترش استفاده، تیم با پرسش‌های تازه مواجه می‌شود: چه کسی پاسخ‌ها را بررسی می‌کند؟ داده‌ها چگونه به‌روز می‌مانند؟ اگر سرویس کند شد، کدام واحد پاسخ‌گوست؟ ارزان‌بودن یک درخواست، لزوماً به معنی ارزان‌بودن یک خدمت نیست.
برداشت من: مخرج هزینه را باید عوض کنیم
به‌نظر من، هزینه «هر پاسخ تولیدشده» برای تصمیم مدیریتی کافی نیست. معیار مفیدتر، هزینه هر کار پذیرفته‌شده با کیفیت قابل قبول است. اگر خروجی به اصلاح زیاد نیاز داشته باشد، بخشی از هزینه فقط از صورتحساب فناوری به زمان کارکنان منتقل شده است.
در یک مثال صرفاً فرضی، دو ابزار هرکدام صد پاسخ می‌سازند. از اولی پنجاه پاسخ و از دومی هشتاد پاسخ قابل استفاده‌اند. مقایسه قیمت صد درخواست، اثر تفاوت کیفیت را پنهان می‌کند. این مثال نتیجه آزمون دو محصول نیست؛ توضیحی برای انتخاب واحد اندازه‌گیری است.
پیشنهاد من این است که پیش از خرید، «کار تمام‌شده» تعریف شود: خلاصه تأییدشده، پاسخ دارای منبع قابل پیگیری یا سندی که مسئول مربوط آن را پذیرفته است. تعریف دقیق، هم ارزیابی کیفیت را بهتر می‌کند و هم بحث هزینه را روشن‌تر.
چهار سبدی که در نسخه نمایشی دیده نمی‌شوند
هزینه را می‌توان در چهار سبد پیشنهادی ثبت کرد. این دسته‌بندی مدل حسابداری رسمی نیست؛ روشی برای جا نماندن کارهای مهم در برآورد اولیه است.
| سبد | نمونه اقلام | سؤال سنجش |
|---|---|---|
| پردازش و سرویس | درخواست API، سخت‌افزار، برق | برای هر کار پذیرفته‌شده چقدر مصرف می‌شود؟ |
| آماده‌سازی داده | پالایش، مجوز، به‌روزرسانی | چه کسی تازگی و اعتبار داده را نگه می‌دارد؟ |
| کنترل کیفیت | بازبینی، اصلاح، رسیدگی به خطا | چه مقدار کار انسانی باقی مانده است؟ |
| عملیات | پایش، دسترسی، بازیابی، پشتیبانی | روز اختلال چه هزینه‌ای ایجاد می‌شود؟ |
این نگاه کمک می‌کند مقایسه اجرای محلی با API منصفانه‌تر شود. خرید دستگاه، هزینه نگهداری را حذف نمی‌کند؛ استفاده از API هم مسئولیت کیفیت، دسترسی و کنترل داده را از سازمان نمی‌گیرد.
یک محاسبه کوچک، با فرض‌های آشکار
برای فهم بخش برق، یک مثال آموزشی بسازیم: اگر متوسط توان کل یک سیستم فرضی ۰٫۳۵ کیلووات باشد و در ماه ۱۲۰ ساعت کار کند، انرژی مصرفی همان سیستم ۴۲ کیلووات‌ساعت خواهد بود. محاسبه برابر است با توان متوسط ضرب‌در زمان کار.
این عدد، مصرف واقعی یک مدل یا GPU مشخص نیست. هزینه سرمایش، UPS، حالت آماده‌به‌کار و تجهیزات جانبی هم در این مثال وارد نشده‌اند. برای برآورد واقعی، اندازه‌گیری و تعرفه محل اجرا لازم است. مقیاس مراکز داده در گزارش IEA را نمی‌توان مستقیماً به یک رایانه اداری تعمیم داد.
از نظر من، ارزش این محاسبه در خود عدد نیست؛ در آشکارشدن فرض‌هاست. اگر استفاده فقط چند ساعت در هفته باشد، نتیجه اقتصادی ممکن است با استفاده پیوسته تفاوت زیادی پیدا کند. پیش از انتخاب، باید الگوی تقاضا را بشناسیم.
اجرای محلی یا API؟ سؤال درست، بار کاری است
در یک سناریوی فرضی، تیمی ماهانه تعداد محدودی سند بررسی می‌کند و الزام خاصی برای اجرای محلی ندارد. تیم دیگر، پردازش مداوم و محدودیت مشخص برای انتقال داده دارد. یک پاسخ واحد برای هر دو، احتمالاً بخش مهمی از مسئله را حذف می‌کند.
بهتر است گزینه‌ها با مجموعه ورودی یکسان و معیار پذیرش یکسان مقایسه شوند. زمان پاسخ، کیفیت، مصرف منابع و زمان بازبینی را کنار هم ثبت کنیم. اگر یک گزینه سریع‌تر است اما اصلاح بیشتری می‌خواهد، مزیت سرعت را باید در کل فرایند سنجید.
همچنین ظرفیت رزروشده و ظرفیت مصرف‌شده را جدا ببینیم. سخت‌افزاری که بیشتر روز بی‌استفاده می‌ماند، همچنان هزینه مالکیت دارد. در مدل مصرفی هم رشد استفاده می‌تواند بودجه را تغییر دهد. هر دو به پایش و حد مصرف متناسب نیاز دارند.
معیار پیشنهادی: این ابزار در یک ماه چند کار قابل قبول را با چه هزینه کل و چه مقدار دخالت انسانی تحویل داده است؟
قبل از افزایش ظرفیت، دوباره‌کاری را کم کنیم
پیشنهاد من این است که ابتدا علت درخواست‌های تکراری، ورودی نامناسب و خروجی ردشده را بررسی کنیم. شاید مسئله با تعریف بهتر کار یا کوتاه‌کردن فرایند حل شود؛ شاید هم واقعاً به ظرفیت بیشتری نیاز باشد. هر دو فرض باید با داده مقایسه شوند.
برای نمونه، اگر دستیار اطلاعات کهنه دریافت می‌کند، خرید پردازنده قوی‌تر تازگی اطلاعات را بهتر نمی‌کند. اگر مسئله تأخیر در دسترسی به داده باشد، تحلیل مسیر ذخیره‌سازی تا GPU نشان می‌دهد چرا بررسی گلوگاه باید پیش از نسبت‌دادن همه مشکل به قدرت پردازش انجام شود.
این تحلیل وعده صرفه‌جویی با درصد ثابت نمی‌دهد. انتخاب مدل کوچک‌تر، تغییر معماری یا محدودکردن خروجی فقط وقتی ارزش دارد که کیفیت موردنیاز حفظ شود. معیار هزینه بدون معیار پذیرش، به کاهش کیفیت پنهان منجر می‌شود.
نتیجه‌گیری: ارزان‌ترین پاسخ، لزوماً ارزان‌ترین خدمت نیست
موضع من این است که تصمیم درباره هوش مصنوعی باید بر هزینه یک نتیجه پذیرفته‌شده تکیه کند. با مشخص‌شدن این واحد، برق، داده، بازبینی و پشتیبانی در تصویر قرار می‌گیرند و مقایسه گزینه‌ها قابل دفاع‌تر می‌شود.
آیا اجرای محلی همیشه ارزان‌تر است؟
خیر. حجم استفاده، کیفیت موردنیاز، منابع تیم و محدودیت داده در نتیجه مؤثرند. بدون ثبت این فرض‌ها، ادعای برتری همیشگی قابل اتکا نیست.
آیا هزینه انرژی تنها عامل تصمیم است؟
خیر. گزارش IEA زمینه بحث انرژی را فراهم می‌کند؛ در یک پروژه سازمانی، هزینه نیروی انسانی و عملیات هم باید بررسی شود.
منبع و حدود تحلیل
بررسی منبع: ۱ نوامبر ۲۰۲۶. اعداد محاسباتی، وضعیت تیم‌ها و مقایسه خروجی‌ها فرضی و آموزشی‌اند. مقاله شامل قیمت روز، بنچمارک مستقل یا ادعای اندازه‌گیری مصرف یک محصول مشخص نیست.
برای ادامه مطالعه
همه نوشته‌ها →
مستندی که ساعت سه صبح به دادت می‌رسد
یک قالب یک‌صفحه‌ای برای مستند عملیاتی سرویس: کاربرد، وابستگی‌ها، محل لاگ، معیار سلامت، مسیر بازیابی و مسئول پیگیری؛ بدون انبارکردن رمز در مستند.
پنج چیزی که قبل از ری‌استارت سرور باید ثبت کنیم
پیش از ری‌استارت، کاربران، وابستگی‌ها، کارهای فعال، وضعیت بازیابی و معیار سلامت را ثبت کنید؛ چک‌لیستی کوتاه برای جلوگیری از راه‌اندازی مجدد بدون شواهد.
سرور روشن است؛ سرویس واقعاً کار می‌کند؟
برای پایش سرویس، از پاسخ ping عبور کنید: یک مسیر واقعی کاربر، وابستگی ضروری و هشدار قابل‌اقدام را انتخاب کنید تا خرابی پشت چراغ سبز پنهان نماند.