使用Jmeter压测Kafka：指标分析、脚本实现与性能调优实践-北京尧图网络

1. 压测目标与方案选型为什么用Jmeter测Kafka1.1 Kafka性能验证的核心指标Kafka这类消息中间件性能测试的重点和普通HTTP接口不太一样。HTTP接口压测关注的是QPS、响应时间和错误率而Kafka压测要看的是一套组合指标写入吞吐量、消费吞吐量、消息端到端时延、分区并发能力以及消费堆积情况。写压测方案之前我先把指标拆清楚了后面所有脚本和参数都是围绕这些指标设计的。这次压测的对象是一个模拟业务的数据接入管道Producer端持续写入用户行为消息Consumer端负责异步消费并落库。选型阶段的目标很明确验证单个Topic在给定分区数下能承受多大的生产压力确认消费端的处理能力会不会成为瓶颈以及消息从发到收的时延能否满足业务要求。实际操作中我主要盯四个指标。第一个是生产吞吐量用每秒发送的消息条数msg/s和每秒写入的数据量MB/s来衡量。第二个是消费吞吐量同样以msg/s为准。第三个是时延重点看平均时延、P95和P99因为业务侧真正关心的是大多数消息能不能在可接受的时间窗口内被消费到。第四个是消费Lag即未消费的消息积压数这个指标能直接反映生产端和消费端的速率匹配情况。1.2 三条技术路线的取舍我第一反应并不是直接拿Jmeter上手而是先翻了翻现成的工具。Kafka官方自带kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh确实能压但它的输出是命令行文本不方便接入团队现有的测试报表。另一种思路是自己写Java或者Go脚本压灵活性高但统计、并发控制、报告展示都要自己造轮子。纠结了一圈最后还是选了Jmeter理由是它已经在我们团队的性能测试体系里跑了很多年压测脚本、报告模板、CI流水线都是现成的我不想为消息队列再维护一套独立工具。确定用Jmeter之后又面临三条技术路线的选择。第一是找现成的第三方插件网上有社区维护的Kafka Sampler插件装起来方便但插件的维护活跃度、功能覆盖范围存在不确定性万一某个参数暴露不全调试起来很被动。第二是JSR223 Sampler配Groovy脚本直接调用Kafka官方客户端库灵活性和可控性都最好这也是我最终采用的方式。第三是Java Request Sampler用Java代码写扩展类性能更好但需要重新编译和打包维护成本偏高。三条路线的取舍我给整理成了下面这张对比表方案优点缺点适用场景第三方Kafka插件开箱即用不需要写脚本版本兼容性不可控功能覆盖有限快速验证不追求深度定制JSR223 kafka-clients灵活能控制客户端全参数便于和Jmeter断言、监听器打通需要管理依赖jar脚本编写有门槛正式压测、深度调优推荐多数团队采用Java Request Sampler执行效率最高逻辑最清晰需要写Java类并编译打包迭代慢有Java开发能力且需要极高性能压测时1.3 测试场景规划指标和工具路线定下来之后就是规划压测场景。我没有一上来就跑极限压力而是按阶梯推进先小并发跑出基线数据再逐步加压观察拐点最后用持续稳定压测验证长时运行的表现。具体的场景矩阵是这样的消息大小分别用512B、1KB、4KB三档并发数从20、50、100到200逐步增加每个场景稳定运行5分钟。acks参数分开测分别用acks0、acks1、acksall对比确认吞吐差异。Compression压缩也单独做了一组对比实验验证开启压缩后对带宽和吞吐的影响。消费者侧的测试场景则围绕分区数展开分别用8分区和16分区的Topic验证消费并行能力。2. 环境准备版本匹配与依赖接入2.1 版本组合与兼容性说明Kafka压测环境里最容易被忽略但又最致命的就是版本兼容性。Jmeter本身是用Java写的Kafka客户端也是Java库但不同版本组合会导致莫名其妙的报错。这次我用的组合是Jmeter 5.6.3、JDK 17、Kafka集群版本3.4.0、Kafka客户端库kafka-clients 3.4.0。版本选择上有一个原则Kafka客户端的版本最好和Broker保持大版本一致或者比Broker略新一点点。Kafka的协议本身做了向后兼容但版本差太多还是会出现字段解析或者Feature探测异常。另外Jmeter的JSR223组件编译Groovy脚本依赖JDK如果Jmeter版本太老在JDK 17下跑会报模块访问错误所以我把Jmeter拉到5.6.3这个版本它在JDK 17下表现很稳定。组件版本说明Jmeter5.6.3支持JDK 17内置Groovy解释器JDK1764位避免大并发下内存分配受限Kafka Broker3.4.0测试集群3节点kafka-clients3.4.0与Broker版本一致Topic分区数8/16做对比测试2.2 把Kafka客户端装进JmeterJmeter本身不包含Kafka客户端所以第一步就是把依赖jar放到Jmeter的lib目录下。注意是lib目录不是lib/ext。lib/ext是放Jmeter插件和Sampler扩展的普通的第三方jar应该放到lib这样Jmeter的类加载器才能在所有线程里访问到。需要准备的依赖包括kafka-clients-3.4.0.jar以及它依赖的几个序列化和压缩库。去Maven中央仓库可以下载到也可以通过本地已有的Maven仓库拷贝。依赖jar列表不太复杂核心是要保证这些库都在lib目录下否则跑到一半就会抛ClassNotFoundException。具体的放置方法很简单把jar下载下来之后解压到Jmeter安装目录下的lib文件夹然后重启Jmeter。重启后验证是否加载成功可以新建一个JSR223 Sampler在Groovy脚本里写一行log.info(org.apache.kafka.clients.producer.KafkaProducer.class.getName())运行时日志里能正常打印类全名就说明类路径没有问题。2.3 测试数据与Topic规划压测数据的构造直接影响脚本的简洁性。消息体我设计成一个JSON字符串包含消息ID、发送时间戳和一个可变长度的payload字段。构造的时候最忌讳每次随机生成长度相差特别大的消息因为吞吐量的分母会被消息大小的波动带偏。为了控制消息大小我用固定长度的填充字符串消息大小基本稳定在指定档位。Topic的创建也提前规划好。用Kafka自带的命令行脚本创建Topic指定8个分区、副本因子1作为基础测试Topic。副本因子为1意味着没有跨副本复制开销适合测出一个集群的裸性能上限。后面做高可用对比时再单独创建一个副本因子为3的Topic。kafka-topics.sh --bootstrap-server 192.168.1.10:9092 \ --create --topic kafka-perf-topic \ --partitions 8 --replication-factor 1Topic命名我用的是kafka-perf-topic简单清晰。压测之前还要确认Topic的min.insync.replicas和retention.ms等参数避免压测过程中因为日志保留时间太短导致数据被提前清理影响消费端拉取数据。3. 生产者压测脚本实现与关键参数调整3.1 JSR223 Sampler封装Producer的正确姿势生产者压测的核心是JSR223 Sampler加上Groovy脚本。但这里有一个大坑网上很多示例脚本在每次采样执行时都new一个KafkaProducer看起来能用实际跑起来会死得很难看。因为KafkaProducer的创建要初始化连接、分配内存、启动后台线程每次请求都创建销毁压力根本没加到Kafka上全耗在客户端初始化和线程切换上了。正确做法是让Producer实例在测试开始前初始化一次所有采样线程复用同一个实例。我利用的是Jmeter的setUp Thread Group它会在普通线程组之前执行正好用来初始化共享资源。把Producer创建脚本放到setUp Thread Group里通过props.put(kafkaProducer, producer)写入Jmeter属性后续JSR223 Sampler直接读取这个属性。import org.apache.kafka.clients.producer.KafkaProducer import java.util.Properties Properties kp new Properties() kp.put(bootstrap.servers, 192.168.1.10:9092,192.168.1.11:9092,192.168.1.12:9092) kp.put(key.serializer, org.apache.kafka.common.serialization.StringSerializer) kp.put(value.serializer, org.apache.kafka.common.serialization.StringSerializer) kp.put(acks, all) kp.put(batch.size, 32768) kp.put(linger.ms, 10) kp.put(compression.type, lz4) kp.put(buffer.memory, 67108864) props.put(kafkaProducer, new KafkaProducer(kp))生产者的消息发送Sampler就简洁多了直接复用Producer实例。这里我建议在生产者和消费者脚本中都加入超时保护和成功标记这样压测报告里的错误率才有参考意义。import org.apache.kafka.clients.producer.KafkaProducer import org.apache.kafka.clients.producer.ProducerRecord import java.util.concurrent.TimeUnit KafkaProducer producer props.get(kafkaProducer) long now System.currentTimeMillis() String payload {\id\: now ,\msgTime\: now ,\payload\:\data_ now \} ProducerRecordString, String record new ProducerRecord(kafka-perf-topic, payload) try { producer.send(record).get(5000, TimeUnit.MILLISECONDS) SampleResult.setResponseData(payload, UTF-8) SampleResult.setSuccessful(true) } catch (Exception e) { SampleResult.setSuccessful(false) SampleResult.setResponseMessage(e.toString()) }这段脚本我选择了future.get()同步等待虽然会让单次请求的耗时比纯异步模式长但能确保每条消息都真正到达Broker并收到确认。用acksall配合这种模式测出来的是端到端可确认吞吐对生产环境更有参考价值。3.2 线程组与压测模型设计线程组的设计决定了压力模型。普通HTTP压测习惯把线程数当成并发用户数但对Kafka来说测试脚本中的线程数更适合理解为Producer客户端的实例数每个线程就是一个发送源。线程太少吞吐量上不去线程太多客户端侧的内存和连接管理开销反而会抢占系统资源。我这次用的是阶梯加压的策略。先创建一个普通的线程组线程数设成20Ramp-Up Period设为30秒循环次数填为无限勾选调度器持续时间设为300秒。这样一个场景就能稳定跑5分钟。后续对比50、100、200并发时直接通过Jmeter属性参数化不用改脚本文件。压测模型还有一个细节要看Jmeter的JSR223 Sampler默认勾选了脚本编译缓存这个勾选必须保持打开。如果不缓存每个采样器每次执行都要重新编译Groovy脚本客户端GC开销巨大压测结果里会掺入大量Jmeter自身开销。实测中我还注意到如果每个Sampler里都要拼大量字符串建议用StringBuilderGroovy的字符串拼接在模板中容易生成大量中间对象影响GC表现。3.3 客户端参数对吞吐量的影响Kafka客户端参数对吞吐的影响聊起来比脚本本身更有价值。我在压测过程中重点调了五个参数每一个都用现场对比验证了效果。acks参数控制的是生产者发送消息后需要等待多少个副本确认。acks0是纯异步发出去就算成功吞吐最高但消息丢失风险大。acks1只等Leader写入成功吞吐和可靠性比较均衡。acksall要等所有ISR副本都确认耗时最长对应吞吐也会打折。实际测试里8分区单副本Topic从acks1切到acksall吞吐大约下降了15%如果副本数为3下降幅度会更明显。batch.size和linger.ms是一对搭档。batch.size控制Producer批量发送的缓冲区大小默认16KB调大到32KB之后单批消息更多网络往返次数变少吞吐有明显提升。linger.ms是消息在缓冲区里等待更多消息加入的时间窗口默认0代表消息立刻发送但TCP层面仍会聚合。调到10毫秒可以显著提高批量效率时延会稍微增加。compression.type我推荐至少用lz4。CPU换带宽这套逻辑在Kafka场景下非常划算。测试数据是1KB的JSON消息开启lz4之后网络流量下降约60%吞吐量提高约20%。如果你的网络带宽是瓶颈压缩几乎是必选项。buffer.memory是Producer内存缓冲区的总大小默认32MB。并发线程多、吞吐要求高时这个值要相应调大否则线程会频繁阻塞等待缓冲区释放。这次压测200并发时我直接调到了64MB。下面这张表是我本地测试环境的实测对照不同环境的绝对值差异会很大但相对趋势可以参考参数组合并发数吞吐量msg/sP99时延msacks1, batch16KB, linger0, 无压缩504200028acks1, batch32KB, linger10, lz4506800019acksall, batch32KB, linger10, lz45056000314. 消费者压测消费速率与端到端时延4.1 消费者的并发边界与脚本实现消费者压测和生产者逻辑上有个本质不同Kafka消费者组里一个分区在同一个时间点只能被组内的一个消费者实例消费。这意味着消费者侧的并发能力被分区数硬性限制住了。如果你启动10个消费者线程但Topic只有8个分区那只有8个线程在干活剩下2个线程空转。因此消费者测试的脚本设计首先要把线程数和分区数对应起来。我先用8分区Topic跑了8个消费者线程后面又专门建了一个16分区Topic做对比测试观察分区数翻倍对消费吞吐的影响。消费者的初始化同样放在setUp Thread Group里创建一个持久的KafkaConsumer实例放到props中缓存。关键配置是enable.auto.commit设为false手动提交位移这样压测过程中不会因为自动提交的偏移量和实际处理进度不一致导致消费重复或丢失。消息消费Sampler每次执行一次poll拉取一批消息然后遍历这批消息解析业务字段统计消息条数和端到端时延。import org.apache.kafka.clients.consumer.KafkaConsumer import org.apache.kafka.clients.consumer.ConsumerRecords import java.time.Duration import java.util.Collections KafkaConsumer consumer props.get(kafkaConsumer) ConsumerRecordsString, String records consumer.poll(Duration.ofMillis(1000)) long msgTime 0 int count records.count() long maxLatency 0 long sumLatency 0 for (record in records) { String value record.value() int start value.indexOf(\msgTime\:) 10 int end value.indexOf(,, start) msgTime Long.parseLong(value.substring(start, end)) long latency System.currentTimeMillis() - msgTime sumLatency latency if (latency maxLatency) { maxLatency latency } } consumer.commitSync() SampleResult.setSuccessful(true) SampleResult.setResponseData(count count , avgLatency (sumLatency / (count 0 ? 1 : count)) , maxLatency maxLatency, UTF-8)这段脚本里我用了字符串截取来代替完整JSON解析就是为了减少处理逻辑对消费性能的影响。解析JSON要额外引入Jackson库或Gson压力侧混入太多解析开销指标就不干净了。4.2 消费Lag与堆积观测消费Lag是消费者压测中比吞吐量更直观的指标。它反映的是Producer已经写入但Consumer还没消费的消息数量。如果Lag持续快速增长说明消费者的处理能力跟不上生产速度消费端就是瓶颈。在压测运行过程中我另外开了一个终端窗口用Kafka自带的命令行工具实时观察订阅组的Lag变化kafka-consumer-groups.sh --bootstrap-server 192.168.1.10:9092 \ --group jmeter-consumer-perf \ --describe输出结果里会显示每个分区的CURRENT-OFFSET、LOG-END-OFFSET和LAG三列。如果每个分区的LAG保持稳定或缓慢漂移说明消费速率和生产速率基本匹配。如果LAG单调递增且增速很快那就必须马上停止压测分析消费端的处理逻辑和设备能力。这里可以顺便提一个技巧Lag观测节奏不需要太高频率10秒刷一次就够了压测环境本身资源紧张频繁跑命令行工具反而抢占CPU。4.3 端到端时延测量方法端到端时延是消息从Producer发送到Consumer接收到之间的时间差。我在Producer侧构造消息时已经在消息体里放入了msgTime字段所以Consumer侧只需要解析这个时间戳并和当前系统时间做差就能得到端到端时延。测量端到端时延有一点值得注意如果生产端和消费端不在同一台机器上两端系统时钟可能不一致直接做差会有误差。我这次压测环境里所有机器都同步过NTP时间所以差值的参考意义足够大。如果你们环境里没法保证时钟同步就要考虑在Broker端记录时间的方式或者接受包含时钟偏差在内的相对时延值。从压测结果来看消息大小为1KB、批次发送开启的情况下端到端平均时延在10到30毫秒左右P95大约50毫秒P99在80毫秒附近。这个值会因为linger.ms从0调到10而增加因为消息在Producer缓冲区内等待批量发送时已经消耗了一部分时间。如果需要极低的时延就牺牲一点吞吐量把linger.ms降回0关闭压缩让消息尽快发出。5. 压测中的典型问题与排查实录5.1 类库冲突NoClassDefFoundError与日志异常第一次跑压测脚本Jmeter界面上的错误就刷了一屏错误类型是NoClassDefFoundError: org/slf4j/LoggerFactory。原因很好定位Kafka客户端依赖slf4j-api但Jmeter自带的日志体系是log4j2没有一个slf4j绑定实现把两者桥接起来。解决方式是确认lib目录下同时存在slf4j-api和对应的log4j2-slf4j-impl桥接包。Jmeter安装目录本身会带一份但版本可能比较旧和kafka-clients的依赖版本不兼容。我把两个包都升级成较新版本后重启问题解决。还有一个类似坑是class path里存在多个版本的kafka-clients。如果你的lib/ext或lib目录下因为历史原因残留了老版本jarJmeter的类加载器会优先加载其中一个导致脚本调用的类方法对不上版本。排查方式是在Jmeter的启动脚本里打开类加载日志或者直接检查lib目录下有无重复的kafka相关jar有就清掉。5.2 连接层面问题超时与元数据拉取失败压测Producer时遇到TimeoutException: Topic kafka-perf-topic not present in metadata after 60000 ms这个报错很典型。它通常意味着三件事bootstrap.servers地址写错了、Broker的advertised.listeners配置不对、或者防火墙挡了端口。我那次排查先确认了bootstrap.servers填的是Broker对外暴露的地址注意不能用localhost因为Broker返回的元数据地址是advertised.listeners里配置的地址如果配置成了内网IP而Jmeter跑在另一台机器上客户端只能连不上。随后我用telnet 192.168.1.10 9092验证了端口连通性确认网络层没阻塞问题就定位在advertised.listeners只监听了Broker本机回环地址改完配置重启Broker之后元数据拉取恢复正常。连接超时还有一个隐蔽原因max.request.size设置过小。如果压测消息设置得非常大比如4KB以上但max.request.size还是默认值1MB单一批次其实不会触发但当batch.size调大后只要生产者发送请求超过这个上限就会报错。建议压测前把max.request.size调到10MB以上留出足够余量。5.3 吞吐量上不去从客户端到集群的排查顺序压测最让人头疼的问题就是吞吐量始终上不去表现是无论怎么加并发吞吐量都稳定在一个低值附近。我总结了一个从客户端到集群的排查顺序每次遇到都是按照这个流程走。先看客户端所在机器的CPU和内存。Jmeter跑压测本身有开销大并发下如果机器只剩单核空闲问题不在Kafka而在压测端。然后用top或jstat观察Jmeter进程的GC频率如果Full GC频繁脚本里对象创建过多或JVM堆太小先调Jmeter的启动参数和解法再谈其他。再看网络。用dstat或者iftop观察压测机到Broker节点的带宽占用。如果带宽跑满就需要开压缩、降低消息大小、或者调整linger.ms让批量更合算。然后是客户端参数按照acks、batch.size、buffer.memory的顺序逐一调优先确认不是Producer配置不合理导致的限流。最后才查Broker侧。查看Kafka的JMX监控中的BytesInPerSec和RequestsPerSec确认Broker实际接收的流量是多少。如果Broker侧接收量正常但Jmeter吞吐低问题肯定出在客户端沿线如果Broker侧接收量本身就低就要检查磁盘IO、分区Leader是否均衡、CPU中断是否打满。5.4 压测结果波动大的常见干扰因素结果波动大的时候八成不是Kafka突然变慢而是测试环境里混入了干扰因素。最典型的是Kafka集群中某个Broker节点状态异常导致分区的Leader集中在少数节点上吞吐量就被拖后腿了。排查方法是用Kafka的kafka-topics.sh --describe看分区Leader分布如果明显不均衡优先检查那个节点是不是磁盘或CPU过热。还有一个干扰源是日志清理线程。Kafka的日志分段删除和压缩清理会消耗IO资源在压测过程中如果恰好触发吞吐曲线会突然出现周期性下跌。规避方式是在压测前用kafka-configs.sh把Topic的cleanup.policy设为delete并且把retention.ms设置为足够大的值让压测期间内容不触发清理任务。Jmeter自身的状态也要关注。如果压测机磁盘写满了Jmeter日志没法继续写最终结果文件会缺数据。我建议压测前检查压测机的剩余磁盘空间至少留出10GB以上。6. 结果分析与工程化落地建议6.1 聚合报告怎么读指标如何对齐Jmeter的聚合报告监听器最简单也最实用。运行完压测后在结果树里添加聚合报告就能直接看到每个Sampler的吞吐量、平均耗时、中位数、P90、P95和P99。但与HTTP场景不同Kafka压测里不能只看吞吐量的绝对值要把生产者和消费者的数据对齐来看。具体操作上我习惯把同一个场景下的Producer端吞吐量、Consumer端吞吐量、消费者Lag和端到端时延四组数据放在同一个表里分析。如果Producer吞吐远高于Consumer说明必须增加消费者实例或分区数如果两者接近而时延仍然很高重点看批次发送参数和网络延迟。注意聚合报告里显示的响应时间是Sampler执行一次的耗时。生产者Sampler执行一次对应一条消息的发送完成消费者Sampler执行一次对应一次poll操作周期是1秒。所以消费者侧的Throughput单位已经通过count字段体现不能简单和Producer的Throughput直接比较。6.2 Topic分区数与副本因子对性能的影响分区数是Kafka性能调优最重要的杠杆。我专门用8分区和16分区同样的Topic做了一组对比在生产者并发50、消息大小1KB的条件下16分区比8分区的吞吐量提升了接近70%。原因是分区增加后Broker节点之间的写入请求并行度提高了Producer可以同时往更多分区发送数据。但分区数也不是越多越好。分区太多会带来大量的Broker端元数据管理开销和文件句柄占用消费组重平衡时间也变长。8到16分区在测试环境里表现最好如果你的业务明确会有大量并行消费者再考虑更高分区数。副本因子的影响集中在写入确认链路。副本因子为1时Leader写完本地日志就可以向Producer返回确认吞吐最高。副本因子为3时每次写入都要同步到至少两个副本节点多出的网络传输和磁盘IO直接转化为时延和吞吐开销。实测中acksall配合副本因子3比副本因子1的吞吐下降了约30%。生产环境为了数据安全必须保留副本压测时建议分别测出两种配置下的性能上限方便后续容量规划时做权衡。6.3 把压测脚本接入CI与回归体系最后一步是把这套压测脚本从本机运行迁移到团队CI流水线里。Jmeter天然支持命令行无界面模式配合用户自定义属性可以在不修改脚本的前提下传入不同环境参数。jmeter -n -t ./jmx/kafka-producer-perf.jmx \ -Jbootstrap.servers192.168.1.10:9092 \ -Jtopickafka-perf-topic \ -Jthreads50 \ -Jduration300 \ -l ./results/kafka-producer-result.jtl \ -e -o ./results/html脚本内部可以通过Jmeter属性读取这些参数比如props.get(topic)这样同一个jmx文件既可以在开发环境跑冒烟也可以在预发环境跑全量压测。CI流水线里把这条命令串进构建任务产物是执行完自动生成的HTML报告团队其他成员直接打开浏览器就能看结果。为了做回归对比我会把每次压测的关键指标存成一份JSON文件提交到一个专门的结果目录里。下次CI跑完用脚本自动对比本次和上一次的吞吐量、P99时延如果下降超过10%直接在流水线里标红拦住。这套流程跑下来消息链路的性能退化就能在发布前被发现。我个人在实际操作中的体会是Kafka压测的思路和HTTP压测差异非常大最重要的不是把TPS刷得多高而是理解分区、副本、批量发送这些机制对指标的耦合影响。前期把指标体系和版本兼容性想清楚后面其实就是不断调整客户端参数、观察系统表现、再把结论沉淀成回归用例的循环。这套东西跑顺了之后以后不管是新Topic上线还是集群扩容都有了一套可以快速复用的验证手段比每次临时抱佛脚强太多。

使用Jmeter压测Kafka：指标分析、脚本实现与性能调优实践

相关推荐

AI Agent 浏览器自动化工具：agent-browser 的 Chromium CLI 配置与验证

Coze智能体工作流：1分钟生成修仙短视频的完整指南

DLL文件丢失别去“免费下载”了，用系统自带修复工具更安全

更多资讯

GET与POST发送普通参数全解析：编码、Content-Type与联调避坑

AI写学术专著靠谱吗？从工具横评到高效流程的完整攻略

Python65：核心语法-函数进阶-默认参数

Excel/WPS 里像写公式一样查 A 股行情：free-stockdb STOCK_DATA 宏快速上手指南

DeepSeek-V3-0324 本地加载实战：从 685B 权重到推理跑通

WebSocket群聊架构实战：握手鉴权、消息广播与断线重连

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？