一种可重复的推理模型选型方法:基于你自己的数据评估模型,并附上DigitalOcean Serverless的一手成本数据。该方法与云厂商无关;DigitalOcean的特定数据有来源引用。 模型选择使成本相差几个数量级 在GenAI部署中,模型选择——而非基础设施、提示词优化或批处理策略——是影响
如果您在生产环境中运行 LLM推理 ,您现在拥有的硬件选择比以往更多。NVIDIA和AMD GPU仍然是默认选择,但它们并非唯一选择。AWS销售Inferentia2。Google出租TPU。Groq制造了一款专用于推理的芯片。Tenstorrent正在研发另一款。每款专用芯片在某一方面都比GPU更
大多数已发布的推理基准测试都只用一个数字来打头阵:一个首 token 的中位时间,一个峰值每秒 token 数。这些数字并非不真实,但它们是在有利于服务商的条件下测得的:低并发、实例已预热、提示词很短。该条件与你的生产流量之间的差距,正是延迟意外潜伏的地方。 本文提出两个论点,并事先说明哪一个是新的
在本教程中,我将向你展示如何使用QLoRA进行监督微调,为大语言模型在AI代理中的应用进行定制。这使我们能够自定义预训练模型,使其按照我们的需求行事。我们将使用轻量级训练流程,仅更新模型的一小部分。 我们将使用Unsloth和Hugging Face生态系统下载Qwen 1.5B基础模型,应用基于Q
每个构建智能体的团队都能使用相同的模型,但很少有智能体让人觉得快。差别不在于模型,而在于围绕它的工程:发送多少上下文、哪些部分并行运行、智能体工作时用户看到什么,以及流水线每个部分部署在哪里。 背后的智能体刻意使用普通部件:一个开源智能体框架( Hermes ,来自Nous Research)、一台
我们对 Ornith-1.0-9B 进行了微调,这是一个来自 DeepReinforce AI 的开源 9B agentic 编码模型,在一个包含 61,000 个示例的推理-摘要数据集上,使用了 DigitalOcean 上的单个 H200 GPU Droplet 。目标是:不将模型的完整原始思维
Here is a thing that has happened to me more than once. I benchmark a model, the numbers look great, p50 latency is low, tokens per second is high. Th
为什么严肃团队默认运行多提供商推理,以及DigitalOcean的第一方推理路由器在哪里适用,附有在 inference.do-ai.run 上记录的运行成本数据。路由模式与提供商无关;DigitalOcean的具体数字来自已发布的API运行,而非营销宣传。 引言 每个推理提供商的销售手册中都有关于
你花了两个星期构建一个AI助手。流式聊天界面看起来很漂亮,系统提示词写得紧凑,安全过滤器也已配置好。 你向团队演示了它,所有人都印象深刻。你提交到App Store,应用上线了。 上线三天后,有用户报告说快速连点两次发送按钮会出现两个永远不消失的加载转圈。另一个用户发现,如果在流式输出中途关闭应用再
每家销售多模型路由基础设施的公司几乎都会做出同样的宣传:把流量交给我们,我们就能降低你的成本,提高质量,并在某个模型宕机时保持你的服务在线。只有好处,没有附加条款。这种宣传就其本身而言是真实的。但它没有涵盖的是,当你的工作负载不适合路由器最初构建的用途时会发生什么,这正是本文要讨论的内容。 这里有一