लागत अप्टिमाइजेसन: प्रम्प्ट क्यासिङ

लाभ:

• प्रम्प्ट क्यासिङको उपसर्ग मिलान तर्क व्याख्या गर्नुहोस्
• फिक्स्ड कन्टेक्स्ट पहिले र चर कन्टेक्स्ट पछि राखेर क्यास हिट बढाउँछ
• क्यास लेख्न/पढ्ने अर्थशास्त्र र ब्रेक-इभन बिन्दु गणना गर्न सक्छ

एउटा LLM उत्पादन प्रोटोटाइपमा सस्तो देखिन्छ; जब तपाईं मापनमा माथि जानुहुन्छ, बिल आश्चर्यचकित हुन्छ। धेरैजसो वर्कलोडहरूमा, धेरैजसो बिल उही निश्चित सन्दर्भबाट आउँछ जुन प्रत्येक अनुरोधको साथ बारम्बार पठाइन्छ: एक लामो प्रणाली प्रम्प्ट, नियम पुस्तिका, सन्दर्भ कागजात। प्रोम्प्ट क्यासिङले यो फोहोरलाई ठ्याक्कै हटाउँछ। यस एकाईमा, तपाईंले क्यासले कसरी काम गर्छ, प्रम्प्टलाई हिट गर्न कसरी मिलाउने, र क्यास अर्थतन्त्रको ब्रेक-इभन बिन्दु कसरी गणना गर्ने भन्ने कुरा सिक्नुहुनेछ। सही रूपमा स्थापना गर्दा, यसले एक्लै तपाईंको बिल आधा वा कममा काट्न सक्छ।

क्यासले कसरी काम गर्छ? एक अपरिवर्तनीय नियम

प्रम्प्ट क्यासिङ एक उपसर्ग मिलान हो। प्रदायकले अस्थायी रूपमा टोकनहरू भण्डारण गर्दछ जुन तपाइँको प्रम्प्टको सुरुदेखि नै प्रशोधन गरिएको छ। यदि प्रम्प्ट अर्को अनुरोधमा एउटै उपसर्गको साथ सुरु हुन्छ भने, यो साझा भाग पुन: गणना गरिएको छैन; यो क्यास भन्दा पढ्न धेरै सस्तो छ।

एउटा अपरिवर्तनीय नियम यसबाट पछ्याउँछ: यदि एकल बाइट उपसर्गमा कहीं पनि परिवर्तन भयो भने, सम्पूर्ण क्यास त्यस बिन्दुबाट अमान्य हुन्छ। अर्थात्, निश्चित सामग्री सुरुमा हुनुपर्छ र चल सामग्री अन्तमा हुनुपर्छ। यदि तपाइँ प्रणाली प्रम्प्टको सुरुमा एक लाइन राख्नुहुन्छ जुन प्रत्येक अनुरोधको साथ परिवर्तन हुन्छ, जस्तै "आजको मिति: 18.07.2026", यसको पछाडि सबै कुरा क्यासमा प्रवेश गर्न सक्षम हुनेछैन।

प्रशोधन क्रम सामान्यतया: उपकरण → प्रणाली प्रम्प्ट → सन्देशहरू। तपाईंले निश्चित खण्डको अन्त्यमा क्यास पोइन्ट (ब्रेकपोइन्ट) राख्नुहुन्छ।

क्यास इकोनोमी

क्यास तीन मूल्य तहहरू छन्:

• क्यास लेख्नुहोस्: पहिलो पटक भण्डारण गर्दै। ~1.25x सामान्य इनपुट मूल्य (5 मिनेट भण्डारणको लागि)।
• क्यास पढ्नुहोस्: पछिका अनुरोधहरूमा पढ्दै। ~ ०.१ गुणा सामान्य इनपुट मूल्य — अर्थात् दशौं भाग।
• सामान्य इनपुट: भाग जुन क्यासमा प्रवेश गर्दैन र प्रत्येक पटक पूर्ण लागतमा प्रशोधन गरिन्छ।

ब्रेक-इभन बिन्दु: पहिलो अनुरोधले प्रिमियम (१.२५×) तिर्छ। दोस्रो अनुरोधबाट, पढाइ (०.१ ×) खेलमा आउँछ। लगभग, तपाईं दुई अनुरोधहरूमा घाँटी र घाँटी हुनुहुनेछ; त्यस पछि, यो शुद्ध बचत हो। फिक्स्ड कन्टेक्स्ट जति ठूलो हुन्छ र जति धेरै अनुरोधहरू पुन: प्रयोग गरिन्छ, त्यति ठूलो लाभ हुन्छ।

परिदृश्य

क्यासले काम गर्छ?

ठूला निश्चित प्रणाली प्रम्प्ट, हजारौं अनुरोधहरू

हो - उच्चतम कमाई

एउटै सन्दर्भ कागजातमा धेरै प्रश्नहरू

हो

प्रत्येक अनुरोधको लागि पूर्ण रूपमा फरक छोटो पाठ

होइन - लेख्ने बोनस बर्बाद भयो

एक पटक अनुरोध

होइन - कुनै पढाइ छैन

प्रणाली प्रम्प्टमा प्रत्येक अनुरोधको साथ मिति/आईडी परिवर्तन

होइन — उपसर्ग टुटेको छ, हिट शून्य छ

चरण-दर-चरण: हिट प्रम्प्ट कसरी सेट अप गर्ने?

1. स्थिर र चर अलग गर्नुहोस्। कुन सामग्री कहिल्यै परिवर्तन हुँदैन (प्रणाली प्रम्प्ट, नियम पुस्तिका, कागजात)? प्रत्येक अनुरोध (प्रयोगकर्ता प्रश्न, मिति, आईडी) संग कुन परिवर्तन हुन्छ?
2. सुरुमा स्थिर राख्नुहोस्। प्रशोधनको समयमा, पहिलो भाग आउने भाग (उपकरणहरू, प्रणाली) स्थिर हुनुपर्छ।
3. अन्तमा चर राख्नुहोस्। प्रयोगकर्ताको हालको प्रश्न, अन्तिम।
4. सिमानाको अन्त्यमा चिन्ह राख्नुहोस्। निश्चित भागको अन्तिम ब्लकमा क्यास पोइन्ट राख्नुहोस्।
5. हिट प्रमाणित गर्नुहोस्। प्रतिक्रियामा प्रयोग फिल्डमा cache_read_input_tokens शून्य भन्दा ठूलो छ कि छैन जाँच गर्नुहोस्। यदि शून्य छ भने, उपसर्गमा लुकेको अवरोधक छ।

{ "प्रणाली": [ { "प्रकार": "टेक्स्ट", "टेक्स्ट": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "सन्देशहरू": [ { "भूमिका": "प्रयोगकर्ता", "सामग्री" {current}}} "प्रयोगकर्ता", "सामग्री" {current}}}

सुझाव: क्यास हिटहरू अनुमान नगर्नुहोस्, तिनीहरूलाई मापन गर्नुहोस्। यदि लगातार अनुरोधहरूमा usage.cache_read_input_tokens अझै पनि शून्य छ भने, एक साइलेन्ट ब्रेकर (datetime.now() प्रणाली प्रम्प्टमा, unordered JSON, प्रत्येक अनुरोधमा परिवर्तन हुने उपकरणहरूको सूची) चलिरहेको छ। बाइटद्वारा दुई अनुरोध बाइटको कच्चा प्रम्प्ट तुलना गर्नुहोस् र फरक फेला पार्नुहोस्।

मौन अवरोधकहरू

अनजानमा क्यास भ्रष्ट गर्ने विशिष्ट ढाँचाहरू:

# BREAKER: प्रणाली प्रम्प्टमा इम्बेडिङ जानकारी जुन प्रत्येक अनुरोधको साथ परिवर्तन हुन्छ "आजको मिति: {{अब}}। तपाईं एक सहायक हुनुहुन्छ..." ← प्रत्येक अनुरोधको साथ उपसर्ग परिवर्तन हुन्छ, हिट शून्य # TRUE: चरलाई सन्देश प्रणालीमा सार्नुहोस्: "तपाईं सहायक हुनुहुन्छ..." ← स्थिरताले क्यासमेसेजहरूमा प्रवेश गर्दछ: "{{roday}} प्रश्न: [{roday}} प्रश्न छ। ..."}] ← अन्त्यमा चल

अन्य ब्रेकरहरू: JSON ले प्रत्येक अनुरोधमा फरक रूपमा क्रमबद्ध गरिएको छ (कुञ्जीहरू निश्चित क्रममा राख्नुहोस्), प्रयोगकर्ताद्वारा फरक-फरक उपकरणहरूको सूची (उपकरणहरू पहिले प्रशोधन गरिन्छ; तिनीहरू परिवर्तन भएमा क्यासमा केही पनि जाँदैन), मोडेलको मध्य-वार्तालाप परिवर्तन गर्दै (क्यासहरू मोडेल विशिष्ट हुन्)।

कमजोर प्रम्प्ट / बलियो प्रम्प्ट (क्यास अनुकूल संरचना)

# कमजोर (क्यास बस्टिङ बिल्ड) प्रणाली: "मिति: 18.07.2026 14:32। प्रयोगकर्ता: Ahmet (आईडी 8842)। तपाईं एक समर्थन बोट हुनुहुन्छ। नियम: ...(2000 टोकनहरू)..."

# स्ट्रङ्ग (क्यास-मैत्री संरचना) प्रणाली: "तपाईं एक समर्थन बोट हुनुहुन्छ। नियम: ...(2000 टोकनहरू, कहिल्यै परिवर्तन हुँदैन)..." [क्यास साइन] सन्देशहरू: [ { भूमिका: प्रयोगकर्ता, सामग्री: "मिति: 18.07.2026 14:32। प्रयोगकर्ता आईडी: 8842। प्रश्न: मेरो रिफन्ड कसरी गर्ने?" }]

कमजोर संस्करणमा, 2000 टोकनहरूको नियम ब्लक प्रत्येक अनुरोधमा पूर्ण लागतमा प्रशोधन गरिन्छ। बलियो संस्करणमा, एउटै ब्लक एक पटक लेखिएको छ र मूल्यको दशांशको लागि सबै पछिका अनुरोधहरूमा पढ्नुहोस्।

तीन मिनी केसहरू

केस १ - नियमपुस्तिका क्यास गर्दै। एक लेखा स्वचालनले प्रत्येक इनभ्वाइसमा 12,000 टोकन नियमपुस्तिका थप्दै थियो; प्रति दिन 5,000 अनुरोध। Cacheless इनपुट लागत प्रति दिन ~ $180। तिनीहरूले नियमपुस्तिका स्थिर राखे र यसलाई क्यास गरे: पहिलो अनुरोधहरूले लेखन प्रिमियम तिर्यो, त्यसपछि ०.१ × पढियो। इनपुट लागत ~90% ~$18 प्रति दिन घट्यो।

केस २ - लुकेको मिति रेखाको लागत। एउटा टोलीले क्यास सेट अप गर्यो तर कुनै हिटहरू पाइनन्; cache_read_input_tokens सधैं शून्य थियो। कारण: प्रणाली प्रम्प्टको पहिलो लाइनमा datetime.now() थियो, प्रत्येक अनुरोधको साथ उपसर्ग परिवर्तन भइरहेको थियो। जब हामीले प्रयोगकर्ता सन्देशमा मिति सार्यौं, हिट दर अचानक 0% बाट 94% मा बढ्यो।

केस 3 - गलत क्यास। एउटा खोज अनुप्रयोगले प्रत्येक अनुरोधको साथ पूर्ण रूपमा फरक छोटो प्रश्नहरू पठाउँदै थियो; तिनीहरूले उत्सुकतासाथ क्यास चिन्ह थपे। कुनै सामान्य उपसर्ग बिना, प्रत्येक अनुरोधले केवल एक लेखन प्रिमियम भुक्तान गर्यो, कुनै पढाइ छैन - लागत बढ्दै। तिनीहरूले चिन्ह हटाए। पाठ: क्यासले मात्र भुक्तान गर्छ यदि त्यहाँ ठूलो र स्थिर उपसर्ग पुन: प्रयोग गरिन्छ।

सामान्य गल्तीहरू

• स्थिर र चर मिश्रण: जब चर सामग्री उपसर्गमा हुन्छ, हिट रिसेट हुन्छ।
• प्रणाली प्रम्प्टमा इम्बेडिङ मिति/आईडी: सबैभन्दा सामान्य मौन अवरोधक।
• हिट मापन गर्दैन: यदि cache_read_input_tokens जाँच गरिएन भने, फोहोरलाई ध्यान दिइने छैन।
• कुनै सार्वजनिक उपसर्ग नभएको बेला क्यास थप्दै: तपाईंले लेखन प्रिमियम मात्र तिर्नुहुन्छ, लागत बढ्छ।
• सवारी साधनको सूची वा मोडेल परिवर्तन गर्दै: उपसर्ग सुरुबाट बिग्रिएको छ; सबै कुरा पुन: लेखिएको छ।
• न्यूनतम क्यास साइज बिर्सिदै: धेरै छोटो क्यासहरू (मोडेलमा निर्भर ~1–4k टोकनहरू अन्तर्गत) चुपचाप क्यासमा प्रवेश गर्दैन।

गहिरो: वर्कलोड प्रकार द्वारा क्यास डिजाइन गर्दै

क्यासिङको वास्तविक भुक्तानी तपाईंको कार्यभारको प्रकृतिमा निर्भर हुन्छ; त्यसैले पहिले आफ्नो ट्राफिक जान्नुहोस्। तीन विशिष्ट ढाँचा र सही स्थापना:

साझा प्रणाली प्रम्प्ट, विभिन्न प्रश्नहरू। सबैभन्दा सामान्य उद्यम ढाँचा: सयौं फरक प्रयोगकर्ता प्रश्नहरूको साथ एक ठूलो प्रणाली प्रम्प्ट (भूमिका, नियमहरू, हुनसक्छ सन्दर्भ कागजात)। यहाँ निश्चित भाग (प्रणाली) सुरुमा क्यास गरिएको छ; प्रत्येक नयाँ प्रश्नले आफ्नै सानो अंशको लागि मात्र पूर्ण मूल्य तिर्छ। लाभ धेरै उच्च छ किनकि ठूलो भाग मूल्यको दशौं भागमा बारम्बार पठाइन्छ।

बहु-गोल मोनोलोग। वार्तालाप तान्दै जाँदा, प्रत्येक नयाँ राउन्ड सबै अघिल्लो इतिहासको शीर्षमा बनाउँछ। यदि तपाईंले अन्तिम राउन्डको अन्त्यमा क्यास फ्ल्याग राख्नुभयो भने, प्रत्येक अनुरोधले अघिल्लो कुराकानी उपसर्ग पुन: प्रयोग गर्दछ; कुराकानी बढ्दै जाँदा हिटहरू जम्मा हुन्छन्। यसले लामो सहायक सत्रहरूको लागतमा नाटकीय रूपमा लगाम राख्छ।

साझा उपसर्ग परिवर्तन गर्न अन्तिम बिट हो। धेरै अनुरोधहरूले निश्चित पूर्वहरू (नमूना सेट, निर्देशनहरू) को ठूलो सेट साझा गर्दछ तर अन्त्यमा एकल प्रश्नद्वारा छुट्याइन्छ। तपाईंले साझा भागको अन्त्यमा क्यास सूचक राख्नुहुन्छ; अन्यथा, प्रत्येक अनुरोधले आफ्नै छुट्टै क्यास लेख्नेछ र कुनै पनि पढिने छैन।

एउटा चेतावनी: क्यास मोडेल र एक निश्चित न्यूनतम आकार मा निर्भर गर्दछ। धेरै साना उपसर्गहरू (केही हजार टोकनहरू अन्तर्गत, मोडेलमा निर्भर गर्दै) तपाईंले तिनीहरूलाई फ्ल्याग गरे पनि चुपचाप क्यासमा प्रवेश गर्दैन — cache_creation_input_tokens शून्य रहन्छ। साथै, मोडेल मध्य-वार्तालाप परिवर्तन गर्दा सम्पूर्ण क्यास अमान्य हुन्छ; यदि फरक कार्यलाई सस्तो मोडेल चाहिन्छ भने, मुख्य प्रवाहलाई एउटा मोडेलमा राख्नुहोस् र छेउको कामलाई छुट्टै कलमा राख्नुहोस्।

संक्षेपमा

प्रम्प्ट क्यासिङ एक उपसर्ग मिलान हो: निश्चित सामग्री सुरुमा हुनुपर्छ, चल सामग्री अन्तमा हुनुपर्छ। ठूलो, पुन: प्रयोग गरिएको सन्दर्भको लागि, पढ्ने लागत पूर्ण मूल्यको दशांश हो, लगभग दुईवटा अनुरोधहरूमा पनि तोड्ने। सबैभन्दा सामान्य गल्ती प्रणाली प्रम्प्टमा चर डाटा इम्बेड गरेर उपसर्ग भ्रष्ट गर्नु हो; तपाईंले प्रयोग क्षेत्रमा मापन गरेर हिट प्रमाणित गर्नुहुन्छ।

आवेदन कार्य

कार्यभार छान्नुहोस्। (१) सामग्रीलाई दुई स्तम्भहरूमा विभाजन गर्नुहोस्: "कहिल्यै परिवर्तन हुँदैन" र "हरेक अनुरोधमा परिवर्तनहरू"। (२) प्रम्प्ट संरचनालाई पुन: कोर्नुहोस्, स्थिर भागलाई सुरुमा र चल भागलाई अन्तमा राख्नुहोस्। (३) निश्चित भागको टोकन साइज अनुमान गर्नुहोस् र क्याससँग/बिना मासिक लागत तुलना गर्नुहोस्। (4) कुन फिल्ड (cache_read_input_tokens) बाट तपाईंले हिट प्रमाणित गर्नुहुनेछ नोट गर्नुहोस्।

चेकलिस्ट

• [ ] म व्याख्या गर्न सक्छु कि क्यास उपसर्ग मिल्दो र एक मात्र अपरिवर्तनीय नियम हो।
• [ ] म सुरुमा निश्चित सामग्री र अन्त्यमा चर राखेर शुद्धता बढाउन सक्छु।
• [] मलाई अर्थशास्त्र र दुई-अनुरोध ब्रेक-इभन पोइन्ट लेख्न/पढ्न थाहा छ।
• [ ] म मौन अवरोधकर्ताहरू (मिति, अक्रमित JSON, सवारी साधनको सूची परिवर्तन गर्ने) चिन्न सक्छु।
• [ ] म usage.cache_read_input_tokens मार्फत हिट प्रमाणित गर्न सक्छु।