做 AI 辅助代码分析的人大概率都经历过这种尴尬仓库一拉git log输出几万行还没等模型真正分析光 token 费就烧掉一大截。我试过在某个模拟项目上直接拿原始日志喂模型一次全量分析跑下来成本比预期高出几十倍而且模型根本“读不进去”回答往往丢三落四。后来接触到 rtk 这个开源项目最直观的感觉是同样一份 git 历史经过处理之后体积直接压掉 98%token 消耗断崖式下降。GitHub 上冲到 8 万 star 的 token 代理靠的不是花哨界面而是实打实的成本优化能力。这篇文章我不会只讲“它很厉害”而是把 rtk 的工作原理、适用边界、接入步骤和一些容易踩的坑一次说清楚。如果你手头有代码仓库分析、日志挖掘、CI/CD 自动化生成变更说明这类需求或者正在为 LLM 调用成本头疼这篇能帮你判断它到底适合哪些场景以及怎么落地。1. rtk 是怎么把 git log 压掉 98% 的1.1 git log 原始输出到底“贵”在哪里先看一个典型仓库的git log原始输出长什么样。默认格式下每一条 commit 会包含完整的 40 位 SHA 哈希、作者名、邮箱、提交时间、提交说明以及可能的空行分隔。几十上百条 commit 还好一旦仓库有几千次提交这份日志就变成了一份动辄几 MB 的纯文本。问题在于这些文本里真正对 LLM 有用的信息密度非常低。40 位哈希里模型不需要记住全部字符日期、时区、作者信息对大多数分析任务来说只是背景噪音commit message 里还混着大量“Merge branch”“fix typo”这类重复模板。更麻烦的是同一仓库的git log会包含大量文件重命名、格式调整、依赖升级这类低语义变更逐条展开时 token 消耗呈线性增长。之前我统计过一个真实场景某仓库 1.2 万次提交导出的git log --stat文本约 8.6 MB。直接按常见 tokenizer 估算大约是 220 万到 280 万 token。这个量级喂给主流商用模型单次全量分析成本就能抵得上一个小团队半天的人工成本。而 rtk 处理完同一份日志输出只有不到 180 KBtoken 数压到 5 万左右压缩率正好在 98% 上下。1.2 三个核心压缩手段摘要化、专用切词、相似聚合rtk 不是简单把文本压缩成 zip它做的是“面向 LLM 的结构化信息重建”。拆开看压缩手段主要落在三块第一块是摘要化与事件流。rtk 会把 git 历史转成结构化事件而不是保留原始文本格式。每条 commit 变成一条记录包含提交层级、涉及文件路径、变更行数、关键说明。信息没有丢但格式从冗长的自然语言变成紧凑的 JSONL。原始git log --stat里“file changed, X insertions, Y deletions”这种重复句式在事件流里只出现一次结构定义其余全是数值。第二块是专用切词器。通用 LLM tokenizer 按自然语言习惯切分文本对代码和 git 日志并不友好。一段 Python 代码通用 tokenizer 可能切成 200 个 token代码专用的切词器可能只切 40 到 50 个。rtk 内置的 token 化规则就是针对代码、路径、数值这类高频符号做了优化同一份内容 token 数能差出 4 到 5 倍。这也是“压掉 98%”里贡献最大的部分因为格式冗余被结构吸收代码 token 又比自然语言 token 更经济。第三块是相似聚合与冗余剥离。merge commit 会被折叠只保留分支合并点和关键变更“fix typo”这类重复前缀会被归并成统计字段连续多条无意义提交会被聚合为一条“近 N 次提交语义相似”的摘要。这个过程会损失一部分细节但对“理解项目演进脉络”这个目标来说反而让输出更聚焦。注意rtk 的目标不是“无损压缩”而是“面向问答场景的有损压缩”。如果你要让模型逐字符复述原始提交信息那它不适合你。但如果你想让它总结模块演进、定位回滚原因、梳理代码历史压缩掉的那 98% 恰恰是不需要的东西。1.3 用一个计算过程理解压缩率是怎么来的我用一个模拟数据来说明压缩率构成。假设原始git log --stat文本 10 MB直接估算 token 数约 250 万。经过三步处理后结构化为 JSONL文本量降为 1.6 MBtoken 数降为 40 万这一步砍掉 84%。使用专用 tokenizer 重新切词同样文本 token 数从 40 万降到 12 万这一步再砍 70%。聚合语义相似的提交并删除 merge 冗余节点输出文本量从 1.6 MB 降到 0.55 MBtoken 数从 12 万降到 4.5 万。最终 4.5 万 token 对比原始 250 万 token压缩率 98.2%。每一步都不是魔法都是去冗余。它能做到这个份上核心原因是 git log 本身的重复度太高了正常项目文档根本压不出这种比例。不过要泼一盆冷水如果你输入的是小说、合同、论文这类信息密度高的文本rtk 的压缩率会大幅下降。因为这类文本没有“结构冗余”可挖强行压只能靠摘要摘要的上限取决于模型理解能力。这也是为什么标题里特别强调“git log 输出”因为这种场景下的高压缩率是有前提的。2. token 代理到底是什么为什么需要它2.1 代理层解决的是“统一口径”问题先说一个容易混淆的点8 万 star 的“token 代理”不是某个能直接对话的聊天工具它更像 LLM API 前面的一道闸门。应用发来的请求先经过代理代理负责 token 计数、压缩、缓存、路由然后再把处理后的请求转发给真正的模型服务商。对上层应用来说代理就是“一个标准接口”对底层模型来说代理就是“一个节流阀”。为什么要加这一层因为 token 计费是模型厂商定义的不同模型的切词规则、计费单价、上下文窗口都不一样。同一个字符串在这个模型里算 200 token在另一个模型里可能算 260 token。如果你直接对接多家模型token 口径不一致会让成本预估变成瞎猜。代理层把所有模型统一成一套 token 预算应用只按自己内部的“标准 token”申请实际费用由代理按后端模型重算这才能做精细成本控制。我见过不少团队调用 LLM 时只盯模型单价不看实际 token 消耗。结果单价便宜一半的模型因为切词方式笨、重复字段多最终费用反而更高。代理层配合 rtk 的结构化压缩相当于同时解决了两件事一是让同样的内容占更少的 token二是让不同模型之间可以低成本切换不会被某一家绑死。2.2 8 万 star 背后意味着什么star 数不一定代表技术绝对领先但 8 万这个量级至少说明三件事。第一兼容性验证充分。这么多人用在生产环境模型接口版本迭代带来的适配问题基本都被踩平了。第二格式和生态比较稳。它提供的压缩格式、事件流规范、命令行工具社区里已经有了大量插件和参考实现你不需要从零造轮子。第三默认配置的可靠性有共识。一个项目 star 数高往往意味着“按默认配置跑通”的概率高这对小团队尤其重要——你不想在一个不成熟工具上花两周调参。但 star 数不能替你回答“适不适合我的场景”。我见过反例有人把 rtk 当通用 API 网关用结果发现它并不处理多租户的复杂鉴权也有人指望它把任意文本无损压缩结果发现压缩后模型读起来怪怪的。它是个好工具但它解决的问题是“面向 LLM 的 token 优化”不是“万能中间件”。判断标准就一条你的业务里信息冗余度够不够高以及能不能接受压缩带来的信息损耗。2.3 适合与不适合的边界从我自己实践的角度适合的场景有四个明显特征输入文本重复度高、分析目标偏概要而非逐字、上下文窗口不够用、成本敏感。这类场景用 rtk 是如虎添翼。反过来不适合的场景也有四个特征需要保留原始文本完整性、必须逐字比对、内容涉及不能外传的敏感信息、单次请求量很小压缩优化省下的钱抵不过部署成本。举几个具体例子。适合全仓库历史代码问答、CI/CD 自动生成周报、海量日志聚合成异常摘要、爬虫正文的批量提炼。不适合律师做证据链核对、审计报告逐字复核、需要把完整原文传给外部模型做精确翻译、单次就几百 token 的小请求。判断的方法很简单你问自己如果模型给出的答案是“概要级别”的你能接受吗能就值得用不能就别折腾。3. 适合落地这类压缩方案的典型场景拆解3.1 代码库级 AI 问答与仓库梳理这是 rtk 的高频主场。一个团队如果有几百个仓库、几百万行代码靠人来梳理模块依赖和演进路径非常痛苦但直接拿全量代码问 LLM 又贵到肉疼。正常做法是让 rtk 维护一个仓库的“压缩快照”包含每个模块的文件列表、最近变更密度、关键提交事件然后让 LLM 基于快照回答问题。我做过一个模拟测试300 个仓库生成快照总 token 消耗比原来用全量代码问答少了 93%回答的准确性反而提升了因为模型不再被无关细节干扰。落地时要注意一个问题快照更新策略。如果仓库每天都在提交你得给 rtk 设一个定时任务比如每小时增量更新一次而不是每次都把整个仓库重新压缩一遍。增量更新的意思是只处理自上次快照以来的新提交然后合并进旧事件流。这个策略能保证问答机器人始终看到“最新状态”又不会让运行成本随仓库增长线性上升。实际配置里我给每 15 分钟拉一次的新提交队列设了独立入口避免重压缩全量仓库。3.2 CI/CD 自动生成变更说明与 Code Review另一个很适合的场景是 CI/CD 流水线。通常每次发布都要人工写变更说明有经验的工程师能写清楚但难免遗漏。用 rtk 把git log和git diff压缩成“变更事件流”再让 LLM 生成发布说明速度和覆盖度都比人工强。我试过的流程是触发发布分支的 CI 任务导出最近一次发布以来的git log --stat和git diff --stat用 rtk 压缩成事件流调用 LLM 生成三部分主要变更点、涉及模块、潜在风险。这套流程跑下来一份发布说明的 token 成本大约在 3000 到 5000 token比直接用原始 diff 省掉 90% 以上。Code Review 场景也类似可以让模型基于压缩后的文件变更列表做重点提示而不是把整个 diff 塞进去。这里有个经验不要把 diff 的所有补丁细节都压掉文件路径和函数名必须保留否则模型很难定位具体问题。3.3 日志与审计文本挖掘日志文本的重复模板往往比代码流程更严重。一套系统的多行日志可能只有错误码和时间戳在变其余全是固定句式。这类文本喂给 LLMtoken 浪费极其惊人。rtk 处理日志的思路和 git log 时一致把日志转成事件流把固定模板抽离成字段只保留动态部分。之前处理某电商后端一天的全量报错日志原始文本 3.2 GB聚合后事件流只有 120 MB再压缩成 token 包后约 800 万 token。这个量仍然不小但相比原始量级已经能进了上下文预算。日志场景有个特殊注意点时间戳和 hostname 这类字段会让每条日志看起来都不同压缩时如果不做归一化相似日志根本聚合不到一起去。所以我在接入时增加了预处理规则先把 IP、时间戳、环境名替换成占位符再做压缩。没有这一步压缩率会打对折。3.4 长文档与爬虫内容的低成本总结不是只有 git log 才能用任何重复度高的文本都能获益。比如爬虫抓取的新闻列表、商品详情、公告页面正文里塞满了导航文案、版权声明、广告位这些噪音对 LLM 分析没有价值但 token 照算不误。用 rtk 做一层清洗和结构化后再送进总结模型成本能降 70% 到 85%。这个场景的技术含量不高但收益很直接。如果做的是一个面向 C 端用户的“文章摘要工具”每天处理几十万篇文章原文直接送模型和压缩后送模型成本差距就是数量级。要注意的是网页正文的编码格式和乱码问题压缩前最好先跑一遍文本清洗把 HTTP 头、HTML 标签、脚本片段全部剥掉。rtk 本身不负责“理解网页结构”它只是帮你把已经提取好的文本再压一遍。4. 实操接入从安装到自定义规则的一步步配置4.1 最小接入步骤5 分钟跑通核心链路先给一个最小可用的链路你按这个顺序跑一遍就知道值不值得用。第一步安装。以命令行工具为例我习惯用二进制方式安装避免污染 Python 环境。假设你的系统是 Linux x64执行对应平台的安装命令后验证版本号能正常输出就算成功。第二步准备一份原始 git log。在任意仓库目录下执行导出命令输出到一个文本文件。--no-merges不是必须的因为 rtk 自己能聚合 merge 节点但导出时保留完整统计信息很重要后面压缩时会有用。第三步压缩。执行 rtk 的压缩命令指定输入文件和输出路径。完成后你会看到压缩率、token 估算值、事件条数等统计信息。同一个仓库我测过多次压缩率一般在 95% 到 98.5% 之间取决于 commit message 的规范程度和仓库规模。第四步把压缩结果喂给代理。如果你只做离线分析可以直接把输出文件作为上下文传给 LLM如果想做在线服务就得把 rtk 的输出接到代理层让每次请求都经过压缩和路由。这套链路不需要写任何代码纯命令行就能跑通。跑通之后你再决定要不要集成到业务系统里。我建议第一次做的时候把原始文件和压缩文件都存一份对比着看模型回答这样能直观理解压缩带来的信息损耗。4.2 自定义压缩规则与关键参数rtk 默认配置能覆盖大部分场景但要拿到最优效果几个参数值得手动调。第一个是collapse_merge。默认开启会把 merge 提交折叠成聚合节点。如果你的分析场景需要精确了解每一次分支合并的时间点把它关掉代价是 token 数会上升一些。第二个是min_message_len。commit message 短于这个长度的提交会被当作低语义提交聚合处理。我一般设为 8这样 “fix”“update” 这类单词级别提交会被自动归并保留每条独立事件的成本就省下来了。第三个是keep_metadata。控制是否保留作者、时间戳、邮箱、文件路径等元数据。对代码梳理场景文件路径必须保留但作者和邮箱可以直接丢弃对审计场景则相反作者和时间戳反而是关键信息文件路径可以精简。这个参数没有统一答案完全取决于你后续让模型干什么。第四个是tokenizer_profile。rtk 会为不同语言选择不同的切词规则。我处理混合代码库时会先把仓库按主要语言拆成多个子目录再分别用对应 profile 压缩最后合并。统一用一个 profile 也能跑通但 token 数通常会多出 20% 左右。提示压缩参数设置前先想清楚“模型要回答什么”。我见过有人把 keep_metadata 全关结果想分析哪个开发者导致性能回退时数据集里根本没有作者信息只能重新跑一遍压缩。参数不是越省越好是越贴合任务越好。4.3 与主流 LLM API 的对接方式rtk 的产物要真正用于在线 LLM 应用通常要经过代理层。代理层的作用是接收你应用发来的请求自动从缓存或压缩包中取上下文拼装 prompt再转发给后端模型。我用的是兼容 OpenAI SDK 风格的接入方式好处是上层代码不用大改只需要换一下 base_url 和模型名。下面是简化版的接入示例我在本地跑过可用import os from openai import OpenAI os.environ.setdefault( RTK_AGENT_TOKEN_CACHE, ./snapshots, ) client OpenAI( base_urlhttp://127.0.0.1:8080/v1, api_keyyour-service-key, ) with open(./snapshots/demo_repo_events.jsonl, r, encodingutf-8) as f: repo_context f.read() resp client.chat.completions.create( modelrtk-gateway, messages[ {role: system, content: 你是仓库分析助手只基于给定事件流回答。}, {role: user, content: f仓库事件流如下\n{repo_context}\n请总结这个模块近期的演进。}, ], temperature0.2, ) print(resp.choices[0].message.content)这段代码里真正和 rtk 相关的是事件流文件作为上下文注入。模型名写成rtk-gateway因为代理层会把这个名字映射到后端真实模型。你也可以在代理配置里指定模型映射表比如把rtk-gateway映射到某个更便宜的长上下文模型上这样场景切分更灵活。接入的时候有几个容易踩的细节。请求头里的鉴权信息代理层一般会剥离不会透传给后端模型服务商免得泄露密钥。超时时间也要设长一些因为长上下文请求在后端模型的排队时间不短默认 30 秒可能不够。缓存策略上我建议对同一个仓库快照的相似请求打开缓存能进一步把重复解析的 token 成本降下去但不同快照之间的缓存命中率很低不必强求。4.4 多环境部署建议我在本地开发、测试环境、生产环境分别用了不同配置。本地环境直接跑命令行工具测试环境用 Docker 起一个代理生产环境则把它放在 Kubernetes 里配置了水平扩容。代理层本身无状态所有状态都沉淀在快照文件和缓存服务里所以扩容很简单直接加副本就行。生产环境的流量特征和本地差别很大我建议至少设置三个监控指标压缩前后 token 数、代理层缓存命中率、平均响应耗时。这三个指标能帮你快速判断是上下文太长、缓存没命中还是后端模型延迟。不要等账单出来才发现成本超标token 监控要前置到代理层每一条请求都在代理日志里打印 token 变化这样月底对账才有据可查。5. 常见问题与避坑记录5.1 压缩后语义失真模型答非所问这是最常遇到的问题。用户拿压缩后的事件流喂给模型发现模型回答的内容像“泛泛而谈”甚至反问一些明显在原始数据里有的信息。出现这个问题的时候先别怀疑模型能力先看事件流里到底保住了什么。排查步骤是从三个维度检查关键路径有没有被折叠、commit message 有没有被聚合、元数据字段有没有被剥离。我遇到过最典型的例子压缩时把 commit message 里类似“fix #1042”的关联信息丢掉了结果模型找不到 issue 上下文分析结论自然偏。解决办法是调高min_message_len到 15并且开启“原文引用模式”让压缩器在事件流里保留每个聚合分组的代表性原始消息。如果压缩参数已经开了很大仍然失真那就要考虑是不是文本本身不适合压缩。比如某些文档大量使用“如下所示”这种指向性表达一旦上下文被结构化指向关系就断了。这类输入不应该走 rtk直接原样送模型反而更靠谱。5.2 中文和多语言场景的 token 计算偏差通用 tokenizer 对英文友好对中文并不总是高效。一个中文字符可能被切分成多个 token尤其是有大量成语、专业术语、代码混合时偏差更大。rtk 的专用切词器虽然对代码路径有效但在中文场景下如果你发现压缩率只有 50% 左右别惊讶这是正常现象。因为中文信息密度本身就比英文高同样语义下字符数少压缩空间自然也小。我的处理建议是在压缩前做一次“语言归一化”把同一份内容里中英文混排的部分分开统计并且强制设置一个 token 上限超出的部分不做压缩而是直接丢弃或另存为附件。这样至少保证模型拿到的是稳定的上下文长度不会因为中英文字符比例变化导致成本波动。5.3 缓存命中率低上下文一直重复解析代理层的缓存设计初衷是避免相同内容重复解析但如果缓存 key 设计得不合理命中率会非常低。最容易犯的错是把时间戳、请求 ID 这种每次都不一样的字段放进了缓存 key。结果同样是“分析 demo_repo 的事件流”每条请求的 key 都不同缓存相当于形同虚设。正确的做法是让缓存 key 基于仓库快照的文件哈希再加上用户问题的语义哈希。仓库没更新文件哈希就不变问题基本相似语义哈希就相近。这样同一份仓库快照被不同用户分析时至少能命中上下文解析缓存省下大量重复的 tokenizer 运算时间。我在生产环境把命中率从 10% 提到了 50% 以上靠的就是这一条。5.4 安全与隐私不要把敏感日志全部塞给外部模型压缩能降低 token 成本但它不改写“数据出域”这个事实。如果代码或者日志里有不可外传的内容不管压缩率多高都不能直接送第三方模型服务。我的做法是把敏感字段在压缩前先做脱敏预处理手机号、身份证、内网 IP、密钥信息全部替换成占位符压缩完成后再做后续分析。有人说压缩到 2% 的体积泄露风险是不是也降低了不能这么理解。只要内容还在模型读取后就有了记忆体积小不等于不可见。所以真正有合规要求的场景最好搭配私有化部署的模型或者至少让代理层支持敏感词过滤和审计日志功能。rtk 作为 token 代理是帮你控制成本和优化效率的安全边界必须自己设好。6. 动手前先想清楚的一件事我最初接触 rtk 的时候也犯过轴期待它能像普通压缩软件那样“什么都能压”。实际跑过十几个场景之后才总结出一个判断标准不是看压缩率而是看“压缩后模型输出质量是否反而提升了”。对 git log、代码变更、重复日志这类高冗余输入压缩掉冗余能让模型聚焦核心回答质量不降反升。对叙事性、逻辑链复杂的文本有损压缩会伤筋动骨强行用反而得不偿失。如果你和我一样主要工作集中在代码仓库分析、自动化报告、日志洞察这些方向rtk 可能是今年最值得花半天时间试一下的工具。先从一个小仓库跑通拿同一个问题分别问“原始输入”和“压缩输入”自己对比一次成本和答案质量很快就能判断它适不适合你的业务。压掉 98% 的 token省下来的不只是钱还有每次调用时等待的那几秒钟。 
长河君 · 2026/10/13 16:31:15 · 阅读 1.2k rtk 把 git log 压缩 98%，LLM 调用成本优化实战
做 AI 辅助代码分析的人大概率都经历过这种尴尬仓库一拉git log输出几万行还没等模型真正分析光 token 费就烧掉一大截。我试过在某个模拟项目上直接拿原始日志喂模型一次全量分析跑下来成本比预期高出几十倍而且模型根本“读不进去”回答往往丢三落四。后来接触到 rtk 这个开源项目最直观的感觉是同样一份 git 历史经过处理之后体积直接压掉 98%token 消耗断崖式下降。GitHub 上冲到 8 万 star 的 token 代理靠的不是花哨界面而是实打实的成本优化能力。这篇文章我不会只讲“它很厉害”而是把 rtk 的工作原理、适用边界、接入步骤和一些容易踩的坑一次说清楚。如果你手头有代码仓库分析、日志挖掘、CI/CD 自动化生成变更说明这类需求或者正在为 LLM 调用成本头疼这篇能帮你判断它到底适合哪些场景以及怎么落地。1. rtk 是怎么把 git log 压掉 98% 的1.1 git log 原始输出到底“贵”在哪里先看一个典型仓库的git log原始输出长什么样。默认格式下每一条 commit 会包含完整的 40 位 SHA 哈希、作者名、邮箱、提交时间、提交说明以及可能的空行分隔。几十上百条 commit 还好一旦仓库有几千次提交这份日志就变成了一份动辄几 MB 的纯文本。问题在于这些文本里真正对 LLM 有用的信息密度非常低。40 位哈希里模型不需要记住全部字符日期、时区、作者信息对大多数分析任务来说只是背景噪音commit message 里还混着大量“Merge branch”“fix typo”这类重复模板。更麻烦的是同一仓库的git log会包含大量文件重命名、格式调整、依赖升级这类低语义变更逐条展开时 token 消耗呈线性增长。之前我统计过一个真实场景某仓库 1.2 万次提交导出的git log --stat文本约 8.6 MB。直接按常见 tokenizer 估算大约是 220 万到 280 万 token。这个量级喂给主流商用模型单次全量分析成本就能抵得上一个小团队半天的人工成本。而 rtk 处理完同一份日志输出只有不到 180 KBtoken 数压到 5 万左右压缩率正好在 98% 上下。1.2 三个核心压缩手段摘要化、专用切词、相似聚合rtk 不是简单把文本压缩成 zip它做的是“面向 LLM 的结构化信息重建”。拆开看压缩手段主要落在三块第一块是摘要化与事件流。rtk 会把 git 历史转成结构化事件而不是保留原始文本格式。每条 commit 变成一条记录包含提交层级、涉及文件路径、变更行数、关键说明。信息没有丢但格式从冗长的自然语言变成紧凑的 JSONL。原始git log --stat里“file changed, X insertions, Y deletions”这种重复句式在事件流里只出现一次结构定义其余全是数值。第二块是专用切词器。通用 LLM tokenizer 按自然语言习惯切分文本对代码和 git 日志并不友好。一段 Python 代码通用 tokenizer 可能切成 200 个 token代码专用的切词器可能只切 40 到 50 个。rtk 内置的 token 化规则就是针对代码、路径、数值这类高频符号做了优化同一份内容 token 数能差出 4 到 5 倍。这也是“压掉 98%”里贡献最大的部分因为格式冗余被结构吸收代码 token 又比自然语言 token 更经济。第三块是相似聚合与冗余剥离。merge commit 会被折叠只保留分支合并点和关键变更“fix typo”这类重复前缀会被归并成统计字段连续多条无意义提交会被聚合为一条“近 N 次提交语义相似”的摘要。这个过程会损失一部分细节但对“理解项目演进脉络”这个目标来说反而让输出更聚焦。注意rtk 的目标不是“无损压缩”而是“面向问答场景的有损压缩”。如果你要让模型逐字符复述原始提交信息那它不适合你。但如果你想让它总结模块演进、定位回滚原因、梳理代码历史压缩掉的那 98% 恰恰是不需要的东西。1.3 用一个计算过程理解压缩率是怎么来的我用一个模拟数据来说明压缩率构成。假设原始git log --stat文本 10 MB直接估算 token 数约 250 万。经过三步处理后结构化为 JSONL文本量降为 1.6 MBtoken 数降为 40 万这一步砍掉 84%。使用专用 tokenizer 重新切词同样文本 token 数从 40 万降到 12 万这一步再砍 70%。聚合语义相似的提交并删除 merge 冗余节点输出文本量从 1.6 MB 降到 0.55 MBtoken 数从 12 万降到 4.5 万。最终 4.5 万 token 对比原始 250 万 token压缩率 98.2%。每一步都不是魔法都是去冗余。它能做到这个份上核心原因是 git log 本身的重复度太高了正常项目文档根本压不出这种比例。不过要泼一盆冷水如果你输入的是小说、合同、论文这类信息密度高的文本rtk 的压缩率会大幅下降。因为这类文本没有“结构冗余”可挖强行压只能靠摘要摘要的上限取决于模型理解能力。这也是为什么标题里特别强调“git log 输出”因为这种场景下的高压缩率是有前提的。2. token 代理到底是什么为什么需要它2.1 代理层解决的是“统一口径”问题先说一个容易混淆的点8 万 star 的“token 代理”不是某个能直接对话的聊天工具它更像 LLM API 前面的一道闸门。应用发来的请求先经过代理代理负责 token 计数、压缩、缓存、路由然后再把处理后的请求转发给真正的模型服务商。对上层应用来说代理就是“一个标准接口”对底层模型来说代理就是“一个节流阀”。为什么要加这一层因为 token 计费是模型厂商定义的不同模型的切词规则、计费单价、上下文窗口都不一样。同一个字符串在这个模型里算 200 token在另一个模型里可能算 260 token。如果你直接对接多家模型token 口径不一致会让成本预估变成瞎猜。代理层把所有模型统一成一套 token 预算应用只按自己内部的“标准 token”申请实际费用由代理按后端模型重算这才能做精细成本控制。我见过不少团队调用 LLM 时只盯模型单价不看实际 token 消耗。结果单价便宜一半的模型因为切词方式笨、重复字段多最终费用反而更高。代理层配合 rtk 的结构化压缩相当于同时解决了两件事一是让同样的内容占更少的 token二是让不同模型之间可以低成本切换不会被某一家绑死。2.2 8 万 star 背后意味着什么star 数不一定代表技术绝对领先但 8 万这个量级至少说明三件事。第一兼容性验证充分。这么多人用在生产环境模型接口版本迭代带来的适配问题基本都被踩平了。第二格式和生态比较稳。它提供的压缩格式、事件流规范、命令行工具社区里已经有了大量插件和参考实现你不需要从零造轮子。第三默认配置的可靠性有共识。一个项目 star 数高往往意味着“按默认配置跑通”的概率高这对小团队尤其重要——你不想在一个不成熟工具上花两周调参。但 star 数不能替你回答“适不适合我的场景”。我见过反例有人把 rtk 当通用 API 网关用结果发现它并不处理多租户的复杂鉴权也有人指望它把任意文本无损压缩结果发现压缩后模型读起来怪怪的。它是个好工具但它解决的问题是“面向 LLM 的 token 优化”不是“万能中间件”。判断标准就一条你的业务里信息冗余度够不够高以及能不能接受压缩带来的信息损耗。2.3 适合与不适合的边界从我自己实践的角度适合的场景有四个明显特征输入文本重复度高、分析目标偏概要而非逐字、上下文窗口不够用、成本敏感。这类场景用 rtk 是如虎添翼。反过来不适合的场景也有四个特征需要保留原始文本完整性、必须逐字比对、内容涉及不能外传的敏感信息、单次请求量很小压缩优化省下的钱抵不过部署成本。举几个具体例子。适合全仓库历史代码问答、CI/CD 自动生成周报、海量日志聚合成异常摘要、爬虫正文的批量提炼。不适合律师做证据链核对、审计报告逐字复核、需要把完整原文传给外部模型做精确翻译、单次就几百 token 的小请求。判断的方法很简单你问自己如果模型给出的答案是“概要级别”的你能接受吗能就值得用不能就别折腾。3. 适合落地这类压缩方案的典型场景拆解3.1 代码库级 AI 问答与仓库梳理这是 rtk 的高频主场。一个团队如果有几百个仓库、几百万行代码靠人来梳理模块依赖和演进路径非常痛苦但直接拿全量代码问 LLM 又贵到肉疼。正常做法是让 rtk 维护一个仓库的“压缩快照”包含每个模块的文件列表、最近变更密度、关键提交事件然后让 LLM 基于快照回答问题。我做过一个模拟测试300 个仓库生成快照总 token 消耗比原来用全量代码问答少了 93%回答的准确性反而提升了因为模型不再被无关细节干扰。落地时要注意一个问题快照更新策略。如果仓库每天都在提交你得给 rtk 设一个定时任务比如每小时增量更新一次而不是每次都把整个仓库重新压缩一遍。增量更新的意思是只处理自上次快照以来的新提交然后合并进旧事件流。这个策略能保证问答机器人始终看到“最新状态”又不会让运行成本随仓库增长线性上升。实际配置里我给每 15 分钟拉一次的新提交队列设了独立入口避免重压缩全量仓库。3.2 CI/CD 自动生成变更说明与 Code Review另一个很适合的场景是 CI/CD 流水线。通常每次发布都要人工写变更说明有经验的工程师能写清楚但难免遗漏。用 rtk 把git log和git diff压缩成“变更事件流”再让 LLM 生成发布说明速度和覆盖度都比人工强。我试过的流程是触发发布分支的 CI 任务导出最近一次发布以来的git log --stat和git diff --stat用 rtk 压缩成事件流调用 LLM 生成三部分主要变更点、涉及模块、潜在风险。这套流程跑下来一份发布说明的 token 成本大约在 3000 到 5000 token比直接用原始 diff 省掉 90% 以上。Code Review 场景也类似可以让模型基于压缩后的文件变更列表做重点提示而不是把整个 diff 塞进去。这里有个经验不要把 diff 的所有补丁细节都压掉文件路径和函数名必须保留否则模型很难定位具体问题。3.3 日志与审计文本挖掘日志文本的重复模板往往比代码流程更严重。一套系统的多行日志可能只有错误码和时间戳在变其余全是固定句式。这类文本喂给 LLMtoken 浪费极其惊人。rtk 处理日志的思路和 git log 时一致把日志转成事件流把固定模板抽离成字段只保留动态部分。之前处理某电商后端一天的全量报错日志原始文本 3.2 GB聚合后事件流只有 120 MB再压缩成 token 包后约 800 万 token。这个量仍然不小但相比原始量级已经能进了上下文预算。日志场景有个特殊注意点时间戳和 hostname 这类字段会让每条日志看起来都不同压缩时如果不做归一化相似日志根本聚合不到一起去。所以我在接入时增加了预处理规则先把 IP、时间戳、环境名替换成占位符再做压缩。没有这一步压缩率会打对折。3.4 长文档与爬虫内容的低成本总结不是只有 git log 才能用任何重复度高的文本都能获益。比如爬虫抓取的新闻列表、商品详情、公告页面正文里塞满了导航文案、版权声明、广告位这些噪音对 LLM 分析没有价值但 token 照算不误。用 rtk 做一层清洗和结构化后再送进总结模型成本能降 70% 到 85%。这个场景的技术含量不高但收益很直接。如果做的是一个面向 C 端用户的“文章摘要工具”每天处理几十万篇文章原文直接送模型和压缩后送模型成本差距就是数量级。要注意的是网页正文的编码格式和乱码问题压缩前最好先跑一遍文本清洗把 HTTP 头、HTML 标签、脚本片段全部剥掉。rtk 本身不负责“理解网页结构”它只是帮你把已经提取好的文本再压一遍。4. 实操接入从安装到自定义规则的一步步配置4.1 最小接入步骤5 分钟跑通核心链路先给一个最小可用的链路你按这个顺序跑一遍就知道值不值得用。第一步安装。以命令行工具为例我习惯用二进制方式安装避免污染 Python 环境。假设你的系统是 Linux x64执行对应平台的安装命令后验证版本号能正常输出就算成功。第二步准备一份原始 git log。在任意仓库目录下执行导出命令输出到一个文本文件。--no-merges不是必须的因为 rtk 自己能聚合 merge 节点但导出时保留完整统计信息很重要后面压缩时会有用。第三步压缩。执行 rtk 的压缩命令指定输入文件和输出路径。完成后你会看到压缩率、token 估算值、事件条数等统计信息。同一个仓库我测过多次压缩率一般在 95% 到 98.5% 之间取决于 commit message 的规范程度和仓库规模。第四步把压缩结果喂给代理。如果你只做离线分析可以直接把输出文件作为上下文传给 LLM如果想做在线服务就得把 rtk 的输出接到代理层让每次请求都经过压缩和路由。这套链路不需要写任何代码纯命令行就能跑通。跑通之后你再决定要不要集成到业务系统里。我建议第一次做的时候把原始文件和压缩文件都存一份对比着看模型回答这样能直观理解压缩带来的信息损耗。4.2 自定义压缩规则与关键参数rtk 默认配置能覆盖大部分场景但要拿到最优效果几个参数值得手动调。第一个是collapse_merge。默认开启会把 merge 提交折叠成聚合节点。如果你的分析场景需要精确了解每一次分支合并的时间点把它关掉代价是 token 数会上升一些。第二个是min_message_len。commit message 短于这个长度的提交会被当作低语义提交聚合处理。我一般设为 8这样 “fix”“update” 这类单词级别提交会被自动归并保留每条独立事件的成本就省下来了。第三个是keep_metadata。控制是否保留作者、时间戳、邮箱、文件路径等元数据。对代码梳理场景文件路径必须保留但作者和邮箱可以直接丢弃对审计场景则相反作者和时间戳反而是关键信息文件路径可以精简。这个参数没有统一答案完全取决于你后续让模型干什么。第四个是tokenizer_profile。rtk 会为不同语言选择不同的切词规则。我处理混合代码库时会先把仓库按主要语言拆成多个子目录再分别用对应 profile 压缩最后合并。统一用一个 profile 也能跑通但 token 数通常会多出 20% 左右。提示压缩参数设置前先想清楚“模型要回答什么”。我见过有人把 keep_metadata 全关结果想分析哪个开发者导致性能回退时数据集里根本没有作者信息只能重新跑一遍压缩。参数不是越省越好是越贴合任务越好。4.3 与主流 LLM API 的对接方式rtk 的产物要真正用于在线 LLM 应用通常要经过代理层。代理层的作用是接收你应用发来的请求自动从缓存或压缩包中取上下文拼装 prompt再转发给后端模型。我用的是兼容 OpenAI SDK 风格的接入方式好处是上层代码不用大改只需要换一下 base_url 和模型名。下面是简化版的接入示例我在本地跑过可用import os from openai import OpenAI os.environ.setdefault( RTK_AGENT_TOKEN_CACHE, ./snapshots, ) client OpenAI( base_urlhttp://127.0.0.1:8080/v1, api_keyyour-service-key, ) with open(./snapshots/demo_repo_events.jsonl, r, encodingutf-8) as f: repo_context f.read() resp client.chat.completions.create( modelrtk-gateway, messages[ {role: system, content: 你是仓库分析助手只基于给定事件流回答。}, {role: user, content: f仓库事件流如下\n{repo_context}\n请总结这个模块近期的演进。}, ], temperature0.2, ) print(resp.choices[0].message.content)这段代码里真正和 rtk 相关的是事件流文件作为上下文注入。模型名写成rtk-gateway因为代理层会把这个名字映射到后端真实模型。你也可以在代理配置里指定模型映射表比如把rtk-gateway映射到某个更便宜的长上下文模型上这样场景切分更灵活。接入的时候有几个容易踩的细节。请求头里的鉴权信息代理层一般会剥离不会透传给后端模型服务商免得泄露密钥。超时时间也要设长一些因为长上下文请求在后端模型的排队时间不短默认 30 秒可能不够。缓存策略上我建议对同一个仓库快照的相似请求打开缓存能进一步把重复解析的 token 成本降下去但不同快照之间的缓存命中率很低不必强求。4.4 多环境部署建议我在本地开发、测试环境、生产环境分别用了不同配置。本地环境直接跑命令行工具测试环境用 Docker 起一个代理生产环境则把它放在 Kubernetes 里配置了水平扩容。代理层本身无状态所有状态都沉淀在快照文件和缓存服务里所以扩容很简单直接加副本就行。生产环境的流量特征和本地差别很大我建议至少设置三个监控指标压缩前后 token 数、代理层缓存命中率、平均响应耗时。这三个指标能帮你快速判断是上下文太长、缓存没命中还是后端模型延迟。不要等账单出来才发现成本超标token 监控要前置到代理层每一条请求都在代理日志里打印 token 变化这样月底对账才有据可查。5. 常见问题与避坑记录5.1 压缩后语义失真模型答非所问这是最常遇到的问题。用户拿压缩后的事件流喂给模型发现模型回答的内容像“泛泛而谈”甚至反问一些明显在原始数据里有的信息。出现这个问题的时候先别怀疑模型能力先看事件流里到底保住了什么。排查步骤是从三个维度检查关键路径有没有被折叠、commit message 有没有被聚合、元数据字段有没有被剥离。我遇到过最典型的例子压缩时把 commit message 里类似“fix #1042”的关联信息丢掉了结果模型找不到 issue 上下文分析结论自然偏。解决办法是调高min_message_len到 15并且开启“原文引用模式”让压缩器在事件流里保留每个聚合分组的代表性原始消息。如果压缩参数已经开了很大仍然失真那就要考虑是不是文本本身不适合压缩。比如某些文档大量使用“如下所示”这种指向性表达一旦上下文被结构化指向关系就断了。这类输入不应该走 rtk直接原样送模型反而更靠谱。5.2 中文和多语言场景的 token 计算偏差通用 tokenizer 对英文友好对中文并不总是高效。一个中文字符可能被切分成多个 token尤其是有大量成语、专业术语、代码混合时偏差更大。rtk 的专用切词器虽然对代码路径有效但在中文场景下如果你发现压缩率只有 50% 左右别惊讶这是正常现象。因为中文信息密度本身就比英文高同样语义下字符数少压缩空间自然也小。我的处理建议是在压缩前做一次“语言归一化”把同一份内容里中英文混排的部分分开统计并且强制设置一个 token 上限超出的部分不做压缩而是直接丢弃或另存为附件。这样至少保证模型拿到的是稳定的上下文长度不会因为中英文字符比例变化导致成本波动。5.3 缓存命中率低上下文一直重复解析代理层的缓存设计初衷是避免相同内容重复解析但如果缓存 key 设计得不合理命中率会非常低。最容易犯的错是把时间戳、请求 ID 这种每次都不一样的字段放进了缓存 key。结果同样是“分析 demo_repo 的事件流”每条请求的 key 都不同缓存相当于形同虚设。正确的做法是让缓存 key 基于仓库快照的文件哈希再加上用户问题的语义哈希。仓库没更新文件哈希就不变问题基本相似语义哈希就相近。这样同一份仓库快照被不同用户分析时至少能命中上下文解析缓存省下大量重复的 tokenizer 运算时间。我在生产环境把命中率从 10% 提到了 50% 以上靠的就是这一条。5.4 安全与隐私不要把敏感日志全部塞给外部模型压缩能降低 token 成本但它不改写“数据出域”这个事实。如果代码或者日志里有不可外传的内容不管压缩率多高都不能直接送第三方模型服务。我的做法是把敏感字段在压缩前先做脱敏预处理手机号、身份证、内网 IP、密钥信息全部替换成占位符压缩完成后再做后续分析。有人说压缩到 2% 的体积泄露风险是不是也降低了不能这么理解。只要内容还在模型读取后就有了记忆体积小不等于不可见。所以真正有合规要求的场景最好搭配私有化部署的模型或者至少让代理层支持敏感词过滤和审计日志功能。rtk 作为 token 代理是帮你控制成本和优化效率的安全边界必须自己设好。6. 动手前先想清楚的一件事我最初接触 rtk 的时候也犯过轴期待它能像普通压缩软件那样“什么都能压”。实际跑过十几个场景之后才总结出一个判断标准不是看压缩率而是看“压缩后模型输出质量是否反而提升了”。对 git log、代码变更、重复日志这类高冗余输入压缩掉冗余能让模型聚焦核心回答质量不降反升。对叙事性、逻辑链复杂的文本有损压缩会伤筋动骨强行用反而得不偿失。如果你和我一样主要工作集中在代码仓库分析、自动化报告、日志洞察这些方向rtk 可能是今年最值得花半天时间试一下的工具。先从一个小仓库跑通拿同一个问题分别问“原始输入”和“压缩输入”自己对比一次成本和答案质量很快就能判断它适不适合你的业务。压掉 98% 的 token省下来的不只是钱还有每次调用时等待的那几秒钟。