تحوّل GPT API كل صورة إلى توكنات، وحقل detail يحدد عددها. يعرض هذا المقال تنسيق الطلب، وقيم low وhigh وoriginal وauto، وأمثلة محلولة لحساب التوكنات للنماذج القائمة على البلاطات والنماذج القائمة على الرقع، واختبارًا عمليًا خطوة بخطوة على PicassoIA.
حقل واحد في جسم الطلب يحدد ما إذا كانت الصورة تكلّف 85 توكنًا أو 3,000 توكن. هذا الحقل هو detail، ويقع داخل كائن الصورة بجانب الرابط، وكثير من الدروس إما تتجاهله أو تذكر أرقامًا لم تعد صحيحة منذ جيلين من النماذج. إذا أرسلت لقطات شاشة أو إيصالات أو صورًا لمنتجات أو مخططات إلى نماذج GPT، فهذا الإعداد يشكّل فاتورتك وزمن الاستجابة ومقدار ما يستطيع النموذج قراءته فعليًا من الصورة.
يتناول هذا المقال تنسيق الطلب، وقيم detail الأربع، وحساب التوكنات للنماذج القائمة على البلاطات والنماذج القائمة على الرقع، والحالات التي يأتي فيها low بنتيجة عكسية، والحدود التي تستحق المعرفة قبل النشر. تأتي الأرقام من صفحات إدخال الصور في توثيق API لدى OpenAI كما تظهر اليوم، وكل مثال محلول يعرض حسابه، لذا يمكنك التحقق منه مقابل كتلة usage في ردودك. تتغير صفحات كهذه كثيرًا، وهذا سبب إضافي لتسجيل عدد التوكنات بدلًا من الاعتماد على جدول، بما في ذلك الجداول أدناه.
لا يقرأ نموذج GPT ملف JPEG الخاص بك كملف أبدًا. تقوم API بتغيير حجمه، ثم تقطعه إلى كتل صغيرة، وتحوّل كل كتلة إلى توكنات تقع في نافذة السياق بجانب نصك. تُحتسب هذه التوكنات بسعر الإدخال المعتاد للنموذج، لذا تعني الصورة الأكبر أو الأكثر حدة فاتورة أكبر وزمن استجابة أطول. كما تتنافس هذه التوكنات مع أمرك النصي والإجابة على نافذة السياق نفسها، وهذا مهم عندما يحمل الطلب عدة صور.
تُرسل الصور داخل رسالة المستخدم كأجزاء محتوى. تستخدم Responses API أجزاء input_text وinput_image، بينما تستخدم Chat Completions أجزاء text وimage_url. وفي الحالتين يقع detail على جزء الصورة. إليك قارئًا للإيصالات يعمل على GPT 5.4:
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.4",
input=[
{
"role": "user",
"content": [
{"type": "input_text", "text": "List every line item and the total."},
{
"type": "input_image",
"image_url": "https://example.com/receipt.jpg",
"detail": "original",
},
],
}
],
)
print(response.output_text)
print(response.usage.input_tokens)
الاستدعاء نفسه عبر Chat Completions مع GPT-4o يضع الرابط في مستوى أعمق:
completion = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "user",
"content": [
{"type": "text", "text": "Describe this photo in one sentence."},
{
"type": "image_url",
"image_url": {"url": "https://example.com/photo.jpg", "detail": "low"},
},
],
}
],
)
print(completion.usage.prompt_tokens)
بعد كل استدعاء، اقرأ usage.input_tokens في Responses أو usage.prompt_tokens في Chat Completions. إنه الرقم الوحيد الذي يحسم أي نقاش حول التكلفة.
data:image/jpeg;base64,... مضمّنة تعمل مع الملفات الخاصة، وتضيف نحو الثلث إلى حجم الحمولة.vision، ثم أشر إلى المعرّف عبر حقل file_id في جزء الصورة، وأعد استخدامه عبر الطلبات.الصيغ المقبولة هي PNG وJPEG وWEBP وGIF غير المتحرك.
يقبل حقل detail القيم low وhigh وoriginal وauto. إذا حذفته تحصل على auto، أي الحجم الافتراضي الذي يحدده النموذج. تبدو الأسماء كسلّم بسيط، لكن ما تفعله كل درجة يعتمد على النموذج الذي تستدعيه.
| القيمة | ما تقوله الوثائق عنها | انتبه إلى |
|---|---|---|
low | قراءة تقريبية للصورة | ليست دائمًا أرخص من high في النماذج الأحدث |
high | دقة عالية قياسية | محدودة بـ 2,500 رقعة في عائلة GPT 5.4 |
original | الصور الكبيرة الكثيفة أو الحساسة للموضع أو صور استخدام الحاسوب | تحتاج إلى GPT 5.4 أو أحدث، ولا تُدعم في GPT 5.2 أو GPT 4.1 mini |
auto | الحجم الافتراضي للنموذج | القيمة التي تحصل عليها عندما يغيب الحقل |
في نماذج القائمة على البلاطات الأقدم، تُحتسب low برسوم ثابتة: 85 توكنًا في GPT-4o وGPT 4.1، مهما كان حجم الملف. يستقبل النموذج نسخة بدقة 512 × 512 بكسل، وهذا يكفي لقول "كلب على شاطئ" لكنه لا يكفي لقراءة لوحة شارع. استخدمه للتصنيف والتعليقات التقريبية وجولات الإشراف وقرارات التوجيه، حيث يكون المهم هو الفكرة العامة فقط.
في نماذج البلاطات، تُدخل high الصورة أولًا داخل مربع 2,048 × 2,048 بكسل، ثم تُقيس أقصر ضلع إلى 768 بكسل، ثم تحسب البلاطات 512 بكسل. وفي عائلة GPT 5.x تعمل بدلًا من ذلك بالرقع 32 × 32 بكسل، بأقصى ضلع 2,048 بكسل وميزانية 2,500 رقعة في GPT 5.4 وإخوته الأصغر. وهذا كافٍ للصور الفوتوغرافية وصور المنتجات ولقطات الشاشة العادية. يبدأ الضرر مع الوثائق الكثيفة ونصوص الواجهات الصغيرة، حيث تتحول بضعة بكسلات مفقودة من الرقم 6 إلى 8.
ترفع original السقف إلى 10,000 رقعة وضلع أطول 6,000 بكسل في GPT 5.4 وإخوته. توجهها OpenAI إلى الصور الكبيرة الكثيفة الحساسة للموضع أو صور استخدام الحاسوب، وإلى الأعمال الحساسة للإحداثيات مثل التعرف الضوئي على الحروف OCR أو اكتشاف الأجسام الصغيرة. تخيل لقطة شاشة بدقة 4K يجب على النموذج أن يعيد فيها موضع زر، أو مخططًا لطابق حيث يحمل خط رفيع معنى. أنت تدفع ثمن هذه الحدّة: حتى 12,000 توكن صورة لكل صورة بمضاعف 1.2.
القاعدة العملية أن تبرّر هذا الخيار بالنتائج. ابدأ المهمة بـhigh، واجمع الأخطاء، وانقل أنواع الصور الفاشلة فقط إلى original. إذا أُسيء قراءة حقل عند high وقُرئ بشكل صحيح عند original، فقد اشترت التوكنات الإضافية شيئًا. أما إذا فشل الإعدادان بالطريقة نفسها، فالمشكلة في الأمر النصي أو في الصورة المصدر، ولن تنفع البكسلات الإضافية.
يتكون احتساب البلاطات من رسم أساسي زائد رسم عن كل بلاطة 512 بكسل. يتقاضى GPT-4o وGPT 4.1 85 توكنًا أساسيًا و170 لكل بلاطة. ويتقاضى GPT 5.1 70 و140. ويتقاضى GPT 4o Mini 2,833 و5,667، لذا فنقل عمل الصور إلى النموذج الصغير يضخم عدد التوكنات بدل أن يخفضه. قارن التكلفة الإجمالية، لا سعر التوكن الواحد.
| الصورة | Detail | النموذج | الحساب | التوكنات |
|---|---|---|---|---|
| أي حجم | low | GPT-4o | رسم أساسي ثابت | 85 |
| 1024 x 1024 | high | GPT-4o | 4 بلاطات × 170 + 85 | 765 |
| 1920 x 1080 | high | GPT-4o | يُغيّر الحجم إلى 1365 x 768، و3 x 2 = 6 بلاطات، و6 × 170 + 85 | 1,105 |
| 1024 x 1024 | high | GPT 4o Mini | 4 بلاطات × 5,667 + 2,833 | 25,501 |
تحسب النماذج الأحدث رقعًا بحجم 32 × 32 بكسل: ceil(width / 32) x ceil(height / 32). وعندما يتجاوز المجموع الميزانية، يُصغَّر حجم الصورة حتى تتناسب معها، ويكون عدد التوكنات النهائي هو عدد الرقع مضروبًا في مضاعف النموذج ومقرّبًا للأعلى. المضاعف هو 1.2 لـ GPT 5.2 وGPT 5.4 وعائلة GPT 5.6 (Sol وTerra وLuna)، و1.62 لـ GPT 4.1 mini.
| الصورة | Detail | الرقع | التوكنات بمضاعف 1.2 |
|---|---|---|---|
| 1920 x 1080 | low، أو high، أو original | 60 x 34 = 2,040 | 2,448 |
| 4000 x 3000 | high | محدودة بـ 2,500 | حتى 3,000 |
| 4000 x 3000 | low | نحو 3,072 بعد سقف 2,048 بكسل | نحو 3,700 |
| 4000 x 3000 | original | محدودة بـ 10,000 | حتى 12,000 |
صفوف 4000 x 3000 هي حساباتي الخاصة من الميزانيات المنشورة، فاعتبرها تقديرات وتحقق منها عبر usage. أما صف 1080p فهو دقيق تمامًا لأن الصورة تتسع أصلًا لكل الميزانيات.
يُحدث الحجم فرقًا حقيقيًا. عشرة آلاف صورة منتج بـ 2,448 توكنًا لكل منها تساوي 24.48 مليون توكن إدخال قبل أن تُكتب كلمة واحدة من الأمر النصي. أما المجموعة نفسها بـ 85 توكنًا لكل منها على GPT-4o low فتساوي 850,000، أي فرقًا يقارب 29 ضعفًا لا يمكن أن تلاحظه من الكود وحده.
تحمل الوثائق تحذيرًا يفاجئ الناس: low لا تستخدم دائمًا توكنات أقل من high. في GPT 5.4 وإخوته الأصغر، تسمح low بميزانية 6,144 رقعة بينما تتوقف high عند 2,500، لذا قد تُحتسب الصورة الكبيرة بتكلفة أعلى عند low. أما في GPT 5.2 وGPT 4.1 mini فكل المستويات تتشارك قاعدة حجم واحدة، وهي ضلع أطول 2,048 بكسل وميزانية 6,144 رقعة، لذا فإن low وhigh وauto تعيد أعدادًا متطابقة، وoriginal غير متاحة.
يترتب على ذلك أمران. لا تفترض أبدًا أن الإعداد الرخيص رخيص، وتوقع أن يتغير معنى قيم detail الحالية عندما تبدّل النماذج. اختبار قصير يحسم الأمرين:
💡 إذا أعاد
lowوhighالعدد نفسه من التوكنات على نموذج ما، فالحقل لا يفعل شيئًا هناك. احذفه من كودك بدلًا من الإبقاء على معامل يوحي بتوفير لن تحصل عليه.
تسمح الوثائق الحالية بحمولة إجمالية تصل إلى 512 ميغابايت وبما يصل إلى 1,500 صورة في الطلب الواحد. تذكر المقالات القديمة 50 ميغابايت و500 صورة، لذا فإن أي مكتبة تفرض هذه الأرقام قد تكون قديمة. طلب بحجم 512 ميغابايت يمثل مشكلة في زمن الاستجابة قبل أن يمثل مشكلة في الحدود، لأن Base64 يضخّم البايتات بنحو الثلث، وكل صورة ما زالت تُحتسب توكناتها.
تسرد OpenAI نقاط الضعف بوضوح، وهي تطابق ما يظهر في بيئة الإنتاج:
الخط الصغير هو الضحية المعتادة في العمل اليومي. عندما يكون الجزء المهم صغيرًا، أرسل ذلك الجزء وحده.
💡 اقتصّ الصورة قبل الإرسال. قصّ بحجم 600 × 400 لسطر المجموع في إيصال يكلّف نحو 300 توكن على GPT 5.4 (19 × 13 = 247 رقعة، مضروبة في 1.2). أما الصفحة الكاملة بدقة 4000 × 3000 عند
originalفقد تصل إلى 12,000، والقص غالبًا ما يُقرأ بشكل أفضل.
معظم الإنفاق الزائد يأتي من عادات قليلة:
original لـ GPT 5.4 وإخوته)، وصدّرها كملف JPEG، فيُرفع الطلب أسرع دون أن يضيع شيء.| المهمة | ابدأ بـ | السبب |
|---|---|---|
| الإشراف والتوجيه والتعليقات التقريبية | low في نماذج البلاطات، وauto في نماذج الرقع | الفكرة العامة تكفي |
| صور المنتجات ووصف المشاهد | high أو auto | تفاصيل جيدة بتكلفة معتدلة |
| الإيصالات والفواتير | high بعد القص، أو original في GPT 5.4 وما بعده | الخط الصغير يحتاج إلى بكسلات |
| المخططات ولوحات المتابعة | original، أو قارئ متخصص | الخطوط الرفيعة تحمل معنى |
| لقطات الشاشة لوكلاء الواجهات | original | يجب أن تكون الإحداثيات دقيقة |
النص هو أول ما يتضرر من تغيير الحجم. اقتصّ المنطقة، وعدّل استقامتها، واطلب شكل JSON ثابتًا حتى يسهل اكتشاف رقم خاطئ. أخبر النموذج أن يجيب unreadable عن أي حقل لا يستطيع قراءته، لأن النموذج الذي يُسمح له بالتخمين سيخمّن، والمجموع الخاطئ بثقة أسوأ من الفراغ. وإذا كان المسح ضبابيًا، فأصلحه قبل الرفع بأداة لاستعادة الصور بالذكاء الاصطناعي، لأن أي إعداد للتفاصيل لا يستطيع أن يخترع بكسلات لم تُلتقط أصلًا.
تجمع المخططات بين خطوط رفيعة وتسميات صغيرة وألوان متشابهة، وهي الحالة الدقيقة التي تنبّه إليها OpenAI. أرسلها بـoriginal عندما يدعمها النموذج. اطلب الأرقام الأساسية في جدول أولًا والتفسير ثانيًا، حتى تتمكن من مراجعة القيم مقابل الصورة قبل أن تثق بأي اتجاه يصفه النموذج. أما للجداول والمخططات التي تستخرجها يوميًا، فيستحق متخصص مثل Granite Vision 4.1 4B اختبارًا جنبًا إلى جنب.
في أعمال الكتالوج، شغّل اختبار الصور الثلاث المذكور سابقًا على صورك الحقيقية، ثم ثبّت الإعداد والأمر النصي للدفعة كلها. اطلب الخصائص نفسها بالترتيب نفسه في كل مرة، مثل اللون والمادة والعيوب الظاهرة، وسيصبح الناتج سهل التحميل في قاعدة بيانات. صوّر الأصناف بالطريقة نفسها أيضًا: خلفية ثابتة ومسافة وإضاءة متسقة تتيح لك إعدادًا أرخص، لأن النموذج لم يعد مضطرًا للتعامل مع الضوضاء. صورة منتج التقطت على سطح طاولة بسيط تحت إضاءة متساوية كثيرًا ما تُقرأ جيدًا عند high، بينما قد لا تُقرأ صورة الكوب نفسه جيدًا في مطبخ مزدحم.
لا تحتاج إلى كود لترى ما يقرؤه النموذج. يقبل GPT 5.4 على PicassoIA الصور إلى جانب أمر نصي، وتعرض واجهته نفس أدوات الضبط التي تضبطها في API: موجّه النظام، ودرجة الإسهاب، وجهد الاستدلال، وحد توكنات الإكمال. لذلك هو مكان سريع لحسم الأسئلة التي تسبق الإعدادات. ما صيغة الأمر النصي التي تنجح؟ هل يقرأ النموذج هذا النوع من الصور أصلًا؟ هل يكفي نموذج أرخص؟ تنبيه واحد: تحتوي الواجهة على حقل إدخال صور لكن لا تحتوي على مفتاح detail، لذا تعامل مع النتائج كاختبار لاختيار الأمر النصي والنموذج، لا كقياس low مقابل high.
low لمهام الاستخراج، وhigh عندما تريد تفصيلًا كاملًا.none للقراءة البسيطة. ارفعه للأسئلة متعددة الخطوات، وارفع Max Completion Tokens معه، لأن الجهد العالي قد يستنفد الميزانية كلها في الاستدلال ويعيد إجابة فارغة.
تحويل الصورة إلى نص هو إحدى القدرات المدمجة في المنصة، وتقبل عدة نماذج لغوية الصور:
| النموذج | مناسب لـ |
|---|---|
| GPT-4o | نص وصور في طلب واحد، ومخرجات JSON عند الطلب |
| GPT 5.4 | لقطات الشاشة والمخططات مع جهد استدلال قابل للضبط |
| Gemini 3.5 Flash | الدردشة السريعة، وأسئلة الكود والصور |
| Qwen3.7-Plus | تفسير النص مع الصورة |
| Kimi K2.5 | دردشة تقرأ النص والصور |
| Claude Opus 4.7 | البرمجة والرؤية والاستدلال في نموذج واحد |
| Granite Vision 4.1 4B | استخراج المخططات والجداول |
اختر خمس صور من عملك الفعلي: واحدة صغيرة جدًا، وواحدة بدقة 1080p، وواحدة بدقة 12 ميغابكسل، وإيصالًا، ومخططًا. شغّلها عبر GPT 5.4 وGPT-4o على PicassoIA، ودوّن الإجابات الصحيحة، ثم خذ الفائز إلى API وقارن عدد التوكنات عند كل قيمة من detail. ساعة اختبار كهذه توفر مالًا أكثر من أي تعديل على التسعير.
تحتاج إلى مواد اختبار؟ افتح PicassoIA، وولّد مشاهدك الخاصة بنماذج تحويل النص إلى صورة، وحوّلها إلى مجموعة اختبار لأوامرك النصية الخاصة بالرؤية. يمكنك تصفح كل ما هو متاح عبر picassoia.com/en/all-models. ابدأ بصورة واحدة، واطرح سؤالًا واحدًا ضيقًا، وشاهد بالضبط ما يقرأه النموذج.
اختر لغتك
