خفض فاتورة Gemini API: متى يوفّر التخزين المؤقت ومتى لا؟

لا يصبح التخزين المؤقت أرخص لمجرد أن سعر الرمز المخزّن أدنى من سعر الإدخال العادي. يتحقق الوفر فقط عندما تتجاوز قيمة إعادة استخدام السياق رسوم الاحتفاظ به طوال مدة TTL؛ لذلك قد يكون الإرسال المباشر أقل تكلفة إذا كانت التكرارات قليلة أو كانت الذاكرة ستبقى ساعات بلا استخدام.

يمكن حسم القرار بأربعة مدخلات: عدد رموز السياق، وعدد مرات استخدامه، ومدة الاحتفاظ به بالساعات، وأقصى زمن استجابة مقبول. يحدد الزمن ما إذا كان Standard أو Flex أو Batch صالحاً للعمل، ثم تكشف معادلة التعادل ما إذا كان التخزين الصريح يخفض الفاتورة فعلاً.

اختر وضع التنفيذ قبل حساب التخزين

Standard هو الوضع الافتراضي للتوليد المتزامن ويخدم معظم التطبيقات التفاعلية اليومية. أما Flex فيظل متزامناً لكنه يستخدم سعة متاحة بأفضل جهد؛ وقد يُوقَف الطلب عند ضغط السعة، مقابل خصم قدره 50% وزمن مستهدف بين دقيقة و15 دقيقة. Batch غير متزامن، ويعالج الأحمال الكبيرة في طوابير خلفية بخصم 50% ووقت إنجاز مستهدف يصل إلى 24 ساعة، وفق مقارنة أوضاع Gemini API.

• اختر Standard عندما ينتظر التطبيق استجابة مباشرة ولا يناسبه تأخير بالدقائق.
• اختر Flex لسلسلة خلفية غير عاجلة تعتمد فيها خطوة على نتيجة سابقتها، مع إمكانية إعادة محاولة الطلبات المتوقفة.
• اختر Batch للتقييمات والمعالجة الجماعية والأعمال غير المتزامنة التي لا تتطلب نتيجة فورية.

يجب إجراء هذه المفاضلة أولاً لأن Flex وBatch يخفضان تكلفة الإدخال نفسها. وعندما يصبح الإرسال المباشر أرخص بينما تبقى رسوم التخزين بالساعة ثابتة، يحتاج السياق إلى عدد أكبر من الاستخدامات كي يعوض تكلفة الاحتفاظ به؛ أي إن التخزين الذي يربح مع Standard قد يخسر مع وضع أرخص.

الضمني لا يساوي التخزين الصريح

يعمل التخزين الضمني افتراضياً في Gemini 2.5 والنماذج الأحدث، من دون إنشاء كائن cache أو تحديد TTL. ترتفع فرصة الإصابة عند وضع المحتوى الطويل المشترك في بداية الطلب، والحفاظ على بادئة متشابهة، وإرسال الطلبات في وقت متقارب. ولا ينبغي افتراض وقوع الإصابة: عدد الرموز المستفيدة يظهر في الحقل usage.total_cached_tokens.

أما التخزين الصريح فينشئ كائناً يعاد الرجوع إليه خلال مدة احتفاظ محددة. وتوضح وثائق تخزين السياق أن Interactions API يدعم التخزين الضمني فقط، وأن التخزين الصريح يتطلب generateContent؛ كما تحدد حداً أدنى قدره 4096 رمزاً لنماذج Gemini 3.7 و3.6 و3.5 Flash، و2048 رمزاً لـGemini 2.5 Flash وPro.

يصلح الضمني كبداية عندما تتكرر البادئة تلقائياً ولا تحتاج إلى ضمان نافذة الاحتفاظ. ويصبح الصريح قابلاً للحساب عندما تكون لديك مجموعة معروفة من التعليمات أو المستندات، ويمكن توقع عدد مرات الرجوع إليها قبل انتهاء TTL. لكن التحكم في المدة يضيف رسماً لا يوجد في مقارنة أسعار الرموز وحدها.

حاسبة ورقية بأربعة مدخلات

اكتب C لعدد رموز الجزء الثابت، وN لعدد مرات استخدامه خلال النافذة، وH لمدة TTL بالساعات، وL لأقصى زمن استجابة مقبول. استخدم L لاستبعاد الأوضاع غير المناسبة، ثم انقل من جدول تسعير النموذج المختار ثلاث قيم لكل مليون رمز: S لسعر الإدخال المباشر، وK لسعر قراءة الرموز المخزنة، وT لسعر تخزين مليون رمز لمدة ساعة.

1. تكلفة إعادة إرسال السياق مباشرة = C ÷ 1,000,000 × N × S.
2. تكلفة التخزين الصريح = C ÷ 1,000,000 × N × K + C ÷ 1,000,000 × H × T.
3. يكون التخزين أوفر عندما تكون النتيجة الثانية أدنى من الأولى.

بعد حذف العامل C المشترك من طرفي المقارنة، تصبح نقطة التعادل: N أكبر من H × T ÷ (S − K)، بشرط أن يكون S أكبر من K. لذلك يغير حجم السياق قيمة الفاتورة، لكنه لا يغير عدد التكرارات اللازم للتعادل ما دامت الأسعار نفسها تنطبق على كل رموزه.

تحسب الصيغة تكلفة الجزء الثابت فقط. لا تضف رموز الإخراج أو المدخلات المتغيرة إلى طرف دون الآخر إذا كانت متساوية في البديلين، لأنها ترفع الفاتورة الكلية ولا تغير قرار التخزين. وإذا كان مسار إنشاء الذاكرة يتضمن تكلفة إضافية خاصة بتطبيقك، فأضفها صراحة إلى طرف التخزين؛ عندها ترتفع نقطة التعادل.

مثال: متى تبتلع TTL الوفر؟

تعرض أسعار Gemini 3.7 Flash المدفوعة حتى 31 ديسمبر 2026 مبلغ 0.75 دولار لكل مليون رمز إدخال في Standard، و0.075 دولار للرموز المخزنة، و0.50 دولار لتخزين مليون رمز في الساعة. في Flex وBatch يصبح سعرا الإدخال والرموز المخزنة 0.375 و0.0375 دولار، بينما تظل رسوم التخزين 0.50 دولار في الساعة خلال الفترة نفسها.

لنأخذ مثالاً افتراضياً لسياق من 100 ألف رمز، وTTL مدتها أربع ساعات. في Standard تكون العتبة 4 × 0.50 ÷ (0.75 − 0.075)، أي أكثر من 2.96 استخدام؛ وبالأعداد الصحيحة يبدأ الوفر من الاستخدام الثالث. عند ثمانية استخدامات يكلف الإرسال المباشر 0.60 دولار، بينما تكلف القراءات المخزنة 0.06 دولار والتخزين 0.20 دولار، بإجمالي 0.26 دولار.

في Flex ترتفع العتبة إلى أكثر من 5.92 استخدام، فيبدأ الوفر من الاستخدام السادس. ليست المشكلة أن قراءة الرموز المخزنة غالية، بل أن سعر الإدخال المباشر انخفض إلى النصف فيما لم تنخفض رسوم الاحتفاظ. وإذا امتدت TTL إلى ثماني ساعات، تصبح عتبة Standard أكثر من 5.92 وعتبة Flex أكثر من 11.85؛ وقد يحول الاحتفاظ الطويل خياراً رابحاً إلى رسم إضافي.

مصفوفة القرار

• Standard بلا تخزين صريح: للطلبات التفاعلية عندما يتغير السياق أو يبقى تكراره دون نقطة التعادل.
• Standard مع تخزين صريح: لسياق طويل وثابت يعاد استخدامه بكثافة خلال TTL قصيرة يمكن توقعها.
• Flex: للعمل المتزامن الخلفي الذي يقبل زمناً أطول وإعادة المحاولة؛ احسب التعادل بأسعار Flex لا Standard.
• Batch: للمعالجة الجماعية غير العاجلة؛ ابدأ بخصمه الأساسي، ثم اختبر ما إذا كانت التكرارات تعوض رسوم التخزين.
• التخزين الضمني: للبادئات المتشابهة والمتقاربة زمنياً، على أن يُقاس الوفر من الإصابات الفعلية لا من عدد الطلبات المفترض.

الخلاصة الحسابية بسيطة: يختار L وضع التنفيذ المقبول، وتحدد N وH ما إذا كان التخزين الصريح سيغطي رسمه. انقل S وK وT من صفحة النموذج كلما تغير النموذج أو نمط الخدمة، واحسب التكرارات داخل نافذة TTL نفسها؛ فالمتوسط اليومي لا يفيد إذا انتهت الذاكرة قبل وصول الطلبات التالية.