随着大模型在工业数据采集、网页结构化解析、文档信息提取等场景的普及很多团队发现效果上去了成本也跟着爆炸。同样是日均千页的解析任务有的团队每月几百块就能跑通有的团队账单直接冲到五位数。很多人把大模型当黑盒用喂全文、等输出、不看账最后成本失控才来找原因。本质上大模型数据采集的核心竞争力从来不是“能不能解析”而是“在可控成本下解析到什么精度”。同样的准确率成本差一个数量级落地能力天差地别。本文就从输入侧提纯、输出侧精简、模型路由、工程化优化到治理体系完整拆解Token消耗优化的全链路实战技巧所有方法都经过生产验证落地就能看到成本下降。一、先算明白成本构成与最大误区1.1 Token成本的基本公式大模型调用成本的核心公式非常简单总成本 输入Token量 × 输入单价 输出Token量 × 输出单价数据采集场景有非常鲜明的特征输入远大于输出。通常一页网页提纯后还有20005000token而最终输出的结构化数据可能只有100300token。输入侧成本普遍占到总成本的80%以上是优化的核心主战场。1.2 最烧钱的5个常见误区绝大多数团队的成本失控都不是模型贵而是用法太粗放全文投喂原始HTML直接喂广告、导航、脚本、样式全算token有效内容不到20%模型一刀切不管简单复杂都用最贵的模型简单列表提取也用高阶模型成本直接乘10输出无约束任由模型输出解释、说明、客套话有效数据不到一半重复请求相同内容重复调用没有缓存机制相同页面反复计费任务碎片化一条数据一个请求系统提示词重复计费批量能力完全浪费二、输入侧优化把水分挤干成本直接砍半输入侧是优化空间最大的环节。做好前置预处理不用换模型、不用改逻辑成本直接降50%以上。2.1 正文提取前置过滤80%的噪声原始HTML页面里真正的业务正文通常只占20%~30%剩下的导航栏、广告、页脚、脚本、样式全是无效token。方案调用大模型之前先用正文提取工具提纯只保留核心内容。推荐工具trafilatura、readability-lxml、BeautifulSoup自定义规则实战代码from trafilatura import extract import requests def get_pure_content(url): resp requests.get(url, timeout10) html resp.text # 提取纯正文自动过滤导航、广告、脚本、评论区 content extract(html, include_linksFalse, include_imagesFalse) return content if content else 效果对比典型电商详情页原始HTML约12000token提取正文后约1800token输入量直接减少85%。2.2 HTML标签裁剪属性全清只留骨架如果需要保留HTML结构比如提取表格、嵌套列表不要直接喂完整HTML先清理所有标签属性。class、style、data-*、id这些属性占了HTML标签的大部分token对语义提取几乎没有作用。处理前div classproduct-item price-box>2.3 按需分块提取只喂你需要的部分不要整页投喂先定位目标区块只提取对应区域。比如只需要商品列表就先通过CSS选择器定位到列表容器只把这部分内容喂给大模型。soup BeautifulSoup(html, html.parser) product_list soup.select_one(#product-list) target_html str(product_list) if product_list else 优势不仅大幅节省token还能减少无关内容的干扰提取准确率反而更高。2.4 文本无损压缩挤掉所有多余空格换行、连续空格、冗余标点、注释这些都是不影响语义的无效token。def compress_text(text): # 合并空白字符去掉空行和首尾空格 lines [line.strip() for line in text.splitlines() if line.strip()] return .join(lines)简单一步通常能再省10%~20%的token完全不影响语义理解。三、输出侧优化每一个Token都用在刀刃上输出侧虽然占比不高但优化成本极低积少成多做好了能再降20%~30%。3.1 强制纯结构化输出禁止废话最核心的一条提示词里明确要求只输出数据不要任何解释。反面典型输出大量废话好的我来为你提取商品信息。第一个商品名称是xxx价格是xxx… 以上就是全部提取结果总共5条数据。正确提示词写法提取下面内容中的商品信息严格输出JSON数组每个元素包含name、price两个字段。要求只输出纯JSON不要任何解释、说明、注释、markdown代码块不要额外文字。就加这一句话输出token量直接减少一半以上。3.2 字段极简设计缩写代替全称输出的JSON字段名用短缩写输出完成后再映射回全称。比如用n代替namep代替pricec代替category。同时尽量扁平化不要多层嵌套。对比// 冗余版本 [{product_name:商品A,product_price:99.00,product_category:数码}] // 极简版本 [{n:商品A,p:99,c:数码}]字段越多节省越明显通常能再省30%左右的输出token。3.3 批量输出一次请求搞定多条不要一条数据发一次请求尽量批量提取。一次请求提取10条数据和10次单独请求相比系统提示词只算1次节省大量重复的上下文开销。经验值单批10条数据单条平均成本下降40%~60%。四、模型路由策略不是越贵越好够用就好不同模型的价格是数量级的差异。选对模型效果差不多成本直接降一个数量级。4.1 分级路由体系按任务难度分三级自动路由到对应模型任务等级适用场景推荐模型相对成本简单规则清晰的列表、表格、固定字段提取轻量大模型 / 本地开源小模型1x中等语义理解、模糊匹配、轻度混淆通用大模型5x复杂强混淆、语义推理、跨页面关联高精度大模型20x实际生产中80%的常规数据采集任务用轻量模型就能搞定和大模型效果差异极小成本只有几十分之一。4.2 本地模型兜底量大的终极杀招如果是大批量、固定场景的提取任务直接部署本地开源模型。比如Qwen、Llama系列开源模型针对特定场景微调之后提取准确率和通用大模型不相上下。成本模型一次性部署成本服务器成本调用量越大单条成本越低。日均万级以上的请求量单条边际成本几乎可以忽略不计比调用云端API便宜两个数量级。4.3 降级重试机制先尝试小模型置信度不够或者提取失败自动升级到大模型。def extract_with_route(content, fields): # 先用小模型尝试 result call_small_model(content, fields) if validate_result(result, fields): return result # 校验失败降级到大模型 return call_large_model(content, fields)既保证整体成功率又最大化节省成本。五、工程化优化批量与缓存的复利效应工程化优化是成本的放大器做好了能在前面优化的基础上再砍一半。5.1 请求合并共享上下文摊薄固定成本每个请求都有固定的系统提示词开销大概几十到几百token。把多个同类任务合并成一个请求固定成本一次分摊。比如把5个页面的同类提取合并系统提示词只算1次相当于每条省了一份固定开销。注意合并也要控制总token量不要超过模型的最优窗口一般控制在8k以内效果最好。5.2 结果缓存相同内容绝不重复计费网页内容不是每次都变相同的内容直接返回缓存结果不用重复调用。实现逻辑对输入内容计算哈希值作为缓存键请求前先查缓存命中直接返回设置过期时间定期更新import hashlib import json cache {} def get_cache_key(content, fields): key content json.dumps(fields) return hashlib.md5(key.encode()).hexdigest() def extract_with_cache(content, fields): key get_cache_key(content, fields) if key in cache: return cache[key] result call_model(content, fields) cache[key] result return result效果更新频率低的页面缓存命中率能到60%以上成本直接减半。5.3 增量更新只处理变化的部分对于定期采集的页面不要每次都整页解析。先对比内容哈希没变直接用缓存变了只解析变化的部分。配合ETag或者内容指纹做增量处理长期运行的成本下降非常明显。六、成本治理从瞎用到可控6.1 分维度统计不要只看总账按场景、按接口、按任务类型统计token消耗。找到Top消耗的场景针对性优化。通常20%的场景占了80%的成本优化这20%整体成本就下来了。6.2 预算与告警设置单日、单月预算阈值超阈值自动告警甚至自动降级到小模型。避免异常情况比如采集失控、循环调用导致账单爆炸。6.3 异常拦截识别异常大请求比如单请求超过几万token自动拦截告警先检查是不是不小心把整个附件、脚本都喂进去了。七、踩坑与最佳实践7.1 常见踩坑为了准确率盲目上大模型90%的场景小模型足够先测再决定输入不做预处理直接喂原始HTML钱都花在解析广告和脚本上了输出不做约束任由模型发挥一半token是废话不做缓存相同内容反复调用钱白白浪费任务拆太碎一条一个请求固定成本占大头7.2 最佳实践清单先提纯再输入所有内容先预处理再喂模型先小模型再大模型能小不大分级路由先批量再单个尽量合并减少请求数先缓存再请求命中缓存不花钱7.3 优化效果参考以日均1000页电商详情页解析为例完整优化前后对比指标优化前优化后下降比例日均输入Token约1200万约220万81.7%日均输出Token约80万约30万62.5%日均成本约180元约32元82.2%提取准确率92%93%基本持平完整优化下来成本下降80%左右准确率还略有提升因为输入噪声减少了。最后大模型数据采集的竞争到最后一定是成本和效率的竞争。算法效果大家都差不太多谁能把成本控制住谁才能大规模落地。Token优化不是抠门而是工程能力的体现用最少的成本拿到足够好的结果。这套优化体系做下来不是省一点半点而是数量级的成本下降。从全文投喂的粗放模式到分层优化的精细化运营才是大模型数据采集从“能用”到“生产级可用”的必经之路。
随着大模型在工业数据采集、网页结构化解析、文档信息提取等场景的普及很多团队发现效果上去了成本也跟着爆炸。同样是日均千页的解析任务有的团队每月几百块就能跑通有的团队账单直接冲到五位数。很多人把大模型当黑盒用喂全文、等输出、不看账最后成本失控才来找原因。本质上大模型数据采集的核心竞争力从来不是“能不能解析”而是“在可控成本下解析到什么精度”。同样的准确率成本差一个数量级落地能力天差地别。本文就从输入侧提纯、输出侧精简、模型路由、工程化优化到治理体系完整拆解Token消耗优化的全链路实战技巧所有方法都经过生产验证落地就能看到成本下降。一、先算明白成本构成与最大误区1.1 Token成本的基本公式大模型调用成本的核心公式非常简单总成本 输入Token量 × 输入单价 输出Token量 × 输出单价数据采集场景有非常鲜明的特征输入远大于输出。通常一页网页提纯后还有20005000token而最终输出的结构化数据可能只有100300token。输入侧成本普遍占到总成本的80%以上是优化的核心主战场。1.2 最烧钱的5个常见误区绝大多数团队的成本失控都不是模型贵而是用法太粗放全文投喂原始HTML直接喂广告、导航、脚本、样式全算token有效内容不到20%模型一刀切不管简单复杂都用最贵的模型简单列表提取也用高阶模型成本直接乘10输出无约束任由模型输出解释、说明、客套话有效数据不到一半重复请求相同内容重复调用没有缓存机制相同页面反复计费任务碎片化一条数据一个请求系统提示词重复计费批量能力完全浪费二、输入侧优化把水分挤干成本直接砍半输入侧是优化空间最大的环节。做好前置预处理不用换模型、不用改逻辑成本直接降50%以上。2.1 正文提取前置过滤80%的噪声原始HTML页面里真正的业务正文通常只占20%~30%剩下的导航栏、广告、页脚、脚本、样式全是无效token。方案调用大模型之前先用正文提取工具提纯只保留核心内容。推荐工具trafilatura、readability-lxml、BeautifulSoup自定义规则实战代码from trafilatura import extract import requests def get_pure_content(url): resp requests.get(url, timeout10) html resp.text # 提取纯正文自动过滤导航、广告、脚本、评论区 content extract(html, include_linksFalse, include_imagesFalse) return content if content else 效果对比典型电商详情页原始HTML约12000token提取正文后约1800token输入量直接减少85%。2.2 HTML标签裁剪属性全清只留骨架如果需要保留HTML结构比如提取表格、嵌套列表不要直接喂完整HTML先清理所有标签属性。class、style、data-*、id这些属性占了HTML标签的大部分token对语义提取几乎没有作用。处理前div classproduct-item price-box>2.3 按需分块提取只喂你需要的部分不要整页投喂先定位目标区块只提取对应区域。比如只需要商品列表就先通过CSS选择器定位到列表容器只把这部分内容喂给大模型。soup BeautifulSoup(html, html.parser) product_list soup.select_one(#product-list) target_html str(product_list) if product_list else 优势不仅大幅节省token还能减少无关内容的干扰提取准确率反而更高。2.4 文本无损压缩挤掉所有多余空格换行、连续空格、冗余标点、注释这些都是不影响语义的无效token。def compress_text(text): # 合并空白字符去掉空行和首尾空格 lines [line.strip() for line in text.splitlines() if line.strip()] return .join(lines)简单一步通常能再省10%~20%的token完全不影响语义理解。三、输出侧优化每一个Token都用在刀刃上输出侧虽然占比不高但优化成本极低积少成多做好了能再降20%~30%。3.1 强制纯结构化输出禁止废话最核心的一条提示词里明确要求只输出数据不要任何解释。反面典型输出大量废话好的我来为你提取商品信息。第一个商品名称是xxx价格是xxx… 以上就是全部提取结果总共5条数据。正确提示词写法提取下面内容中的商品信息严格输出JSON数组每个元素包含name、price两个字段。要求只输出纯JSON不要任何解释、说明、注释、markdown代码块不要额外文字。就加这一句话输出token量直接减少一半以上。3.2 字段极简设计缩写代替全称输出的JSON字段名用短缩写输出完成后再映射回全称。比如用n代替namep代替pricec代替category。同时尽量扁平化不要多层嵌套。对比// 冗余版本 [{product_name:商品A,product_price:99.00,product_category:数码}] // 极简版本 [{n:商品A,p:99,c:数码}]字段越多节省越明显通常能再省30%左右的输出token。3.3 批量输出一次请求搞定多条不要一条数据发一次请求尽量批量提取。一次请求提取10条数据和10次单独请求相比系统提示词只算1次节省大量重复的上下文开销。经验值单批10条数据单条平均成本下降40%~60%。四、模型路由策略不是越贵越好够用就好不同模型的价格是数量级的差异。选对模型效果差不多成本直接降一个数量级。4.1 分级路由体系按任务难度分三级自动路由到对应模型任务等级适用场景推荐模型相对成本简单规则清晰的列表、表格、固定字段提取轻量大模型 / 本地开源小模型1x中等语义理解、模糊匹配、轻度混淆通用大模型5x复杂强混淆、语义推理、跨页面关联高精度大模型20x实际生产中80%的常规数据采集任务用轻量模型就能搞定和大模型效果差异极小成本只有几十分之一。4.2 本地模型兜底量大的终极杀招如果是大批量、固定场景的提取任务直接部署本地开源模型。比如Qwen、Llama系列开源模型针对特定场景微调之后提取准确率和通用大模型不相上下。成本模型一次性部署成本服务器成本调用量越大单条成本越低。日均万级以上的请求量单条边际成本几乎可以忽略不计比调用云端API便宜两个数量级。4.3 降级重试机制先尝试小模型置信度不够或者提取失败自动升级到大模型。def extract_with_route(content, fields): # 先用小模型尝试 result call_small_model(content, fields) if validate_result(result, fields): return result # 校验失败降级到大模型 return call_large_model(content, fields)既保证整体成功率又最大化节省成本。五、工程化优化批量与缓存的复利效应工程化优化是成本的放大器做好了能在前面优化的基础上再砍一半。5.1 请求合并共享上下文摊薄固定成本每个请求都有固定的系统提示词开销大概几十到几百token。把多个同类任务合并成一个请求固定成本一次分摊。比如把5个页面的同类提取合并系统提示词只算1次相当于每条省了一份固定开销。注意合并也要控制总token量不要超过模型的最优窗口一般控制在8k以内效果最好。5.2 结果缓存相同内容绝不重复计费网页内容不是每次都变相同的内容直接返回缓存结果不用重复调用。实现逻辑对输入内容计算哈希值作为缓存键请求前先查缓存命中直接返回设置过期时间定期更新import hashlib import json cache {} def get_cache_key(content, fields): key content json.dumps(fields) return hashlib.md5(key.encode()).hexdigest() def extract_with_cache(content, fields): key get_cache_key(content, fields) if key in cache: return cache[key] result call_model(content, fields) cache[key] result return result效果更新频率低的页面缓存命中率能到60%以上成本直接减半。5.3 增量更新只处理变化的部分对于定期采集的页面不要每次都整页解析。先对比内容哈希没变直接用缓存变了只解析变化的部分。配合ETag或者内容指纹做增量处理长期运行的成本下降非常明显。六、成本治理从瞎用到可控6.1 分维度统计不要只看总账按场景、按接口、按任务类型统计token消耗。找到Top消耗的场景针对性优化。通常20%的场景占了80%的成本优化这20%整体成本就下来了。6.2 预算与告警设置单日、单月预算阈值超阈值自动告警甚至自动降级到小模型。避免异常情况比如采集失控、循环调用导致账单爆炸。6.3 异常拦截识别异常大请求比如单请求超过几万token自动拦截告警先检查是不是不小心把整个附件、脚本都喂进去了。七、踩坑与最佳实践7.1 常见踩坑为了准确率盲目上大模型90%的场景小模型足够先测再决定输入不做预处理直接喂原始HTML钱都花在解析广告和脚本上了输出不做约束任由模型发挥一半token是废话不做缓存相同内容反复调用钱白白浪费任务拆太碎一条一个请求固定成本占大头7.2 最佳实践清单先提纯再输入所有内容先预处理再喂模型先小模型再大模型能小不大分级路由先批量再单个尽量合并减少请求数先缓存再请求命中缓存不花钱7.3 优化效果参考以日均1000页电商详情页解析为例完整优化前后对比指标优化前优化后下降比例日均输入Token约1200万约220万81.7%日均输出Token约80万约30万62.5%日均成本约180元约32元82.2%提取准确率92%93%基本持平完整优化下来成本下降80%左右准确率还略有提升因为输入噪声减少了。最后大模型数据采集的竞争到最后一定是成本和效率的竞争。算法效果大家都差不太多谁能把成本控制住谁才能大规模落地。Token优化不是抠门而是工程能力的体现用最少的成本拿到足够好的结果。这套优化体系做下来不是省一点半点而是数量级的成本下降。从全文投喂的粗放模式到分层优化的精细化运营才是大模型数据采集从“能用”到“生产级可用”的必经之路。
)
)
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
