跳到主要内容

18 篇博文 含有标签「llm-inference」

查看所有标签

混合云边 LLM 推理:端侧模型何时优于云端

· 阅读需 14 分钟
Tian Pan
Software Engineer

你的 LLM 在云端生成的每一个 Token 都在产生费用,增加延迟,并跨越网络边界传输用户数据。在设备端生成的每一个 Token 都避开了这三个问题——但受限于手机或笔记本电脑 GPU 的处理能力。有趣的工程挑战发生在边界上:决定哪些查询值得调用云端的前沿能力,而哪些更适合由运行时间不到 20 毫秒的 3B 参数本地模型来处理。

混合云边推理模式并非理论。Apple Intelligence 在端侧模型和私有云计算 (Private Cloud Compute) 之间进行路由。Google 的 Gemini Nano 直接在 Pixel 和三星设备上运行,同时将复杂的请求升级到云端 Gemini。这些不是演示项目——它们正以数十亿设备的规模进行交付。而底层架构现在正被任何愿意仔细思考“延迟-隐私-成本”三角形的团队所采用。

LLM 排队论:为什么你的负载均衡器按请求思考,而你的 GPU 按 Token 思考

· 阅读需 14 分钟
Tian Pan
Software Engineer

你的负载均衡器将请求均匀地分配到你的 GPU 集群中。每个实例接收到的并发请求数量大致相同。一切看起来都很均衡。然而,一个实例的运行速度缓慢,仅为每秒 40 个 token,而另一个实例却能稳定在 200 个。仪表板显示请求数相等,但你的用户体验到的延迟却天差地别。

问题的根源在于:传统的负载均衡在请求层面运行,但 LLM 推理成本是随 token 数量扩展的。一个要求生成 4,000 个 token 文章的请求所消耗的 GPU 时间,是一个生成 80 个 token 分类结果请求的 50 倍。将它们视为同等单位,就像高速公路收费站只计算车辆数量而不区分摩托车和 18 轮大卡车一样。

这种请求层面的思维与 token 层面的现实之间的不匹配,正是古典排队论面临的最有趣的现代挑战。

生产环境中的 MoE 模型:稠密模型基准测试所掩盖的服务特性

· 阅读需 13 分钟
Tian Pan
Software Engineer

基准测试告诉过你,运行 Mixtral 8x7B 的成本只有 46B 稠密模型的一半。但它们没告诉你的是,它需要的 GPU 显存大约是同等稠密模型的 8.6 倍,其响应延迟会因令牌命中哪个专家而产生剧烈波动,并且在中等批处理大小下会以难以诊断的方式崩溃。专家混合(MoE)架构已成为几乎所有前沿模型——DeepSeek-V3、Llama 4、Gemini 1.5、Grok、Mistral Large——的中流抵柱,但适用于稠密模型的推理假设在 MoE 上会以微妙且昂贵的方式失效。

如果你打算私有化部署或将流量路由到这些模型,以下是稠密模型直觉可能出错的地方。

生产环境下的自托管 LLM:没人告诉你的 GPU 显存计算公式

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数决定自托管 LLM 的工程师都会从同样的计算开始:模型有 70B 参数,FP16 每参数 2 字节,所以是 140 GB。他们检查发现两块 A100-80GB GPU 能容纳 160 GB,感到很满意,于是订购了硬件。然后进入生产环境,却发现还没服务一个真实用户,显存(VRAM)就已经耗尽了。

模型权重只是故事的一部分。让几乎每个团队都感到意外的部分是 KV 缓存(KV cache)—— 理解它会改变你的每一个决定,从量化选择到推理框架,再到你实际需要的 GPU 数量。

持续批处理:LLM 服务中提升 GPU 利用率的最关键技术

· 阅读需 14 分钟
Tian Pan
Software Engineer

生产环境中大多数 LLM 推理基础设施的故障并不是模型故障——而是调度故障。团队部署了一个高性能模型,进行了压力测试,却发现用户在等待的同时,昂贵的 GPU 时间仅以 35% 的利用率在消耗。罪魁祸首几乎总是静态批处理(Static batching):这是从传统深度学习中继承下来的默认设置,但根本不符合语言模型生成文本的方式。

持续批处理(Continuous batching)——也称为迭代级调度(Iteration-level scheduling)或飞行中批处理(In-flight batching)——是解决这一问题的核心机制。它不是一个微调旋钮,而是对推理循环运行方式的架构性改变。在使用相同硬件的情况下,使用该技术的系统与不使用的系统相比,吞吐量可能相差 4–8 倍。

AI 流水线中的投机执行:通过押注未来降低延迟

· 阅读需 13 分钟
Tian Pan
Software Engineer

大多数 LLM 流水线在无意中表现出了令人尴尬的顺序执行特征。一个智能体调用天气 API,等待 300 ms,调用日历 API,再等 300 ms,调用流量 API,再次等待 —— 最后才综合出一个答案。如果这三个调用是并行运行的,那 900 ms 的总延迟本可以缩减到 300 ms。没有人故意将系统设计成顺序执行;这只是在编写一个接一个的异步调用时自然而然产生的结果。

推测执行(Speculative execution)是一系列技术的统称,这些技术通过在你确定需要某些工作之前就提前执行它们,来降低感知的延迟 —— 包括运行并行的假设、预取可能的后续步骤以及同时生成多个候选输出。这些技术直接借鉴了 CPU 设计,自 20 世纪 90 年代以来,处理器就一直在推测性地执行未来的指令。应用到 AI 流水线时,这种本能 —— 押注可能的结果、取消失败者、接受偶然的浪费 —— 可以产生显著的加速。但如果你不小心选择应用时机,协调开销也可能会抵消所有的收益。