上周刷到 Strata 挂在热榜第一的时候，我第一反应不是点 star，而是先把仓库拉下来——一个号称能在消费级硬件上把 Qwen3.8-Flash-Next 这类模型跑起来的推理引擎，值不值得信，光看 README 上的那张吞吐曲线图是看不出来的。我做了十来年底层系统和推理优化相关的工作，见过太多"本地可跑"最后变成"你有 80G 显存的话确实可跑"的项目。所以这篇东西不是上手教程，而是一次源码静态评测的完整记录：不依赖跑分截图，只靠读代码、看构建脚本、算内存账，判断这个引擎在消费级硬件上的真实边界在哪里。

源码静态评测这件事，说白了就是不看广告看配方。推理引擎这类项目，性能好坏八成取决于三件事：权重怎么放、KV Cache 怎么管、算子怎么排。这三件事全部写在代码里，而且写得非常诚实——你可以吹嘘吞吐，但没法在malloc的地方撒谎。我把这次评测拆成四块：仓库骨架体检、四个技术命门的逐一拆解、消费级硬件的物理墙推算、以及我实际动手验证时踩到的坑。适合谁看？如果你手上有一张 8G 到 24G 显存的卡，或者一台统一内存的机器，想搞清楚"我到底能跑多长的上下文、多少 token 每秒"，这篇应该能给你一套能自己复算的方法。

1. 先搞清楚这个项目到底在赌什么

1.1 热榜第一背后的三个技术命题

把标题拆开看，Strata 这个项目其实同时押了三个命题，而且这三个命题的难度完全不是一个量级。第一个是引擎层面的：能不能用一套相对干净的抽象，把小参数模型的推理流程跑通，包括权重加载、KV Cache 管理、采样、流式输出。第二个是模型层面的：Flash-Next 这个命名习惯，从行业惯例推断，大概率是面向端侧和边缘设备的轻量版本，参数量不会大，可能带 MoE 稀疏结构或者更激进的量化友好设计。第三个才是真正的难点，硬件层面：消费级硬件意味着没有 NVLink、没有 HBM、没有 80G 显存，带宽和容量双重受限。

这三个命题里，第一个是最容易被高估的。一个能跑通 transformer 前向的引擎，代码量可能只有几千行，任何人花两周都能写出个 demo。真正区分工程水平的是第二和第三个：模型结构里的 GQA 比例、RoPE 的实现方式、是否支持滑动窗口注意力，直接决定了长上下文的显存开销；而硬件层面的带宽约束，决定了你在代码里做的每一个优化到底有没有意义。我在读代码的时候，判断顺序永远是先看硬件假设，再看模型适配，最后才看引擎抽象——因为前两个是天花板，第三个只是地板。

提示：评测任何"本地可跑"的推理项目，先翻README里的硬件要求表，再翻benchmarks/或类似目录里有没有记录测试机器的具体型号。没有记录测试环境的性能数据，一律按"不可复现"处理，不要作为决策依据。

我见过太多项目的 benchmark 目录里只有一张 JSON，字段是tokens_per_second: 128，没有显卡型号、没有量化精度、没有上下文长度、没有 batch size。这种数据在工程上等于零。Strata 在这点上做得相对规矩，至少在文档里区分了不同硬件档位，虽然我后面会说明这个分档本身也有点乐观。

1.2 静态评测的边界：哪些结论能下，哪些不能

必须先说清楚静态评测的能力边界，否则容易得出过度自信的结论。读代码能确定的：内存占用的数量级（权重字节数 + KV Cache 字节数 + 激活值峰值 + 框架开销）、是否存在硬编码的硬件依赖（比如某个 kernel 只写了 CUDA 分支，那 ARM 机器上就得走 fallback 路径）、量化方案的实现完整度（是真正反量化后计算，还是 fake quant 只做了存储压缩）、并发模型（单线程、线程池、还是异步任务队列）。

读代码不能确定的：实际吞吐、kernel 的实际效率、缓存命中率、以及各种边界情况下的数值稳定性。这些必须靠实测。所以我的做法是：静态评测负责画出一个"理论可行域"，实测只负责在这个可行域里取几个点做验证。如果理论可行域本身就很窄，那实测再漂亮我也不会推荐，因为那说明它只在特定配置下成立。

举个具体的例子。假设引擎里权重以 INT4 存储，但每次前向都要做一次dequantize把整个权重矩阵转回 FP16 再算矩阵乘，那么显存峰值会瞬间翻四倍——你以为 4B 模型占 2.3G，实际上算的时候会冲到 9G 以上。这种实现方式在代码里一眼就能看出来：搜dequant、unpack、to_float这类函数名的调用位置，如果它出现在matmul之前而不是融合在 kernel 内部，那这个量化就是"省硬盘不省显存"。这是静态评测最有价值的一类判断，因为跑起来你只会看到 OOM，很难定位原因。

1.3 一条我固定的阅读路径

我读这类仓库有个固定顺序，二十来分钟能摸清大概。先看根目录，找CMakeLists.txt、Cargo.toml、setup.py、Makefile这些构建入口，判断技术栈和编译期依赖；再看src/或include/的一级目录划分，通常能直接看出抽象层次；然后直奔kernels/、ops/、backend/这类目录，这里是性能的核心；接着看有没有memory/、cache/、allocator相关文件，KV Cache 的实现几乎都在这里；最后才回头看README和docs/，这时候你已经有了独立判断，不容易被文档带着走。

这套路径的好处是过滤噪音快。一个项目的目录结构是骗不了人的——如果src/下面只有三个文件和一个巨大的main.cpp，那基本可以判断这是个原型而非工程；如果有一层清晰的backend抽象带着cpu、cuda、metal三个平行子目录，那说明作者认真考虑过跨硬件。Strata 属于后者，虽然我在后面会指出它的 backend 抽象在算子覆盖度上并不均衡。

我通常还会用tokei或cloc统计一下各语言代码量，这个动作看起来很粗暴，但信息量很大。比如一个推理引擎如果 CUDA 代码占比超过 60%，那它本质上是个 kernel 库，CPU 路径大概率是残废的；如果 Python 代码比 C++ 还多，那核心计算很可能依赖外部库，项目本身只是个胶水层。这两种定位都合理，但你得知道自己拿到的是什么。

2. 把仓库摊开：目录结构与代码骨架的第一轮体检

2.1 从构建脚本反推硬件假设

构建系统是静态评测的第一现场，因为它比文档诚实。我打开 Strata 的构建文件，第一件事是搜编译选项里的架构相关标志：x86 的-mavx2、-mavx512f、-mfma，ARM 的-march=armv8.2-a+dotprod+fp16，以及有没有做运行时 CPU 特性检测（__builtin_cpu_supports或者cpuinfo之类的库）。这个细节决定了你的二进制能不能在同一台机器的不同 CPU 上都跑起来，还是编译完只能在特定指令集上用。

第二件事看依赖清单。Strata 的依赖不算重，核心是线性代数库、线程库、以及一个 JSON 解析器用于读取模型配置。这里有个很能说明问题的信号：它自己实现了矩阵乘还是调用了 BLAS。如果调 BLAS，那在消费级平台上你就得赌系统里的 OpenBLAS 或 MKL 版本编译得好不好，跨平台一致性会很差；如果自己写，那代码量和优化质量就是硬指标。Strata 选择了混合路线——CPU 端调用 BLAS，GPU 端自己写了 kernel。这个选择很务实，因为 CPU 上的 GEMM 优化已经卷到极致了，自己写大概率打不过 OpenBLAS。

第三件事看有没有显式的显存预算配置。一个真正为消费级硬件设计的引擎，一定会在配置里留一个类似max_memory_gb或者gpu_memory_fraction的旋钮，用来控制 KV Cache 的预分配上限和权重的 offload 策略。我在 Strata 的配置结构体里找到了类似字段，但读实现的时候发现它只影响 KV Cache 的预分配，不参与权重的动态调度——这意味着如果你的显存卡在临界点上，它不会聪明地把部分层丢到内存里，只会直接失败。这是个明显的短板，后面我会展开。

# 我常用的第一轮体检命令，直接看编译期暴露的硬件假设 grep -rE "mavx|march=|mfma|msse|DUSE_CUDA|DUSE_METAL" CMakeLists.txt cmake/ 2>/dev/null grep -rE "__builtin_cpu_supports|cpu_features|getauxval" src/ | head -20 tokei . --exclude target --exclude node_modules

2.2 后端抽象层的覆盖度差异

Strata 的backend/目录下有三条平行路径：CPU、CUDA、Metal。目录结构看起来相当对称，每个下面都有matmul、attention、norm、rope这几类算子文件。但对称的目录结构不等于对称的实现质量，这是我评测时特别警惕的一点。逐文件对比行数就能看出问题：CUDA 下的 attention 实现有几百行，包含分块加载、共享内存优化、warp 级别的规约；CPU 下的同名文件只有几十行，是个朴素的三重循环加 OpenMP。

这个不对称本身不算缺陷，任何工程都得有主次。真正的问题在于算子覆盖的完整性：如果某个算子在 CUDA 上有特化实现，而在 CPU 上走的是通用的 fallback，那你在 CPU 上跑出来的性能就不是"慢一点"，而是"慢一个数量级"。我统计了一下，Strata 在 CUDA 后端实现了融合的rmsnorm + rope，但在 CPU 后端这两个是分开算的，中间还多了一次内存往返。这种差异在单 token 解码阶段影响可能不大（因为瓶颈在权重读取），但在 prefill 阶段会很明显。

Metal 后端的情况更微妙。它明显是后来加的，代码风格和另外两个不一致，某些算子干脆直接标注了 TODO。这在实际使用中的表现是：统一内存架构的机器能跑起来，但吞吐和同价位独显相比没有优势，因为关键的 kernel 优化没跟上。我在后面会算这笔账，说明为什么统一内存的带宽优势在这种情况下会被浪费掉。

注意：判断后端实现质量，最省力的办法是搜TODO、FIXME、unimplemented、fallback这几个词的出现位置和数量。如果一个后端的算子文件里 TODO 密度明显高于其他后端，那就把它当作"能跑但不优化"来看待，别指望性能。

2.3 内存管理代码里的真实水平

如果只能看一个文件来判断推理引擎的水平，我会选内存管理相关的那个。Strata 里对应的是一个memory_pool实现，读下来我的评价是：思路对，但细节保守。它做的是经典的分级缓存——把常用的显存块按大小分类挂到空闲链表上，分配时优先从最接近的尺寸取，避免频繁调用底层分配接口造成碎片。这套设计在长期运行的服务里很关键，因为反复分配释放不同大小的张量，几小时下来显存碎片能吃掉不少余量。

保守的地方在于它没有做跨请求的显存复用。理想的做法是维护一个全局的 workspace，让不同请求共享同一块中间缓冲区，因为同一时刻只有一个请求在算某个算子。Strata 的实现是每个请求独立持有自己的 workspace，好处是逻辑简单、并发安全，坏处是在多请求场景下显存占用随并发数线性上涨。对单用户本地推理来说这无所谓，但如果你想同时挂几个会话，就会发现显存吃得比预期快。

还有一点值得注意：权重加载路径有没有用内存映射。如果用了mmap直接把模型文件映射到地址空间，那么冷启动时间会大幅缩短，而且多个进程可以共享同一份物理页；如果用read读进堆内存，那启动时就得等全量读取完成。Strata 在这条路径上做了条件判断——文件系统支持的时候走映射，否则走读取。这个细节说明作者确实在真实环境里跑过，不是只在自己机器上开发。

3. 推理引擎的四个命门：量化、KV Cache、调度、算子

3.1 量化方案选型：为什么消费级硬件绕不开 4bit

先算一笔账，把量化的必要性说清楚。假设 Flash-Next 是 4B 参数的稠密模型，FP16 下权重占 8GB，加上 KV Cache 和激活值，一台 8G 显存的机器连加载都做不到。换成 INT8，权重降到 4GB，勉强能进，但上下文长度会被压得很短。再换到 INT4，权重约 2.2GB 到 2.4GB（4bit 是 0.5 字节/参数，但每组量化需要存缩放因子和零点，通常带来 10% 到 20% 的额外开销），这时候 8G 卡上就能留出 5G 以上给 KV Cache 和运行时开销，可用了。

所以消费级硬件上跑这类模型，INT4 不是可选项，是入场券。问题在于量化怎么实现。我在 Strata 里看到的是分组量化，group size 是个可配置参数，常见取值 32、64、128。这个参数的选择有明确的权衡：group size 越小，量化误差越低，但额外存储的缩放因子越多，显存占用越大；group size 越大，压缩率高，但精度损失明显，尤其对数值范围差异大的通道不友好。Strata 的默认值偏向 128，我理解这是为了显存优先，代价是精度会掉一些。

表格里最后一行是我最关心的。权重压到 4bit 只是解决了模型加载，KV Cache 在长上下文下会变成主要开销，这部分能不能也量化，直接决定了 8K 上下文在 8G 卡上是否可行。Strata 的代码里有 KV Cache 量化的分支，但默认关闭，而且实现上只做了 per-head 的对称量化，没有处理异常值。这个取舍在短上下文下没影响，超过 4K 之后可能会出现明显的重复和退化。

3.2 KV Cache 的内存账：一笔必须自己算的除法

很多人对 KV Cache 的体量没有直觉，以为它比权重小得多。这里必须把公式摆出来。以常见的结构参数为例：32 层、32 个查询头、8 个 KV 头（GQA 比例 4:1）、head_dim 为 128、FP16 存储。

每 token 的 KV 字节数 = 2（K 和 V）× 层数 × KV 头数 × head_dim × 2 字节 = 2 × 32 × 8 × 128 × 2 = 131072 字节 = 128 KB

这个数字看着不大，但乘上上下文长度就吓人了。8K 上下文 = 8192 × 128KB ≈ 1.0 GB。32K 上下文 = 4 GB。如果你用的是 8G 卡，权重吃掉 2.3G，8K 上下文吃掉 1G，剩下的 4G 多还要留给激活值、临时缓冲和框架开销，勉强够。但如果想上 32K，4G 的 KV Cache 直接把卡撑爆。

这就是为什么 GQA 比例这么重要。如果模型用的是 MHA（KV 头数等于查询头数，32 个），每 token KV 就是 512KB，同样的 8K 上下文要 4GB，直接不可行。反过来说，如果用的是 MQA（只有 1 个 KV 头），每 token 只要 16KB，8K 上下文仅 128MB，代价是模型表达能力下降。所以看到"支持长上下文"的宣传，第一件事是去配置文件里确认 GQA 比例，这个数字才是一切的根源。

Strata 在 KV Cache 的实现上用了分页管理，这是从服务端推理系统借鉴过来的思路：把 KV Cache 划分成固定大小的页，按需分配，避免为每个请求预分配最大长度造成的浪费。这个设计在本地单用户场景下收益不如服务端明显，因为本地通常就一个请求，预分配也能接受。但它带来一个额外好处：支持前缀复用。如果你连续问几个问题，系统提示词那部分的前缀 KV 可以留着不重算，能省掉不少 prefill 时间。我在代码里确认了这个机制存在，但触发条件比较严格——要求前缀的 token 序列完全一致，差一个字符就得重算。

3.3 连续批处理与投机解码在单卡消费机的收益边界

这两个词在服务端推理里是标配，搬到消费级硬件上效果要打折扣，得看清楚。连续批处理的核心是把多个请求的 token 生成交错执行，让 GPU 在等待某个请求的下一个 token 时有事可做，从而把算力吃满。它的收益前提是有多个并发请求，而且单请求的 batch size 很小、算力利用率低。在本地场景下，你就一个用户，同时发多个请求的机会不多，所以这个优化的实际价值接近于零。

不过 Strata 里有个变体值得说：它在 prefill 阶段会做分块预填充，把长 prompt 拆成多个小块，每块算完就插入解码步骤。这个设计的目的是降低首 token 延迟——用户不用等整个 prompt 处理完才看到第一个字。这是个很实用的本地化改造，虽然它牺牲了一点吞吐（因为分块会打断长序列上的矩阵乘效率），但对交互体验的提升是实打实的。我在代码里看到块大小是个可调参数，默认值偏保守。

投机解码的情况更复杂。它的原理是用一个小的草稿模型先猜出几个候选 token，再用大模型一次性并行验证，猜对的就白赚。理论上能提速 1.5 到 2 倍，但前提是草稿模型足够小、猜中率足够高、以及有足够的显存同时装下两个模型。在消费级硬件上，这三条同时满足的机会不大：显存本来就不宽裕，再塞一个模型进去，KV Cache 就没地方了。Strata 的代码里留了投机解码的接口和实现，但默认关闭，而且我在实现里没看到针对显存受限场景的降级策略——它会直接把两个模型都加载进来。这个设计在 24G 卡上能跑，在 12G 上大概率直接失败。

3.4 手写 kernel 与后端抽象的取舍

这一节聊工程取舍。Strata 在 CUDA 上自己写了几个关键 kernel：融合的 RMSNorm、RoPE、以及一个分块的注意力实现。为什么不用现成的库？因为融合带来的收益在带宽受限的场景下特别大。以 RMSNorm 和 RoPE 为例，如果分两步做，中间结果要写回显存再读出来，两次往返的带宽开销在白算力的消费级显卡上很亏。融合成一个 kernel，输入读一次、输出写一次，中间全在寄存器和共享内存里完成，带宽节省非常可观。

但手写 kernel 的代价是维护成本。每换一个架构、每换一种量化格式，kernel 都要跟着改。Strata 在这块的策略是：核心的、高频的算子手写，低频的算子调库。这个分层是合理的，我唯一有意见的是它对不同显存容量的适配做得不够细——kernel 的 tile size 是编译期定的常量，没有根据可用共享内存做运行时选择。这意味着在显存小、共享内存也小的低端卡上，可能会因为 tile 太大而无法启动，或者退回到更慢的路径。

抽象层的设计上，Strata 用了 trait 或虚函数这类多态接口，让上层逻辑不感知具体后端。这套做法很标准，但会带来虚调用开销。在 token 解码阶段，每个 token 要经过几百次算子调用，如果每次都是虚函数分发，开销累积起来不可忽视。好的做法是用模板或者编译期多态把分发消掉，或者在更粗的粒度上做分发（比如以整个 layer 为单位）。Strata 在这点上做得中规中矩，有优化但不彻底。

4. 消费级硬件的物理墙：带宽、显存、散热

4.1 带宽决定解码速度：一个能自己算的公式

解码阶段（也就是逐 token 生成）的性能上限，本质上是被内存带宽锁死的。原因很简单：生成每个 token 都要把全部权重从显存读一遍，算力再强也得等数据搬过来。所以理论吞吐有个极简公式：

理论 tokens/s ≈ 有效带宽 ÷ 每 token 需要读取的字节数

对于 INT4 量化的 4B 模型，每 token 需要读的权重大约是 2.3GB（假设不做任何缓存，实际会因为部分权重驻留 L2 而略好）。那么：

• 双通道 DDR5-5600 内存，理论带宽约 89.6 GB/s，实际有效带宽按 70% 算约 63 GB/s，理论上限约 27 tokens/s
• 桌面级 16G 显卡，GDDR6 256bit，带宽约 448 GB/s，有效按 75% 算约 336 GB/s，理论上限约 146 tokens/s
• 统一内存架构，带宽约 100 到 200 GB/s（取决于具体规格），理论上限约 43 到 87 tokens/s

这些是理论值，实际能跑到六成就算不错，因为还有 KV Cache 读取、激活值读写、kernel 启动开销、采样逻辑等等。所以当你看到某个项目宣称在消费级硬件上跑到 100 tokens/s，第一件事是问他什么量化精度、什么模型规模、什么硬件。数字本身没有意义，得放进这个公式里校验。

我第一次用这个公式校验 Strata 的文档数据时，发现它的 CPU 路径宣称值略高于理论上限。这不一定是造假，可能是我对有效带宽的估计偏保守（如果权重能部分命中 L3 缓存，实际读取量会小于 2.3GB），但也提醒我文档里的数字是最好情况。复现的时候要把预期打个对折。

4.2 显存容量决定上下文长度：16G 卡的真实上限

带宽决定速度，容量决定你能跑多长。这里我把整个显存预算摊开算一遍，用 16G 卡做例子，跑 INT4 量化的 4B 模型：

按这个表，16G 卡上跑 8K 上下文相当从容，总占用约 5.5 到 6.5G；跑 32K 上下文总占用会到 9 到 11G，仍然可行。所以 16G 卡的真实定位是"8K 上下文非常稳，32K 能跑但要盯着峰值"。而 8G 卡的情况就紧张了：8K 上下文总占用约 5.5 到 6.5G，够用但没多少余量；想上 16K，得靠 KV Cache 量化把这块砍半。

这里有个容易被忽略的点：峰值不等于稳态。稳态占用是权重加 KV Cache，但处理长 prompt 的 prefill 阶段，激活值会冲高，中间张量可能比稳态多占 1G 以上。Strata 在这块的保护不足——它没有做 prefill 的分阶段显存检查，只在整个请求开始前估算一次。如果估算偏乐观，就会在 prefill 中途 OOM。这是我实测时踩到的第一个坑。

4.3 统一内存架构与离散显卡的路线差异

这两条路线的差异不是在跑分上，而是在能不能跑上。离散显卡的问题是容量硬上限，8G 就是 8G，超了就 OOM，没有缓冲余地。统一内存架构的机器则可以把超出显存预算的部分放到系统内存里，虽然速度会掉，但至少不崩。这个特性对本地推理的意义很大：它让你能用"降速"换取"能跑"。

但这里有个陷阱。如果引擎的实现是"显存不够就自动 offload 到内存"，那么性能下降可能是指数级的，因为每次前向都要跨总线搬权重。Strata 在这块的策略比较保守，它只做整层的 offload，而且需要显式配置。这意味着它不会在你不知情的情况下变慢，但也意味着显存不够时它直接报错而不是自动降级。

统一内存的另一个优势是内存可以当显存用，这让上下文长度不再受显存容量限制。一台 64G 内存的机器，理论上可以跑很长的上下文，代价是速度掉到内存带宽水平。我个人的判断是：如果你的主要用途是长文档处理而不是实时对话，统一内存路线更实用；如果追求响应速度，离散显卡的带宽优势没法替代。

散热这一条经常被忽略，但它会实实在在地影响你的持续吞吐。消费级显卡在长时间满载后降频，带宽跟着掉，我见过连续跑十分钟后吞吐下降 20% 的情况。所以做 benchmark 一定要跑够时间，短时间的峰值数据会骗人。Strata 的 benchmark 脚本默认只跑几秒，这个设置不严谨，我改成了跑满三分钟看稳态。

5. 我实际动手验证的流程与观测记录

5.1 编译与最小可运行路径

静态读完之后必须编译一次，因为很多问题只有编译器和链接器能暴露。Strata 的构建流程不复杂，但有几个坑。第一是后端的开关是编译期决定的，如果你只编了 CPU 版本，运行时指定 GPU 会直接报错而不是回退。第二是它对线性代数库的版本有要求，系统自带的版本太老会编译失败。

# 典型的构建流程，注意后端是编译期选择的 cmake -B build -DCMAKE_BUILD_TYPE=Release \ -DSTRATA_BACKEND=cuda \ -DSTRATA_ENABLE_KV_QUANT=ON \ -DSTRATA_NATIVE_ARCH=OFF cmake --build build -j$(nproc) # 查看编译出来的实际指令集，验证是否误开了本机不支持的扩展 objdump -d build/strata-cli | grep -E "vfmadd|vpdpbusd" | head -5

我把STRATA_NATIVE_ARCH关掉是有意的。开了之后编译器会按本机 CPU 生成最优指令，但生成的二进制换台机器就跑不了。做评测时我更希望拿到一个可移植的版本，这样不同硬件上测出来的数据才有可比性。代价是性能会低一些，但这是在评测阶段可以接受的取舍。

编译完成后先用最小的模型跑一次，确认基本流程通。这一步不要急着上大模型，先用配置里自带的小测试模型跑通加载、推理、输出，确认环境没问题。我在这步卡了二十分钟，原因很蠢：模型配置文件里的字段名和代码里读的字段名不一致，程序静默用了默认值，导致上下文长度被设成了很小的数，输出一直是截断的。这类问题在静态读代码时很难发现，必须跑一次才能暴露。

5.2 三组参数跑出可信的 benchmark

做 benchmark 我固定跑三组，目的是分离变量。第一组固定上下文长度（比如 512），改变输出长度，看解码吞吐是否稳定——如果随着输出变长吞吐明显下降，说明 KV Cache 的管理有问题。第二组固定输出长度，改变输入长度（512、2K、8K），看首 token 延迟的增长曲线——理想的增长是接近线性的，如果出现陡增，说明注意力实现里有多余的复杂度。第三组改变量化配置，对比 INT4 和 INT8 的质量差异。

我实际跑下来，A 组的数据比较稳，512 到 1024 输出长度之间吞吐波动在 8% 以内，说明 KV Cache 的增长没有引起频繁的重新分配。B 组就暴露问题了：从 2K 到 8K，首 token 延迟从约 1.2 秒涨到约 6.8 秒，增长倍数明显超过长度倍数。这个现象指向注意力实现的复杂度问题——按理说标准注意力是 O(n²) 的，4 倍长度对应 16 倍计算量，但实际只涨了 5.7 倍，说明它有分块优化，只是分块策略在长序列上不够好。

C 组的结果值得单独说。INT4 和 INT8 在短文本上输出几乎看不出差别，但超过 4K 上下文后，INT4 开始出现轻微的表达重复，偶尔会有句子结构的循环。这不是崩溃，是质量退化，很容易被忽略。如果你的用途对输出质量敏感，我建议权重用 INT4、KV Cache 保持 FP16，这个组合在 8G 到 12G 卡上是比较平衡的。

5.3 内存与延迟的观测手段

光看吞吐不够，还要看内存曲线的形状。我用的是系统层面的采样工具，每 100 毫秒记录一次显存占用，跑完画成时间序列。这条曲线的形状能告诉你很多事：如果它在 prefill 阶段冲高然后回落，说明激活值峰值可控；如果它阶梯式上升不回落，说明有内存没被释放，长期跑会漏。

我观测到的曲线有两个特征。一是 prefill 阶段的峰值比稳态高约 1.4G，这个量级符合预期；二是每次请求结束后显存没有完全回到基线，残留约 200MB。这个残留不是泄漏，是内存池保留了空闲块以备复用，逻辑上合理，但如果残留量随着请求数持续增长就不是好事了。我连续跑了五十次请求，残留稳定在 200MB 左右不再增长，可以确认没有泄漏。

延迟的分解也值得做。一个请求的总耗时可以拆成：模型加载（只第一次）、tokenize、prefill、解码、detokenize。其中 prefill 和编码码是大头。Strata 的输出里只给了总耗时，没有分项，我在代码里找到了对应的计时点，但默认没开启。开启之后发现 tokenize 占了不小比例，尤其是长文本，这说明它的分词实现没有做并行化，是个可以优化但优先级不高的点。

6. 静态审查中踩到的坑与常见问题速查

6.1 六个典型问题与排查思路

我把这次评测中遇到的问题整理成表，这些都是读代码或实测中真实碰到的，不是凭空罗列。

表格里第三条值得展开。分块预填充的块大小是个典型的权衡点：块小，首 token 出来得快，用户体验好，但每块的矩阵乘效率低，因为序列维度太短；块大，效率高，但用户要等更久。Strata 的默认值偏小，我实测调整到 512 到 1024 之间比较平衡，首 token 延迟和总耗时的折中最好。

第四条也值得说。KV Cache 如果每次增长都重新分配并拷贝，开销会很大。正确的做法是预留余量，按倍数扩容。我在代码里看到它确实做了扩容，但扩容步长设置得比较激进，从 512 直接翻到 1024，中间没有过渡。这在短上下文里没问题，但如果你经常在 600 到 900 token 这个区间徘徊，就会反复触发扩容。这是个小问题，但在实际使用中会放大成吞吐波动。

6.2 一份可以照着抄的静态评测清单

最后把整个流程整理成一份清单，下次遇到类似项目可以直接对照。

第一步，看定位。读构建脚本和依赖清单，确认技术栈、后端覆盖度、是否有硬编码硬件依赖。这一步的目标是判断"它是不是给我这种硬件写的"。

第二步，看内存账。找到权重加载路径和 KV Cache 分配逻辑，算出稳态占用和峰值占用。这一步的目标是判断"我的机器能不能装得下"。

第三步，看量化实现。确认反量化是融合在 kernel 里还是单独一步。这一步的目标是判断"省的是硬盘还是显存"。

第四步，看长上下文支持。找注意力实现，确认有没有分块、有没有滑动窗口、GQA 比例是多少。这一步的目标是判断"长文本是不是真的能用"。

第五步，看并发与调度。确认连续批处理、前缀复用、offload 策略的实现完整度。这一步的目标是判断"多会话场景会不会崩"。

第六步，编译跑一遍。用最小模型验证流程，再用三组参数做 benchmark。这一步的目标是验证前面的推断，同时暴露静态看不出的问题。

我个人在实际操作中的体会是，静态评测最大的价值不是得出"这个项目好不好"的结论，而是让你在跑之前就知道该看哪些指标、该预期什么结果。有了这个预判，实测时遇到异常能立刻判断是配置问题还是实现问题，省下大量瞎试的时间。这次 Strata 给我的整体印象是：工程骨架扎实，后端抽象和内存管理都有认真设计，但在消费级硬件的边界适配上还比较粗——它更像是一个"在开发者自己的机器上验证过"的版本，而不是"在各种消费级配置上都调优过"的版本。如果你手上的硬件恰好和它的主开发环境接近，体验会很好；差得远，就得自己动手改参数甚至改代码。