← Back to Concept Contrast

Concept Contrast Fable

Prompt caching and prefix caching: one stores the whole order, the other reuses the shared header

Conclusion first:When calling large models, prompt caching and prefix caching both help you save money. But prompt caching stores the result of an entire prompt and reuses it directly when the same prompt hits next time; prefix caching extracts and caches the common prefix shared by all requests separately, so it hits as long as the beginning is the same. The scenarios covered by the two mechanisms overlap but are not identical, and choosing the wrong caching strategy can make the savings differ by several times.

When calling large models, prompt caching and prefix caching both help you save money. But prompt caching stores the result of an entire prompt and reuses it directly when the same prompt hits next time; prefix caching extracts and caches the common prefix shared by all requests separately, so it hits as long as the beginning is the same. The scenarios covered by the two mechanisms overlap but are not identical, and choosing the wrong caching strategy can make the savings differ by several times.

Fable

Two ways of prepping at the noodle shop

At the old street corner there are two noodle shops, both claiming they can serve food quickly. The shop on the left does it by serving a complete bowl of noodles, then keeping the remaining broth and toppings, so that when the next customer orders exactly the same noodles, it can be served directly. The shop on the right does it differently: before opening each day, it simmers a large pot of base broth. No matter whether the customer orders beef noodles, three-delicacy noodles, or vegetarian noodles, the base broth is the same; once the noodles are cooked, the base broth is poured over them, and then toppings are added according to the ordered flavor.

At the lunch rush, a group of company employees came for a team-building meal. Ten of the twelve ordered the signature beef noodle set—the noodles and toppings were exactly the same. The noodle shop on the left was delighted; the ten pre-made bowls in storage went straight out, and serving speed broke records. The noodle shop on the right still had to cook noodles bowl by bowl, but the base broth was ready-made, and the toppings and side dishes could be prepared in parallel, so its speed wasn't too slow either.

The scene changed during afternoon tea. Each guest who came in ordered a different noodle dish—beef, three delicacies, pork ribs, pickled cabbage, seafood—no two the same. The noodle shop on the left could not use a single item of its inventory and had to start from scratch, tripling serving time. The noodle shop on the right was unaffected: the base broth was used as usual, different toppings were already prepared separately, and serving speed was almost no different from the lunch rush.

Two noodle shops found a strange ranking in their monthly review: in months with a high share of set meals, the left shop crushed the right on total score; in months with many walk-in customers, the right shop pulled far ahead. Neither won, neither lost—facing different order structures, the two prep strategies simply had completely different efficiency distributions.

Later someone proposed a plan to the restaurant association on the old street: during peak hours, first build the base soup system according to the method on the right, covering the common part of all orders; at the same time, build express slots for high-frequency set meals according to the method on the left, with matching conditions strictly limited to "noodles and toppings exactly the same." The two systems run in parallel without interfering with each other.

After parallelization, an interesting phenomenon appeared in the meal data: the base soup covered 100% of the day's orders, but only 15% of orders hit the full combo cache. This means the right-side strategy contributed baseline efficiency, while the left-side strategy provided extra acceleration only in specific scenarios. Only after separating the statistics could the true value of each strategy be seen clearly.

In the year-end summary, one line was written: do not use set-meal caching to cover what the base broth can do, and do not use the base broth to benchmark the speed of set-meal caching. Keep the two accounts separate, and set hit conditions for the two rules separately.

Prompt caching

Cache the computed result of the entire prompt. It can only be reused when the prompt of the next request is exactly identical to the cached content. Suitable for fixed prompt templates with high-frequency repetition.

Prefix caching

Cache the shared prefix of a prompt separately. As long as multiple requests share the same beginning, the prefix can be reused no matter how much the rest of the content differs. Suited to scenarios with a shared system prompt or long context.

Story Mapping

  • Store the complete set meal and serve it directly: prompt caching, reuse only when the entire prompt hits exactly
  • Simmer one pot of base broth every day to cover all orders: prefix caching, where the common prefix takes effect for all requests
  • Team-building package time slots crushed on the left: prompt cache hit rate is extremely high in high-frequency repetitive scenarios
  • The right side during off-peak hours is unaffected: prefix caching does not depend on identical content, offering broader coverage

Applying this to API cost optimization

When optimizing API call costs, set the system prompt and shared context as prefix caching—this part is identical across all requests, so the hit rate approaches 100%. Only fixed prompts within business templates that are genuinely high-frequency and completely unchanging should be set as prompt caching separately. Each of the two caches should have its own hit-rate monitoring curve; do not use the same "cache hit rate" metric to evaluate both mechanisms, otherwise the stable contribution of the prefix will mask the scenario-dependent nature of prompt caching.

京ICP备2026014272号