[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"similar-ray-project--llm-numbers":3,"tool-ray-project--llm-numbers":61},[4,18,26,36,44,53],{"id":5,"name":6,"github_repo":7,"description_zh":8,"stars":9,"difficulty_score":10,"last_commit_at":11,"category_tags":12,"status":17},4358,"openclaw","openclaw\u002Fopenclaw","OpenClaw 是一款专为个人打造的本地化 AI 助手，旨在让你在自己的设备上拥有完全可控的智能伙伴。它打破了传统 AI 助手局限于特定网页或应用的束缚，能够直接接入你日常使用的各类通讯渠道，包括微信、WhatsApp、Telegram、Discord、iMessage 等数十种平台。无论你在哪个聊天软件中发送消息，OpenClaw 都能即时响应，甚至支持在 macOS、iOS 和 Android 设备上进行语音交互，并提供实时的画布渲染功能供你操控。\n\n这款工具主要解决了用户对数据隐私、响应速度以及“始终在线”体验的需求。通过将 AI 部署在本地，用户无需依赖云端服务即可享受快速、私密的智能辅助，真正实现了“你的数据，你做主”。其独特的技术亮点在于强大的网关架构，将控制平面与核心助手分离，确保跨平台通信的流畅性与扩展性。\n\nOpenClaw 非常适合希望构建个性化工作流的技术爱好者、开发者，以及注重隐私保护且不愿被单一生态绑定的普通用户。只要具备基础的终端操作能力（支持 macOS、Linux 及 Windows WSL2），即可通过简单的命令行引导完成部署。如果你渴望拥有一个懂你",349277,3,"2026-04-06T06:32:30",[13,14,15,16],"Agent","开发框架","图像","数据工具","ready",{"id":19,"name":20,"github_repo":21,"description_zh":22,"stars":23,"difficulty_score":10,"last_commit_at":24,"category_tags":25,"status":17},3808,"stable-diffusion-webui","AUTOMATIC1111\u002Fstable-diffusion-webui","stable-diffusion-webui 是一个基于 Gradio 构建的网页版操作界面，旨在让用户能够轻松地在本地运行和使用强大的 Stable Diffusion 图像生成模型。它解决了原始模型依赖命令行、操作门槛高且功能分散的痛点，将复杂的 AI 绘图流程整合进一个直观易用的图形化平台。\n\n无论是希望快速上手的普通创作者、需要精细控制画面细节的设计师，还是想要深入探索模型潜力的开发者与研究人员，都能从中获益。其核心亮点在于极高的功能丰富度：不仅支持文生图、图生图、局部重绘（Inpainting）和外绘（Outpainting）等基础模式，还独创了注意力机制调整、提示词矩阵、负向提示词以及“高清修复”等高级功能。此外，它内置了 GFPGAN 和 CodeFormer 等人脸修复工具，支持多种神经网络放大算法，并允许用户通过插件系统无限扩展能力。即使是显存有限的设备，stable-diffusion-webui 也提供了相应的优化选项，让高质量的 AI 艺术创作变得触手可及。",162132,"2026-04-05T11:01:52",[14,15,13],{"id":27,"name":28,"github_repo":29,"description_zh":30,"stars":31,"difficulty_score":32,"last_commit_at":33,"category_tags":34,"status":17},1381,"everything-claude-code","affaan-m\u002Feverything-claude-code","everything-claude-code 是一套专为 AI 编程助手（如 Claude Code、Codex、Cursor 等）打造的高性能优化系统。它不仅仅是一组配置文件，而是一个经过长期实战打磨的完整框架，旨在解决 AI 代理在实际开发中面临的效率低下、记忆丢失、安全隐患及缺乏持续学习能力等核心痛点。\n\n通过引入技能模块化、直觉增强、记忆持久化机制以及内置的安全扫描功能，everything-claude-code 能显著提升 AI 在复杂任务中的表现，帮助开发者构建更稳定、更智能的生产级 AI 代理。其独特的“研究优先”开发理念和针对 Token 消耗的优化策略，使得模型响应更快、成本更低，同时有效防御潜在的攻击向量。\n\n这套工具特别适合软件开发者、AI 研究人员以及希望深度定制 AI 工作流的技术团队使用。无论您是在构建大型代码库，还是需要 AI 协助进行安全审计与自动化测试，everything-claude-code 都能提供强大的底层支持。作为一个曾荣获 Anthropic 黑客大奖的开源项目，它融合了多语言支持与丰富的实战钩子（hooks），让 AI 真正成长为懂上",149489,2,"2026-04-10T11:32:46",[14,13,35],"语言模型",{"id":37,"name":38,"github_repo":39,"description_zh":40,"stars":41,"difficulty_score":32,"last_commit_at":42,"category_tags":43,"status":17},2271,"ComfyUI","Comfy-Org\u002FComfyUI","ComfyUI 是一款功能强大且高度模块化的视觉 AI 引擎，专为设计和执行复杂的 Stable Diffusion 图像生成流程而打造。它摒弃了传统的代码编写模式，采用直观的节点式流程图界面，让用户通过连接不同的功能模块即可构建个性化的生成管线。\n\n这一设计巧妙解决了高级 AI 绘图工作流配置复杂、灵活性不足的痛点。用户无需具备编程背景，也能自由组合模型、调整参数并实时预览效果，轻松实现从基础文生图到多步骤高清修复等各类复杂任务。ComfyUI 拥有极佳的兼容性，不仅支持 Windows、macOS 和 Linux 全平台，还广泛适配 NVIDIA、AMD、Intel 及苹果 Silicon 等多种硬件架构，并率先支持 SDXL、Flux、SD3 等前沿模型。\n\n无论是希望深入探索算法潜力的研究人员和开发者，还是追求极致创作自由度的设计师与资深 AI 绘画爱好者，ComfyUI 都能提供强大的支持。其独特的模块化架构允许社区不断扩展新功能，使其成为当前最灵活、生态最丰富的开源扩散模型工具之一，帮助用户将创意高效转化为现实。",108322,"2026-04-10T11:39:34",[14,15,13],{"id":45,"name":46,"github_repo":47,"description_zh":48,"stars":49,"difficulty_score":32,"last_commit_at":50,"category_tags":51,"status":17},6121,"gemini-cli","google-gemini\u002Fgemini-cli","gemini-cli 是一款由谷歌推出的开源 AI 命令行工具，它将强大的 Gemini 大模型能力直接集成到用户的终端环境中。对于习惯在命令行工作的开发者而言，它提供了一条从输入提示词到获取模型响应的最短路径，无需切换窗口即可享受智能辅助。\n\n这款工具主要解决了开发过程中频繁上下文切换的痛点，让用户能在熟悉的终端界面内直接完成代码理解、生成、调试以及自动化运维任务。无论是查询大型代码库、根据草图生成应用，还是执行复杂的 Git 操作，gemini-cli 都能通过自然语言指令高效处理。\n\n它特别适合广大软件工程师、DevOps 人员及技术研究人员使用。其核心亮点包括支持高达 100 万 token 的超长上下文窗口，具备出色的逻辑推理能力；内置 Google 搜索、文件操作及 Shell 命令执行等实用工具；更独特的是，它支持 MCP（模型上下文协议），允许用户灵活扩展自定义集成，连接如图像生成等外部能力。此外，个人谷歌账号即可享受免费的额度支持，且项目基于 Apache 2.0 协议完全开源，是提升终端工作效率的理想助手。",100752,"2026-04-10T01:20:03",[52,13,15,14],"插件",{"id":54,"name":55,"github_repo":56,"description_zh":57,"stars":58,"difficulty_score":32,"last_commit_at":59,"category_tags":60,"status":17},4721,"markitdown","microsoft\u002Fmarkitdown","MarkItDown 是一款由微软 AutoGen 团队打造的轻量级 Python 工具，专为将各类文件高效转换为 Markdown 格式而设计。它支持 PDF、Word、Excel、PPT、图片（含 OCR）、音频（含语音转录）、HTML 乃至 YouTube 链接等多种格式的解析，能够精准提取文档中的标题、列表、表格和链接等关键结构信息。\n\n在人工智能应用日益普及的今天，大语言模型（LLM）虽擅长处理文本，却难以直接读取复杂的二进制办公文档。MarkItDown 恰好解决了这一痛点，它将非结构化或半结构化的文件转化为模型“原生理解”且 Token 效率极高的 Markdown 格式，成为连接本地文件与 AI 分析 pipeline 的理想桥梁。此外，它还提供了 MCP（模型上下文协议）服务器，可无缝集成到 Claude Desktop 等 LLM 应用中。\n\n这款工具特别适合开发者、数据科学家及 AI 研究人员使用，尤其是那些需要构建文档检索增强生成（RAG）系统、进行批量文本分析或希望让 AI 助手直接“阅读”本地文件的用户。虽然生成的内容也具备一定可读性，但其核心优势在于为机器",93400,"2026-04-06T19:52:38",[52,14],{"id":62,"github_repo":63,"name":64,"description_en":65,"description_zh":66,"ai_summary_zh":66,"readme_en":67,"readme_zh":68,"quickstart_zh":69,"use_case_zh":70,"hero_image_url":71,"owner_login":72,"owner_name":72,"owner_avatar_url":73,"owner_bio":74,"owner_company":75,"owner_location":75,"owner_email":75,"owner_twitter":76,"owner_website":77,"owner_url":78,"languages":75,"stars":79,"forks":80,"last_commit_at":81,"license":75,"difficulty_score":82,"env_os":74,"env_gpu":83,"env_ram":84,"env_deps":85,"category_tags":88,"github_topics":75,"view_count":32,"oss_zip_url":75,"oss_zip_packed_at":75,"status":17,"created_at":89,"updated_at":90,"faqs":91,"releases":92},6329,"ray-project\u002Fllm-numbers","llm-numbers","Numbers every LLM developer should know","llm-numbers 是一份专为大语言模型（LLM）开发者整理的实用数据参考指南，汇集了在进行系统设计和成本估算时必须掌握的关键数值。它解决了开发者在构建 AI 应用时，因缺乏具体性能与成本基准而难以进行快速粗略计算（back-of-the-envelope calculations）的痛点。\n\n这份资料详细列出了诸如“提示词中添加‘请简洁’可节省 40-90% 费用”、“英文单词与 Token 的平均换算比例约为 1.3:1\"等实战经验，并深入对比了不同模型（如 GPT-4 与 GPT-3.5 Turbo）之间高达 50:1 的成本差异，以及调用 API 与自建向量嵌入服务之间的性价比分析。通过这些具体数据，用户能更科学地决定何时使用高价模型进行高质量数据生成，何时切换至低成本方案处理常规任务。\n\nllm-numbers 特别适合 LLM 应用开发者、算法工程师及技术决策者使用。其独特亮点在于将抽象的技术参数转化为直观的成本效益比例，帮助团队在架构设计初期就做出兼顾性能与预算的最优选择，避免资源浪费。无论是优化提示词策略，还是评估自托管方案的可行性，这份指南都能提供有力的数据支撑。","# Numbers every LLM Developer should know\n\n[中文](https:\u002F\u002Fgithub.com\u002FNascentCore\u002Fllm-numbers-cn)\n\nAt Google, there was a document put together by [Jeff Dean](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FJeff_Dean), the legendary engineer, called [Numbers every Engineer should know](http:\u002F\u002Fbrenocon.com\u002Fdean_perf.html). It’s really useful to have a similar set of numbers for LLM developers to know that are useful for back-of-the envelope calculations. Here we share particular numbers we at Anyscale use, why the number is important and how to use it to your advantage. \n\n## Notes on the Github version\n\nLast updates: 2023-05-17\n\nIf you feel there's an issue with the accuracy of the numbers, please file an issue. Think there are more numbers that should be in this doc? Let us know or file a PR. \n\nWe are thinking the next thing we should add here is some stats on tokens per second of different models. \n\n## Prompts\n\n\n### 40-90%[^1]: Amount saved by appending “Be Concise” to your prompt\n\nIt’s important to remember that you pay by the token for responses. This means that asking an LLM to be concise can save you a lot of money. This can be broadened beyond simply appending “be concise” to your prompt: if you are using GPT-4 to come up with 10 alternatives, maybe ask it for 5 and keep the other half of the money. \n\n\n### 1.3:1 -- Average tokens per word\n\nLLMs operate on tokens. Tokens are words or sub-parts of words, so “eating” might be broken into two tokens “eat” and “ing”. A 750 word document in English will be about 1000 tokens. For languages other than English, the tokens per word increases depending on their commonality in the LLM's embedding corpus.\n\nKnowing this ratio is important because most billing is done in tokens, and the LLM’s context window size is also defined in tokens. \n\n\n## Prices[^2]\n\nPrices are of course subject to change, but given how expensive LLMs are to operate, the numbers in this section are critical. We use OpenAI for the numbers here, but prices from other providers you should check out ([Anthropic](https:\u002F\u002Fcdn2.assets-servd.host\u002Fanthropic-website\u002Fproduction\u002Fimages\u002Fmodel_pricing_may2023.pdf), [Cohere](https:\u002F\u002Fcohere.com\u002Fpricing)) are in the same ballpark. \n\n\n### ~50:1 -- Cost Ratio of GPT-4 to GPT-3.5 Turbo[^3] \n\nWhat this means is that for many practical applications, it’s much better to use GPT-4 for things like generating high quality fine tuning data, or for automated evaluation of other models -- things you might only do once instead of it living in the middle of your inference cycle. It is roughly 50 times cheaper to use GPT-3.5-Turbo than GPT-4 (the “roughly” is because GPT-4 charges differently for the prompt and the generated output)  – so you really need to check on how far you can get with GPT-3.5-Turbo. GPT-3.5-Turbo is more than enough for tasks like summarization for example. \n\n\n### 5:1 -- Cost Ratio of generation of text using GPT-3.5-Turbo vs OpenAI embedding \n\nThis means it is way cheaper to look something up in a vector store than to ask an LLM to generate it. E.g. “What is the capital of Delaware?” when looked up in an neural information retrieval system costs about 5x[^4] less than if you asked GPT-3.5-Turbo. The cost difference compared to GPT-4 is a whopping 250x! \n\n\n### 10:1 -- Cost Ratio of OpenAI embedding to Self-Hosted embedding \n\n> Note: this number is sensitive to load and embedding batch size, so please consider this approximate. \n\nIn our blog post, we noted that using a g4dn.4xlarge (on-demand price: $1.20\u002Fhr) we were able to embed at about 9000 tokens per second using Hugging Face’s SentenceTransformers (which are pretty much as good as OpenAI’s embeddings). Doing some basic math of that rate and that node type indicates it is considerably cheaper (factor of 10 cheaper) to self-host embeddings (and that is before you start to think about things like ingress and egress fees). \n\n\n### 6:1 -- Cost Ratio of OpenAI fine tuned vs base model queries\n\nIt costs you 6 times as much to serve a fine tuned model as it does the base model on OpenAI. This is pretty exorbitant, but might make sense because of the possible multi-tenancy of base models. It also means it is far more cost effective to tweak the prompt for a base model than to fine tune a customized model. \n\n\n### 1:1 -- Cost Ratio of Self-Hosted base vs fine-tuned model queries \n\nIf you’re self hosting a model, then it more or less costs the same amount to serve a fine tuned model as it does to serve a base one: the models have the same number of parameters. \n\n\n## Training and Fine Tuning\n\n\n### ~$1 million: Cost to train a 13 billion parameter model on 1.4 trillion tokens\n\nThe [LLaMa paper](https:\u002F\u002Farxiv.org\u002Fabs\u002F2302.13971) mentions it took them 21 days to train LLaMa using 2048 GPUs A100 80GB GPUs. We considered training our own model on the Red Pajama training set, then we ran the numbers. The above is assuming everything goes right, nothing crashes, and the calculation succeeds on the first time, etc. Plus it involves the coordination of 2048 GPUs. That’s not something most companies can do (shameless plug time: of course, we at Anyscale can – that’s our [bread and butter](https:\u002F\u002Fwww.anyscale.com\u002Fblog\u002Ftraining-175b-parameter-language-models-at-1000-gpu-scale-with-alpa-and-ray)! Contact us if you’d like to learn more). The point is that training your own LLM is possible, but it’s not cheap. And it will literally take days to complete each run. Much cheaper to use a pre-trained model. \n\n\n### < 0.001: Cost ratio of fine tuning vs training from scratch\n\nThis is a bit of a generalization, but the cost of fine tuning is negligible. We showed for example that you can fine tune a [6B parameter model for about $7](https:\u002F\u002Fwww.anyscale.com\u002Fblog\u002Fhow-to-fine-tune-and-serve-llms-simply-quickly-and-cost-effectively-using). Even at OpenAI’s rate for its most expensive fine-tunable model, Davinci, it is 3c per 1000 tokens. That means to fine tune on the entire works of Shakespeare (about 1 million words), you’re looking at $40[^5]. However, fine tuning is one thing and training from scratch is another … \n\n\n## GPU Memory\n\nIf you’re self-hosting a model, it’s really important to understand GPU memory because LLMs push your GPU’s memory to the limit. The following statistics are specifically about inference. You need considerably more memory for training or fine tuning. \n\n\n### V100: 16GB, A10G: 24GB, A100: 40\u002F80GB: GPU Memory Capacities\n\nIt may seem strange, but it’s important to know the amount of memory different types of GPUs have. This will cap the number of parameters your LLM can have. Generally, we like to use A10Gs because they cost $1.50 to $2 per hour each at AWS on-demand prices and have 24G of GPU memory, vs the A100s which will run you about $5 each at AWS on-demand prices. \n\n\n### 2x number of parameters: Typical GPU memory requirements of an LLM for serving\n\nFor example, if you have a 7 billion parameter model, it takes about 14GB of GPU space. This is because most of the time, one 16-bit float (or 2 bytes) is required per parameter. There’s usually no need to go beyond 16-bit accuracy, and most of the time when you go to 8-bit accuracy you start to lose resolution (though that may be acceptable in some cases). Of course there are efforts to reduce this, notably llama.cpp which runs a 13 billion parameter model on a 6GB GPU by quantizing aggressively down to 4 bits (and 8 bits without too much impact), but that’s atypical. \n\n\n### ~1GB: Typical GPU memory requirements of an embedding model\n\nWhenever you are doing sentence embedding (a very typical thing you do for clustering, semantic search and classification tasks), you need an embedding model like [sentence transformers](https:\u002F\u002Fwww.sbert.net\u002Fdocs\u002Fpretrained_models.html#sentence-embedding-models\u002F). OpenAI also has its own embeddings that they provide commercially. \n\nYou typically don’t have to worry about how much memory embeddings take on the GPU, they’re fairly small. We’ve even had the embedding and the LLM on the same GPU. \n\n\n### >10x: Throughput improvement from batching LLM requests \n\nRunning an LLM query through a GPU is very high latency: it may take, say, 5 seconds, with a throughput of 0.2 queries per second.  The funny thing is, though, if you run two tasks, it might only take 5.2 seconds. This means that if you can bundle 25 queries together, it would take about 10 seconds, and our throughput has improved to 2.5 queries per second. However, see the next point. \n\n\n### ~1 MB: GPU Memory required for 1 token of output with a 13B parameter model\n\nThe amount of memory you need is directly proportional to the maximum number of tokens you want to generate. So for example, if you want to generate outputs of up to 512 tokens (about 380 words), you need 512MB. No big deal you might say – I have 24GB to spare, what’s 512MB? Well, if you want to run bigger batches it starts to add up. So if you want to do batches of 16, you need 8GB of space. There are some techniques being developed that overcome this, but it’s still a real issue. \n\n# Cheatsheet\n\n\u003Cimg width=\"1097\" alt=\"Screenshot 2023-05-17 at 1 46 09 PM\" src=\"https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fray-project_llm-numbers_readme_8c90302baa75.png\">\n\n# Next Steps\n\nSee our earlier [blog series on solving Generative AI infrastructure](https:\u002F\u002Fwww.anyscale.com\u002Fblog\u002Fray-common-production-challenges-for-generative-ai-infrastructure) and [using LangChain with Ray](https:\u002F\u002Fwww.anyscale.com\u002Fblog\u002Fllm-open-source-search-engine-langchain-ray). \\\n \\\nIf you are interested in learning more about Ray, see [Ray.io](http:\u002F\u002Fray.io\u002F) and [Docs.Ray.io](http:\u002F\u002Fdocs.ray.io\u002F). \\\n \\\nTo connect with the Ray community join #LLM on the [Ray Slack](https:\u002F\u002Fdocs.google.com\u002Fforms\u002Fd\u002Fe\u002F1FAIpQLSfAcoiLCHOguOm8e7Jnn-JJdZaCxPGjgVCvFijHB5PLaQLeig\u002Fviewform) or our [Discuss forum](https:\u002F\u002Fdiscuss.ray.io\u002F). \\\n \\\nIf you are interested in our Ray hosted service for ML Training and Serving, see [Anyscale.com\u002FPlatform ](http:\u002F\u002Fwww.anyscale.com\u002Fplatform)and click the 'Try it now' button\n\n**Ray Summit 2023:** If you are interested to learn much more about how Ray can be used to build performant and scalable LLM applications and fine-tune\u002Ftrain\u002Fserve LLMs on Ray, join [Ray Summit](https:\u002F\u002Fraysummit.anyscale.com\u002F) on September 18-20th! We have a set of great keynote speakers including John Schulman from OpenAI and Aidan Gomez from Cohere, community and tech talks about Ray as well as [practical training focused on LLMs](https:\u002F\u002Fgithub.com\u002Fray-project\u002Fray-educational-materials\u002Fblob\u002Fmain\u002FNLP_workloads\u002FText_generation\u002FLLM_finetuning_and_batch_inference.ipynb).\n\n\u003C!-- Footnotes themselves at the bottom. -->\n## Notes\n\n[^1]:\n     Based on experimentation with GPT-3.5-Turbo using a suite of prompts on 2023-05-08. \n\n[^2]:\n     Retrieved from [http:\u002F\u002Fopenai.com\u002Fpricing](http:\u002F\u002Fopenai.com\u002Fpricing) on 2023-05-08. \n\n[^3]:\n      **GPT-4**: 6c\u002F1k tokens for the prompt, 12c\u002F1k tokens for the generation (32,000 window version, 8,000 window version is half that). **GPT-3.5 Turbo**: 0.2c\u002F1k tokens. \n\n[^4]:\n     This assumes the vector lookup is “free.” It’s not, but it uses CPUs (much cheaper) and is fairly fast. \n\n[^5]:\n     1 million words \u002F 0.75 tokens\u002Fword \u002F 1000*0.03 = $40. \n","# 每个大语言模型开发者都应该知道的数字\n\n[中文](https:\u002F\u002Fgithub.com\u002FNascentCore\u002Fllm-numbers-cn)\n\n在谷歌，由传奇工程师杰夫·迪恩（Jeff Dean）整理了一份名为《每个工程师都应该知道的数字》的文档。对于 LLM 开发者来说，拥有一套类似的、可用于快速估算的数字同样非常有用。在这里，我们分享 Anyscale 团队常用的一些关键数字、它们的重要性以及如何将其运用到实际工作中。\n\n## 关于 GitHub 版本的说明\n\n最后更新：2023-05-17\n\n如果您认为这些数字的准确性存在问题，请提交 issue。或者您觉得还有其他应该加入本文档的数字？欢迎告诉我们或直接提交 PR。\n\n我们接下来计划补充一些关于不同模型每秒处理 token 数量的统计数据。\n\n## 提示词\n\n\n### 40–90%[^1]：在提示词末尾加上“请简明扼要”可节省的费用比例\n\n需要记住的是，LLM 的计费是按 token 数量计算的。因此，要求 LLM 回答简洁可以显著降低使用成本。这不仅限于在提示词中简单添加“请简明扼要”，例如，如果您使用 GPT-4 来生成 10 种备选方案，不妨只请求 5 种，从而节省一半的费用。\n\n\n### 1.3:1——平均每个单词对应的 token 数量\n\nLLM 是基于 token 进行处理的。token 可以是完整的单词，也可以是单词的一部分，比如“eating”可能会被拆分为“eat”和“ing”两个 token。一篇 750 字的英文文档大约会有 1000 个 token。而对于非英语语言，每个单词对应的 token 数量会根据其在 LLM 嵌入语料库中的常见程度而增加。\n\n了解这一比例非常重要，因为大多数计费是以 token 为单位的，同时 LLM 的上下文窗口大小也是以 token 数量来定义的。\n\n\n## 价格[^2]\n\n当然，价格可能会随时变化，但鉴于 LLM 的运行成本非常高，本节中的数据至关重要。我们这里以 OpenAI 的定价为例，不过其他厂商的价格也大致在这个范围内（如 Anthropic [链接](https:\u002F\u002Fcdn2.assets-servd.host\u002Fanthropic-website\u002Fproduction\u002Fimages\u002Fmodel_pricing_may2023.pdf)、Cohere [链接](https:\u002F\u002Fcohere.com\u002Fpricing)）。\n\n\n### 约 50:1——GPT-4 与 GPT-3.5 Turbo 的成本比[^3]\n\n这意味着，在许多实际应用场景中，使用 GPT-4 更适合用于生成高质量的微调数据，或对其他模型进行自动化评估等仅需执行一次的任务，而不是将其嵌入到推理流程的核心环节。使用 GPT-3.5-Turbo 相较于 GPT-4 大约便宜 50 倍（之所以说是“大约”，是因为 GPT-4 对提示词和生成内容的收费方式不同），因此您需要仔细评估 GPT-3.5-Turbo 能够满足的需求范围。例如，对于摘要生成这类任务，GPT-3.5-Turbo 已经绰绰有余。\n\n\n### 5:1——使用 GPT-3.5-Turbo 生成文本与 OpenAI 嵌入服务的成本比\n\n这表明，从向量数据库中检索信息要比让 LLM 生成信息便宜得多。例如，“特拉华州的首都是哪里？”如果通过神经网络信息检索系统查询，其成本大约是向 GPT-3.5-Turbo 提问的五分之一[^4]；而与 GPT-4 相比，则更是低了整整 250 倍！\n\n\n### 10:1——OpenAI 嵌入服务与自托管嵌入服务的成本比\n\n> 注意：该数值受负载和嵌入批次大小的影响，因此仅供参考。\n\n我们在博客文章中提到，使用 g4dn.4xlarge 实例（按需价格为每小时 1.20 美元），借助 Hugging Face 的 SentenceTransformers 库，我们可以达到每秒约 9000 个 token 的嵌入速度。按照这一速率和实例规格进行简单计算后发现，自托管嵌入服务的成本要低得多（大约便宜 10 倍），而且这还未考虑流量的进出费用等因素。\n\n\n### 6:1——OpenAI 微调模型与基础模型查询的成本比\n\n在 OpenAI 平台上，提供微调模型的服务成本是基础模型的 6 倍。虽然这一差距相当大，但考虑到基础模型可能支持多租户场景，这种定价策略也有一定合理性。这也意味着，与其微调一个定制化的模型，不如通过调整提示词来优化基础模型的表现，这样更为经济高效。\n\n\n### 1:1——自托管基础模型与微调模型查询的成本比\n\n如果您选择自托管模型，则服务微调模型与基础模型的成本基本相同：因为两者具有相同的参数量。\n\n\n## 训练与微调\n\n\n### 约 100 万美元——训练一个拥有 130 亿参数、基于 1.4 万亿 token 数据集的模型所需的成本\n\nLLaMa 论文[链接](https:\u002F\u002Farxiv.org\u002Fabs\u002F2302.13971)提到，他们使用 2048 张 A100 80GB GPU，在 21 天内完成了 LLaMa 的训练。我们也曾考虑过基于 Red Pajama 数据集训练自己的模型，并进行了相关测算。上述成本假设一切顺利、没有硬件故障、首次尝试即成功等情况。此外，还需要协调 2048 张 GPU 卡，这对大多数公司而言并非易事（顺便打个广告：Anyscale 当然可以做到——这正是我们的核心优势[链接](https:\u002F\u002Fwww.anyscale.com\u002Fblog\u002Ftraining-175b-parameter-language-models-at-1000-gpu-scale-with-alpa-and-ray)！如有兴趣，欢迎联系我们了解更多）。总之，自主训练 LLM 是可行的，但绝非廉价之举。而且每次训练都需要耗费数天时间。相比之下，使用预训练模型要经济得多。\n\n\n### \u003C 0.001——微调与从零开始训练的成本比\n\n这是一个相对笼统的说法，但微调的成本确实可以忽略不计。例如，我们已经演示过，只需约 7 美元就能微调一个 60 亿参数的模型[链接](https:\u002F\u002Fwww.anyscale.com\u002Fblog\u002Fhow-to-fine-tune-and-serve-llms-simply-quickly-and-cost-effectively-using)。即使按照 OpenAI 最昂贵的可微调模型 Davinci 的收费标准，每 1000 个 token 的费用也仅为 3 美分。也就是说，要对莎士比亚全集（约 100 万个单词）进行微调，总成本也仅需 40 美元[^5]。然而，微调毕竟不同于从零开始训练……\n\n\n## GPU 显存\n\n如果您选择自托管模型，理解 GPU 显存容量至关重要，因为 LLM 会将 GPU 的显存占用推向极限。以下统计数据专门针对推理场景。如果是训练或微调，则所需的显存容量会更高。\n\n\n### V100：16GB，A10G：24GB，A100：40\u002F80GB——不同型号 GPU 的显存容量\n\n这听起来或许有些奇怪，但了解不同型号 GPU 的显存容量却十分重要。它决定了您的 LLM 能够承载的最大参数量。通常，我们更倾向于使用 A10G，因为其在 AWS 按需价格下每小时仅需 1.50 至 2.00 美元，且拥有 24GB 显存，而 A100 在 AWS 按需价格下每张则需约 5.00 美元。\n\n### 参数量的2倍：LLM推理服务的典型GPU显存需求\n\n例如，如果你有一个70亿参数的模型，大约需要14GB的GPU显存。这是因为大多数情况下，每个参数需要一个16位浮点数（即2字节）。通常没有必要使用高于16位精度的数据类型，而当降到8位精度时，往往会损失一定的分辨率（尽管在某些场景下这种损失是可以接受的）。当然，也有人在努力减少这一需求，比如llama.cpp通过激进地量化到4位（以及在影响不大的情况下量化到8位），可以在一块6GB显存的GPU上运行一个130亿参数的模型，但这种情况并不常见。\n\n\n### 约1GB：嵌入模型的典型GPU显存需求\n\n每当进行句子嵌入时（这是聚类、语义搜索和分类任务中非常常见的操作），你都需要一个嵌入模型，比如[Sentence Transformers](https:\u002F\u002Fwww.sbert.net\u002Fdocs\u002Fpretrained_models.html#sentence-embedding-models\u002F)。OpenAI也有自己的嵌入模型，并以商业方式提供。\n\n一般来说，你无需担心嵌入模型在GPU上占用多少显存，因为它们通常很小。我们甚至曾经将嵌入模型和LLM放在同一块GPU上运行。\n\n\n### 超过10倍：通过批处理LLM请求可提升的吞吐量\n\n通过GPU运行一个LLM查询的延迟非常高：可能需要5秒，此时吞吐量仅为每秒0.2个请求。有趣的是，如果你同时运行两个任务，总耗时可能只会增加到5.2秒。这意味着，如果能将25个查询打包在一起，整个过程大约只需10秒，我们的吞吐量就能提升至每秒2.5个请求。不过，请参阅下一点。\n\n\n### 约1MB：使用130亿参数模型生成1个token所需的GPU显存\n\n所需显存与你希望生成的最大token数量成正比。例如，如果你想生成最多512个token（约380个单词）的输出，就需要512MB显存。你可能会觉得这没什么大不了——我还有24GB空余呢，区区512MB算什么？然而，当你需要处理更大的批次时，显存需求就会迅速累积。比如，如果你要执行16个并发请求的批次，就需要8GB显存。目前有一些技术正在开发以缓解这一问题，但它仍然是一个实际存在的挑战。\n\n# 备忘单\n\n\u003Cimg width=\"1097\" alt=\"Screenshot 2023-05-17 at 1 46 09 PM\" src=\"https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fray-project_llm-numbers_readme_8c90302baa75.png\">\n\n# 下一步\n\n请参阅我们之前关于解决生成式AI基础设施问题的[博客系列](https:\u002F\u002Fwww.anyscale.com\u002Fblog\u002Fray-common-production-challenges-for-generative-ai-infrastructure)以及[如何将LangChain与Ray结合使用](https:\u002F\u002Fwww.anyscale.com\u002Fblog\u002Fllm-open-source-search-engine-langchain-ray)。\\\n \\\n如果您有兴趣了解更多关于Ray的信息，请访问[Ray.io](http:\u002F\u002Fray.io\u002F)和[Docs.Ray.io](http:\u002F\u002Fdocs.ray.io\u002F)。\\\n \\\n如需加入Ray社区，请前往[Ray Slack](https:\u002F\u002Fdocs.google.com\u002Fforms\u002Fd\u002Fe\u002F1FAIpQLSfAcoiLCHOguOm8e7Jnn-JJdZaCxPGjgVCvFijHB5PLaQLeig\u002Fviewform)中的#LLM频道，或访问我们的[Discuss论坛](https:\u002F\u002Fdiscuss.ray.io\u002F)。\\\n \\\n如果您对我们的ML训练与推理托管服务感兴趣，请访问[Anyscale.com\u002FPlatform](http:\u002F\u002Fwww.anyscale.com\u002Fplatform)，并点击“立即试用”按钮。\n\n**Ray Summit 2023：** 如果您想深入了解如何利用Ray构建高性能、可扩展的LLM应用，以及如何在Ray平台上微调、训练和部署LLM，请于9月18日至20日参加[Ray Summit](https:\u002F\u002Fraysummit.anyscale.com\u002F)！本次峰会将邀请多位重量级演讲嘉宾，包括来自OpenAI的John Schulman和来自Cohere的Aidan Gomez，同时还将举办关于Ray的社区和技术分享会，以及专注于LLM的[实践培训](https:\u002F\u002Fgithub.com\u002Fray-project\u002Fray-educational-materials\u002Fblob\u002Fmain\u002FNLP_workloads\u002FText_generation\u002FLLM_finetuning_and_batch_inference.ipynb)。\n\n\u003C!-- 脚注位于页面底部。 -->\n## 注释\n\n[^1]:\n     基于2023年5月8日使用一系列提示词对GPT-3.5-Turbo进行的实验。\n\n[^2]:\n     数据来源于2023年5月8日的[http:\u002F\u002Fopenai.com\u002Fpricing](http:\u002F\u002Fopenai.com\u002Fpricing)。\n\n[^3]:\n      **GPT-4**：提示词为6美分\u002F1000个token，生成部分为12美分\u002F1000个token（窗口大小为32,000的版本；窗口大小为8,000的版本则为一半价格）。**GPT-3.5 Turbo**：0.2美分\u002F1000个token。\n\n[^4]:\n     这里假设向量查找是“免费”的。实际上并非如此，但它使用CPU（成本更低）且速度较快。\n\n[^5]:\n     100万字 \u002F 每字0.75个token \u002F 1000 * 0.03 = 40美元。","# llm-numbers 快速上手指南\n\n`llm-numbers` 并非一个需要安装运行的软件库，而是一份由 Anyscale 团队整理的**大语言模型（LLM）开发关键数据速查表**。它旨在帮助开发者进行成本估算、资源规划和架构决策。以下内容基于官方文档整理，助您快速掌握核心数据。\n\n## 环境准备\n\n本项目无需特定的系统环境或前置依赖。\n- **适用人群**：LLM 应用开发者、架构师、技术决策者。\n- **阅读方式**：直接浏览本指南、访问 [GitHub 仓库](https:\u002F\u002Fgithub.com\u002FNascentCore\u002Fllm-numbers-cn) 或查看官方 CheatSheet 图片。\n- **知识储备**：了解 Token、上下文窗口、微调（Fine-tuning）、嵌入（Embedding）及 GPU 显存等基本概念。\n\n## 安装步骤\n\n由于这是一份参考文档而非代码包，**无需执行安装命令**。\n\n您可以直接收藏以下资源以便随时查阅：\n- **中文社区版**：[https:\u002F\u002Fgithub.com\u002FNascentCore\u002Fllm-numbers-cn](https:\u002F\u002Fgithub.com\u002FNascentCore\u002Fllm-numbers-cn)\n- **英文原版**：[https:\u002F\u002Fgithub.com\u002Fray-project\u002Fllm-numbers](https:\u002F\u002Fgithub.com\u002Fray-project\u002Fllm-numbers)\n\n> **提示**：建议将下方的“核心数据速查”保存为团队内部知识库，用于项目初期的预算评估。\n\n## 基本使用\n\n在实际开发中，您可以利用以下关键数据进行“信封背面”式的快速估算：\n\n### 1. 提示词优化与成本节省\n- **节省 40-90% 费用**：在 Prompt 末尾添加 `\"Be Concise\"`（请简洁）可显著减少输出 Token 数量，从而大幅降低费用。\n- **策略建议**：如果需要 10 个方案，先让模型生成 5 个，往往能节省一半预算。\n\n### 2. Token 换算基准\n- **换算比例**：`1.3 : 1` (Token : 单词)。\n- **估算公式**：英文文档中，750 个单词约等于 1000 个 Token。非英语语言因分词差异，比例可能更高。\n- **应用场景**：用于计算输入文档大小是否超出模型的上下文窗口限制，以及预估 API 调用成本。\n\n### 3. 模型选型与成本比率\n- **GPT-4 vs GPT-3.5-Turbo**：成本比约为 `50 : 1`。\n  - *建议*：仅在需要高质量微调数据或自动化评估时使用 GPT-4；常规任务（如摘要）首选 GPT-3.5-Turbo。\n- **生成文本 vs 向量检索**：使用 GPT-3.5-Turbo 生成答案的成本是向量数据库检索的 `5` 倍；若是 GPT-4，则高达 `250` 倍。\n  - *建议*：优先构建 RAG（检索增强生成）架构，而非让模型凭空生成事实性知识。\n- **OpenAI 嵌入 vs 自建嵌入**：成本比约为 `10 : 1`。\n  - *建议*：大规模数据处理时，自建嵌入服务（如使用 HuggingFace SentenceTransformers）更具性价比。\n- **微调 vs 从头训练**：成本比 `\u003C 0.001`。\n  - *数据*：微调一个 6B 参数模型仅需约 $7；而从头训练一个 13B 参数模型需约 $100 万（需 2048 张 A100 运行 21 天）。\n  - *建议*：绝大多数场景应选择预训练模型 + 微调\u002FPrompt 工程，避免从头训练。\n\n### 4. GPU 显存规划 (自托管场景)\n- **显存需求估算**：推理时，显存需求约为参数量大小的 `2` 倍（基于 16-bit 精度）。\n  - *示例*：7B 参数模型 $\\approx$ 14GB 显存。\n- **常见显卡容量**：\n  - V100: 16GB\n  - A10G: 24GB (性价比推荐，AWS 约 $1.5-$2\u002F小时)\n  - A100: 40GB \u002F 80GB\n- **批量处理优化**：通过 Batch 处理请求，吞吐量可提升 `>10` 倍（例如：单次请求 5 秒，25 个请求打包仅需 10 秒）。\n- **输出显存占用**：对于 13B 模型，每生成 1 个 Token 约占用 `1 MB` 显存。若需生成 512 Token 且 Batch Size 为 16，需额外预留约 8GB 显存。\n\n### 5. 快速决策口诀\n- **能检索就不生成**：向量查找比 LLM 生成便宜得多。\n- **能微调就不重训**：微调成本几乎可以忽略不计。\n- **能 3.5 就不 4**：除非必要，否则 GPT-3.5-Turbo 足以胜任大部分任务。\n- **提示词要简短**：明确约束模型输出长度可直接省钱。","某初创团队正在开发一款基于 RAG 架构的法律咨询助手，需要在控制成本的同时保证回答的准确性与响应速度。\n\n### 没有 llm-numbers 时\n- 团队默认全程调用 GPT-4 处理所有用户提问，导致单次对话成本高昂，预算迅速耗尽。\n- 提示词（Prompt）设计冗长且未加约束，模型输出大量无关废话，进一步推高了 Token 消耗。\n- 对于“法律定义查询”等事实性问题，直接让大模型生成答案，而非检索向量库，浪费了约 5 倍的成本。\n- 缺乏对 Token 与单词换算比例的认知，无法准确预估上下文窗口限制，常出现长文档被截断的情况。\n- 盲目使用 OpenAI 的 Embedding 服务，未评估自建方案，导致在大规模数据入库时多支付了约 10 倍的费用。\n\n### 使用 llm-numbers 后\n- 依据 50:1 的成本比例，团队将常规问答切换至 GPT-3.5-Turbo，仅在复杂案例推理时启用 GPT-4，整体成本降低 90%。\n- 利用\"Be Concise\"可节省 40-90% 输出的数据，优化提示词工程，强制模型精简回答，显著减少计费 Token 数。\n- 遵循 5:1 的成本差异，将事实类查询改为优先检索向量库，仅在需要综合研判时才调用大模型生成。\n- 按照 1.3:1 的 Token\u002F单词比率重新规划文档切片策略，确保关键法律条文完整进入上下文窗口，避免信息丢失。\n- 参考 10:1 的自建与服务成本差，将 Embedding 任务迁移至本地 GPU 集群部署，大幅降低了长期运营开支。\n\nllm-numbers 通过提供关键的量化基准，帮助开发者从“凭感觉开发”转向“基于数据的成本与性能最优解”，实现了效益最大化。","https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fray-project_llm-numbers_8c90302b.png","ray-project","https:\u002F\u002Foss.gittoolsai.com\u002Favatars\u002Fray-project_341db8ae.png","",null,"raydistributed","https:\u002F\u002Fdocs.ray.io","https:\u002F\u002Fgithub.com\u002Fray-project",4290,140,"2026-04-09T10:30:18",1,"非运行此文档的必需条件，但文中提及自托管模型需关注显存。参考型号：V100 (16GB), A10G (24GB), A100 (40\u002F80GB)。7B 参数模型推理约需 14GB 显存 (16-bit)，13B 模型量化后可在 6GB 显存运行。","未说明",{"notes":86,"python":84,"dependencies":87},"该仓库并非一个可执行的软件工具，而是一份关于 LLM 开发关键数据（如成本比例、显存需求、训练费用）的参考文档\u002F速查表。文中提到的具体硬件需求（如 GPU 显存）是针对‘自托管模型推理’场景的通用估算，而非安装此仓库本身的要求。例如：7B 模型通常需 2 倍参数量大小的显存；嵌入模型显存需求较小（约 1GB）；批量处理可显著提升吞吐量。",[],[35,14],"2026-03-27T02:49:30.150509","2026-04-11T03:25:18.540908",[],[]]