單會(huì)話:billion-context 上線的第 71 天,社區(qū)在聊什么)
從 100K 到十億級(jí)單會(huì)話:billion-context 上線的第 71 天,社區(qū)在聊什么【免費(fèi)下載鏈接】billion-contextA context-compression plugin for small context windows (a 100K context is enough), token savings (5x fewer tokens), and month-long single sessions (billions of tokens).上下文壓縮插件兼顧小窗口(100k上下文足矣)省token(省5倍token)和超長(zhǎng)會(huì)話(數(shù)月級(jí)別幾十億token單會(huì)話)。billion-context is all you need項(xiàng)目地址: https://gitcode.com/gh_mirrors/bil/billion-context一個(gè)夾在編碼 Agent 和模型 API 之間的本地代理,把上下文不夠用拆成了一道可審計(jì)的工程問(wèn)題:不擴(kuò)窗口、不加顯存、不堆向量庫(kù),而是讓模型自己決定把已消費(fèi)的對(duì)話折疊成可逆摘要。billion-context 于 2026-08-06 開源,今天是它上線的第 71 天。這個(gè)時(shí)間點(diǎn)的觀察價(jià)值在于:它已經(jīng)跑出了真實(shí)的用戶反饋回路——GitHub 的 issue/PR 編號(hào)推進(jìn)到 3200,npm 版本號(hào)從 0.1.34 走到了 0.1.197,倉(cāng)庫(kù)里沉淀了 800 多個(gè)測(cè)試文件和一篇 MIT 許可的預(yù)印本論文。本文基于倉(cāng)庫(kù)源碼、CHANGELOG、論文與最近的社區(qū)文章,回答三個(gè)問(wèn)題:71 天的增長(zhǎng)軌跡是什么形狀;100K 上下文撐幾十億 token 單會(huì)話的量級(jí)跨度是否可信;以及接下來(lái)值得盯的里程碑在哪里。一、71 天的增長(zhǎng)軌跡:一周一個(gè)功能面,一天一個(gè)補(bǔ)丁先看節(jié)奏。倉(cāng)庫(kù)里的版本證據(jù)鏈很密:8 月 8 日(上線第 3 天),reference/release.md中的發(fā)布分支示例已是2026-08-08_release-v0.1.17;到8 月 11 日,CHANGELOG 記錄已推進(jìn)到0.1.34——頭一周就密集修掉了 thinking 模式reasoning_content回傳 400、round-2 流式緩沖、compress 死循環(huán)這類第一天就會(huì)遇到的問(wèn)題;8 月 24 日前后,CHANGELOG 已記錄到0.1.49,devlog 目錄(devlog/)在 8 月 13 日至 9 月 27 日間沉淀了 36 個(gè)迭代記錄,每條都帶實(shí)施前寫好的REQ.md和實(shí)施中寫好的WORKLOG.md;當(dāng)前package.json中的版本是0.1.197。71 天,160 多個(gè) npm 發(fā)布,平均不到一天一個(gè)版本?;顒?dòng)量上,tests/目錄最大的回歸測(cè)試編號(hào)已到issue3250,最近一次合并的 PR 是#3234,71 天內(nèi) issue/PR 編號(hào)推進(jìn)到 3200,意味著平均每天 40 多個(gè)社區(qū)事件(提交、討論、回歸)。測(cè)試規(guī)模同樣可觀:tests/下 700 多個(gè)測(cè)試文件,kernel/tests/96 個(gè),pi-subagents/tests/16 個(gè),tests/e2e/17 個(gè)套件——其中 E2E 直接驅(qū)動(dòng)真實(shí)的codexCLI 穿過(guò)代理與 Responses 兼容上游,斷言 warmup → 負(fù)載增長(zhǎng) → ACP 壓縮 → 原生 compact 攔截的完整生命周期。社區(qū)討論的密度也能佐證。10 月 14 日,CSDN 上出現(xiàn)了一篇專門講如何為 billion-context 貢獻(xiàn)代碼的開發(fā)者指南,通篇是 500 測(cè)試體系、原生插件協(xié)議(x-bili-plugin頭 GET /__bili/plugin/manifestPOST /__bili/plugin/tool)與統(tǒng)一存儲(chǔ)架構(gòu)的拆解——當(dāng)一個(gè) 71 天的項(xiàng)目開始有第三方寫貢獻(xiàn)指南,說(shuō)明它的社區(qū)敘事已經(jīng)從怎么用切換到了怎么共建??蛻舳烁采w面也在持續(xù)擴(kuò)張。README.md的 Which do I need? 表格里現(xiàn)在列了 20 多個(gè)宿主:pi、opencode、omp、dsh、kimi、hermes、zcode、claude、codex、gemini、iflow、qwen、antigravity、mcode、aider、copilot、amp、crush、zed、goose、codebuddy、qoder、trae、jcode——有插件接縫的走bili plugin install client原生模式,沒(méi)有的走bili client啟動(dòng)器(cert-MITM 或/bili/baseURL 改寫),兜底方案是把 baseURL 前綴換成http://localhost:8787/bili/。還有一個(gè)容易被忽略的信號(hào):10 月上旬的發(fā)布注記(release-notes/package.json,由 CI 從本倉(cāng)庫(kù)發(fā)布到獨(dú)立 npm 包)在 10 月 1 日至 12 日間出了 5 個(gè)版本,其中 3 個(gè)是critical級(jí)——0.1.186(修 codex 啟動(dòng)器與 claude code 賬號(hào)場(chǎng)景)、0.1.192/0.1.193(修 dsh/codex 切模型導(dǎo)致會(huì)話 fork、壓縮狀態(tài)失效、緩存重付)。critical 級(jí)發(fā)布集中出現(xiàn)在上線第 56–67 天,恰好是真實(shí)用戶把 dsh 桌面版、codex 訂閱登錄這類長(zhǎng)尾場(chǎng)景用出來(lái)的階段:這 71 天里,項(xiàng)目經(jīng)歷了跑通 → 跑順 → 長(zhǎng)尾場(chǎng)景挨個(gè)打補(bǔ)丁的完整過(guò)程,而它的自動(dòng)更新 critical 分級(jí)注記 advisories/強(qiáng)制更新通道(獨(dú)立 npm 包,當(dāng)前 advisory 列表為空,即從未觸發(fā)過(guò))構(gòu)成了完整的線上修復(fù)閉環(huán)。二、社區(qū)焦點(diǎn)一:量級(jí)跨度到底可不可信100K 上下文夠用、單會(huì)話幾十億 token——這是 README 第一行的承諾,也是社區(qū)質(zhì)疑最多的一點(diǎn)??尚诺年P(guān)鍵在于分清倉(cāng)庫(kù)里三個(gè)不同口徑的數(shù)字,它們都來(lái)自隨代碼開源的論文(paper/目錄下,MIT 許可的活文檔,v0.2 版,2026-09-07):口徑一:實(shí)測(cè)多會(huì)話總量。主宿主機(jī)上 4.5 個(gè)月(2026-04-23 → 2026-09-07)的生產(chǎn)日志:4,843 個(gè)會(huì)話、174,327 次模型調(diào)用、18.76B 累計(jì)輸入 token(其中 1.75B 是新鮮輸入,17.01B 是緩存讀取),三臺(tái)宿主合計(jì)約 24.7B。注意這是累計(jì)輸入口徑、跨會(huì)話的,且緩存讀取占絕對(duì)大頭(讀:新 ≈ 9.7:1)——billion 首先是這個(gè)名字的由來(lái),而不是單次請(qǐng)求的大小??趶蕉?實(shí)測(cè)單會(huì)話?cǎi)R拉松。真正對(duì)應(yīng)十億級(jí)單會(huì)話的數(shù)字:OpenCode 宿主上最長(zhǎng)的會(huì)話跑了12,049 次調(diào)用、1.52B 累計(jì)輸入 token,峰值上下文 374,946(1M 級(jí)窗口);Pi 宿主上最長(zhǎng)的會(huì)話8,584 次調(diào)用、1.01B token,峰值 257,721。這兩個(gè)數(shù)字是逐次調(diào)用從 API usage 里實(shí)測(cè)的,不是推演??趶饺?仿真外推上限。論文 §7 給出的1M 窗口單會(huì)話可支撐28.6B token / 106 天是閉式推導(dǎo) 離散事件仿真的結(jié)果,論文明確標(biāo)注為[A: simulation],且承認(rèn)這是對(duì)最大實(shí)測(cè)會(huì)話約 19 倍的純外推,tier-3 蒸餾率甚至是設(shè)計(jì)值(未觀測(cè)到)。附錄 B 的 Claims register 把每個(gè)聲明逐條標(biāo)了[V](有日志證據(jù))/[A](分析模擬)/[P](計(jì)劃實(shí)驗(yàn))——把哪些是實(shí)測(cè)、哪些是模型寫進(jìn)論文正文,這本身就是回應(yīng)量級(jí)可信度質(zhì)疑的方式。支撐這套數(shù)字的工程事實(shí)有三條,都在源碼里有對(duì)應(yīng)物:零窗口違規(guī)。204,800 窗口模型上 42,986 次調(diào)用零溢出(峰值 198,628);第三臺(tái)宿主(ework,自主 agent 服務(wù))12.2 天 32,733 次調(diào)用對(duì) 262,144 窗口同樣零違規(guī),峰值 229,355(87.5%)。Pi 宿主更干凈的逐次計(jì)費(fèi)顯示平均 88K / 中位 72K / p99 218K——典型的鋸齒震蕩在窗口帶內(nèi),而不是爬升。折疊只壓縮已消費(fèi)的增量。生產(chǎn)數(shù)據(jù):229M token 被壓縮,但 62% 集中在 1.3% 的超大會(huì)話里(≥1000 條消息)——論文稱之為馬拉松現(xiàn)象:短會(huì)話基準(zhǔn)根本觀測(cè)不到壓縮真正起作用的地帶。單次壓縮的產(chǎn)出中位只有185 token、97.5% 不超 2K;每次折疊中位吃掉 2.6K 增量。重負(fù)載會(huì)話(歷史中位 ~530K)最終只留 ~13K 常駐摘要,宏觀折疊比約70×。前綴緩存不被壓縮破壞。這是省 5 倍 token的經(jīng)濟(jì)學(xué)核心:歷史 append-only、壓縮只把后綴區(qū)段置為摘要,已建立的 KV 前綴永不失效。實(shí)測(cè)緩存讀取占比 90.7%(主宿主混合值),按調(diào)用間隔分層后,間隔 2 分鐘(占 89% 流量)的請(qǐng)求緩存讀取占比達(dá)94.2%,miss 歸因里只有 16% 來(lái)自新追加的后綴,其余是 provider 側(cè) TTL 過(guò)期——與布局無(wú)關(guān)。README 的健康判據(jù)也寫得很直白:健康會(huì)話保持95–97%前綴緩存命中,壓縮本身的成本 ≤2%。受控實(shí)驗(yàn)給了另一組佐證:在 Session Marathon 試點(diǎn)里,壓縮組相對(duì)保留基線計(jì)費(fèi) token 降 31–54%、重復(fù)取數(shù)(re-fetch)調(diào)用降 63%(2.7×),而記憶探針得分持平;階段結(jié)構(gòu)化負(fù)載上默認(rèn)配置在質(zhì)量、成本、方差三個(gè)維度全部最優(yōu)。論文也誠(chéng)實(shí)地記錄了反面:128K 窗口的靜默對(duì)照組(不執(zhí)行任何壓縮、只保留 doctrine 文本和消息標(biāo)簽)獨(dú)自復(fù)現(xiàn)了幾乎全部的 re-fetch 降幅(?62% vs ?63%),說(shuō)明收益大部分來(lái)自判斷內(nèi)容 標(biāo)簽布局這個(gè)組合,而不是壓縮動(dòng)作本身。三、社區(qū)焦點(diǎn)二:實(shí)現(xiàn)路徑——一個(gè) fold,而不是更大的窗口2026 年的Agent 上下文工程已經(jīng)是條熱鬧賽道:火山引擎的 OpenViking 把 Agent 記憶做成可自進(jìn)化的上下文數(shù)據(jù)庫(kù),headroom 主打上下文壓縮層、最高省 95% token,Context Mode 用 SQLite FTS5 BM25 把大輸出轉(zhuǎn)進(jìn)本地沙箱(21K stars),Lindy 走共享記憶服務(wù)路線——同一時(shí)間窗里,掘金、CSDN 上關(guān)于上下文數(shù)據(jù)庫(kù)上下文節(jié)流輕量級(jí)上下文模式的解讀一篇接一篇。billion-context 的差異化答案很明確:不動(dòng)模型(免訓(xùn)練)、不動(dòng)窗口(200K 夠)、不搬數(shù)據(jù)(蒸餾物留在會(huì)話內(nèi)),在代理層做增量分層折疊。拆開源碼看,實(shí)現(xiàn)路徑是四個(gè)部件:1. 折疊布局(the fold)。模型窗口 金字塔分級(jí)摘要塊 逐字最近區(qū)。tier-1 塊總結(jié)一段消息區(qū)間;tier-1 積累到一定體量后被折成 tier-2,tier-2 再折成 tier-3——論文的原話是an LSM tree over prose。關(guān)鍵不變量是每段內(nèi)容一生只被折疊一次,然后以摘要塊形式常駐不再變:所以早期內(nèi)容的保留率恒在 ~1/8(工具主導(dǎo)的塊中位 24×),不會(huì)像閾值觸發(fā)式一次性 compaction 那樣按 ρ^k 幾何衰減(四輪只剩 3–13%)。塊攜帶directBlockIds/effectiveMessageIds血統(tǒng)鏈,任意塊可decompress還原,還有 decompress-to-file 模式把全文寫到文件系統(tǒng)而不是上下文,還原時(shí)不擾動(dòng)緩存前綴。2. 模型驅(qū)動(dòng)的壓縮決策。代理注入四個(gè)工具——compress/decompress/search_context/acp_status——由模型自己調(diào)用。觸發(fā)是需求側(cè)的:增長(zhǎng)門(growth-gate)默認(rèn)每50K token 增量注入一次 nudge(kernel 契約里 growthFloor/growthCap 都是平的 50000,故意不做窗口百分比縮放,見AGENTS.md關(guān)鍵設(shè)計(jì)決策第 8 條),nudge 只帶候選區(qū)段 真實(shí)大小的推薦清單,從不告訴模型窗口占用百分比,且模型有權(quán)拒絕。生產(chǎn)日志顯示這不只是紙面設(shè)計(jì):五天窗口內(nèi) 23/103 次有效壓縮發(fā)生在引擎刻意不注入 nudge 的回合上(22%),模型會(huì)自發(fā)發(fā)起壓縮;內(nèi)核還會(huì)把無(wú)法恢復(fù)的 drop 直接拋錯(cuò)而不是靜默降級(jí)。3. 會(huì)話身份。代理以客戶端自己提供的 conversation id逐字作為壓縮狀態(tài)鍵(src/session-id.ts),不做哈希、不摻協(xié)議/上游/API-key 維度——因?yàn)槟切?huì)中途變化,歷史上正是它們?cè)谟脩暨€在說(shuō)話時(shí)把狀態(tài)孤兒化。無(wú)頭客戶端(如裸 pi)走src/prefix-affinity.ts的匿名前綴親和:歷史從位置 0 起字節(jié)級(jí)復(fù)現(xiàn)才重新附著到已有會(huì)話,否則鑄造獨(dú)立的pfa-…會(huì)話。子會(huì)話在出生時(shí)上報(bào)parentConversationId,獲得只讀的derivedFrom鏈,decompress/search_context可以沿父鏈回查(循環(huán)保護(hù) 深度上限 8)。4. 可機(jī)檢的不變量。這是倉(cāng)庫(kù)里最非典型的部分:proof/spec/下用 SMT-LIB 對(duì)出站請(qǐng)求體的組裝寫了字節(jié)級(jí)模型,在 Z3 上證明了兩條定理——T1(增長(zhǎng)穩(wěn)定性:追加一條消息后,新舊請(qǐng)求體共享長(zhǎng)度 ≥D 的字節(jié)前綴,除聲明過(guò)的 carrier 位置外逐字節(jié)相等)、T2(ref id 永不復(fù)用:單調(diào)游標(biāo)下已發(fā)號(hào)不會(huì)重發(fā)),每條定理配一個(gè)變異孿生(注入已知缺陷,solver 必須在時(shí)間預(yù)算內(nèi)給出反例,否則證明視為無(wú)效),再配 grounding 測(cè)試把每條公理釘回真實(shí)代碼(kernel/src/rebuild.ts、kernel/src/refs.ts等)。proof/README.md甚至單列了一節(jié)Trust boundary,明說(shuō)定理證明的是滿足公理的組裝函數(shù),代碼?公理的同步由 grounding 測(cè)試 計(jì)費(fèi)套件雙機(jī)制兜底。對(duì)前綴緩存這種錯(cuò)一個(gè)字節(jié)就重付整個(gè)前綴的系統(tǒng),用求解器鎖字節(jié)前綴,是社區(qū)在討論實(shí)現(xiàn)路徑時(shí)反復(fù)被引用的一點(diǎn)。此外,壓縮有 proxy / plugin 兩種模式、摘要載體不同(proxy 模式用acp_summary消息,plugin 模式用工具調(diào)用本身),內(nèi)核源碼就 vendored 在kernel/(npm 名acp-kernel,550 獨(dú)立測(cè)試,構(gòu)建時(shí)內(nèi)聯(lián)進(jìn)dist/index.js),統(tǒng)一存儲(chǔ)走 SQLite(src/storage/,node:sqlite內(nèi)置優(yōu)先),當(dāng)前默認(rèn)shadow模式雙寫對(duì)賬——這些細(xì)節(jié)構(gòu)成了第三方寫貢獻(xiàn)指南時(shí)的全部骨架。四、社區(qū)焦點(diǎn)三:工程治理與貢獻(xiàn)門檻71 天里最容易被低估的部分,是這個(gè)項(xiàng)目把怎么修 bug寫成了規(guī)范。AGENTS.md(倉(cāng)庫(kù)自述的最高優(yōu)先級(jí)開發(fā)規(guī)范)里能看到一套完整的治理機(jī)器:自動(dòng)合并 8 條門檻:單模塊、有復(fù)現(xiàn)原 bug 的回歸測(cè)試、rebase 最新 master 全綠、不碰配置 schema/持久化格式/wire 形狀/kernel、純fix:、diff 干凈、引用 issue、不碰承重基建——?dú)v史數(shù)據(jù)里約 7% 的 PR 需要二輪返工,主因是過(guò)期 base和只修癥狀路徑;kernel 變更人類門檻:觸碰kernel/**的 PR 必須在正文聲明kernel-change: reason,先經(jīng) owner 批準(zhǔn),內(nèi)核版本 bump 由 CI 強(qiáng)制,永不自動(dòng)合并;版本紀(jì)律:版本號(hào)只在*_release-v*發(fā)布分支變更,lock-syncCI 校驗(yàn)package-lock.json同步——絕不在內(nèi)容分支碰version;發(fā)布通道:CI 全自動(dòng)發(fā)布到 npm tag Release;billion-context-release-notes(分層、模型撰寫的發(fā)布注記)與billion-context-advisories(critical 缺陷強(qiáng)制更新,可指定回滾目標(biāo)版本)作為獨(dú)立 npm 包,代理每 3 分鐘輪詢,失敗時(shí)指數(shù)退避(5 分鐘起、上限 6 小時(shí))且不阻塞模型流量;許可證:MIT 一條附加條款——任何終端用戶可見/可交互且使用了本軟件的產(chǎn)品,須在首頁(yè)或文檔中注明使用了 billion-context 并附倉(cāng)庫(kù)鏈接(LICENSE末尾)。這條MIT1在社區(qū)討論里也是話題,它劃清了誰(shuí)算下游的邊界??捎^測(cè)性則直接面向終端用戶:客戶端內(nèi)/acp面板(會(huì)話、塊、可壓縮區(qū)段、用量)、/acp-cache緩存歸因報(bào)告( GRAND LEDGER / FOLD ECONOMICS / LINE ITEMS / MODEL SWITCHES 四個(gè)區(qū)塊,把 miss 分解成新增內(nèi)容、壓縮重付、TTL 過(guò)期、密鑰輪換),以及 Web 控制臺(tái)(會(huì)話列表、逐會(huì)話明細(xì)、命中率折線圖、配置編輯、上游連通性測(cè)試)。健康判據(jù)就一行:命中率低于 95–97% 時(shí),報(bào)告按上游 TTL → 模型切換 → bili bug → 其他的順序告訴你嫌疑對(duì)象。五、下一步值得盯的里程碑從CHANGELOG.md的 Unreleased 段、論文[P](planned)標(biāo)記和最近的 devlog,可以列出一個(gè)有明確倉(cāng)庫(kù)證據(jù)的觀察清單:增量回合(#3248)——客戶端停止重發(fā)全量歷史。原生宿主現(xiàn)在可以在普通模型請(qǐng)求上打x-bili-plugin-turn: 1,首回合 seed 規(guī)范態(tài)、后續(xù)回合只發(fā) delta(含上一條 assistant 回復(fù)),代理端組裝完整 body 重入管線,嚴(yán)格x-bili-applied-seq回執(zhí),409 強(qiáng)制 resync。對(duì)數(shù)十億 token 單會(huì)話而言,這砍掉的是每輪重發(fā)完整歷史的 O(full) 管線開銷,是當(dāng)前 roadmap 上杠桿最大的一條。R3 內(nèi)存平面(#3050)——把最長(zhǎng)會(huì)話的常駐內(nèi)存降下來(lái)。空閑會(huì)話的元數(shù)據(jù)、塊內(nèi)容、raw tail 在保存后折疊成懶加載殼(實(shí)測(cè)最肥的 dogfood 會(huì)話分別省 ~19.6 / ~27 / ~47 MB),啟動(dòng)預(yù)熱集默認(rèn)關(guān)閉(空閑 RSS ?151 MB),新增GET /__bili/memory診斷端點(diǎn)。超長(zhǎng)會(huì)話的另一個(gè)瓶頸從來(lái)不只是 token,還有代理自身的內(nèi)存。統(tǒng)一存儲(chǔ) Phase 3。SQLite 索引已是 shadow 默認(rèn)真相源(storage.unified當(dāng)前默認(rèn)shadow),下一步是storage.jsonWriter: off——JSON 信封徹底退役,SQLite 成為唯一持久副本;fork 檢查點(diǎn)已隨本階段落地。持久化格式變更是這個(gè)項(xiàng)目自己劃的承重區(qū),值得盯它怎么過(guò)回滾契約。論文 [P] 項(xiàng)落地。RQ1 的 7 臂全量評(píng)估(含 oracle 全上下文臂與忠實(shí)的 LCM 無(wú)損遞歸實(shí)現(xiàn),OOLONG 與 SWE-ContextBench 基準(zhǔn))、RQ4 的脫敏語(yǔ)料公開(目前 4,843 會(huì)話的原始存儲(chǔ)尚未公開,論文寫明sanitized corpus planned)。多個(gè)月、多宿主、24.7B token 的壓縮語(yǔ)料一旦放出,會(huì)直接改變這條賽道誰(shuí)有生產(chǎn)數(shù)據(jù)的格局。doctrine → weights,以及 ~50K 極端壓縮區(qū)間。論文 §9 把壓縮 doctrine 定位成可版本化的判斷規(guī)格,兩條延伸:把日志里的壓縮決策做成 SFT 課程蒸餾進(jìn)權(quán)重(模型不再需要腳手架提示),以及針對(duì) ~50K 總上下文的極端壓縮配置(受速率限制的 nudge 是缺的安全閥)。前者如果走通,免訓(xùn)練這個(gè)項(xiàng)目的立身之本會(huì)進(jìn)化成先免訓(xùn)練、后蒸餾。28.6B 仿真外推會(huì)被實(shí)測(cè)追上多少。當(dāng)前最長(zhǎng)實(shí)測(cè)會(huì)話(1.52B)只觸及模型上限的 5.3%,論文自己標(biāo)注這是 ~19× 外推、tier-3 蒸餾率尚屬設(shè)計(jì)值。未來(lái)幾個(gè)月馬拉松會(huì)話繼續(xù)跑,實(shí)測(cè)與仿真的差距本身就是最好的進(jìn)度條;順帶留意 tier-3 蒸餾在生產(chǎn)中是否開始被觀測(cè)到(當(dāng)前 1,711 塊中 tier-2 只有 60 個(gè))。71 天,billion-context 交出的不只是一個(gè)省 token 的代理,而是一整套可審計(jì)的證據(jù)鏈:實(shí)測(cè)數(shù)字標(biāo)[V]、仿真數(shù)字標(biāo)[A]、計(jì)劃實(shí)驗(yàn)標(biāo)[P],前綴穩(wěn)定性有求解器背書,修復(fù)通道有 critical 分級(jí)與強(qiáng)制更新兜底。社區(qū)討論的重心從它能不能做到轉(zhuǎn)向怎么貢獻(xiàn)代碼和下一個(gè)里程碑是什么——對(duì)一個(gè)上線第七周的項(xiàng)目來(lái)說(shuō),這已經(jīng)是相當(dāng)少見的社區(qū)狀態(tài)?!久赓M(fèi)下載鏈接】billion-contextA context-compression plugin for small context windows (a 100K context is enough), token savings (5x fewer tokens), and month-long single sessions (billions of tokens).上下文壓縮插件兼顧小窗口(100k上下文足矣)省token(省5倍token)和超長(zhǎng)會(huì)話(數(shù)月級(jí)別幾十億token單會(huì)話)。billion-context is all you need項(xiàng)目地址: https://gitcode.com/gh_mirrors/bil/billion-context創(chuàng)作聲明:本文部分內(nèi)容由AI輔助生成(AIGC),僅供參考