أهم 5 أسباب لانخفاض معدل إصابة ذاكرة التخزين المؤقت في Gemini: شرح مفصل للفروق في فوترة التخزين المؤقت بين AI Studio وVertex

في الاستخدام الفعلي لـ APIYI، تعمل عمليات كتابة ذاكرة التخزين المؤقت واسترجاعها في سلسلتي OpenAI وClaude بشكل طبيعي، وتكون نسبة الاسترجاع مرتفعة. لكن نماذج Gemini النصية تختلف عن ذلك: فنسبة الاسترجاع فيها منخفضة جدًا، بل تكاد تكون معدومة. ويمكن التحقق من هذه الحقيقة في الفواتير وتفاصيل الاستخدام، وهي من أكثر الأمور التي تحيّر المطورين عند مطابقة الحسابات.

استنادًا إلى الوثائق الرسمية من Google (حتى 20 أكتوبر 2026)، يشرح هذا المقال خمسة أسباب لانخفاض نسبة استرجاع ذاكرة التخزين المؤقت في Gemini، ويوضح كيفية احتساب رسوم التخزين المؤقت في AI Studio (Gemini Developer API) وVertex AI.

هذا ليس تحليلًا يحمّل طرفًا آخر المسؤولية. لا تنص القواعد الرسمية لـ Google على أن «استخدام خدمة وكيل يخفض نسبة استرجاع ذاكرة التخزين المؤقت في Gemini»، كما لا يمكننا الجزم بصحة سبب معين من دون سجلات الطلبات لدى الجهة المزوّدة. لذلك سنبدأ بشرح القواعد الرسمية، ثم نعرض الحالات التي قد تجعلها «لا تنطبق»، ونختتم بخطوات عملية يمكنك تنفيذها بنفسك للتحقق من المشكلة ومطابقة الحسابات.

الفائدة الأساسية: بعد قراءة هذا المقال، ستعرف متى يسترجع Gemini البيانات من ذاكرة التخزين المؤقت ومتى لا يفعل ذلك، وستفهم نقطة التسعير المهمة وهي أن «إجمالي المدخلات يشمل الجزء المخزّن مؤقتًا»، كما ستتمكن من مطابقة الفاتورة بنفسك بالاستناد إلى حقول الاستجابة الرسمية.

النقاط الأساسية لمعدل نجاح التخزين المؤقت في Gemini

لنبدأ بالخلاصة: لفهم التخزين المؤقت في Gemini، يجب التمييز بين آليتين مختلفتين تمامًا في طريقة التفعيل والفوترة: التخزين المؤقت الضمني والتخزين المؤقت الصريح.

تتضمن الوثائق الرسمية عبارة مهمة بشأن التخزين المؤقت الضمني في Developer API، وهي أنه لا يضمن توفير التكاليف. أما التخزين المؤقت الصريح، فرغم أنه أكثر قابلية للتنبؤ، فإنه يتطلب جهدًا إضافيًا في التطوير، مثل إنشاء كائن التخزين المؤقت وإدارة مدة صلاحيته والإشارة إليه في الطلبات اللاحقة.

لماذا تختلف تجربة Gemini عن OpenAI وClaude؟

من منظور المستخدم، يظهر استخدام سلسلتي OpenAI وClaude عبر APIYI وكأنه يتيح «إرسال البادئة الطويلة نفسها» ورؤية عمليات كتابة التخزين المؤقت والاستفادة منه باستمرار. أما Gemini، فيتطلب تحقق عدة شروط معًا: أن يدعم النموذج التخزين المؤقت الضمني، وأن يبلغ الطلب الحد الأدنى من التوكنات المطلوب لذلك النموذج، وأن يكون المحتوى القابل لإعادة الاستخدام في بداية الموجه، وأن تُرسل الطلبات المتشابهة خلال فترة زمنية قصيرة، وأن تكون الطلبات في Vertex ضمن مشروع Google Cloud نفسه.

إذا لم يتحقق أي شرط من هذه الشروط، فستُحاسَب الطلبات وفق سعر الإدخال العادي، من دون ظهور خطأ أو أي تنبيه. وهذا ما يجعل انخفاض معدل النجاح في التخزين المؤقت يمر أحيانًا من دون ملاحظة: فعدم الاستفادة من التخزين المؤقت يحدث بصمت.

تحديد المقصود بـ AI Studio أولًا

نقصد بعبارة «قناة AI Studio» في هذا المقال Gemini Developer API، أي المسار الذي يستخدم مفتاح API صادرًا من AI Studio، ونقارنه بـ Vertex AI على Google Cloud. تتبع الآليتان النهج نفسه في التخزين المؤقت، لكنهما تختلفان في قيم الحد الأدنى ونطاق العزل وقواعد رسوم التخزين. وسنوضح هذه الفروق بالتفصيل أدناه.

الأسباب الخمسة لانخفاض معدل نجاح التخزين المؤقت في Gemini

ينقسم التحليل التالي إلى مستويين: أول سببين يستندان إلى قواعد مذكورة صراحةً في الوثائق الرسمية، أما الأسباب الثلاثة الأخرى فهي تفسيرات مشروطة تتعلق بظروف قد تُخلّ بهذه القواعد عند استخدام خدمات الوكيل أو في الممارسات الهندسية. ولا يمكننا تحديد السبب بمجرد معرفة أنك «استخدمت خدمة وكيل»؛ إذ نحتاج إلى بيانات المشروع upstream وسجلات الطلبات لتشخيص المشكلة.

السبب 1: عدم بلوغ الطلب الحد الأدنى من توكنات التخزين المؤقت

يشترط التخزين المؤقت الضمني حدًا أدنى من التوكنات، ولن تُخزَّن الطلبات الأقصر من ذلك مؤقتًا. كما أن الحد الأدنى يختلف بين المسارين. يوضح الجدول التالي بعض القيم الواردة في الوثائق الحالية:

هناك نقطتان يسهل الوقوع في الخطأ بشأنهما. أولًا، الحد الأدنى في النماذج الأحدث، مثل Gemini 3.8 Flash، أعلى منه في سلسلة 2.5؛ لذا فإن استخدام قيمة 2,048 من إصدار أقدم للتقدير سيؤدي إلى استنتاج خاطئ. ثانيًا، قد يكون الحد الأدنى للنموذج نفسه أعلى في Vertex. فالطلب الذي يتضمن 5,000 توكن قد يستوفي الشرط في Developer API، لكنه لا يستوفيه في Vertex.

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

السبب 2: المحتوى القابل لإعادة الاستخدام ليس في بداية الموجه

توصي Google في كلا المسارين بوضع المحتوى الطويل والمتكرر في بداية الموجه، وإرسال الطلبات ذات البادئات المتشابهة خلال فترة زمنية قصيرة. يعتمد التخزين المؤقت على البادئة المشتركة، لا على مجرد «احتواء الطلب على المستند نفسه».

بعبارة أخرى، لا يكفي إرفاق المستند نفسه بطلبين لضمان الاستفادة من التخزين المؤقت. يجب أيضًا الانتباه إلى موضعه في الطلب، وإلى ثبات المحتوى الذي يسبقه. ومن السهل أن تؤدي كتابة كهذه إلى كسر البادئة:

# مثال مضاد: وضع المحتوى المتغير في البداية
[الوقت الحالي: 2026-10-20 10:31:07]
[معرّف الطلب: a8f3...]
{تعليمات النظام}
{المستند الطويل}
{سؤال المستخدم}

إذا اختلف حرف واحد في البداية، فلن يشترك المستند الطويل الذي يليه مع الطلب السابق في بادئة مشتركة. وهذا استنتاج مبني على التوصيات الرسمية، لكنه شائع جدًا في الممارسات الهندسية.

السبب 3: تغيير طبقة الوكيل للبادئة (احتمال مشروط)

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

عند استكشاف المشكلة، ميّز بين مستويين: هل البادئة التي ترسلها إلى خدمة الوكيل ثابتة؟ وهل البادئة التي ترسلها خدمة الوكيل إلى Google ثابتة؟ يمكنك التحكم في الأولى بنفسك، أما الثانية فتتطلب الاطلاع على سجلات الطلبات upstream.

السبب 4: توزيع الطلبات على مشاريع Vertex مختلفة (احتمال مشروط)

تنص Vertex صراحةً على أن التخزين المؤقت معزول بحسب مشروع Google Cloud، ولا يُشارك بين المشاريع. فإذا وُزعت الطلبات المتعددة في الجلسة نفسها على مشاريع Vertex مختلفة، فلن يتمكن المشروع B من استخدام التخزين المؤقت الذي أنشأه المشروع A.

لكن ينبغي توخي الحذر: ما إذا كان «تغيير المفتاح» يؤدي إلى فقدان التخزين المؤقت يعتمد على ما إذا كان المشروع قد تغيّر معه. لا يمكن الجزم بأن تغيير كل مفتاح يؤدي إلى فقدان التخزين المؤقت؛ بل يجب التحقق من العلاقة بين المفتاح والمشروع.

السبب 5: تمرير طلبات التوليد فقط من دون استخدام التخزين المؤقت الصريح

إذا كانت سلسلة الاستدعاء تكتفي بتمرير طلبات generateContent، من دون إنشاء كائن تخزين مؤقت أو الإشارة إليه في الطلبات اللاحقة، فستعتمد السلسلة بأكملها على التخزين المؤقت الضمني. ولا يقدم التخزين المؤقت الضمني ضمانًا بالاستفادة منه، لذلك لا يمكنه تحقيق العائد المستقر الذي يوفره التخزين المؤقت الصريح عبر «إنشاء الكائن مرة واحدة ثم الإشارة إليه مرارًا».

يوضح الجدول التالي كيف ترتبط بعض سيناريوهات استخدام خدمات الوكيل بالقواعد الرسمية:

🎯 نصيحة تقنية: عند استكشاف مشكلات التخزين المؤقت في Gemini، جرّب أولًا إرسال عدة طلبات متتالية بالبادئة الطويلة الثابتة نفسها عبر APIYI apiyi.com، ثم قارن حقل توكنات التخزين المؤقت في الردود. استخدم طلبات مضبوطة لاستبعاد مشكلات البادئة والحد الأدنى، ثم تحقّق مما إذا كانت المشكلة مرتبطة بمسار الطلب.

من دون بيانات المشروع upstream وسجلات الطلبات، لا يمكن تحديد السبب بمجرد معرفة أنك «استخدمت خدمة وكيل»، ولا يوجد سند رسمي للقول إن معدل الاستفادة من التخزين المؤقت في Vertex أعلى بالضرورة منه في Developer API.

كيفية تحديد فوترة التخزين المؤقت في AI Studio وVertex

يظن كثيرون أن «الإصابة في ذاكرة التخزين المؤقت» تعني أن الاستخدام مجاني، أو أن الطلب كله يحصل على الخصم نفسه. وهذا غير صحيح. ففي كلا النظامين، يجب التمييز بين أربعة بنود: الإدخال العادي، والإدخال المخزّن مؤقتًا، والإخراج، ورسوم تخزين الذاكرة المؤقتة الصريحة.

مقارنة قواعد الفوترة في النظامين

توضح وثائق Developer API أن الفوترة تعتمد على رسوم استخدام الرموز المميزة للذاكرة المؤقتة، ومدة التخزين، والإدخال غير المخزّن مؤقتًا، والإخراج. أما Vertex، فيوضح أيضًا نقطتين: يُحاسب الإدخال المستخدم لإنشاء ذاكرة مؤقتة بسعر الإدخال القياسي، ولا توجد رسوم تخزين للذاكرة المؤقتة الضمنية، بينما تُفرض رسوم تخزين على الذاكرة المؤقتة الصريحة. يُرجى الرجوع إلى صفحات الأسعار الرسمية الحالية لكلتا الخدمتين لمعرفة الأسعار الدقيقة، إذ تختلف باختلاف النموذج وإصداره.

معادلة حساب تكلفة الإدخال

يمكن فهم تكلفة الإدخال في طلبات توليد النص العادية وفق الصيغة التالية:

输入费用 =
（总输入 tokens − 缓存命中 tokens）× 普通输入单价
＋ 缓存命中 tokens × 缓存输入单价

تُحسب تكلفة الإخراج على حدة، وتُضاف إليها رسوم تخزين الذاكرة المؤقتة الصريحة إن وُجدت. إليك مثالًا افتراضيًا: إجمالي الإدخال في طلب ما هو 10,000 tokens، منها 8,000 tokens مطابقة لما هو مخزّن مؤقتًا. عندئذٍ تُحاسب 2,000 tokens بالسعر العادي، و8,000 tokens بسعر الإدخال المخزّن مؤقتًا.

أكثر نقطة يسهل الخطأ في حسابها: إجمالي الإدخال يشمل الجزء المخزّن مؤقتًا

عند مراجعة الحسابات، اعتمد على الاستجابة الأصلية من Google، لا على «نسبة إصابات الذاكرة المؤقتة» التي تعرضها لوحة خدمة الوكيل. في الحقل usageMetadata ضمن استجابة generateContent، يوجد حقلان أساسيان:

لذلك، لا تحسب promptTokenCount بأكمله بالسعر العادي ثم تضف إليه رسوم الإدخال المخزّن مؤقتًا؛ فذلك يؤدي إلى احتساب الجزء نفسه مرتين. الطريقة الصحيحة هي طرح الجزء المخزّن مؤقتًا من إجمالي الإدخال أولًا، ثم احتساب المتبقي بالسعر العادي. وإذا كنت تستخدم Interactions API الجديد، فإن الحقل الرسمي لإحصاءات التخزين المؤقت هو usage.total_cached_tokens.

أمران يجب الفصل بينهما

من المهم أيضًا التمييز بين أمرين: مقدار ما طابق الذاكرة المؤقتة فعليًا لدى Google، وكيف تحتسب خدمة الوكيل هذا الخصم في فاتورتك. يمكن قياس الأول باستخدام الحقول الرسمية، أما الثاني فيعتمد على قواعد الفوترة الخاصة بخدمة الوكيل، ولا يمكن لوثائق Google الرسمية أن تثبته نيابةً عنها. لذلك، عند مراجعة الفاتورة، يُنصح بمقارنة حقول التخزين المؤقت الواردة من الخدمة المصدرية مع تفاصيل الفاتورة وطريقة احتسابها.

💡 نصيحة للاختيار: ابدأ بمراجعة حقل رموز الذاكرة المؤقتة على مستوى الطلب، ثم تحقّق من إجمالي الفاتورة. وإذا أردت مقارنة OpenAI وClaude وGemini وفق معيار موحّد، يمكنك استخدام APIYI apiyi.com لاستدعاء النماذج المختلفة بالموجه نفسه، والتبديل بينها بسهولة.

اختلاف فوترة التخزين المؤقت بين Gemini وClaude وOpenAI

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

ثمة ثلاث نقاط في هذا الجدول يكثر الالتباس حولها:

• رسوم الكتابة: في Claude، تكلف كتابة البيانات إلى الذاكرة المؤقتة أكثر، بينما تكون القراءة منها أرخص. لذلك، قد يكون استخدامها أغلى من عدم استخدامها إذا كثرت الكتابة وقلّت القراءة. أما OpenAI فلا يفرض رسومًا للكتابة، لذا لا تترتب تكلفة إضافية عند عدم المطابقة. وينطبق الأمر نفسه على التخزين المؤقت الضمني في Gemini؛ إذ لا توجد رسوم كتابة، بينما تنشأ تكاليف الإنشاء والتخزين في حالة التخزين المؤقت الصريح فقط.
• من يقرر التخزين المؤقت؟ يحدد الطرف صاحب الطلب نقاط التخزين المؤقت صراحةً في Claude، لذا تكون نتائج المطابقة أكثر قابلية للتوقع. أما التخزين المؤقت الضمني لدى OpenAI وGemini، فتقرره المنصة تلقائيًا، ولا يسع المطور سوى تحسين فرص المطابقة بالحفاظ على ثبات البادئة. وهذا أحد أسباب شعور المستخدمين بأن المطابقة في Claude وOpenAI أكثر استقرارًا من Gemini؛ إذ تتأثر Gemini بالحد الأدنى والبادئة وعزل القنوات في الوقت نفسه.
• طريقة احتساب إجمالي الإدخال: يشمل إجمالي الإدخال في Gemini وOpenAI الجزء المخزّن مؤقتًا، لذا يجب طرحه قبل حساب التكلفة. أما input_tokens في Claude فلا يشمل عمليات القراءة والكتابة من الذاكرة المؤقتة، وتُحسب البنود الثلاثة كلٌّ على حدة ثم تُجمع. استخدام معادلة إحدى الشركات لحساب تكلفة شركة أخرى يؤدي إلى خطأ في الحساب. وعند مقارنة الفواتير بين النماذج عبر APIYI apiyi.com، تحقّق أولًا من طريقة احتساب الحقول التي تعرضها كل شركة.

دليل سريع لاختبار معدل إصابة ذاكرة Gemini المؤقتة بنفسك

بعد استعراض الجانب النظري، يبقى الاختبار العملي الطريقة الأوثق للتحقق. الفكرة هي إنشاء بادئة ثابتة وطويلة تتجاوز الحد الأدنى المطلوب، ووضع السؤال المتغير في النهاية، ثم إرسال عدة طلبات متتالية ومراقبة تغيّر حقول الرموز المميزة المخزّنة مؤقتًا.

مثال مبسط

يستخدم الكود التالي تنسيقًا متوافقًا مع OpenAI، ويطبع معلومات الاستخدام الواردة في الاستجابة. اعتمد أسماء الحقول الفعلية التي تظهر في الاستجابة، إذ قد تختلف أسماء الحقول المتعلقة بالتخزين المؤقت باختلاف طريقة الاتصال:

import time
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # 使用 APIYI 统一接口
)

# 固定的长前缀：务必超过目标模型的最低缓存门槛
LONG_PREFIX = "这里放一段稳定不变的长文档或系统指令……" * 800

for i in range(3):
    resp = client.chat.completions.create(
        model="gemini-3.8-flash",
        messages=[
            {"role": "system", "content": LONG_PREFIX},
            {"role": "user", "content": f"请用一句话总结，第 {i} 次提问"},
        ],
    )
    print(i, resp.usage)
    time.sleep(2)

import time
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # 使用 APIYI 统一接口
)

LONG_PREFIX = "这里放一段稳定不变的长文档或系统指令……" * 800


def extract_cached_tokens(usage) -> int:
    """尝试从 usage 中读取缓存 token 数，字段名以实际返回为准"""
    details = getattr(usage, "prompt_tokens_details", None)
    if details is not None:
        cached = getattr(details, "cached_tokens", None)
        if cached is not None:
            return cached
    return 0


def estimate_input_cost(total_in: int, cached: int,
                        normal_price: float, cached_price: float) -> float:
    """
    按官方口径估算输入费用：
    总输入已包含缓存部分，所以普通部分 = 总输入 - 缓存部分
    单价请填入官方定价页当前数值（每百万 token）
    """
    normal_part = total_in - cached
    return (normal_part * normal_price + cached * cached_price) / 1_000_000


def run_test(model: str, rounds: int = 3):
    results = []
    for i in range(rounds):
        resp = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": LONG_PREFIX},
                {"role": "user", "content": f"请用一句话总结，第 {i} 次提问"},
            ],
        )
        usage = resp.usage
        cached = extract_cached_tokens(usage)
        results.append((i, usage.prompt_tokens, cached))
        print(f"第 {i} 次：总输入={usage.prompt_tokens}，缓存命中={cached}")
        time.sleep(2)
    return results


if __name__ == "__main__":
    for m in ["gemini-3.8-flash"]:
        print("模型：", m)
        run_test(m)

🚀 ابدأ بسرعة: نوصي باستخدام APIYI apiyi.com لإجراء هذه المقارنة. يكفي تغيير قيمة model في السكربت نفسه لاختبار Gemini وOpenAI وClaude تباعًا، وملاحظة الفروق في أداء التخزين المؤقت بين النماذج.

متغيرات ينبغي ضبطها أثناء الاختبار

أثناء الاختبار، راجع القائمة التالية بندًا بندًا، حتى لا تخلط بين مشكلة في إعداداتك ومشكلة في مسار الاتصال:

كيفية تفسير نتائج الاختبار

إذا كانت البادئة طويلة بما يكفي، وبنيتها مستقرة، والفاصل بين الطلبات قصيرًا، ومع ذلك لم يحقق Gemini إلا عددًا ضئيلًا من الإصابات في الذاكرة المؤقتة، بينما نجح الموجه نفسه في تحقيق إصابات طبيعية على OpenAI أو Claude، فهذا يعني أن الفرق يرجع إلى آلية التخزين المؤقت في Gemini وظروف مسار الاتصال مع الخدمة الأساسية، وليس إلى طريقة كتابة الموجه. في هذه الحالة، يمكنك التفكير في استخدام التخزين المؤقت الصريح، بتثبيت المحتوى الطويل الذي تحتاج إلى إعادة استخدامه، وإنشاء عنصر ذاكرة مؤقتة يدويًا ثم الإشارة إليه في الطلبات.

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

الأسئلة الشائعة

أهم النقاط حول معدل إصابة ذاكرة التخزين المؤقت

• الملاحظة مؤكدة: تحقق سلسلة OpenAI وسلسلة Claude معدلات إصابة مستقرة، بينما يكون المعدل في Gemini منخفضًا، وقد يقترب من الصفر؛ لذا ينبغي تحليل الحالة على حدة.
• الإصابة غير مضمونة رسميًا: لا تضمن ذاكرة التخزين المؤقت الضمنية في Gemini توفير التكاليف، أما الذاكرة الصريحة فتتطلب إنشاء كائن ذاكرة تخزين مؤقت والإشارة إليه يدويًا.
• الحد الأدنى يختلف باختلاف النموذج: الحد الأدنى أعلى في النماذج الأحدث، وقد تختلف القيم بين Vertex وDeveloper API.
• المقدمة تحدد الإصابة: ضع المحتوى الطويل في البداية، وتجنب إدراج عناصر متغيرة، مثل الوقت أو المعرّفات، في مطلع الطلب حتى لا ينقطع البادئ المشترك.
• ذاكرة Vertex معزولة بحسب المشروع: لا تُشارك ذاكرة التخزين المؤقت بين المشاريع؛ لذا يؤدي توزيع الطلبات على مشاريع مختلفة إلى فقدان الإصابة.
• إجمالي الإدخال يشمل الجزء المخزّن مؤقتًا: يتضمن promptTokenCount الرموز الموجودة في ذاكرة التخزين المؤقت؛ لذا اطرحها أولًا عند مطابقة الفواتير، ثم احسب تكلفة كل جزء على حدة.
• طابق الفواتير بالاعتماد على الحقول: اعتمد على حقول ذاكرة التخزين المؤقت في الاستجابة الرسمية، وأجرِ مقارنة بين النماذج باستخدام الموجه نفسه عبر APIYI ‏apiyi.com.

الخلاصة

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

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

الخطوة التالية المقترحة: استخدم نص الاختبار الوارد في المقال لإجراء مقارنة بين Gemini وOpenAI وClaude مع تثبيت بادئ طويل، ثم قرر ما إذا كان من المناسب اعتماد التخزين الصريح. ونوصي باستخدام APIYI ‏apiyi.com للتحقق من النتائج بسرعة؛ إذ تتيح واجهة موحدة استخدام عدة نماذج ومقارنة تكاليفها بسهولة.

المراجع

1. وثائق التخزين المؤقت في Gemini API: شرح رسمي للتخزين المؤقت الضمني والصريح
2. الرابط: ai.google.dev/gemini-api/docs/caching

3. ملاحظة: تتضمن الحد الأدنى لعدد الرموز والعوامل المؤثرة في الفوترة

4. صفحة أسعار Gemini API: أسعار الإدخال العادي والإدخال المخزّن مؤقتًا والإخراج والتخزين

5. الرابط: ai.google.dev/gemini-api/docs/pricing

6. ملاحظة: مرجع للتحقق من الأسعار الحالية

7. نظرة عامة على التخزين المؤقت للسياق في Vertex AI: عزل المشاريع وقواعد الفوترة الخاصة بالتخزين المؤقت

8. الرابط: docs.cloud.google.com/vertex-ai/generative-ai/docs/context-cache/context-cache-overview

9. ملاحظة: توضح أن ذاكرة التخزين المؤقت في Vertex لا تُشارك بين المشاريع

10. مرجع Gemini API generateContent: حقل usageMetadata في الاستجابة

11. الرابط: ai.google.dev/api/generate-content
12. ملاحظة: حقل رموز التخزين المؤقت المستخدم عند مراجعة الفوترة

المؤلف: فريق APIYI
للنقاشات التقنية: يسعدنا أن تشاركوا تجاربكم في استكشاف مشكلات التخزين المؤقت في Gemini ضمن التعليقات. ولمزيد من المعلومات، تفضلوا بزيارة مركز وثائق APIYI على docs.apiyi.com.

مقالات ذات صلة

• تحليل أسعار Gemini 4 Argon: أصبح النموذج متاحًا الآن عبر Vertex AI، وحساب التكلفة الفعلية لـ5 سيناريوهات: أصبح نموذج Gemini 4 Argon متاحًا للتشغيل عبر Vertex AI؛ وتشرح هذه المقالة التكاليف الخفية لأسعار التجربة 2/10 دولارات والأسعار الرسمية 4/20 دولارًا، وخصم التخزين المؤقت بنسبة 95%، واحتساب رموز الاستدلال، والحد الأقصى للمخرجات البالغ مليون رمز، وتقارنه بـGemini 3.8 Flash وGPT-6 Astra وClaude Opus 5.5، مع تقديرات تكلفة لخمسة سيناريوهات وشيفرة لدمجه بتكلفة أقل.
• claude-sonnet-5-5 مقابل claude-opus-5-5: هل Opus أسرع وSonnet لم يعد سوى الأرخص؟ 6 مجموعات من البيانات توضح أفضل توليفة لوكلاء المؤسسات ذوي السياق الطويل: أصبح استخدام claude-opus-5-5 أسرع من المتوقع، فهل بقيت لـ claude-sonnet-5-5 ميزة السعر فقط؟ تقارن هذه المقالة بينهما عبر 6 أبعاد وتقدم خطة لاختيار النماذج لسيناريوهات الشركات ذات المدخلات والمخرجات الطويلة.
• ما معدل التزامن في gemini-4-argon AI Studio؟ 5 أسباب شائعة لتكرار أخطاء 429 و6 خطوات لحلها: وضّح آلية تحديد المعدل لنموذج gemini-4-argon في Google AI Studio، واشرح الفرق بين RPM وTPM والتزامن، وقدّم حلًا من 6 خطوات لخطأ 429 وشيفرة إعادة محاولة قابلة للتشغيل مباشرةً.