标签： streaming

发布于

Speculative Streaming：在流式传输中利用Draft Model并行生成并验证多个Token

Speculative Streaming：在流式传输中利用Draft Model并行生成并验证多个Token 大家好，今天我们要讨论一个令人兴奋的话题：Speculative Streaming。它旨在通过并行生成和验证多个token，来提升流式传输场景下大型语言模型（LLM）的推理速度。这个技术的核心思想是利用一个较小的、速度更快的“Draft Model”（也称为“提案模型”或“辅助模型”）来并行生成多个候选token，然后使用更大的、更准确的“Verification Model”（验证模型，通常就是我们想要使用的LLM）来验证这些候选token，从而在保证生成质量的前提下加速推理过程。 1. 背景：流式传输的挑战与机遇 在深入Speculative Streaming之前，我们首先需要了解流式传输（Streaming）的背景以及它带来的挑战。流式传输指的是模型在生成token时，可以立即将已生成的token输出，而不需要等待整个序列生成完毕。这种方式对于实时应用，例如对话机器人、实时翻译、代码补全等，至关重要。 然而，流式传输也面临着一些挑战： 延迟问题： 传统的自回归生成方 …

继续阅读“Speculative Streaming：在流式传输中利用Draft Model并行生成并验证多个Token”

发布于

OpenJDK JFR Streaming API实时事件订阅告警：RecordingStream与jfr tool

OpenJDK JFR Streaming API实时事件订阅告警：RecordingStream与jfr tool 大家好，今天我们来深入探讨OpenJDK Flight Recorder (JFR) 的Streaming API，以及如何利用它实现实时事件订阅告警。我们将对比RecordingStream和传统的jfr tool方式，并展示如何构建一个实时监控系统，并结合实际代码示例，逐步讲解实现过程。 JFR 简介 OpenJDK Flight Recorder (JFR) 是一个低开销的分析和诊断工具，内置于HotSpot JVM中。它可以记录JVM运行时的各种事件，如CPU使用率、内存分配、垃圾回收、锁竞争等。这些数据可以帮助我们分析应用程序的性能瓶颈，诊断问题，并进行优化。 JFR有两种使用方式： 基于文件的录制 (File-based Recording): 将事件数据写入磁盘文件（.jfr），然后使用jfr tool或者Java Mission Control (JMC) 等工具进行分析。 流式录制 (Streaming Recording): 通过JFR Stream …

继续阅读“OpenJDK JFR Streaming API实时事件订阅告警：RecordingStream与jfr tool”

发布于

MyBatis的ResultHandler：实现流式查询（Streaming Query）的内存优化

MyBatis ResultHandler：流式查询的内存优化之道 大家好，今天我们来深入探讨 MyBatis 中的 ResultHandler 接口，以及如何利用它实现流式查询，从而优化大型数据集查询时的内存占用。在处理海量数据时，一次性加载所有数据到内存中往往会导致 OutOfMemoryError。而流式查询允许我们逐行处理数据，无需一次性加载整个结果集，这对于内存资源有限的系统来说至关重要。 1. 什么是 ResultHandler？ ResultHandler 是 MyBatis 提供的接口，用于处理查询结果的每一行数据。它允许我们在 MyBatis 完成 SQL 查询后，逐行接收查询结果，并对每一行数据进行自定义处理。这与默认的将整个结果集加载到 List 中的方式截然不同。 ResultHandler 接口的定义非常简单： public interface ResultHandler<T> { void handleResult(ResultContext<? extends T> resultContext); } 其中： T 是结果集中每一行数 …

继续阅读“MyBatis的ResultHandler：实现流式查询（Streaming Query）的内存优化”

发布于

MyBatis的ResultHandler：实现流式查询（Streaming Query）的内存优化

MyBatis ResultHandler：流式查询的内存优化之道 各位好，今天我们来聊聊 MyBatis 中一个非常重要的特性：ResultHandler。 准确地说，是利用 ResultHandler 实现流式查询，从而优化内存使用，解决大数据量查询时可能遇到的内存溢出问题。 1. 为什么要流式查询？内存溢出的威胁 在传统的数据库查询中，MyBatis 会一次性将所有结果集加载到内存中，然后映射成 Java 对象列表返回给调用方。这种方式对于小数据量来说自然没有问题，简单高效。但是，当查询结果集非常庞大，例如几百万甚至几千万行数据时，问题就来了。 试想一下，如果一条记录映射成 Java 对象后占用 1KB 内存，那么 100 万条记录就需要 1GB 内存。如果你的 JVM 分配的堆内存不足以容纳这些数据，就会抛出臭名昭著的 OutOfMemoryError 异常，导致程序崩溃。 这就是内存溢出的威胁。为了避免这种问题，我们需要一种能够逐条处理结果集，而不是一次性加载所有数据的机制。这就是流式查询的意义所在。 2. ResultHandler：逐行处理结果的利器 MyBatis 提供 …

继续阅读“MyBatis的ResultHandler：实现流式查询（Streaming Query）的内存优化”

发布于

MyBatis的ResultHandler：实现流式查询（Streaming Query）的内存优化

MyBatis ResultHandler：流式查询的内存优化之道 大家好，今天我们来聊聊MyBatis中一个非常有用的特性：ResultHandler，以及如何利用它来实现流式查询，从而优化内存使用。尤其是在处理大量数据时，这种优化显得尤为重要。 1. 为什么需要流式查询？ 在传统的数据库查询中，MyBatis通常会将查询结果一次性加载到内存中。这对于小规模的数据集来说没有问题，但当数据量非常庞大时，一次性加载会导致内存溢出（OutOfMemoryError），甚至拖垮整个应用。想象一下，你要从一个包含几百万行数据的表中查询数据，如果一次性将所有数据加载到内存，那将消耗大量的资源，效率也极其低下。 流式查询则提供了一种更优雅的解决方案。它允许我们逐行处理查询结果，而不是一次性加载所有数据。这样，内存中始终只保留当前正在处理的数据行，从而大大降低了内存消耗。 2. ResultHandler：流式查询的核心 MyBatis的ResultHandler接口正是实现流式查询的关键。它允许我们自定义如何处理查询结果的每一行。我们可以将ResultHandler传递给MyBatis的查询方法， …

继续阅读“MyBatis的ResultHandler：实现流式查询（Streaming Query）的内存优化”

发布于

gRPC 流式 RPC (Streaming RPC) 在 gRPC-Web 中如何实现？如何对其进行流量分析？

各位朋友们，晚上好！我是你们的老朋友，今天咱们来聊聊一个挺有意思的话题：gRPC 流式 RPC 在 gRPC-Web 中的实现以及流量分析。保证让大家听得懂，学得会，还能拿出去吹吹牛皮！ 开场白：gRPC-Web 的“流”言蜚语 话说，gRPC 这玩意儿，效率高，协议紧凑，简直是微服务的标配。但是，浏览器可不认这套“二进制”的规矩，它就喜欢 HTTP/1.1，外加 JSON。于是乎，gRPC-Web 应运而生，它就像一个翻译官，把 gRPC 的协议翻译成浏览器能懂的 HTTP/1.1 + Protobuf。 但是，问题来了，gRPC 有流式 RPC，这可是它的一个重要特性，可以让服务器源源不断地推送数据，或者客户端源源不断地上传数据。在 gRPC-Web 里，这“流”怎么玩？别急，咱们一步步来。 第一幕：gRPC 流式 RPC 的三种姿势 首先，咱们得搞清楚 gRPC 流式 RPC 有哪几种类型。简单来说，有三种： 服务器端流式 RPC (Server Streaming RPC)：客户端发一个请求，服务器像瀑布一样，哗啦啦地返回一堆数据。 客户端流式 RPC (Client Stre …

继续阅读“gRPC 流式 RPC (Streaming RPC) 在 gRPC-Web 中如何实现？如何对其进行流量分析？”

发布于

JS `Streaming SSR`：渐进式渲染与更快的首屏内容

各位观众老爷，大家好！我是你们的老朋友，今天咱来聊聊一个听起来高端大气上档次，实际上原理简单易懂的东西——JS Streaming SSR，也就是流式SSR。 什么？你说你已经听说过SSR了？那敢情好，省的我从头开始科普了。不过，普通的SSR和Streaming SSR，那可不是一回事儿。就好比都是吃饭，一个是大锅饭，一个自助餐，想吃啥拿啥，效率杠杠的！ 传统的SSR的痛点 先来回顾一下传统的SSR。简单来说，就是服务器把整个页面都渲染好，然后一股脑儿地发给浏览器。 问题一：TTFB（Time To First Byte）太长。服务器得吭哧吭哧地把所有数据都准备好，然后才能开始发送，这段时间用户只能干瞪眼。 问题二：阻塞渲染。浏览器收到完整的HTML后才能开始解析，然后才能渲染页面，用户体验大打折扣。 想象一下，你点了个外卖，商家非得把所有菜都炒好，装盒，打包，再送到你手里，等你饿得前胸贴后背了，才能吃上一口热乎饭。 Streaming SSR：化整为零，逐段发送 Streaming SSR的核心思想就是：化整为零，逐段发送。服务器不再等待整个页面渲染完成，而是将页面分成多个小块，渲染 …

继续阅读“JS `Streaming SSR`：渐进式渲染与更快的首屏内容”

发布于

Spark Structured Streaming 的 Exactly-Once 语义实现：Checkpointing 与 Offset Management

好的，各位观众老爷们，欢迎来到 “Spark Structured Streaming 的 Exactly-Once 语义实现：Checkpointing 与 Offset Management” 专题讲座。我是你们的老朋友，今天就让我带着大家，拨开云雾见青天，彻底搞懂这看似高深莫测的“Exactly-Once”语义！ 开场白：一场关于“恰好一次”的执念 想象一下，你是一位银行柜员，负责处理用户的存款业务。用户辛辛苦苦攒了一年的血汗钱，存入银行，你总不能告诉人家：“哎呀，系统有点问题，钱可能存进去了，也可能没存进去，要不您明天再来碰碰运气？” ? 这种“At-Least-Once”（至少一次）或者“At-Most-Once”（至多一次）的语义，在某些场景下简直就是灾难！我们追求的是什么？是“Exactly-Once”（恰好一次）！就像你每天早上起床，必须恰好刷一次牙，少刷了不舒服，多刷了牙龈受罪。 在流式处理的世界里，Exactly-Once 的重要性更是毋庸置疑。试想一下，如果你的电商平台在统计用户点击量时，一会儿多统计了几次，一会儿又漏掉了几次，那报表还有什么意义？老板看了直接让你 …

继续阅读“Spark Structured Streaming 的 Exactly-Once 语义实现：Checkpointing 与 Offset Management”

发布于

Spark Streaming：构建实时流处理应用的实践指南

Spark Streaming：构建实时流处理应用的实践指南 各位观众老爷们，大家好！我是你们的老朋友，江湖人称“代码诗人”的程序猿老王。今天，咱们不聊风花雪月，也不谈人生理想，咱们来聊点硬核的——Spark Streaming！? 别听到“实时流处理”就觉得高深莫测，仿佛只有科学家才能驾驭。其实，只要掌握了正确的方法，你也能像武侠小说里的主角一样，挥舞着代码，在数据的洪流中游刃有余，笑傲江湖！ 今天，老王就来给大家带来一份“Spark Streaming：构建实时流处理应用的实践指南”，保证通俗易懂，幽默风趣，让你在欢声笑语中学到真功夫！? 一、什么是Spark Streaming？—— 别被名字吓到，它就是个“数据管道工” 首先，咱们得搞明白，什么是Spark Streaming？ 简单来说，它就是一个数据管道工！ 想象一下，你家自来水管，源源不断地输送着水。 Spark Streaming 也一样，它负责接收源源不断的数据流，然后对这些数据进行处理、分析，最终把结果输出到你想要的地方。 官方的解释嘛，Spark Streaming 是 Apache Spark 的一个扩展，用于处 …

继续阅读“Spark Streaming：构建实时流处理应用的实践指南”