AI评估工程：从零开始构建生产级LLM评估平台 [完整手册]
令人印象深刻的演示与值得信赖的系统之间的差距，是用评测来衡量的。 我想从一个正在数百个工程团队中发生的故事开始。 一个团队为法律研究构建了一个RAG应用。他们用40个精心挑选的问题进行测试。答案看起来不错，于是他们向合伙人团队演示。合伙人们印象深刻，他们便将其上线了。 上线三周后，一名律师助理标记了
一夜处理百万文档：端到端批量推理
假设你的对象存储中有一百万张支持工单，而明天早上之前你需要将每一张按问题类型分类并总结成一段话。第一时间想到的显然是通过实时聊天补全API逐个发送，但这是错误的方法。按照标准速率限制，仅请求本身就需要超过一天时间，每个token都要付全价，而且在凌晨三点的一次网络故障就可能让你的脚本半途而废。 本文
为推理用例选择正确的模型：生产环境中的推理系列
一种可重复的推理模型选型方法：基于你自己的数据评估模型，并附上DigitalOcean Serverless的一手成本数据。该方法与云厂商无关；DigitalOcean的特定数据有来源引用。 模型选择使成本相差几个数量级 在GenAI部署中，模型选择——而非基础设施、提示词优化或批处理策略——是影响
超越GPU：Inferentia2、TPU、Groq LPU和Tenstorrent在LLM服务中的实际差异
如果您在生产环境中运行 LLM推理 ，您现在拥有的硬件选择比以往更多。NVIDIA和AMD GPU仍然是默认选择，但它们并非唯一选择。AWS销售Inferentia2。Google出租TPU。Groq制造了一款专用于推理的芯片。Tenstorrent正在研发另一款。每款专用芯片在某一方面都比GPU更
p50与p99延迟：中位数基准测试为何误导AI代理工作负载
大多数已发布的推理基准测试都只用一个数字来打头阵：一个首 token 的中位时间，一个峰值每秒 token 数。这些数字并非不真实，但它们是在有利于服务商的条件下测得的：低并发、实例已预热、提示词很短。该条件与你的生产流量之间的差距，正是延迟意外潜伏的地方。 本文提出两个论点，并事先说明哪一个是新的
如何使用SFT和QLoRA为AI代理定制LLM
在本教程中，我将向你展示如何使用QLoRA进行监督微调，为大语言模型在AI代理中的应用进行定制。这使我们能够自定义预训练模型，使其按照我们的需求行事。我们将使用轻量级训练流程，仅更新模型的一小部分。 我们将使用Unsloth和Hugging Face生态系统下载Qwen 1.5B基础模型，应用基于Q
让AI代理在无服务器推理中感知更快
每个构建智能体的团队都能使用相同的模型，但很少有智能体让人觉得快。差别不在于模型，而在于围绕它的工程：发送多少上下文、哪些部分并行运行、智能体工作时用户看到什么，以及流水线每个部分部署在哪里。 背后的智能体刻意使用普通部件：一个开源智能体框架（ Hermes ，来自Nous Research）、一台
在单个 H200 GPU Droplet 上微调 LLM Ornith 9b：成本、延迟和服务开销
我们对 Ornith-1.0-9B 进行了微调，这是一个来自 DeepReinforce AI 的开源 9B agentic 编码模型，在一个包含 61,000 个示例的推理-摘要数据集上，使用了 DigitalOcean 上的单个 H200 GPU Droplet 。目标是：不将模型的完整原始思维
为什么你的 vLLM p99 延迟在生产环境暴涨，以及分块预填充和调度如何解决
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
多提供商LLM路由不是问题，而是你的架构：生产环境推理系列
为什么严肃团队默认运行多提供商推理，以及DigitalOcean的第一方推理路由器在哪里适用，附有在 inference.do-ai.run 上记录的运行成本数据。路由模式与提供商无关；DigitalOcean的具体数字来自已发布的API运行，而非营销宣传。 引言 每个推理提供商的销售手册中都有关于