లాభాలు:
- ప్రాంప్ట్ కాషింగ్ యొక్క ప్రిఫిక్స్ మ్యాచింగ్ లాజిక్ను వివరించండి
- స్థిర సందర్భాన్ని ముందుగా మరియు వేరియబుల్ సందర్భాన్ని తర్వాత ఉంచడం ద్వారా కాష్ హిట్ను పెంచుతుంది
- కాష్ రైట్/రీడ్ ఎకనామిక్స్ మరియు బ్రేక్-ఈవెన్ పాయింట్ని లెక్కించవచ్చు
ఒక LLM ఉత్పత్తి ప్రోటోటైప్లో చౌకగా కనిపిస్తుంది; మీరు స్థాయికి చేరుకున్నప్పుడు, బిల్లు ఆశ్చర్యపరుస్తుంది. చాలా పనిభారంలో, బిల్లులో ఎక్కువ భాగం ప్రతి అభ్యర్థనతో పదే పదే పంపబడే స్థిరమైన సందర్భం నుండి వస్తుంది: సుదీర్ఘ సిస్టమ్ ప్రాంప్ట్, రూల్బుక్, రిఫరెన్స్ డాక్యుమెంటేషన్. ప్రాంప్ట్ కాషింగ్ సరిగ్గా ఈ వ్యర్థాలను తొలగిస్తుంది. ఈ యూనిట్లో, కాష్ ఎలా పని చేస్తుందో, హిట్ చేయడానికి ప్రాంప్ట్ను ఎలా ఏర్పాటు చేయాలో మరియు కాష్ ఎకానమీ యొక్క బ్రేక్-ఈవెన్ పాయింట్ను ఎలా లెక్కించాలో మీరు నేర్చుకుంటారు. సరిగ్గా ఇన్స్టాల్ చేసినప్పుడు, అది ఒక్కటే మీ బిల్లును సగానికి లేదా అంతకంటే తక్కువకు తగ్గించగలదు.
Cache ఎలా పని చేస్తుంది? ఒక మార్పులేని నియమం
ప్రాంప్ట్ కాషింగ్ అనేది ఉపసర్గ సరిపోలిక. ప్రొవైడర్ మీ ప్రాంప్ట్ ప్రారంభం నుండి ప్రాసెస్ చేసిన టోకెన్లను తాత్కాలికంగా నిల్వ చేస్తుంది. తదుపరి అభ్యర్థనపై ప్రాంప్ట్ అదే ఉపసర్గతో ప్రారంభమైతే, ఈ సాధారణ భాగం మళ్లీ లెక్కించబడదు; కాష్ కంటే చదవడం చాలా చౌకగా ఉంటుంది.
దీని నుండి ఒక మార్పులేని నియమం అనుసరిస్తుంది: ఉపసర్గలో ఎక్కడైనా ఒక్క బైట్ మారితే, ఆ పాయింట్ నుండి మొత్తం కాష్ చెల్లదు. అంటే, స్థిర కంటెంట్ ప్రారంభంలో మరియు వేరియబుల్ కంటెంట్ ముగింపులో ఉండాలి. మీరు సిస్టమ్ ప్రాంప్ట్ ప్రారంభంలో "నేటి తేదీ: 18.07.2026" వంటి ప్రతి అభ్యర్థనతో మారే పంక్తిని ఉంచినట్లయితే, దాని వెనుక ఉన్న ప్రతిదీ కాష్లోకి ప్రవేశించలేరు.
ప్రాసెసింగ్ క్రమం సాధారణంగా ఉంటుంది: సాధనాలు → సిస్టమ్ ప్రాంప్ట్ → సందేశాలు. మీరు స్థిర విభాగం చివరిలో కాష్ పాయింట్ (బ్రేక్పాయింట్)ని ఉంచారు.
కాష్ ఎకానమీ
Cache మూడు ధర స్థాయిలను కలిగి ఉంది:
- కాష్ రైట్: మొదటిసారి నిల్వ చేస్తోంది. ~1.25x సాధారణ ఇన్పుట్ ధర (5 నిమిషాల నిల్వ కోసం).
- కాష్ రీడ్: తదుపరి అభ్యర్థనలను చదవడం. సాధారణ ఇన్పుట్ ధర కంటే ~0.1 రెట్లు — అంటే పదవ వంతు.
- సాధారణ ఇన్పుట్: కాష్లోకి ప్రవేశించని భాగం మరియు ప్రతిసారీ పూర్తి ఖర్చుతో ప్రాసెస్ చేయబడుతుంది.
బ్రేక్-ఈవెన్ పాయింట్: మొదటి అభ్యర్థన రైట్ ప్రీమియం (1.25×) చెల్లిస్తుంది. రెండవ అభ్యర్థన నుండి, పఠనం (0.1×) అమలులోకి వస్తుంది. స్థూలంగా, మీరు రెండు అభ్యర్థనలపై మెడ మరియు మెడతో ఉంటారు; ఆ తర్వాత నికర ఆదా అవుతుంది. స్థిరమైన సందర్భం పెద్దది మరియు ఎక్కువ అభ్యర్థనలు తిరిగి ఉపయోగించబడతాయి, పెద్ద లాభం అవుతుంది.
దృశ్యం
కాష్ పని చేస్తుందా?
పెద్ద స్థిర సిస్టమ్ ప్రాంప్ట్, వేలాది అభ్యర్థనలు
అవును — అత్యధిక ఆదాయాలు
ఒకే రిఫరెన్స్ డాక్స్పై చాలా ప్రశ్నలు
అవును
ప్రతి అభ్యర్థనకు పూర్తిగా భిన్నమైన చిన్న వచనం
లేదు — వ్రాసే బోనస్ వృధా అవుతుంది
ఒక సారి అభ్యర్థన
లేదు — అస్సలు చదవడం లేదు
సిస్టమ్ ప్రాంప్ట్లో ప్రతి అభ్యర్థనతో తేదీ/ID మారుతోంది
లేదు — ఉపసర్గ విరిగింది, హిట్ సున్నా
దశల వారీగా: హిట్ ప్రాంప్ట్ను ఎలా సెటప్ చేయాలి?
- స్థిరమైన మరియు వేరియబుల్ను వేరు చేయండి. ఏ కంటెంట్ ఎప్పుడూ మారదు (సిస్టమ్ ప్రాంప్ట్, రూల్బుక్, డాక్యుమెంటేషన్)? ప్రతి అభ్యర్థనతో (వినియోగదారు ప్రశ్న, తేదీ, ID) ఏ మార్పులు?
- ప్రారంభంలో స్థిరాంకం ఉంచండి. ప్రాసెసింగ్ సమయంలో, ముందుగా వచ్చే భాగం (సాధనాలు, సిస్టమ్) స్థిరంగా ఉండాలి.
- చివరిలో వేరియబుల్ ఉంచండి. వినియోగదారు ప్రస్తుత ప్రశ్న, చివరిది.
- సరిహద్దు చివరిలో గుర్తును ఉంచండి. స్థిర భాగం యొక్క చివరి బ్లాక్లో కాష్ పాయింట్ను ఉంచండి.
- హిట్ని ధృవీకరించండి. ప్రతిస్పందనలో వినియోగ ఫీల్డ్లో cache_read_input_tokens సున్నా కంటే ఎక్కువగా ఉన్నాయో లేదో తనిఖీ చేయండి. సున్నా అయితే, ఉపసర్గలో దాచిన డిస్రప్టర్ ఉంటుంది.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user_}, "{contentscurrent" ]}
చిట్కా: కాష్ హిట్లను ఊహించవద్దు, వాటిని కొలవండి. యూసేజ్.cache_read_input_tokens ఇప్పటికీ వరుస అభ్యర్థనలపై సున్నా అయితే, సిస్టమ్ ప్రాంప్ట్లో సైలెంట్ బ్రేకర్ (datetime.now(), క్రమం చేయని JSON, ప్రతి అభ్యర్థనతో మారుతున్న సాధనాల జాబితా) అమలవుతోంది. బైట్ ద్వారా రెండు అభ్యర్థనల యొక్క ముడి ప్రాంప్ట్ను సరిపోల్చండి మరియు వ్యత్యాసాన్ని కనుగొనండి.
సైలెంట్ డిస్ట్రప్టర్స్
తెలియకుండానే కాష్ని పాడు చేసే సాధారణ నమూనాలు:
# BREAKER: సిస్టమ్ ప్రాంప్ట్లో పొందుపరిచే సమాచారం ప్రతి అభ్యర్థనతో మారుతూ ఉంటుంది "నేటి తేదీ: {{ఇప్పుడు}}. మీరు సహాయకుడు..." ← ప్రతి అభ్యర్థనతో ఉపసర్గ మార్పులు, హిట్ సున్నా# నిజం: వేరియబుల్ను సందేశ వ్యవస్థకు తరలించండి: "మీరు సహాయకుడు..." ← స్థిరంగా క్యాచెమెసేజ్లలోకి ప్రవేశిస్తుంది. ప్రశ్న: ..."}] ← చివరిలో వేరియబుల్
ఇతర బ్రేకర్లు: JSON ప్రతి అభ్యర్థనపై వేర్వేరుగా క్రమబద్ధీకరించబడింది (కీలను స్థిరమైన క్రమంలో ఉంచండి), వినియోగదారుని బట్టి మారుతూ ఉండే సాధనాల జాబితా (సాధనాలు ముందుగా ప్రాసెస్ చేయబడతాయి; అవి మారితే ఏమీ కాష్లోకి వెళ్లదు), మధ్య సంభాషణను మార్చడం (కాష్లు మోడల్ నిర్దిష్టంగా ఉంటాయి).
బలహీనమైన ప్రాంప్ట్ / బలమైన ప్రాంప్ట్ (కాష్ స్నేహపూర్వక నిర్మాణం)
# బలహీనమైన (కాష్ బస్టింగ్ బిల్డ్)సిస్టమ్: "తేదీ: 18.07.2026 14:32. వినియోగదారు: Ahmet (id 8842). మీరు సపోర్ట్ బాట్. నియమాలు: ...(2000 టోకెన్లు)..."
# STRONG (కాష్-ఫ్రెండ్లీ స్ట్రక్చర్)సిస్టమ్: "మీరు సపోర్ట్ బాట్. రూల్స్: ...(2000 టోకెన్లు, ఎప్పటికీ మారవు)..." [కాష్ సైన్] సందేశాలు: [ { పాత్ర: వినియోగదారు, కంటెంట్: "తేదీ: 18.07.2026 14:32. యూజర్ ఐడి: 8842. ప్రశ్న: నేను ఎలా తిరిగి ఇవ్వాలి?" }]
బలహీనమైన సంస్కరణలో, 2000 టోకెన్ల నియమం బ్లాక్ ప్రతి అభ్యర్థనపై పూర్తి ధరతో ప్రాసెస్ చేయబడుతుంది. బలమైన సంస్కరణలో, అదే బ్లాక్ ఒకసారి వ్రాయబడుతుంది మరియు ధరలో పదవ వంతు కోసం అన్ని తదుపరి అభ్యర్థనలపై చదవబడుతుంది.
మూడు మినీ కేసులు
కేస్ 1 - రూల్బుక్ను కాషింగ్ చేయడం. అకౌంటింగ్ ఆటోమేషన్ ప్రతి ఇన్వాయిస్కు 12,000 టోకెన్ రూల్బుక్ను జోడిస్తోంది; రోజుకు 5,000 అభ్యర్థనలు. క్యాష్లెస్ ఇన్పుట్ ఖర్చులు రోజుకు ~$180. వారు రూల్బుక్ను స్థిరంగా ఉంచారు మరియు దానిని కాష్ చేసారు: మొదటి అభ్యర్థనలు రైట్ ప్రీమియం చెల్లించబడ్డాయి, తదుపరి రీడ్లు 0.1×. ఇన్పుట్ ఖర్చు రోజుకు ~90% నుండి ~$18కి పడిపోయింది.
కేసు 2 — దాచిన తేదీ రేఖ ధర. ఒక బృందం కాష్ని సెటప్ చేసింది కానీ హిట్లు పొందలేదు; cache_read_input_tokens ఎల్లప్పుడూ సున్నా. కారణం: సిస్టమ్ ప్రాంప్ట్ యొక్క మొదటి లైన్లో datetime.now() ఉంది, ప్రతి అభ్యర్థనతో ఉపసర్గ మారుతోంది. మేము తేదీని వినియోగదారు సందేశానికి తరలించినప్పుడు, హిట్ రేటు అకస్మాత్తుగా 0% నుండి 94%కి పెరిగింది.
కేస్ 3 - తప్పుగా ఉంచబడిన కాష్. శోధన అప్లికేషన్ ప్రతి అభ్యర్థనతో పూర్తిగా భిన్నమైన చిన్న ప్రశ్నలను పంపుతోంది; వారు ఆసక్తిగా కాష్ గుర్తును జోడించారు. సాధారణ ఉపసర్గ లేకుండా, ప్రతి అభ్యర్థనకు వ్రాత ప్రీమియం మాత్రమే చెల్లించబడుతుంది, రీడ్లు లేవు — ఖర్చు పెరుగుతుంది. వారు గుర్తును తొలగించారు. పాఠం: మళ్లీ ఉపయోగించబడే పెద్ద మరియు స్థిరమైన ఉపసర్గ ఉన్నట్లయితే మాత్రమే కాష్ చెల్లిస్తుంది.
సాధారణ తప్పులు
- స్థిరమైన మరియు వేరియబుల్ కలపడం: వేరియబుల్ కంటెంట్ ఉపసర్గలో ఉన్నప్పుడు, హిట్ రీసెట్ చేయబడుతుంది.
- సిస్టమ్ ప్రాంప్ట్లో తేదీ/ID పొందుపరచడం: అత్యంత సాధారణ సైలెంట్ డిస్రప్టర్.
- హిట్ని కొలవడం లేదు: కాష్_రీడ్_ఇన్పుట్_టోకెన్లను తనిఖీ చేయకపోతే, వ్యర్థాలు గుర్తించబడవు.
- పబ్లిక్ ప్రిఫిక్స్ లేనప్పుడు కాష్ని జోడించడం: మీరు రైట్ ప్రీమియం మాత్రమే చెల్లిస్తారు, ఖర్చు పెరుగుతుంది.
- వాహన జాబితా లేదా మోడల్ను మార్చడం: ఉపసర్గ మొదటి నుండి విచ్ఛిన్నమైంది; ప్రతిదీ తిరిగి వ్రాయబడింది.
- కనీస కాష్ పరిమాణాన్ని మర్చిపోవడం: చాలా చిన్న కాష్లు (మోడల్ను బట్టి ~1–4k టోకెన్లలోపు) నిశ్శబ్దంగా కాష్లోకి ప్రవేశించవు.
లోతుగా: వర్క్లోడ్ రకం ద్వారా కాష్ రూపకల్పన
మీ పనిభారం యొక్క స్వభావాన్ని బట్టి కాషింగ్ యొక్క వాస్తవ చెల్లింపు మారుతుంది; కాబట్టి ముందుగా మీ ట్రాఫిక్ను తెలుసుకోండి. మూడు సాధారణ నమూనాలు మరియు సరైన సంస్థాపన:
సాధారణ సిస్టమ్ ప్రాంప్ట్, విభిన్న ప్రశ్నలు. అత్యంత సాధారణ ఎంటర్ప్రైజ్ నమూనా: వందలాది విభిన్న వినియోగదారు ప్రశ్నలతో కూడిన పెద్ద సిస్టమ్ ప్రాంప్ట్ (పాత్ర, నియమాలు, బహుశా సూచన పత్రం). ఇక్కడ స్థిర భాగం (సిస్టమ్) ప్రారంభంలో కాష్ చేయబడుతుంది; ప్రతి కొత్త ప్రశ్న దాని స్వంత చిన్న భాగానికి మాత్రమే పూర్తి ధరను చెల్లిస్తుంది. అధిక భాగం ధరలో పదవ వంతుతో పదే పదే పఠించడం వలన లాభం చాలా ఎక్కువగా ఉంటుంది.
బహుళ రౌండ్ మోనోలాగ్. సంభాషణ సాగుతున్నప్పుడు, ప్రతి కొత్త రౌండ్ మునుపటి మొత్తం చరిత్రపై ఆధారపడి ఉంటుంది. మీరు చివరి రౌండ్ చివరిలో కాష్ ఫ్లాగ్ను ఉంచినట్లయితే, ప్రతి అభ్యర్థన మునుపటి సంభాషణ ఉపసర్గను మళ్లీ ఉపయోగిస్తుంది; సంభాషణ పెరిగే కొద్దీ హిట్లు పేరుకుపోతాయి. ఇది లాంగ్ అసిస్టెంట్ సెషన్ల ఖర్చును నాటకీయంగా నిర్వహిస్తుంది.
భాగస్వామ్య ఉపసర్గ మార్చడానికి చివరి బిట్. బహుళ అభ్యర్థనలు స్థిరమైన ప్రీయర్ల (నమూనా సెట్, సూచనలు) పెద్ద సెట్ను పంచుకుంటాయి కానీ చివరలో ఒకే ప్రశ్నతో వేరు చేయబడతాయి. మీరు భాగస్వామ్య భాగం చివరిలో కాష్ పాయింటర్ను ఉంచారు; లేకపోతే, ప్రతి అభ్యర్థన దాని స్వంత ప్రత్యేక కాష్ని వ్రాస్తుంది మరియు ఏదీ చదవబడదు.
ఒక హెచ్చరిక: కాష్ మోడల్ మరియు నిర్దిష్ట కనీస పరిమాణంపై ఆధారపడి ఉంటుంది. చాలా చిన్న ఉపసర్గలు (మోడల్పై ఆధారపడి కొన్ని వేల టోకెన్ల కంటే తక్కువ) మీరు వాటిని ఫ్లాగ్ చేసినప్పటికీ నిశ్శబ్దంగా కాష్లోకి ప్రవేశించవు — cache_creation_input_tokens సున్నాగా మిగిలిపోయింది. అలాగే, మోడల్ మధ్య సంభాషణను మార్చడం మొత్తం కాష్ చెల్లదు; వేరొక పనికి చౌక మోడల్ అవసరమైతే, ప్రధాన ప్రవాహాన్ని ఒక మోడల్లో ఉంచండి మరియు సైడ్ జాబ్ను ప్రత్యేక కాల్లో ఉంచండి.
సారాంశంలో
ప్రాంప్ట్ కాషింగ్ అనేది ఉపసర్గ సరిపోలిక: స్థిర కంటెంట్ ప్రారంభంలో ఉండాలి, వేరియబుల్ కంటెంట్ ముగింపులో ఉండాలి. పెద్ద, తిరిగి ఉపయోగించిన సందర్భం కోసం, చదవడానికి అయ్యే ఖర్చు పూర్తి ధరలో పదో వంతు, రెండు అభ్యర్థనలలో కూడా దాదాపుగా విభజించవచ్చు. సిస్టమ్ ప్రాంప్ట్లో వేరియబుల్ డేటాను పొందుపరచడం ద్వారా ఉపసర్గను పాడు చేయడం అత్యంత సాధారణ తప్పు; మీరు వినియోగ ఫీల్డ్లో హిట్ని కొలవడం ద్వారా ధృవీకరిస్తారు.
అప్లికేషన్ టాస్క్
పనిభారాన్ని ఎంచుకోండి. (1) కంటెంట్ను రెండు నిలువు వరుసలుగా విభజించండి: "ఎప్పటికీ మారదు" మరియు "ప్రతి అభ్యర్థనతో మార్పులు". (2) ప్రాంప్ట్ నిర్మాణాన్ని మళ్లీ గీయండి, స్థిరమైన భాగాన్ని ప్రారంభంలో మరియు వేరియబుల్ భాగాన్ని చివరిలో ఉంచండి. (3) స్థిర భాగం యొక్క టోకెన్ పరిమాణాన్ని అంచనా వేయండి మరియు కాష్తో/లేకుండా నెలవారీ ఖర్చును సరిపోల్చండి. (4) మీరు ఏ ఫీల్డ్ (cache_read_input_tokens) నుండి హిట్ని ధృవీకరిస్తారో గమనించండి.
చెక్లిస్ట్
- [ ] కాష్ అనేది ఉపసర్గ సరిపోలిక మరియు మార్పులేని ఏకైక నియమం అని నేను వివరించగలను.
- [ ] నేను స్థిరమైన కంటెంట్ను ప్రారంభంలో మరియు వేరియబుల్ను చివరిలో ఉంచడం ద్వారా ఖచ్చితత్వాన్ని పెంచగలను.
- [ ] నాకు వ్రాయడం/చదవడం మరియు రెండు అభ్యర్థనల బ్రేక్-ఈవెన్ పాయింట్ గురించి తెలుసు.
- [ ] నేను నిశ్శబ్ద అంతరాయాలను గుర్తించగలను (తేదీ, ఆర్డర్ చేయని JSON, మారుతున్న వాహన జాబితా).
- [ ] నేను usage.cache_read_input_tokensతో హిట్ని ధృవీకరించగలను.