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

本文涉及的产品
实时计算 Flink 版,5000CU*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}")
AI 代码解读

这个包对于估计输入提示和来自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}")
AI 代码解读

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

总结

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

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

作者:Eugene Evstafev

目录
打赏
0
1
3
0
553
分享
相关文章
Kimi K2开源炸场,1万亿参数碾压GPT-4.1,成本仅Claude 4的1/5!
月之暗面开源的万亿参数大模型Kimi K2引发行业震动,48小时内即登顶OpenRouter API调用榜,GitHub项目激增200%。该模型在代码生成、Agent任务及中文创作上超越Claude 4,标志着中国大模型首次在三大核心能力上达到全球顶尖水平。
构建高性能LLM推理服务的完整方案:单GPU处理172个查询/秒、10万并发仅需15美元/小时
本文将通过系统性实验不同的优化技术来构建自定义LLaMA模型服务,目标是高效处理约102,000个并行查询请求,并通过对比分析确定最优解决方案。
47 0
构建高性能LLM推理服务的完整方案:单GPU处理172个查询/秒、10万并发仅需15美元/小时
基于内存高效算法的 LLM Token 优化:一个有效降低 API 成本的技术方案
本文探讨了在构建对话系统时如何通过一种内存高效算法降低大语言模型(LLM)的Token消耗和运营成本。传统方法中,随着对话深度增加,Token消耗呈指数级增长,导致成本上升。
135 7
基于内存高效算法的 LLM Token 优化:一个有效降低 API 成本的技术方案
TurboAttention:基于多项式近似和渐进式量化的高效注意力机制优化方案,降低LLM计算成本70%
**TurboAttention**提出了一种全新的LLM信息处理方法。该方法通过一系列优化手段替代了传统的二次复杂度注意力机制,包括稀疏多项式软最大值近似和高效量化技术。
245 5
TurboAttention:基于多项式近似和渐进式量化的高效注意力机制优化方案,降低LLM计算成本70%
大模型下HPE GPT解决问题之确保服务高效可靠如何解决
大模型下HPE GPT解决问题之确保服务高效可靠如何解决
79 0
公理训练让LLM学会因果推理:6700万参数模型比肩万亿参数级GPT-4
【8月更文挑战第3天】新论文提出“公理训练”法,使仅有6700万参数的语言模型掌握因果推理,性能媲美万亿级GPT-4。研究通过大量合成数据示例教授模型因果公理,实现有效推理并泛化至复杂图结构。尽管面临合成数据需求大及复杂关系处理限制,此法仍为语言模型的因果理解开辟新途径。[链接: https://arxiv.org/pdf/2407.07612]
193 1
从本地部署到企业级服务:十种主流LLM推理框架的技术介绍与对比
本文深入探讨了十种主流的大语言模型(LLM)服务引擎和工具,涵盖从轻量级本地部署到高性能企业级解决方案,详细分析了它们的技术特点、优势及局限性,旨在为研究人员和工程团队提供适合不同应用场景的技术方案。内容涉及WebLLM、LM Studio、Ollama、vLLM、LightLLM、OpenLLM、HuggingFace TGI、GPT4ALL、llama.cpp及Triton Inference Server与TensorRT-LLM等。
1005 7
|
9月前
|
LLM-03 大模型 15分钟 FineTuning 微调 GPT2 模型 finetuning GPT微调实战 仅需6GB显存 单卡微调 数据 10MB数据集微调
LLM-03 大模型 15分钟 FineTuning 微调 GPT2 模型 finetuning GPT微调实战 仅需6GB显存 单卡微调 数据 10MB数据集微调
236 0
GPT-4无师自通预测蛋白质结构登Nature子刊!LLM全面进军生物学,AlphaFold被偷家?
【9月更文挑战第17天】近日,《自然》子刊发表的一篇论文展示了GPT-4在预测蛋白质结构方面的惊人能力,这一突破不仅揭示了大型语言模型在生物学领域的巨大潜力,还可能影响传统预测工具如AlphaFold的地位。研究人员发现,GPT-4仅通过自然语言处理就能准确预测蛋白质的三维结构,包括常见的氨基酸序列和复杂的α-螺旋结构。实验结果显示,其预测精度与实际结构非常接近。这一成果意味着自然语言处理技术也可应用于生物学研究,但同时也引发了关于其局限性和对现有工具影响的讨论。论文详情见:https://www.nature.com/articles/s41598-024-69021-2
187 8
多模态LLM视觉推理能力堪忧,浙大领衔用GPT-4合成数据构建多模态基准
【9月更文挑战第2天】浙江大学领衔的研究团队针对多模态大型模型(MLLM)在抽象图像理解和视觉推理上的不足,提出了一种利用GPT-4合成数据构建多模态基准的方法。该研究通过合成数据提高了MLLM处理图表、文档等复杂图像的能力,并构建了一个包含11,193条指令的基准,涵盖8种视觉场景。实验表明,这种方法能显著提升模型性能,但依赖闭源模型和高计算成本是其局限。论文详细内容见:https://arxiv.org/pdf/2407.07053
246 10
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问