当我们调用大模型 API 时真正昂贵且影响响应速度的往往不是模型本身的计算负载而是上下文里堆积的冗余 Token。无论是 ChatGPT、Claude、Gemini还是本地部署的开源模型输入越长的文本每次调用就要为重复的代码、结构化的样板文本、历史对话残留支付额外费用。如果团队正在做 LLM Agent、RAG 流水线、代码解释器、自动测试生成这类的重上下文任务这个问题会更明显。这篇文章要聊的就是一个很有意思的解决思路用 AST Pruning抽象语法树剪枝来修剪冗余 LLM Token 的 API 代理。简单说它不是在模型侧做优化也不是靠通用的 prompt 压缩而是在 API 代理层对代码类上下文做结构级分析把“模型根本不需要看完整才能推理”的部分直接剪掉再转发给 LLM从源头降低 Token 消耗和请求延迟。这个项目有几个值得关注的点API 代理形态所有 LLM 请求先经过它再转发到上游模型服务对现有应用改造成本低。AST 剪枝核心对代码类 token 做语法分析根据抽象语法树识别可省略的节点。目标是降本提速减少 input tokens降低费用缩短首字返回时间。适合 LLM 应用开发者尤其是 Agent、自动编程、代码分析方向的工程团队。这篇文章会带你完整过一遍它解决什么问题、AST 剪枝的基本原理、怎么把代理部署起来、如何验证 Token 节省效果、有哪些坑和排查方法以及在生产环境使用时要注意的边界。如果你关心 LLM 调用成本、API Proxy 服务质量、上下文优化和批量任务处理这篇可以收藏备用。1. 核心能力速览能力项说明项目类型API 代理 / 中间层服务核心机制基于 AST 的代码 Token 修剪主要功能在请求转发前裁剪冗余代码上下文降低 LLM input tokens上游兼容面向 OpenAI 兼容接口设计实际端点需按部署配置确认硬件要求纯 CPU 可运行无需 GPU因为不跑模型推理显存占用无独立显存需求启动方式命令行服务启动作为本地或内网代理运行是否支持 API本身暴露代理接口请求方式一般为 OpenAI 格式是否支持批量任务支持代理层无状态处理天然可搭配批量请求队列适用场景LLM Agent、自动编程、代码理解、RAG 中的代码片段注入从材料来看这个项目不依赖 GPU也不是一个端到端的大模型推理服务而是位于“应用”和“LLM API”之间的一层代理。它更准确的身份是一个面向开发者的成本优化基础设施。对于已经接入 OpenAI 风格接口的应用只要把 base_url 切到这个代理上就能观察请求体被修剪后再上行的差异。2. 它到底解决了什么问题大模型 API 的成本很多时候不是花在“模型生成”上而是花在“重复阅读”上。以常见的代码类 Agent 场景为例把项目里的多个源文件塞进上下文让模型理解结构把报错堆栈、相关代码、历史修复记录全部拼进 prompt一次会话中多次调用模型每次调用都把完整的对话历史重新发送。如果输入内容里存在大量建模不需要的代码块、注释、未引用函数、格式化样板文本这些 token 对最终推理结果贡献很小却每次都被计费。还有一种有点反直觉的情况模型可能因为上下文太臃肿而变笨。大量的冗余 token 会稀释注意力分布让模型更难聚焦到关键函数和数据结构。所以修剪冗余 token 不只在省钱还可能顺带提升输出质量。这个项目选择的切入点是 AST。AST 就是我们做代码编译、静态分析时常说的抽象语法树。一段代码可以被解析成一个树形结构根节点代表整个文件子节点代表函数、类、变量声明、导入语句、控制流结构等。既然是树就能做结构判断哪些子树对语义理解是必要的哪些是冗余的。常见的可剪枝目标包括未被引用的函数或方法定义重复出现的 import 声明超长注释块与当前任务无关的类定义工具函数和测试桩代码核心难点不在于“能不能剪”而在于判断哪些可以安全地剪掉且不破坏模型对问题的理解。如果剪错了模型就会因为缺少关键上下文而产生幻觉或错误输出。这也是为什么这个项目选择 AST 而不是简单的按行截断——它做的是结构化决策而不是字符级粗剪。3. AST 修剪的基本工作流程3.1 请求进入代理当应用发送一个包含代码的 prompt 时代理首先解析请求体提取出 messages 数组。针对每一条消息找到其中被标记为代码块或者本身就是代码文件的内容。这里最常见的输入格式是 Markdown 代码块。Agent 工具调用返回的文件内容、代码搜索返回的片段通常都是这种格式。3.2 解析并生成 AST代理对检测到的代码片段进行语言识别然后调用对应的解析器生成抽象语法树。比如 Python 代码用 Python 的 ast 模块JavaScript/TypeScript 用 Babel 或 tree-sitterJava 用 tree-sitter-java。支持的编程语言范围取决于项目集成了哪些解析器。从原理上讲tree-sitter 这套方案覆盖的语言最多也最适合这种场景。3.3 分析并标记冗余节点AST 生成后代理会做一次遍历分析找出可以安全移除的节点。判断依据通常包括函数是否从入口点可达函数是否被其他保留节点调用变量是否被后续代码读取节点是否位于文件末尾且从未被引用注释节点是否包含提示词关键信息。这一步不是简单的“删除所有未被调用的函数”。我们还要考虑模型可能需要从代码风格、命名习惯里推断约定某些看似没被调用的函数可能是测试用例删了会影响模型对项目全貌的判断。所以实际实现往往使用一个保守策略只剪掉“绝对冗余”的节点。3.4 重新生成代码并构造成新请求保存树中需要保留的源代码范围重新拼成一段紧凑代码替换原消息里的代码块再组装请求体转发给上游 LLM API。注意这里有一个重要的工程细节如果 AST 的节点范围记录不准确重新生成代码时会出现语法错误或内容丢失。所以成熟的实现通常会基于源码的字节偏移量做映射而不是直接对 AST 节点做 toString。整个过程对应用层透明因为请求格式不变、返回格式不变。应用只知道自己发了一段代码收到了一份回复并不知道代理在中间做了剪枝。4. 部署与启动方式由于项目正文材料没有提供明确的启动命令下面给出一套通用部署流程。如果你已经拉取到项目源码按 README 中的实际命令替换即可。4.1 环境准备因为不依赖 GPU这层代理几乎可以在任何轻量服务器、容器、甚至开发机上运行。建议环境Linux / macOS / WindowsWSL2Python 3.9 或 Node.js 18以项目实现语言为准能够访问上游 LLM API 的网络环境磁盘占用一般不超过 500MB取决于解析器依赖先检查 Python 和 Node 环境python3 --version node --version npm --version4.2 安装依赖以 Python 项目为例通常是git clone repo-url cd llm-token-trimmer-proxy pip install -r requirements.txt如果项目基于 Node.jsgit clone repo-url cd llm-token-trimmer-proxy npm install这一步最常见的报错是tree-sitter编译失败。排查时优先确认系统是否有 C/C 编译工具链。macOS 需要 Xcode Command Line ToolsUbuntu 需要build-essential。4.3 配置上游 API代理需要知道把修剪后的请求转发到哪里。通常通过环境变量或配置文件指定。export UPSTREAM_BASE_URLhttps://api.openai.com export UPSTREAM_API_KEYsk-xxxx export PROXY_PORT8787这里需要特别注意UPSTREAM_API_KEY是你的上游密钥这个代理会持有它并代替应用调用上游。如果服务部署在团队内网要限制访问范围避免密钥被滥用。4.4 启动服务python app.py --port 8787 # 或者 node server.js --port 8787启动后代理会监听本地端口。应用接入时把原有的 base_url 改为http://127.0.0.1:8787/v1请求路径与 OpenAI 风格一致。4.5 最小可用验证先用一个简单的 curl 测试代理链路是否正常curl http://127.0.0.1:8787/v1/chat/completions \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [ {role: user, content: hello} ] }如果配置正确这个请求会被代理转发到上游然后原样返回模型回复。此时还没有触发 AST 剪枝因为消息里没有代码内容。5. 功能测试与效果验证部署完成不代表有效果。我们需要一套可重复的验证流程来确认代理真正减掉了 token并且没有影响输出质量。5.1 观察请求体变化最直接的方法是在代理日志中打印修剪前后的字符数和预估 token 数。代码类文本的 token 估算可以按“4 字符约等于 1 token”粗略计算更准确的方式是用上游模型的 tokenizer。如果项目本身没有日志输出可以在代理层加一条中间日志# 示例在请求转发前输出 token 估算 input_text request_body[messages][0][content] estimated_tokens len(input_text) // 4 print(f[TRIM] before{estimated_tokens} tokens) # 转发前 trimmed_text trim_with_ast(input_text) trimmed_tokens len(trimmed_text) // 4 print(f[TRIM] after{trimmed_tokens} tokens, saved{estimated_tokens - trimmed_tokens})5.2 测试用例设计准备一组包含冗余代码的测试样本每份样本包含一个入口函数多个从未被调用的辅助函数大段注释重复导入与任务无关的类定义。示例输入import os import sys import json import datetime # 冗余导入实际并未使用 import requests def _unused_helper_a(): # 这个函数从未被调用 return a def _unused_helper_b(): # 这个函数也从未被调用 return b def main(): print(hello world) if __name__ __main__: main()把这段代码发给一个需要模型回答问题的 prompt请阅读以下代码并回答问题 这段代码的入口点是什么 python 上面的代码### 5.3 对比实验 分别直接调用上游 API 和通过代理调用记录 - 输入字符数 - 估算 token 数 - 首字返回时间 - 实际费用 - 模型回答内容。 判断标准 - 代理调用后 token 数明显减少 - 模型还能正确回答入口点是 main - 模型输出与直接调用时等价。 如果模型因为代码被剪得太多而回答错误说明修剪策略太激进需要调整保守度配置。 ### 5.4 更接近真实场景的测试 单个代码文件的场景验证通过后可以用一个模拟 Agent 任务做集成测试。构造一个包含 20 个文件的“虚拟项目”其中只有 3 个文件与任务相关其余 17 个文件都是构造的冗余代码。 通过代理执行一个“找到 XX 功能实现”的提问对比修剪前后的 token 消耗和回答正确性。 这种测试很能暴露一个关键问题**当多个文件被拼接进同一个 prompt 时哪些文件可以整体丢弃哪些不能**。只做节点级剪枝不做文件级过滤的代理在这个场景下节省比例会明显更低。 ### 5.5 判断修剪质量 不要只看节省比例。要同时看 - **答案保真度**模型回答是否仍能体现原代码的关键语义 - **语法完整性**被剪后的代码块是否仍然可以被解析器解析如果不一致说明剪枝过程破坏了源码结构 - **输出稳定性**多次调用同一请求模型答案是否稳定。 这里要提醒一下节省 50% 以上 token 的配置不一定是最优配置。如果模型回答质量下降省下的钱会被重试成本吞掉。更稳妥的做法是先保守保留更多上下文验证效果稳定后再逐步提高剪枝强度。 ## 6. 接口 API 与批量任务接入 这个项目对外暴露的接口是 OpenAI 兼容格式因此现有 SDK 不需要改代码。如果你接入的是 LangChain、LlamaIndex 或其他框架只需要修改 openai_api_base 指向代理地址。 ### 6.1 Python SDK 接入示例 python from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8787/v1, api_keyany-string ) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: user, content: 分析下面代码的性能问题} ] ) print(response.choices[0].message.content)注意api_key字段即使代理不校验也需要填写因为 OpenAI SDK 有这个必填项。6.2 直接 HTTP 调用示例curl http://127.0.0.1:8787/v1/chat/completions \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [ { role: user, content: 请阅读以下代码找出未使用的函数并解释\n\npython\ndef unused():\n return 1\n\ndef main():\n print(2)\n } ] }6.3 批量任务设计由于代理本身是无状态转发批量任务的瓶颈在上游 API 的速率限制而不是代理本身。一个比较稳的批量任务配置如下import json import time import requests PROXY_URL http://127.0.0.1:8787/v1/chat/completions tasks [ {filename: app.py, question: 这个文件的主要功能是什么}, {filename: utils.py, question: 如何调用 utils 中的函数}, {filename: test.py, question: 测试覆盖率如何提高}, ] results [] for task in tasks: with open(task[filename], r, encodingutf-8) as f: code f.read() payload { model: gpt-4o-mini, messages: [ { role: user, content: f{task[question]}\n\npython\n{code}\n } ] } try: resp requests.post(PROXY_URL, jsonpayload, timeout120) data resp.json() results.append({ task: task[filename], status: ok, reply: data[choices][0][message][content] }) except Exception as e: results.append({ task: task[filename], status: error, error: str(e) }) # 避免触达上游速率限制 time.sleep(1) # 落盘方便中途失败后断点续跑 with open(batch_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)批量任务的两个关键点失败要记录任务队列中的单个请求可能因为上游限流、超时、网络抖动失败要把失败任务单独记录稍后重试速率控制不要无脑并发。先确认上游 API 的 RPM 和 TPM 限制再设置并发数和间隔。6.4 接口返回结构代理不会改动上游返回体所以应用侧解析逻辑完全不用变。OpenAI 兼容接口的标准返回结构是{ id: chatcmpl-xxx, object: chat.completion, choices: [ { index: 0, message: { role: assistant, content: answer } } ], usage: { prompt_tokens: 123, completion_tokens: 45, total_tokens: 168 } }这里值得注意usage.prompt_tokens是上游计算出来的 token 数也就是剪枝后真正被计费的 token 数。如果代理本身也打印了剪枝前的 token 数两者对比就能得到准确的节省比例。7. 资源占用与性能观察7.1 CPU 和内存AST 解析是 CPU 密集操作但单次解析耗时通常在几十毫秒到几百毫秒之间取决于代码块大小和语言。对于常规的 LLM 请求这层开销可以接受。内存占用取决于并发数和代码块大小常规配置下 512MB 到 1GB 足够。观察方式ps aux | grep python # 或 docker stats7.2 对延迟的影响代理会增加一次内部网络转发和一次 AST 解析理论上会增加延迟但通常远小于一次 LLM 调用的耗时。实际影响需要对比time curl http://127.0.0.1:8787/v1/chat/completions -d ...一个值得观察的现象是剪枝后 token 数下降会让上游 LLM 的首 token 延迟降低。也就是说即使代理本身增加了 50ms 处理时间上游因输入变短而减少了排队和预填充时间整体延迟反而可能下降。7.3 如何降低资源占用限制单个请求最大代码块长度超过阈值的代码直接透传不做 AST 解析为不同语言配置独立的解析池避免频繁创建解析器增加 LRU 缓存对相同文件的多次请求复用修剪结果。7.4 端口冲突与进程残留启动时如果端口被占用lsof -i :8787 # 或 netstat -an | grep 8787然后换端口启动或者结束占用进程。8. 常见问题与排查方法问题现象可能原因排查方式解决方案代理启动后接口 404请求路径与 OpenAI 版式不匹配查看日志确认监听路径检查路径是否为/v1/chat/completions剪枝后代码语法错误AST 节点范围映射不准打印被剪代码人工检查降低剪枝强度或切换解析器Token 节省不明显输入不是代码或代码中没有冗余观察日志中是否触发 AST 分支检查消息内容格式确认代码块被正确识别模型回答质量下降明显剪枝策略太激进对比直接调用和代理调用的输出调整保守度配置保留更多辅助代码上游提示 API Key 无效代理没有正确传递密钥检查环境变量和请求头确认UPSTREAM_API_KEY配置正确批量任务部分请求超时上游速率受限查看上游返回的错误码增加退避重试降低并发数tree-sitter 安装失败系统缺少编译工具链查看 pip/npm 编译日志安装build-essential或 Visual Studio Build Toolsrestarts 后配置丢失环境变量未持久化检查 shell 配置文件写入.env文件或系统服务配置8.1 如何判断是代理问题还是上游问题当请求失败时先绕过代理直接调用上游 API。如果上游正常说明问题在代理层如果上游也报错优先排查上游密钥、账户余额、模型访问权限。8.2 如何诊断“修剪错误”在代理中开启“对比模式”同时发送剪枝前后的请求对比两个输出。这是定位剪枝是否导致模型误解的最快方法# 对比模式伪代码 original_output call_upstream(original_request) trimmed_output call_upstream(trimmed_request) print( ORIGINAL ) print(original_output) print( TRIMMED ) print(trimmed_output)对比模式不应该在生产环境默认开启否则每次请求会产生两倍费用。建议只在调试阶段使用。9. 生产环境最佳实践9.1 先做保守配置首次上线时只剪掉最安全的冗余节点比如“未被引用的 import”和“超长注释”。先跑几天确认模型输出质量没有下降再逐步放开函数级剪枝。9.2 不能剪的内容下面这些场景建议直接透传不要做任何 AST 剪枝用户明确要求“阅读整个文件”代码块中包含错误堆栈或运行时信息代码块本身是用户问题的核心而不是辅助材料剪枝后会导致 import 关系断裂。9.3 日志和监控记录每个请求修剪前后的 token 数写入结构化日志{ request_id: req_123, original_chars: 8452, trimmed_chars: 4231, saved_chars: 4221, estimated_saved_tokens: 1055, language: python, triggered: true }这样可以按日聚合估算总共省了多少钱也可以用来发现某些代码模式剪枝率特别低的问题。9.4 安全与合规代理持有上游 API Key禁止把服务直接暴露在公网至少加一层访问鉴权代码内容可能包含敏感业务逻辑代理所在环境要与内网安全基线对齐如果分析第三方代码注意许可证和保密协议要求涉及用户数据的请求日志脱敏后再存储。9.5 版本兼容大型语言模型 API 的响应格式偶尔会调整。代理并不依赖响应内容做后续处理所以升级上游 SDK 版本风险较低。但要注意如果上游修改了请求参数比如新增了reasoning_effort之类的字段代理需要支持透传未知参数不能丢弃。10. 总结与最后一步这个项目最值得尝试的点是把“代码理解”的成本优化从“经验判断”升级为“结构判断”。它不是靠估计“这段代码重不重要”而是真正解析代码结构找到不被使用、不影响语义的子树并移除。对于 LLM Agent、自动编程、代码分析这类有大量代码上下文的场景这种机制能有效降低 token 消耗和请求延迟。建议先做这几件事搭好代理接入一个测试应用用一份包含明显冗余代码的测试样本对比修剪前后的 token 数和输出质量观察日志确认 AST 剪枝确实被触发而不是所有请求都走了透传在批量任务场景下跑一小批数据验证稳定性和节省比例。最容易踩的坑有两个一个是剪枝策略太激进导致模型回答质量下降另一个是日志里没记录剪枝前后的 token 数导致无法判断效果。后续可以继续扩展的方向很多接入更多语言的 tree-sitter 解析器、增加基于目录结构的文件级过滤、把修剪策略做成可配置规则、为 Agent 工具调用场景定制代码块保留策略。如果你正在做 LLM 成本治理这个项目值得花一个下午拉下来跑一遍看看在自己真实代码上到底能省多少 token。