Deepseek 上下文硬盤緩存

DeepSeek API 上下文硬盤緩存技術(shù)對(duì)所有用戶默認(rèn)開啟，用戶無需修改代碼即可享用。

用戶的每一個(gè)請(qǐng)求都會(huì)觸發(fā)硬盤緩存的構(gòu)建。若后續(xù)請(qǐng)求與之前的請(qǐng)求在前綴上存在重復(fù)，則重復(fù)部分只需要從緩存中拉取，計(jì)入“緩存命中”。

注意：兩個(gè)請(qǐng)求間，只有重復(fù)的前綴部分才能觸發(fā)“緩存命中”，詳間下面的例子。

例一：長文本問答?

第一次請(qǐng)求

messages: [
    {"role": "system", "content": "你是一位資深的財(cái)報(bào)分析師..."}
    {"role": "user", "content": "<財(cái)報(bào)內(nèi)容>\n\n請(qǐng)總結(jié)一下這份財(cái)報(bào)的關(guān)鍵信息。"}
]

第二次請(qǐng)求

messages: [
    {"role": "system", "content": "你是一位資深的財(cái)報(bào)分析師..."}
    {"role": "user", "content": "<財(cái)報(bào)內(nèi)容>\n\n請(qǐng)分析一下這份財(cái)報(bào)的盈利情況。"}
]

在上例中，兩次請(qǐng)求都有相同的前綴，即 system 消息 + user 消息中的 <財(cái)報(bào)內(nèi)容>。在第二次請(qǐng)求時(shí)，這部分前綴會(huì)計(jì)入“緩存命中”。

例二：多輪對(duì)話?

第一次請(qǐng)求

messages: [
    {"role": "system", "content": "你是一位樂于助人的助手"},
    {"role": "user", "content": "中國的首都是哪里？"}
]

第二次請(qǐng)求

messages: [
    {"role": "system", "content": "你是一位樂于助人的助手"},
    {"role": "user", "content": "中國的首都是哪里？"},
    {"role": "assistant", "content": "中國的首都是北京。"},
    {"role": "user", "content": "美國的首都是哪里？"}
]

在上例中，第二次請(qǐng)求可以復(fù)用第一次請(qǐng)求開頭的 system 消息和 user 消息，這部分會(huì)計(jì)入“緩存命中”。

例三：使用 Few-shot 學(xué)習(xí)?

在實(shí)際應(yīng)用中，用戶可以通過 Few-shot 學(xué)習(xí)的方式，來提升模型的輸出效果。所謂 Few-shot 學(xué)習(xí)，是指在請(qǐng)求中提供一些示例，讓模型學(xué)習(xí)到特定的模式。由于 Few-shot 一般提供相同的上下文前綴，在硬盤緩存的加持下，F(xiàn)ew-shot 的費(fèi)用顯著降低。

第一次請(qǐng)求

messages: [    
        {"role": "system", "content": "你是一位歷史學(xué)專家，用戶將提供一系列問題，你的回答應(yīng)當(dāng)簡明扼要，并以`Answer:`開頭"},
        {"role": "user", "content": "請(qǐng)問秦始皇統(tǒng)一六國是在哪一年？"},
        {"role": "assistant", "content": "Answer:公元前221年"},
        {"role": "user", "content": "請(qǐng)問漢朝的建立者是誰？"},
        {"role": "assistant", "content": "Answer:劉邦"},
        {"role": "user", "content": "請(qǐng)問唐朝最后一任皇帝是誰"},
        {"role": "assistant", "content": "Answer:李柷"},
        {"role": "user", "content": "請(qǐng)問明朝的開國皇帝是誰？"},
        {"role": "assistant", "content": "Answer:朱元璋"},
        {"role": "user", "content": "請(qǐng)問清朝的開國皇帝是誰？"}
]

第二次請(qǐng)求

messages: [    
        {"role": "system", "content": "你是一位歷史學(xué)專家，用戶將提供一系列問題，你的回答應(yīng)當(dāng)簡明扼要，并以`Answer:`開頭"},
        {"role": "user", "content": "請(qǐng)問秦始皇統(tǒng)一六國是在哪一年？"},
        {"role": "assistant", "content": "Answer:公元前221年"},
        {"role": "user", "content": "請(qǐng)問漢朝的建立者是誰？"},
        {"role": "assistant", "content": "Answer:劉邦"},
        {"role": "user", "content": "請(qǐng)問唐朝最后一任皇帝是誰"},
        {"role": "assistant", "content": "Answer:李柷"},
        {"role": "user", "content": "請(qǐng)問明朝的開國皇帝是誰？"},
        {"role": "assistant", "content": "Answer:朱元璋"},
        {"role": "user", "content": "請(qǐng)問商朝是什么時(shí)候滅亡的"},        
]

在上例中，使用了 4-shots。兩次請(qǐng)求只有最后一個(gè)問題不一樣，第二次請(qǐng)求可以復(fù)用第一次請(qǐng)求中前 4 輪對(duì)話的內(nèi)容，這部分會(huì)計(jì)入“緩存命中”。

查看緩存命中情況?

在 DeepSeek API 的返回中，我們在 usage 字段中增加了兩個(gè)字段，來反映請(qǐng)求的緩存命中情況：

1. prompt_cache_hit_tokens：本次請(qǐng)求的輸入中，緩存命中的 tokens 數(shù)（0.1 元 / 百萬 tokens）
2. prompt_cache_miss_tokens：本次請(qǐng)求的輸入中，緩存未命中的 tokens 數(shù)（1 元 / 百萬 tokens）

硬盤緩存與輸出隨機(jī)性?

硬盤緩存只匹配到用戶輸入的前綴部分，輸出仍然是通過計(jì)算推理得到的，仍然受到 temperature 等參數(shù)的影響，從而引入隨機(jī)性。其輸出效果與不使用硬盤緩存相同。

其它說明?

1. 緩存系統(tǒng)以 64 tokens 為一個(gè)存儲(chǔ)單元，不足 64 tokens 的內(nèi)容不會(huì)被緩存
2. 緩存系統(tǒng)是“盡力而為”，不保證 100% 緩存命中
3. 緩存構(gòu)建耗時(shí)為秒級(jí)。緩存不再使用后會(huì)自動(dòng)被清空，時(shí)間一般為幾個(gè)小時(shí)到幾天