هزینه‌های API مدل‌های زبانی بزرگ، بهای تمام‌شده کالای فروش‌رفته هستند، نه هزینه سربار: راهنمای حاشیه سود ناخالص برای Wrapperهای هوش مصنوعی

یکی از بنیان‌گذاران یک دستیار نویسندگی مبتنی بر هوش مصنوعی به من گفت «هزینه‌های نرم‌افزاری» او $40,000 در ماه است. وقتی این رقم را تجزیه کردیم، $34,000 از آن صورت‌حساب‌های API شرکت‌های OpenAI و Anthropic بود — و هیچ‌کدام در بهای تمام‌شده کالای فروش‌رفته او ثبت نشده بود. این هزینه در یک ردیف کلی با عنوان «نرم‌افزار و اشتراک‌ها»، درست کنار ابزار مدیریت پروژه‌اش که $19 در ماه هزینه داشت، جای گرفته بود. حاشیه سود ناخالص گزارش‌شده او 91% بود. حاشیه سود ناخالص واقعی او، پس از آنکه هزینه استنتاج به جای درست خودش منتقل شد، 58% بود.

این فقط یک ظرافت دفترداری نیست. این تفاوتی است میان کسب‌وکاری که شبیه نرم‌افزار به نظر می‌رسد و کسب‌وکاری که مانند یک کارخانه عمل می‌کند — جایی که هر واحد فروخته‌شده یک نهاده واقعی و متغیر مصرف می‌کند. اگر شما هم روی GPT-5، Claude، Gemini یا هر مدل میزبانی‌شده دیگری محصول می‌سازید، صورت‌حساب مدل زبانی بزرگ شما هزینه سربار نیست. آن بهای تمام‌شده کالای فروش‌رفته است، و برخورد متفاوت با آن یعنی شما واقعاً نمی‌دانید چقدر سود می‌کنید.

چرا ارتکاب این اشتباه این‌قدر آسان است​

SaaS سنتی نسلی از بنیان‌گذاران را عادت داد که هزینه‌های نرم‌افزاری را ثابت در نظر بگیرند. شما بابت هاستینگ پول می‌دهید، بابت CRM پول می‌دهید، بابت Slack پول می‌دهید — و هیچ‌کدام از این صورت‌حساب‌ها هم‌گام با میزان استفاده هر مشتری از محصول شما تغییر نمی‌کند. پس وقتی اولین فاکتور API از OpenAI می‌رسد، طبیعی است که آن را در همان دسته ذهنی جای دهید: «ابزارهایی که برای اداره کسب‌وکار پول می‌دهیم».

مشکل این است که صورت‌حساب API یک مدل زبانی بزرگ مانند اشتراک SaaS رفتار نمی‌کند. آن مانند یک ماده اولیه عمل می‌کند. هر بار که مشتری یک پرامپت ارسال می‌کند، شما توکن مصرف می‌کنید و هر توکن قیمتی دارد. مشتری‌ای که روزانه 50 درخواست می‌فرستد، هزینه قابل‌توجهی بیشتر از مشتری‌ای که 2 درخواست می‌فرستد برای شما دارد. این دقیقاً تعریف کتاب‌درسیِ بهای تمام‌شده کالای فروش‌رفته است: هزینه‌ای که مستقیماً با تحویل محصول شما به یک مشتری خاص مقیاس می‌گیرد، برخلاف هزینه‌ای که فقط برای روشن نگه‌داشتن چراغ‌ها می‌پردازید، صرف‌نظر از میزان استفاده.

داده‌های صنعت نشان می‌دهند این موضوع تا چه اندازه اهمیت پیدا کرده است. گزارش State of AI ژانویه 2026 شرکت ICONIQ نشان داد که هزینه استنتاج اکنون به‌طور میانگین 23% از کل درآمد شرکت‌های B2B هوش مصنوعی در مرحله رشد را تشکیل می‌دهد، و 84% از این شرکت‌ها گزارش دادند که فرسایش حاشیه سود ناخالص به میزان شش واحد درصد یا بیشتر مستقیماً ناشی از هزینه‌های زیرساخت هوش مصنوعی بوده است. این یک خطای گرد‌کردنی نیست که بتوانید آن را در «سایر هزینه‌های عملیاتی» جذب کنید. این اغلب بزرگ‌ترین محرک هزینه در کسب‌وکار است و سزاوار است که به همین شکل هم با آن برخورد شود.

خط تفکیک COGS از OpEx، به‌درستی رسم‌شده​

قاعده‌ای که COGS را از هزینه عملیاتی جدا می‌کند، صرفاً به این دلیل که نهاده مورد نظر یک API مدل است نه انباری پر از قطعات، تغییر نکرده است: هزینه‌های تحویل محصول شما به یک مشتری پرداخت‌کننده در COGS جای می‌گیرند؛ هزینه‌های ساخت محصول شما در تحقیق و توسعه (R&D)، زیرمجموعه OpEx، جای می‌گیرند. وقتی این تفکیک را روی یک Wrapper هوش مصنوعی اعمال کنیم، به این شکل درمی‌آید:

در COGS جای می‌گیرد:

• هزینه‌های استنتاج تولیدی (Production) — هر فراخوانی API که محصول زنده شما از طرف یک مشتری پرداخت‌کننده انجام می‌دهد، چه یک تکمیل گفت‌وگو (chat completion) باشد، چه یک فراخوانی embedding، یک عملیات طبقه‌بندی، یا یک حلقه فراخوانی ابزار توسط ایجنت
• میزبانی مدل / محاسبات GPU — اگر به‌جای فراخوانی یک API میزبانی‌شده، یک مدل open-weight را روی زیرساخت خودتان یا زیرساخت اجاره‌ای اجرا می‌کنید، زمان محاسباتیِ قابل‌انتساب به پاسخ‌گویی درخواست‌های مشتریان
• زیرساخت پشتیبان استنتاج — پرس‌وجوهای پایگاه‌داده برداری (vector database)، اجرای پایپ‌لاین‌های embedding و سربار هماهنگ‌سازی (orchestration) که مشخصاً برای پاسخ‌گویی به درخواست‌های تولیدی وجود دارند
• هزینه‌های پشتیبانی مختص هوش مصنوعی — یک مهندس پشتیبانی که وظیفه‌اش دسته‌بندی و رسیدگی به مشکلات خروجی مدل برای مشتریان است، هزینه‌ی تحویل محصول محسوب می‌شود، نه یک هزینه عمومی SG&A

در OpEx جای می‌گیرد (معمولاً تحقیق و توسعه):

• استنتاج توسعه و تست — هر پرامپتی که یک مهندس هنگام توسعه یک ویژگی، رفع اشکال یک رگرسیون، یا ارزیابی یک نسخه جدید از مدل ارسال می‌کند
• اجراهای fine-tuning و ارزیابی — ساخت یا بهبود مدل، تحقیق و توسعه است، نه تحویل
• ابزارهای داخلی هوش مصنوعی — لایسنس‌های ChatGPT Enterprise یا GitHub Copilot تیم شما یک هزینه بهره‌وری هستند، نه هزینه پاسخ‌گویی به مشتریان

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

حاشیه سود ناخالص «واقعی» برای محصولات هوش مصنوعی چه شکلی است​

وقتی این تفکیک را انجام دادید، انتظار داشته باشید عددی که به دست می‌آید با آنچه به آن عادت دارید متفاوت باشد. کسب‌وکارهای SaaS سنتی تقریباً به‌طور پیش‌فرض حاشیه سود ناخالص 70 تا 80 درصد را هدف می‌گیرند. محصولات بومی هوش مصنوعی به همان شکل به این عدد نمی‌رسند. راهنمای قیمت‌گذاری فوریه 2026 شرکت Bessemer Venture Partners، حاشیه سود ناخالص معمول محصولات هوش مصنوعی را 50 تا 60 درصد اعلام می‌کند، که به‌طور قابل‌توجهی پایین‌تر از بازه 80 تا 90 درصدِ SaaS سنتی است، و داده‌های ICONIQ نشان می‌دهند میانگین صنعت برای حاشیه سود ناخالص محصولات هوش مصنوعی در حال افزایش است — اما فقط تا 52%، که از 41% در سال 2024 و 45% در سال 2025 رشد کرده است.

قاعده سرانگشتی مفیدی که از تجربه اپراتورهایی که این موضوع را از نزدیک مدیریت می‌کنند به دست آمده این است: اگر می‌خواهید مدل کسب‌وکاری پایدار و مقیاس‌پذیر داشته باشید، هزینه‌های مدل زبانی بزرگ را زیر حدود 20% از کل COGS نگه دارید. اگر از این آستانه عبور کنید، فشردگی حاشیه سود معمولاً با رشد شما شتاب می‌گیرد، نه اینکه کاهش یابد، چون مشتریان بزرگ‌تر محصول را بیشتر استفاده می‌کنند، نه کمتر. برخی دسته‌های سنگین از نظر هوش مصنوعی — دستیارهای کدنویسی، ایجنت‌های پردازش سند — نسبت هزینه مدل زبانی بزرگ به COGS را در بازه 30 تا 40 درصد اجرا می‌کنند و همچنان قابل‌دوام‌اند، اما فقط چون قیمت‌گذاری خود را عامدانه حول این واقعیت طراحی کرده‌اند، نه اینکه ناخواسته به آن رسیده باشند.

عددی که واقعاً اهمیت دارد، حاشیه سود ناخالص ترکیبیِ کل شرکت شما نیست — بلکه هزینه به‌ازای هر مشتری است. کاربران پرمصرف یک ویژگی هوش مصنوعی می‌توانند از نظر هزینه استنتاج خام، 50 تا 100 برابر بیشتر از کاربران کم‌مصرف در همان سطح اشتراک برای شما هزینه داشته باشند. اگر این را ردیابی نمی‌کنید، نمی‌دانید کدام مشتریان سودآور هستند و به کدام‌ها هر ماه به‌آرامی یارانه می‌دهید. طرحی با نرخ ثابت که برای ده مشتری اول شما خوب به نظر می‌رسید، ممکن است در همان لحظه‌ای که یکی از آن‌ها یک گردش‌کار را وارد تولید می‌کند و حجم درخواست‌های خود را 20 برابر می‌کند، شروع به ضررده شدن کند.

ساخت مدل هزینه به‌ازای هر درخواست​

برای شروع نیازی به ابزارهای پیچیده ندارید — به نظمی نیاز دارید که اعداد درست را در هر درخواست ثبت کنید. فرمول اصلی ساده است:

request_cost = (input_tokens / 1,000,000) × input_price_per_million
             + (output_tokens / 1,000,000) × output_price_per_million

توکن‌های خروجی معمولاً به‌ازای هر واحد 2 تا 5 برابر بیشتر از توکن‌های ورودی هزینه دارند، چون تولید (generation) از نظر محاسباتی سنگین‌تر از خواندن یک پرامپت است — بنابراین مدل هزینه‌ای که فقط مجموع توکن‌ها را ردیابی می‌کند بدون تفکیک ورودی از خروجی، به‌طور سیستماتیک قیمت هر چیزی با تکمیل‌های طولانی را اشتباه محاسبه می‌کند. به‌عنوان یک مثال کاربردی با قیمت‌گذاری اواسط 2026: یک درخواست با 2,000 توکن ورودی و یک پاسخ 500 توکنی روی یک مدل رده‌میانی رایج (حدود $3 ورودی / $15 خروجی به ازای هر میلیون توکن) حدود $0.0135 هزینه دارد. همین شکل از درخواست را 50,000 بار در ماه اجرا کنید، به حدود $675 هزینه استنتاج برای همان یک ویژگی می‌رسید — عددی که اگر درون یک ردیف پنج‌رقمیِ «هزینه‌های cloud» پنهان شده باشد نامرئی است، اما به‌محض اینکه به آن ویژگی و بخش مشتریِ تولیدکننده‌اش برچسب بخورد، کاملاً قابل‌مشاهده می‌شود.

برای عملیاتی کردن این موضوع:

1. تعداد توکن‌ها را در هر درخواست ثبت کنید، نه فقط هزینه را — بیشتر ارائه‌دهندگان مدل، تعداد توکن‌های ورودی/خروجی را در همان پاسخ API برمی‌گردانند، پس این فقط یک تغییر در نحوه لاگ‌گیری است، نه یک منبع داده جدید.
2. هر درخواست را با شناسه مشتری و شناسه ویژگی برچسب بزنید تا بتوانید هزینه‌ها را بر اساس حساب و بخش محصول جمع‌بندی کنید، نه فقط بر اساس ماه.
3. هزینه به‌ازای هر مشتری در هر دوره صورت‌حساب را محاسبه کنید و آن را با مبلغی که آن مشتری به شما می‌پردازد مقایسه کنید. این همان عددی است که به شما می‌گوید آیا سطوح قیمت‌گذاری شما واقعاً با هزینه تحویل شما مطابقت دارد، نه حاشیه سود میانگین ترکیبی شما.
4. در جایی که کیفیت اجازه می‌دهد، درخواست‌ها را به مدل‌های ارزان‌تر مسیریابی کنید. هر درخواستی به توانمندترین (و گران‌ترین) مدل شما نیاز ندارد — کارهای طبقه‌بندی، استخراج و قالب‌بندی ساده اغلب روی یک مدل کوچک‌تر و ارزان‌تر هم عملکرد قابل‌قبولی دارند، و مسیریابی مدل یکی از معدود اهرم‌های حاشیه سود است که کاملاً در کنترل خودتان است، برخلاف قیمت‌گذاری ارائه‌دهنده.

قیمت‌گذاری برای حفظ حاشیه سودی که تازه یافتید​

وقتی هزینه استنتاج به‌درستی به‌عنوان COGS طبقه‌بندی شود، گفت‌وگوی قیمت‌گذاری شما تغییر می‌کند. یک لنگر رایج که اپراتورها استفاده می‌کنند، قیمت‌گذاری در حدود 3 تا 5 برابر هزینه توکنِ هر واحد شماست، به‌طوری که یک وظیفه $0.30 با قیمت $1.00 یا بیشتر عرضه شود — نه به این دلیل که این ضریب جادویی است، بلکه چون فضایی برای جذب نوسان مصرف، نوسان قیمت مدل، و هزینه‌های پشتیبانی و زیرساختی که همراه با استنتاج خام می‌آیند باقی می‌گذارد.

صورت‌حساب مبتنی بر مصرف (usage-based billing) به روش استاندارد شرکت‌های هوش مصنوعی برای هماهنگ نگه‌داشتن قیمت‌گذاری و COGS تبدیل شده است: به‌ازای هر توکن، هر درخواست، یا هر وظیفه تکمیل‌شده هزینه بگیرید، تا درآمد شما با همان متغیری مقیاس بگیرد که هزینه شما را تعیین می‌کند، به‌جای آنکه مانند یک اشتراک ثابت هنگام جهش مصرف از آن فاصله بگیرد. اگر آماده نیستید به‌طور کامل به قیمت‌گذاری مبتنی بر مصرف حرکت کنید، دست‌کم سطوحی با حداقل تعهدی به‌علاوه اضافه‌مصرف بسازید تا مشتری‌ای که از مصرف معمول فراتر می‌رود، بی‌سروصدا برای بقیه ماه به یک منبع زیان‌ده تبدیل نشود.

ساختار هزینه خود را به‌همان اندازه کد خود قابل‌ممیزی نگه دارید​

هیچ‌کدام از این‌ها یک بهداشت دفترداریِ اختیاری نیست — این تفاوت میان دانستن اینکه مدل کسب‌وکار شما کار می‌کند و کشف اینکه کار نمی‌کند در جریان یک تماس بررسی دقیق (due diligence) برای جذب سرمایه است، زمانی که همکار یک سرمایه‌گذار همان مدل هزینه به‌ازای هر مشتری را می‌سازد که شما باید شش ماه زودتر می‌ساختید. بنیان‌گذارانی که از آن گفت‌وگو اجتناب می‌کنند، کسانی هستند که از همان اولین فراخوانی API، هزینه‌های استنتاج را به مشتریان و ویژگی‌ها برچسب می‌زنند، نه کسانی که صبر می‌کنند تا صورت‌حساب OpenAI آن‌قدر بزرگ شود که نتوان نادیده‌اش گرفت.

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