使用Tokeniser估算GPT和LLM服务的查询成本

本文涉及的产品
实时计算 Flink 版,1000CU*H 3个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 将LLM集成到项目所花费的成本主要是我们通过API获取LLM返回结果的成本,而这些成本通常是根据处理的令牌数量计算的。我们如何预估我们的令牌数量呢?Tokeniser包可以有效地计算文本输入中的令牌来估算这些成本。本文将介绍如何使用Tokeniser有效地预测和管理费用。

大语言模型(如GPT)中的"tokens"是指模型用来处理和理解文本的基本单位。令牌是语言模型处理文本时的基本单位,可以是单词、子词(subwords)、字符或者其他更小的文本单元。所以我们在计算令牌时不能简单的将单词按照空格分隔,而将一段文本分解成令牌的过程称为"tokenization",这是预处理文本的重要步骤。

大语言模型中一般都会使用子词作为令牌,这对于处理词汇表中未见过的单词很有帮助。例如,"unhappiness"可能被分解成"un", "happi", "ness"这三个子词。

Tokeniser是一个轻量级、高效的Python包,使用正则表达式进行计数,这样可以在不加载复杂的NLP模型时进行快速的估计:

 importtokeniser

 text="Hello, World!"
 token_count=tokeniser.estimate_tokens(text)
 print(f"Number of tokens: {token_count}")

这个包对于估计输入提示和来自LLM模型的预期响应中的令牌数量特别有用。假设输入提示包含60个令牌,期望的响应长度为150个令牌,那么每个请求的令牌总数为210

有了总令牌计数,就可以根据GPT或其他LLM服务的定价来估计成本。例如,如果服务每1000个令牌收费0.02美元:

每次请求费用: 210/1000∗0.02=0.0042

我们可以将上面的工作封装成一个函数进行总成本预测:

 importtokeniser

 defestimate_cost_with_tokeniser(prompt, max_response_length, cost_per_thousand_tokens):
     input_tokens=tokeniser.estimate_tokens(prompt)
     total_tokens=input_tokens+max_response_length
     cost_per_request= (total_tokens/1000) *cost_per_thousand_tokens
     returncost_per_request

 # Example usage
 prompt="Write a concise guide on estimating GPT and LLM query costs."
 max_response_length=150# Desired response length in tokens
 cost_per_thousand_tokens=0.02# Cost per 1,000 tokens
 estimated_cost=estimate_cost_with_tokeniser(prompt, max_response_length, cost_per_thousand_tokens)
 print(f"Estimated cost per request: ${estimated_cost:.4f}")

把它放到我们的工具类中,这样就可以在任何需要的时候直接调用了

总结

Tokeniser包为开发人员提供了一种实用而有效的方法来估计GPT和LLM查询令牌数,这对于管理和预测使用成本至关重要。通过将简单的令牌计数合并到成本估算过程中,可以确保项目更有效的预算管理。

https://avoid.overfit.cn/post/064552e1902b468d834e7d65399dcd04

作者:Eugene Evstafev

目录
相关文章
|
2月前
|
存储 人工智能 数据中心
138_绿色计算:碳排放优化 - 估算部署的碳足迹与LLM环境友好型部署最佳实践
随着大语言模型(LLM)在各个行业的广泛应用,其计算需求和环境影响正日益受到关注。根据最新研究,训练一个大型LLM模型可能产生数百吨二氧化碳当量的排放,这相当于普通家庭几十年的碳足迹。在全球气候变化和可持续发展的背景下,如何优化LLM部署的碳足迹,实现环境友好型AI应用,已成为行业面临的重要挑战。
|
3月前
|
存储 缓存 负载均衡
LLM推理成本直降60%:PD分离在大模型商业化中的关键价值
在LLM推理中,Prefill(计算密集)与Decode(访存密集)阶段特性不同,分离计算可提升资源利用率。本文详解vLLM框架中的PD分离实现及局限,并分析Dynamo、Mooncake、SGLang等主流方案,探讨KV缓存、传输机制与调度策略,助力LLM推理优化。建议点赞收藏,便于后续查阅。
1598 1
|
12月前
|
机器学习/深度学习 PyTorch 测试技术
TurboAttention:基于多项式近似和渐进式量化的高效注意力机制优化方案,降低LLM计算成本70%
**TurboAttention**提出了一种全新的LLM信息处理方法。该方法通过一系列优化手段替代了传统的二次复杂度注意力机制,包括稀疏多项式软最大值近似和高效量化技术。
487 5
TurboAttention:基于多项式近似和渐进式量化的高效注意力机制优化方案,降低LLM计算成本70%
|
5月前
|
人工智能 数据挖掘 API
Kimi K2开源炸场,1万亿参数碾压GPT-4.1,成本仅Claude 4的1/5!
月之暗面开源的万亿参数大模型Kimi K2引发行业震动,48小时内即登顶OpenRouter API调用榜,GitHub项目激增200%。该模型在代码生成、Agent任务及中文创作上超越Claude 4,标志着中国大模型首次在三大核心能力上达到全球顶尖水平。
|
5月前
|
缓存 异构计算 Docker
构建高性能LLM推理服务的完整方案:单GPU处理172个查询/秒、10万并发仅需15美元/小时
本文将通过系统性实验不同的优化技术来构建自定义LLaMA模型服务,目标是高效处理约102,000个并行查询请求,并通过对比分析确定最优解决方案。
475 0
构建高性能LLM推理服务的完整方案:单GPU处理172个查询/秒、10万并发仅需15美元/小时
|
6月前
|
存储 自然语言处理 算法
基于内存高效算法的 LLM Token 优化:一个有效降低 API 成本的技术方案
本文探讨了在构建对话系统时如何通过一种内存高效算法降低大语言模型(LLM)的Token消耗和运营成本。传统方法中,随着对话深度增加,Token消耗呈指数级增长,导致成本上升。
504 7
基于内存高效算法的 LLM Token 优化:一个有效降低 API 成本的技术方案
|
5月前
|
人工智能 缓存 监控
GitHub 8k star!Portkey AI Gateway 如何帮你3行代码接入1600+ LLM,实现成本、可靠性与安全三赢?
Portkey AI Gateway 是一个轻量级、高速、安全的中间层,帮助应用对接多模态 AI 模型,统一管理,快速落地。支持超1600款语言、视觉、音频、图像模型,通过 1 个 API 接口实现快速、可靠、安全的模型路由。具备智能路由、自动重试、缓存机制、合规控制等功能,助力企业高效构建 AI 应用。
333 0
|
人工智能 自然语言处理
公理训练让LLM学会因果推理:6700万参数模型比肩万亿参数级GPT-4
【8月更文挑战第3天】新论文提出“公理训练”法,使仅有6700万参数的语言模型掌握因果推理,性能媲美万亿级GPT-4。研究通过大量合成数据示例教授模型因果公理,实现有效推理并泛化至复杂图结构。尽管面临合成数据需求大及复杂关系处理限制,此法仍为语言模型的因果理解开辟新途径。[链接: https://arxiv.org/pdf/2407.07612]
287 1
|
存储 人工智能 异构计算
大模型下HPE GPT解决问题之确保服务高效可靠如何解决
大模型下HPE GPT解决问题之确保服务高效可靠如何解决
127 0
|
自然语言处理 资源调度 并行计算
从本地部署到企业级服务:十种主流LLM推理框架的技术介绍与对比
本文深入探讨了十种主流的大语言模型(LLM)服务引擎和工具,涵盖从轻量级本地部署到高性能企业级解决方案,详细分析了它们的技术特点、优势及局限性,旨在为研究人员和工程团队提供适合不同应用场景的技术方案。内容涉及WebLLM、LM Studio、Ollama、vLLM、LightLLM、OpenLLM、HuggingFace TGI、GPT4ALL、llama.cpp及Triton Inference Server与TensorRT-LLM等。
1568 7