Perspectives
صورتحسابی را که نمی‌توانید بخوانید، نمی‌توانید کم کنید
کش و ارسال دسته‌ای فقط وقتی کمک می‌کنند که بتوانید اندازه بگیرید.
By Ehsan Gazar, ۲۵ شهریور ۱۴۰۵
فاکتور ارائه‌دهنده‌ی شما به‌صورت یک عدد می‌رسد. می‌دانید جمع کل این ماه بالا رفته است. نمی‌دانید کدام قابلیت باعثش شد، کدام مدل، یا کدام هفته.
توکن ارزان‌تر به این مشکل دست نمی‌زند.
صورتحسابی بدون ریز هزینه
ارائه‌دهنده برای حساب صورتحساب صادر می‌کند، نه برای قابلیت. یک کلید، یک جمع کل، یک سطر در صورتحساب. هر چیزی که شرکت شما روی آن کلید ساخته، درهم‌آمیخته و در قالب یک رقم می‌رسد.
پس سه سؤال بی‌پاسخ می‌ماند: کدام سرویس پول را خرج کرد، آن را صرف کدام مدل کرد، و آیا این هزینه ارزشش را داشت.
بدون دو سؤال اول، حتی نمی‌توانید سومی را بپرسید. از روی فاکتور، یک قابلیت گران و یک قابلیت پرطرفدار یکسان به نظر می‌رسند، و کل تصمیم در گرو تفاوت میان این دو است.
پرسیدن از آدم‌ها هم این اطلاعات را برنمی‌گرداند. تیمی که قابلیت را ساخته می‌داند چه می‌کند، نه اینکه چقدر هزینه دارد، و تا فاکتور برسد، آن کار سه هفته پشت سرشان است.
بهینه‌سازی بدون انتساب، همان حدس زدن است با چند مرحله‌ی اضافه.
آنچه هر درخواست باید بگوید
هر پاسخی که از درگاه ما می‌گذرد، شرح آنچه همین حالا رخ داد را روی خود پاسخ دارد: شناسه‌ی درخواست؛ مدلی که واقعاً پاسخ داد، که همیشه همان مدل درخواست‌شده نیست؛ تعداد توکن‌های پرامپت و پاسخ؛ اینکه چه تعداد از آن توکن‌های پرامپت از کش آمده‌اند؛ و هزینه به دلار، تا ده رقم اعشار.
این‌ها تخمین نیستند. عکس بالای همین نوشته را هنگام نوشتنش از طریق همین درگاه ساختم. پاسخ گفت req_mu3zdtuc7w7hjzy635، google/gemini-3.1-flash-image و $0.0715239000، و کلیدی که هزینه از آن کسر شد دقیقاً به همین اندازه تغییر کرد.
اینکه کدام مدل پاسخ داد، مهم‌تر از آن است که به نظر می‌رسد. یک درخواست می‌تواند به‌جای یک نسخه، نام یک خانواده‌ی مدل را بیاورد، یا ارزان‌ترین مدلی را بخواهد که از پس کار برمی‌آید، و چیزی باید این را به مدلی مشخص تبدیل کند. وقتی صورتحسابی غافلگیرتان می‌کند، نخستین سؤال این است که واقعاً کدام مدل اجرا شد، و پاسخ پیش از آنکه کسی دنبالش بگردد، جواب آن را داده بود.
پشت آن، سطرهای گزارش سی روز درخواست نگه داشته می‌شود که بر اساس سرویس، سطح، شناسه‌ی درخواست و زمان پاسخ قابل جست‌وجوست. یک درخواست را می‌توان در همه‌ی سرویس‌هایی که با آن سروکار داشته‌اند دنبال کرد.
واحد، درخواست است، نه ماه. کل تفاوت همین است، و همه‌ی آنچه در ادامه می‌آید به آن وابسته است.
توکن‌هایی که پیش‌تر هزینه‌شان را داده‌اید
یک پرامپت سیستمی طولانی و مجموعه‌ای از تعریف‌های ابزار در هر نوبت گفت‌وگو دوباره فرستاده می‌شوند. ارائه‌دهندگان برای پیشوندی که قبلاً دیده‌اند هزینه‌ی کمتری می‌گیرند، چون کارش را قبلاً انجام داده‌اند.
بخشی که ارزش گفتن دارد این است: تا ۵ سپتامبر ۲۰۲۶، این درگاه هر توکن پرامپت را با نرخ کامل ورودی حساب می‌کرد و اصلاً تعداد توکن‌های کش‌شده را نمی‌خواند. صفحه‌ی قیمت‌گذاری ما می‌گفت هر توکن به‌اندازه‌ی قیمت فهرست ارائه‌دهنده به‌علاوه‌ی ۵٪ هزینه دارد، و روی پیشوند کش‌شده، این ادعا بین چهار تا ده برابر اشتباه بود.
راه‌حل این نبود که بیشتر حواسمان را جمع کنیم. نرخ کش منتشرشده‌ی هر ارائه‌دهنده به‌صورت ضریبی از نرخ ورودی آن ذخیره می‌شود، پس توکن کش‌شده به‌حکم ساختار سیستم روی قیمت فهرست کش‌شده به‌علاوه‌ی ۵٪ می‌نشیند. مدلی که نرخ کش ثبت‌شده‌ای ندارد، با همان نرخ کامل ورودی می‌ماند، به‌جای آنکه تخفیفی بگیرد که هیچ‌کس درستی‌اش را بررسی نکرده است.
کارکردش را هم می‌توانید ببینید. پاسخ به شما می‌گوید چه تعداد از توکن‌های پرامپتتان تکراری بوده‌اند، پس صرفه‌جویی عددی است که خودتان می‌بینید، نه ادعایی از سوی ما.
صرفه‌جویی‌ای که نمی‌بینید، صرفه‌جویی‌ای است که نمی‌توانید ثابتش کنید.
یک هزینه به‌جای ده هزار
بسیاری از کارها همین لحظه پاسخ لازم ندارند: بردارسازی (embedding) یک پیکره‌ی متنی، طبقه‌بندی کارهای انباشته، یا بازتولید خلاصه‌ها پس از تغییر یک پرامپت. اگر این کارها به‌صورت دسته (batch) ارسال شوند و نتایجشان بعداً گرفته شود، هزینه‌ی کمتری دارند.
دقت اصلی در سازوکاری است که زیر این کار قرار دارد.
در یک دسته‌ی معمولی، هر مورد یک فراخوانی واقعی و سنجیده‌شده است. کلیدی با سقف ده دلار که در مورد چهار هزارم به آن برسد، مورد چهار هزار و یکم را رد می‌کند، و شش هزار مورد باقی‌مانده هرگز اجرا نمی‌شوند. سقف، خرج کردن را در میانه‌ی راه متوقف می‌کند، و دلیل گذاشتن سقف دقیقاً همین است.
دسته‌ی تخفیف‌دار یک‌جا ارسال می‌شود و به‌صورت یک هزینه‌ی واحد برمی‌گردد. فقط یک لحظه وجود دارد که در آن می‌توان چیزی را رد کرد، و آن لحظه پیش از ارسال است.
این مهم است، چون بررسی‌های معمولی می‌پرسند آیا بودجه‌تان را قبلاً خرج کرده‌اید، نه اینکه آیا این درخواست از آن فراتر می‌رود. تا وقتی واحد هزینه یک فراخوانی است، هر دو برداشت درست‌اند. اما اگر ده هزار فراخوانی را در یک هزینه جمع کنید، تیمی با سقف ماهانه‌ی ده دلار که هنوز چیزی خرج نکرده، از بررسی رد می‌شود و چهارصد دلار صورتحساب می‌گیرد.
برای همین دسته‌ی تخفیف‌دار فقط پس از آنکه پول سه بار بررسی شد پذیرفته می‌شود: هنگام ساخت، پیش از آنکه حتی یک سطر نوشته شود. تخفیف واقعی است. ترمزی هم که حذف می‌کند واقعی است، و چیزی باید جای آن را بگیرد.
آنچه توکن ارزان‌تر حل نمی‌کند
هیچ‌کدام از این‌ها به شما نمی‌گوید آیا آن هزینه ارزشش را داشت. انتساب می‌گوید کدام قابلیت پول را خرج کرد. فقط شما می‌توانید بگویید آن قابلیت باید خرج می‌کرد یا نه.
کش فقط به پیشوند تکراری کمک می‌کند و به هیچ چیز دیگر. بار کاری‌ای که هر بار پرامپت متفاوتی می‌فرستد، هیچ صرفه‌جویی‌ای از آن نمی‌برد، و باید همین را به صاحبش گفت، نه اینکه عددی به او فروخت که هرگز نخواهد دید.
ارسال دسته‌ای تأخیر را با قیمت معاوضه می‌کند. اگر کسی منتظر پاسخ است، صرفه‌جویی‌ای در کار نیست، و فروشنده‌ای که خلاف این را القا می‌کند، بار کاری‌ای غیر از بار کاری شما را توصیف می‌کند.
اول اندازه بگیرید. هر اهرمی پس از آن حساب و کتاب ساده است، و تنها اهرم‌هایی ارزش کشیدن دارند که بتوانید حرکتشان را ببینید.