SQLite 默认未开启 WAL ，这会显著限制并发性能。 PlanTodo 是一个计划管理软件，最近我为它的同步服务编写了性能测试，经过实测，仅开启 WAL 就让同步服务的吞吐量便提升至原来的 3 倍， 其实关于 SQLite 性能优化的文章早有珠玉在前，比如 Optimal SQLite settings for Django 和 Optimizing SQLite for servers ，所以本篇文章并没有独创性，只是为了让更多人了解 SQLite 的 性能 以及分享一个真实的性能 测试用例 。 PlanTodo 同步服务性能测试 性能测试分为三个： oo_upload (one user, one device for a user, only upload) ，就是一个用户一台设备仅上传 oo_download 就是仅下载 oo_cross 是上传和下载交错进行 oo_upload 和 oo_download 是为了查看上传和下载场景下的极限性能，是为了将来专门优化时用来参考的。而 oo_cross 则较为贴近真实使用场景：用户的某个设备上传几个更新，另一个设备被触发下载；因此可以拿它计算服务器能承受的用户量。 如果你不想看下面具体的测试数据，这里简单展示了吞吐量的变化： oo_upload ，18027 -> 61682 ，是原来的 3.42 倍 oo_download ，17082 -> 49635 ，是原来的 2.90 倍 oo_cross ，17085 -> 44203 ，是原来的 2.58 倍 一般查询是比写入要快的，因此下载应该比上传快，但 PlanTodo 的同步服务却反了过来，说明有很大的优化空间。 下面是开启 WAL 前的测试数据： + just -f services/sync/justfile headless_oo_upload --less-output ============================================================ Performance Summary for test_oo_upload ============================================================ Requests : 18,027 Failures : 0 Failure Rate : 0.00% Average RT : 78.14 ms P50 : 78 ms P95 : 110 ms P99 : 130 ms Max : 272.81 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=18,011 Avg=78.1ms P95=110ms P99=130ms Max=272.8ms POST /v1/clients Requests=8 Avg=76.2ms P95=110ms P99=110ms Max=109.9ms GET /v1/sync/full Requests=8 Avg=57.2ms P95=120ms P99=120ms Max=120.3ms + just -f services/sync/justfile headless_oo_download --less-output ============================================================ Performance Summary for test_oo_download ============================================================ Requests : 17,082 Failures : 0 Failure Rate : 0.00% Average RT : 82.63 ms P50 : 82 ms P95 : 110 ms P99 : 130 ms Max : 370.33 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=16 Avg=172.6ms P95=370ms P99=370ms Max=370.3ms GET /v1/sync/delta?cursor=1780662404990&limit=100 Requests=2,087 Avg=83.4ms P95=110ms P99=130ms Max=316.1ms GET /v1/sync/delta?cursor=1780662403978&limit=100 Requests=2,102 Avg=83.3ms P95=110ms P99=130ms Max=325.5ms + just -f services/sync/justfile headless_oo_cross --less-output ============================================================ Performance Summary for test_oo_cross ============================================================ Requests : 17,085 Failures : 0 Failure Rate : 0.00% Average RT : 83.05 ms P50 : 82 ms P95 : 120 ms P99 : 150 ms Max : 245.89 ms Endpoints ------------------------------------------------------------ GET /v1/sync/delta?cursor=1780662760888&limit=100 Requests=1 Avg=245.9ms P95=250ms P99=250ms Max=245.9ms GET /v1/sync/delta?cursor=1780662760900&limit=100 Requests=1 Avg=245.4ms P95=250ms P99=250ms Max=245.4ms GET /v1/sync/delta?cursor=1780662758760&limit=100 Requests=1 Avg=228.2ms P95=230ms P99=230ms Max=228.2ms 下面是 开启 WAL 之后 的测试数据： + just -f services/sync/justfile headless_oo_upload --less-output ============================================================ Performance Summary for test_oo_upload ============================================================ Requests : 61,682 Failures : 0 Failure Rate : 0.00% Average RT : 22.30 ms P50 : 22 ms P95 : 32 ms P99 : 41 ms Max : 74.82 ms Endpoints ------------------------------------------------------------ POST /v1/clients Requests=8 Avg=33.8ms P95=48ms P99=48ms Max=48.1ms POST /v1/sync/delta Requests=61,666 Avg=22.3ms P95=32ms P99=41ms Max=74.8ms GET /v1/sync/full Requests=8 Avg=20.7ms P95=32ms P99=32ms Max=32.5ms + just -f services/sync/justfile headless_oo_download --less-output ============================================================ Performance Summary for test_oo_download ============================================================ Requests : 49,635 Failures : 0 Failure Rate : 0.00% Average RT : 28.03 ms P50 : 28 ms P95 : 38 ms P99 : 46 ms Max : 305.64 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=16 Avg=127.0ms P95=310ms P99=310ms Max=305.6ms GET /v1/sync/delta?cursor=1780663066610&limit=100 Requests=6,109 Avg=28.4ms P95=38ms P99=46ms Max=246.0ms GET /v1/sync/delta?cursor=1780663068640&limit=100 Requests=6,064 Avg=28.3ms P95=38ms P99=46ms Max=95.8ms + just -f services/sync/justfile headless_oo_cross --less-output ============================================================ Performance Summary for test_oo_cross ============================================================ Requests : 44,203 Failures : 0 Failure Rate : 0.00% Average RT : 31.80 ms P50 : 28 ms P95 : 45 ms P99 : 150 ms Max : 477.37 ms Endpoints ------------------------------------------------------------ GET /v1/sync/delta?cursor=1780663421960&limit=100 Requests=1 Avg=477.4ms P95=480ms P99=480ms Max=477.4ms GET /v1/sync/delta?cursor=1780663421963&limit=100 Requests=1 Avg=475.9ms P95=480ms P99=480ms Max=475.9ms GET /v1/sync/delta?cursor=1780663421966&limit=100 Requests=1 Avg=475.4ms P95=480ms P99=480ms Max=475.4ms 每个测试只持续了 3 min ，因此数据量很小，在大数据量的情况下，性能可能会下降很多，这个会在将来补充。 在测试 oo_cross 里，3min 处理了 44203 个请求，也就是一秒 245 个。测试其实是不断在重复先上传再下载，而客户端也是上传下载成对出现，因此一秒能处理 122 （ 245 / 2 ）台设备的请求，即便因为多用户、多设备带来的其他压力，至少能稳定在一秒 100 个请求。 考虑到，真实使用下，平均要几分钟到十几分钟才会更新一次内容，取 10 分钟一次的话，一个同步服务极限下能支撑 100 x 60 x 10 ，6 万个设备正常使用。 如何开启 WAL 不管是什么 ORM ，开启的方式都是一样的，就是在连接数据库后，执行一次 PRAGMA journal_mode=WAL 。 开启了 WAL 后，在原本的 SQLite 数据库文件那里，会多出两个 .db-shm 、 .db-wal 的文件，可以以此判断是否成功开启。 SQLAlchemy from sqlalchemy import create_engine, event engine = create_engine( DATABASE_URL, echo=False, connect_args={ "timeout": 5, }, ) if engine.dialect.name == "sqlite": @event.listens_for(engine, "connect") def set_sqlite_pragma(dbapi_connection, _): cursor = dbapi_connection.cursor() # cursor.execute("PRAGMA foreign_keys=ON") cursor.execute("PRAGMA journal_mode=WAL") cursor.execute("PRAGMA synchronous=NORMAL") cursor.execute("PRAGMA temp_store=MEMORY") cursor.execute("PRAGMA cache_size=2000") cursor.execute("PRAGMA mmap_size=134217728") cursor.close() PlanTodo 的同步服务就是使用 FastAPI + SQLAlchemy 开发的。由于同步服务的特殊性，这里没有开启外键约束。 Django 在项目的 settings.py 文件里，添加 init_command： DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": BASE_DIR / "db.sqlite3", "OPTIONS": { "init_command": ( "PRAGMA foreign_keys = ON;" "PRAGMA journal_mode = WAL;" "PRAGMA synchronous = NORMAL;" "PRAGMA busy_timeout = 5000;" "PRAGMA temp_store = MEMORY;" "PRAGMA cache_size = 2000;" "PRAGMA mmap_size = 134217728;" ), }, } } drift 在数据库类的 migration get 方法里，在 beforeOpen 这个回调里增加执行命令： class PtdDatabase extends _$PtdDatabase { // 省略无关代码 @override MigrationStrategy get migration { return MigrationStrategy( beforeOpen: (details) async { // 在每次打开数据库，正式使用之前，执行的命令 await customStatement('PRAGMA journal_mode = WAL'); await customStatement('PRAGMA synchronous = NORMAL'); await customStatement('PRAGMA busy_timeout = 5000'); await customStatement('PRAGMA temp_store = MEMORY'); await customStatement('PRAGMA cache_size = -2000'); }, ); } } 原文链接： https://yanh.tech/2026/06/sqlite-performance-optimization/ 版权声明：本博客所有文章除特別声明外，均为 AhFei 原创，采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 技焉洲 (yanh.tech) 。
Mellum2是一个120亿参数的模型，专为解决生产AI中的延迟、吞吐量和成本这三大最棘手的挑战而设计，架构与性能如下： 混合专家 (MoE) 设计： 模型共有 120 亿参数，但由于其采用 MoE 设计，每个 token 仅有 25 亿参数处于激活状态。此设计在降低计算成本的同时，可以对实时工作负载进行高吞吐量、低延迟推理。 专属侧重点：与很多现代模型不同，Mellum2 并非多模态模型， 它专门针对自然语言与代码数据进行训练。这种专门化可以确保模型在软件工程环境中表现出色，同时保持轻量和高速。 在 技术报告 中，详细介绍了模型在代码生成、科学、数学和推理基准测试中的表现。Mellum2 在与同规模模型的竞争中不落下风，同时将推理时间缩短至不到一半，这对生产级部署来说是一项决定性优势。 Mellum2 的主要使用场景： 路由和编排 AI 工作负载：使用 Mellum2 分析传入提示，帮助为每项任务选择合适的模型或工具。 构建低延迟 RAG 流水线：检索相关上下文、使用 Mellum2 进行总结，并即时生成回答。 为复杂工作流中的快速子智能体提供支持：将智能体流水线拆分为多个步骤，例如上下文收集、规划和验证。使用 Mellum2 执行快速、专门的任务，而不依赖于单个大模型。 实现私有、本地 AI 部署：在本地运行 Mellum2 或进行自托管，以确保代码和数据完全在您的掌控之中。 文章来源： JetBrains公众号 模型下载： Hugging Face 3 个帖子 - 2 位参与者 阅读完整话题
有H200的机子部署算力，想调查一下大家每天用多少算力，做个吞吐量预算 当然L站到时会有福利 这个贴会违规吗？知道的佬友提醒一下 12 个帖子 - 11 位参与者 阅读完整话题
据说吞吐量能达到 400 。但目前好像只对企业用户开放 https://mp.weixin.qq.com/s/TAVXB_Xuys7_R-SG4oFhOA 智谱AI开放文档 GLM-5.1-HighSpeed - 智谱AI开放文档 4 个帖子 - 4 位参与者 阅读完整话题
IT之家 4 月 29 日消息，当地时间 4 月 28 日，英伟达宣布推出名为 Nemotron 3 Nano Omni 的开源全模态推理模型，旨在为企业级 AI Agent 提供一体化基础模型底座。 据介绍，这是一款将视频、音频、图像和文本的统一多模态推理集成于单个高效开放模型中的产品。该模型旨在替代智能体系统中常见的碎片化视觉-语音-语言模型链，从而减少推理跳数与编排复杂度，降低推理成本，同时增强跨模态上下文一致性。 Nemotron 3 Nano Omni 可在智能体系统中充当多模态感知与上下文子 Agent，使智能体能够在单个共享的“感知-行动”循环中处理视觉、音频和文本输入，提升收敛速度，降低编排复杂度和推理成本。 在文档智能榜单（如 MMlongbench-Doc 和 OCRBenchV2）上，该模型取得了同类领先的准确率；同时在视频与音频理解基准（WorldSense、DailyOmni、VoiceBench）中也表现优异。 行业基准 MediaPerf（基于真实媒体数据和生成任务评估视频理解模型的性能、成本和吞吐量）显示，Nemotron 3 Nano Omni 在所有任务上实现了最高吞吐量，且视频级标注的推理成本最低。 ▲ 在固定的用户交互阈值下，各模型所能维持的总系统吞吐量 该模型基于 30B‑A3B 混合专家（MoE）架构，可根据任务和模态进行激活，实现高吞吐量与可扩展的多模态性能。IT之家注意到，其模型权重、数据集和训练配方完全开放，开发者可在本地、云端或企业环境中定制、部署和集成多模态子 Agent。 英伟达表示，在固定交互延迟阈值下，Nemotron 3 Nano Omni 在视频推理任务中可持续提供更高的聚合吞吐量，相比其他开放式全模态模型有效系统容量最高提升约 9.2 倍；在多文档推理任务中，有效系统容量最高提升约 7.4 倍。在 Blackwell GPU 上采用 NVFP4 量化时，该模型在处理复杂文档、长时推理和大批量视频的企业级工作负载中，吞吐量在开放式全模态模型中居于领先。 架构设计方面，Nemotron 3 Nano Omni 核心为混合 MoE，结合 Mamba 层（提升序列与内存效率）和 Transformer 层（实现精准推理），内存和计算效率最高可提升 4 倍。 视觉处理方面，它采用 3D 卷积捕捉帧间运动，推理时通过高效视频采样层将高密度视觉 token 压缩为 LLM 可处理的精简集合；音频部分则基于 NVIDIA Parakeet 编码器与专用数据集；文本部分以强大的文本模型作为中心解码器，保留基础模型的语言能力；视觉编码采用 C-RADIOv4-H，支持高分辨率图像与 OCR 精度。 其训练方法涵盖适配器与编码器训练（约 1270 亿跨模态 token）、多阶段监督微调及后监督强化学习（超过 230 万次环境 rollout）。该模型权重已在 Hugging Face 上提供，并即将作为 NVIDIA NIM 微服务上线。英伟达还开放了完整的端到端训练与评估配方、部署指南、微调食谱以及开放数据集。
IT之家 4 月 14 日消息，远江盛邦安全科技集团股份有限公司宣布其链路加密网关（RayHLink）正式获得商用密码产品认证证书，拥有国密原生支持、超高吞吐、极低时延等核心优势，打破行业“安全与速度不可兼得”的魔咒。 IT之家注：加密网关是一种安全设备，会在数据离开内部网络（如内网、数据中心）传输至外部时，自动对其进行加密、身份认证与访问控制，形成一道安全“闸门”，但加解密等操作会造成数据访问延缓等问题。 据介绍，商用密码产品认证是国家对密码产品安全性、合规性的认可，更是产品进入政务、金融、能源、算力网络等关键领域的核心准入门槛，能否获得认证直接决定产品能否满足行业密评落地要求。 这是 200G 吞吐量商密产品首次获得该证书，标志着产品全维度符合国家商用密码标准规范，完美适配各行业商用密码应用安全性评估要求。 据介绍，这款产品深度适配 SM2、SM3、SM4 等国密算法，可选配国际通用算法，实现国密算法和国际算法的超高速硬件并行处理，核心算法与 CPU+FPGA 全国产化异构架构 100% 自主可控，从根源上杜绝技术后门；产品支持 X.509 证书管理、外部工作密钥接收、策略集中管控，让国密应用更灵活、更易管。 在核心性能上，这款产品经中国信通院泰尔实验室权威检测，整机实现 200Gbps 明通吞吐、195Gbps 加密吞吐，单口加密速率达 97.68Gbps，逼近 100G 网络线速极限，吞吐量较传统方案提升 5 倍；加密时延平均低于 3 微秒，64 字节小包时延仅 1.128 微秒，较传统方案性能缩短 300 倍。 另外，这款产品在合规与性能双优的基础上还支持 IP 层明通 / 密通灵活切换、SNMP 远程监控，可完美适配“东数西算”跨域算力调度、智算中心 AI 训练、卫星互联网高通量传输、金融高频交易等各类严苛场景。
36氪获悉，交通运输部发布6月1日—6月7日全国物流保通保畅运行情况。国家铁路运输货物8006.6万吨，环比下降0.04%；全国高速公路货车通行5434.9万辆，环比下降1.85%；监测港口完成货物吞吐量25870.5万吨，环比下降7.96%，完成集装箱吞吐量672.7万标箱，环比下降3.65%；民航保障航班10.7万班（其中货运航班5137班，包括国际货运航班3373班，国内货运航班1764班），环比下降3.1%；邮政快递揽收量约43.24亿件，环比下降1.5%；投递量约42.87亿件，环比下降2.37%。
36氪获悉，海南机场公告，2026年4月公司旗下控股7家及管理输出2家机场起降架次28819架次，同比增长4.63%；旅客吞吐量419.65万人次，同比增长4.77%；货邮吞吐量34958吨，同比增长8.56%。累计起降架次13.37万架次，同比增长2.22%；累计旅客吞吐量2119.06万人次，同比增长5.09%；累计货邮吞吐量14.98万吨，同比增长10.90%。
36氪获悉，白云机场公告，2026年4月旅客吞吐量712.58万人次，同比增长6.94%；货邮吞吐量20.08万吨，同比增长0.76%。
36氪获悉，宁波港公告，2026年4月份，公司预计完成集装箱吞吐量456.42万标准箱，同比增长6.85%；预计完成货物吞吐量9650万吨，同比下降7.16%。
36氪获悉，上港集团公告，2026年4月份，公司预计完成母港集装箱吞吐量485.3万标准箱，同比增长7.8%；预计完成母港货物吞吐量5225.7万吨，同比增长2.3%。