/tags/benchmark/ Recent content in Benchmark on Hugo -- gohugo.io en Sun, 19 Apr 2026 02:00:00 +0800 /posts/omlx-gemma4-m5-optimization/ Sun, 19 Apr 2026 02:00:00 +0800 /posts/omlx-gemma4-m5-optimization/ 实验结果 (M5 / 32GB RAM) 测试模型：Gemma4-26B-A4B-it-nvfp4（4-bit 量化，激活权重 ~3.85GB）。 场景 基线 调优后 提升 瓶颈分析 短文本生成 (256 tok) 38.18 tok/s 39.75 tok/s +4.1% 带宽瓶颈：已达硬件理论极限 长文本重复查询 (11k tok) 14.59s 2.27s +540% IO 瓶颈：Hot Cache 消除磁盘加载 瓶颈逻辑：为什么我把 39.7 tok/s 当作接近上限的参考值？ Decode 阶段性能由内存带宽决定：每生成一个 token，都要把激活权重从内存完整读一遍。 MoE 激活：Gemma4-26B-A4B 单步仅激活 4B 专家参数，约 3.85 GB（nvfp4 量化后）。 硬件带宽：M5 标准版 153 GB/s。 理论上限：153 GB/s ÷ 3.85 GB ≈ 39.7 tok/s 这次实测到 39.75 tok/s，已经很接近按带宽估出来的上限。至少在这组测试条件下，软件层面的调参看起来不太容易明显越过这条线。 优化策略 (针对 32GB 机型) 1. 内存硬锁定 sudo sysctl iogpu. /posts/qwen36-vllm-gateway-benchmark/ Fri, 17 Apr 2026 18:00:00 +0800 /posts/qwen36-vllm-gateway-benchmark/ TL;DR 两台 DGX Spark 各自独立运行 vLLM 推理 Qwen3.6-35B-A3B-FP8，前置一层 FastAPI 写的 LLM Gateway 做路由/负载均衡，实测结果： 单请求解码吞吐：机器本地 curl 稳定在 ~50 tok/s，客户端经 Tailscale 访问约 ~45 tok/s（差的是网络往返时间） Gateway 代理开销：serial 场景下相对直连差异 <5%，几乎无额外开销 单机并发饱和点：N≈8 时单机聚合吞吐 ~300 tok/s（6× 单流） 双机聚合上限：经 Gateway round-robin 在 N=16 下 ~485 tok/s，接近这组测试里两台机器各自饱和时的合计 结论：在这组测试里，如果想更充分地利用两台机器，还是要走 Gateway，且客户端并发度也要跟上；低并发时 Gateway 与直连差异不大。 环境背景 两台机器都是 NVIDIA DGX Spark，GB10 Grace Blackwell Superchip + 128GB LPDDR5X 统一内存。通过 Tailscale 组网，内部 200-subnet 做机器间低延迟直连： ┌──────────────────────────────────────────────────────────┐ │ DGX Spark 集群 │ │ │ │ Server 1 (100. /posts/bifrost-load-balancing-dgx-spark/ Tue, 14 Apr 2026 11:30:00 +0800 /posts/bifrost-load-balancing-dgx-spark/ TL;DR 将两台 DGX Spark 从 vLLM TP=2 跨节点部署（RPC 超时、频繁崩溃）迁移到 每台独立运行 vLLM + Bifrost 负载均衡网关后： ✅ 稳定性：至少在这轮测试里没有再复现崩溃，P95 延迟大约在 1,400ms（20 tokens） ✅ 吞吐：单机 ~15 tok/s，双机并发 ~56 tok/s（Bifrost 开销 <1ms） ✅ 可用性：双机独立 + 自动故障转移，不再有单点故障 ✅ 可扩展：水平加节点即可，不受 TP 上限约束 背景：为什么放弃 TP=2 跨节点 之前的实践中，我在两台 DGX Spark 上尝试了 vLLM 的 TP=2（跨节点张量并行）部署： 《vLLM TP=2 跨节点部署实践》 《Nemotron EP2 vs TP2：两台 DGX Spark 的实际对比》 这次测试里最直接的观察是：TP=2 跨节点能跑通但不稳定，日志里反复出现： TimeoutError: RPC call to sample_tokens timed out. No available shared memory broadcast block found in 60 seconds. /posts/nemotron-ep2-dgx-spark/ Tue, 14 Apr 2026 02:10:00 +0800 /posts/nemotron-ep2-dgx-spark/ 结论先行 在同一份 Nemotron 3 Super 120B A12B NVFP4、同一镜像、同一保守 profile 下，我这轮测试里 TP2 明显好于 EP2。 我这里做的是 clean-room 对比：清掉两台机器上所有其他 vLLM 实例后，分别跑 EP2 和 TP2，再额外用 max_tokens=32 做一次长输出探针。 测试条件 镜像：vllm/vllm-openai:gemma4-cu130 模型目录：/home/admin/models/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4-aria2 公共参数：gpu_memory_utilization=0.75、max_model_len=32768、kv_cache_dtype=fp8、quantization=fp4、mamba-ssm-cache-dtype=float32 EP2：TP=1 + DP=2 + --enable-expert-parallel TP2：tensor-parallel-size=2 结果对比 拓扑 短输出 benchmark 成功数 成功 case 平均 tok/s 最慢 case 延迟 32-token 探针 结论 EP2 TP=1 + DP=2 + --enable-expert-parallel 2/4 2.44 301.64 s 第 3 个 case 即把服务打死，后续探针 connection refused 可启动，但不稳定 TP2 tensor-parallel-size=2 4/4 4.68 23. /posts/spring-boot-35-h2c-benchmark/ Wed, 25 Mar 2026 16:30:00 +0800 /posts/spring-boot-35-h2c-benchmark/ 如果你还没理清 h2 和 h2c 的区别，可以先看我的基础概念篇。 这一篇不再讲概念，而是回答一个更实际的问题： Spring Boot 3.5 把 h2c 打开以后，真的会比 HTTP/1.1 更快吗？ 我在自己的 Shop Platform 概念验证（POC）项目里，围绕 buyer-bff -> marketplace-service 做了一整轮压测。这次实验全程基于 Java 25 (LTS) 并在 Spring Boot 中开启了 虚拟线程 (Virtual Threads)。 2026-04 实践更新 当前主线仓库里，BFF 的下游调用已经进一步演进成 @HttpExchange typed clients；因此本文关于 h2c / HTTP/1.1 的性能讨论依然成立，但调用栈样例请理解为“传输层对比实验”，不再代表今天 main 分支的全部客户端装配细节。 先说这次实验里的几个观察： 不会天然更快 但在特定 workload 下，的确可能更快 关键不在“有没有开 h2c”，而在“你的请求模型有没有真的吃到多路复用”，以及虚拟线程在高并发 I/O 场景下会不会放大这件事 这篇文章就是这次实验的完整复盘。 实验背景 这个项目本身是一套基于 Spring Boot 3.5 + Java 25 的微服务电商平台 POC。BFF 层会聚合多个下游领域服务，非常适合拿来验证协议层优化。 在 Java 25 这一最新的 LTS 版本中，虚拟线程的调度已经非常成熟。我在所有服务中都开启了： spring. /posts/mlx-vs-ollama-benchmark-on-m2-mbp/ Sat, 14 Mar 2026 15:00:00 +0800 /posts/mlx-vs-ollama-benchmark-on-m2-mbp/ Apple Silicon 的统一内存架构让本地运行大模型成为可能，而在 macOS 上，目前主要有两条路：通用方案 Ollama（基于 llama.cpp），以及 Apple 官方为 Apple Silicon 定制的 MLX 框架。 这篇文章记录我在 M2 MacBook Pro (32GB) 上的实测过程，重点回答一个问题：在日常使用中，MLX 到底比 Ollama 快多少？值不值得切换？ 测试环境与方法 硬件: M2 MacBook Pro，32GB 统一内存 系统: macOS（后台无其他 GPU 密集型任务） 测试 Prompt: 固定同一段中文提问，限制输出 128 tokens 重复次数: 每组跑 3 次取平均，排除冷启动影响 引擎 模型 量化格式 Ollama qwen3.5:latest GGUF Q4_K_M MLX mlx-community/Qwen3.5-9B-MLX-4bit MLX 4-bit 两者均使用 Qwen3.5 9B，量化精度对齐为 4-bit，尽量排除模型本身的变量。 MLX 与 GGUF：两种格式的本质差异 理解这两种格式的区别，有助于解释为什么它们的性能表现不同。 GGUF（llama.cpp 使用的格式）是一种跨平台的模型格式，设计目标是兼容性：同一个文件可以在 CPU、NVIDIA GPU、AMD GPU、Apple Silicon 上运行。Ollama 底层就是 llama.cpp，通过 Apple 的 Metal API 调用 GPU，但这层抽象有额外的调度开销。