最近在给一个 LLM 推理服务做性能诊断时我碰到一个很尴尬的情况服务端已经用稀疏化技术把推理延迟优化得很好了但从监控面板上只能看到 QPS、平均延迟这类聚合指标完全看不到 Token 在服务系统里到底怎么流转的也看不到稀疏优化到底省了多少计算量。换句话说稀疏性利用系统变成了一只“黑盒”问题定位和成本归因都无从下手。为了把这层窗户纸捅破我在项目里实践了一套面向稀疏性利用 LLM 服务系统的 Token 提取与分析方案并落地了一个轻量观测框架。本文会把我这套完整思路整理出来包含核心概念、环境准备、Token 生命周期采集、稀疏度计算、指标分析、日志解析和常见问题排查。适合正在做 LLM 推理服务性能优化、服务端监控体系建设的开发者阅读也适合想了解 LLM Serving System 内部机制的初学者作为系统化入门。1. 背景与核心概念1.1 从稠密计算到稀疏计算Serving System 的演进背景传统的大模型推理无论是 Prefill 阶段还是 Decode 阶段都要对完整的权重矩阵和激活矩阵做矩阵乘法。这种“每个参数都必须参与计算”的模式称为稠密计算。稠密计算实现简单但计算量巨大。当模型规模到达 7B、13B、70B 甚至更大时显存和算力都会被快速耗尽。于是稀疏性优化被引入到 LLM 服务系统中。这里的“稀疏”指的是矩阵中包含大量零值。在数学上任何数与零相乘结果都是零所以我们可以跳过这些零值对应的计算从而减少浮点运算次数降低延迟和功耗。常见的稀疏化手段包括权重稀疏对已训练模型的权重做剪枝把接近零的参数直接置零。激活稀疏在推理过程中部分神经元对当前输入不敏感输出为零或接近零。KV Cache 稀疏随着生成序列变长历史 KV 缓存中某些位置的键值对重要性降低可以省略计算。MoE 专家稀疏混合专家模型中每个 Token 只激活少量专家天然具备稀疏性。稀疏性利用系统就是在软件层面推理引擎和硬件层面稀疏张量核心、裁剪指令上挖掘这些零值从而让推理更快、更省显存。1.2 稀疏性类型与 Token 流的映射关系那么“从稀疏性利用 LLM 服务系统中提取 Token”是什么意思呢它不是简单地从模型输出里拿几个 token 字符串而是指在一条完整的请求链路中把每个 Token 从输入到输出的生命周期追踪出来并把它与稀疏性事件关联起来。我们可以把 Token 流理解成一条流水线客户端请求 - 文本转 Token IDTokenizer - Prefill 阶段Prompt Token 一次性并行计算 - Decode 阶段每个新 Token 逐步生成 - Token ID 转文本Detokenizer - 流式返回给客户端在传统非稀疏服务系统里我们只需要关注“生成了哪些 Token”“每两个 Token 之间的耗时”就够了。但在稀疏性利用系统中我们还要知道Prefill 阶段当前 Prompt 的激活稀疏度是多少哪些层跳过了一半以上的神经元Decode 阶段每个输出 Token 实际参与计算的权重比例是多少MoE 模型里每个 Token 路由到了几个专家KV Cache 在长上下文场景下的缓存命中率如何SparSEEty 的定位就是针对这些需求而生的 Token 提取与观测工具。它通过采集推理引擎的中间信息把 Token 生命周期数据与稀疏性状态数据合并形成一条可查询、可分析、可可视化的观测链路。1.3 为什么开发者需要掌握 Token 提取能力如果只是调用别人的推理服务可能不需要关注这些细节。但如果你在做以下工作掌握 Token 提取与稀疏性分析能力就非常必要推理成本优化通过稀疏率数据判断当前服务是否真正利用了稀疏特性。性能瓶颈归因定位是 Prefill 慢还是 Decode 慢是注意力计算慢还是 FFN 计算慢。服务容量规划通过 Token 级别的吞吐数据决定部署多少张 GPU、是否需要扩容。算法效果监控有些稀疏化方案可能在计算效率提升的同时影响生成质量需要按 Token 维度进行评估。可观测性建设构建 LLM 服务全链路追踪体系时Token 是最自然的业务语义单元。2. 环境准备与观测思路2.1 运行环境与依赖说明本文示例以常见的本地 GPU 环境为例主要演示思路版本可根据实际情况调整。我们在实践中使用的环境大致如下组件建议版本/说明操作系统LinuxUbuntu 20.04/22.04或 WSL2GPUNVIDIA GPU显存建议 16GB 以上推理引擎vLLM 或 Hugging Face TransformersPython3.10 及以上PyTorch2.xCUDA11.8 或 12.x需与 PyTorch 匹配分析库pandas、numpy、matplotlib这里要特别提醒不同推理引擎的 Token 提取方式不同。vLLM 这类高性能 Serving 引擎对内部细节做了封装不一定能像原生 PyTorch 一样方便地拿到每层激活值。实际项目中我们需要结合“引擎日志解析”“引擎预留接口”“模型 Hook”三种手段来采集数据。2.2 观测目标从请求进入服务到 Token 返回的完整链路我们的目标是拿到这样一组数据请求ID | 阶段 | Token ID | Token 文本 | 时间戳 | 层号 | 稀疏度 | 额外信息以一条请求为例期望的数据形态如下请求ID阶段Token ID时间戳层号稀疏度备注req_001prefill121700000000.123layer.00.45prompt tokenreq_001prefill341700000000.123layer.00.45prompt tokenreq_001decode561700000000.456layer.120.31generated tokenreq_001decode781700000000.789layer.120.28generated token有了这张表我们就可以回答很多问题生成的每个 Token 平均耗时多少哪一层的稀疏度最高稀疏度变化和 Token 生成的语义有没有关联2.3 最小项目结构本文实战部分我们会按下面的目录结构组织代码sparseety_demo/ ├── requirements.txt ├── extract_hooks.py # 通过模型 Hook 提取激活稀疏度 ├── parse_vllm_logs.py # 解析 vLLM 日志提取 Token 时间线 ├── analyze_metrics.py # 计算 TTFT、TPOT、TPM 等指标 ├── output/ │ ├── token_timeline.csv │ ├── sparsity_report.csv │ └── summary.json下面逐步拆解每个文件的作用。3. Token 提取与稀疏性分析核心原理3.1 拦截 Token 生命周期的三种方式想要拿到 Token 级别的数据有三种常见路径方式一模型层 Hook对于基于 Transformers 架构的模型我们可以在模型各层注册 forward hook。当某层执行前向计算时hook 函数会收到该层的输入和输出我们可以在这里统计激活值中零元素的比例从而算出稀疏度。这种方式适合基于 Transformers / PyTorch 的推理服务优点是信息丰富缺点是性能开销相对较大且对 vLLM 等深度优化引擎不一定直接适用。方式二引擎日志解析vLLM 等 Serving 引擎在运行时会输出结构化日志通常包括请求 ID、Prompt Token 数量、生成 Token 数量、平均吞吐等字段。我们可以用脚本定时抓取并解析这些日志提取 Token 生命周期数据。方式三代理层流量捕获在服务入口或出口增加一层代理如自定义中间件从 HTTP 流式响应中按 SSE 协议解析出每个 Token 内容及时间戳。这种方式不侵入推理引擎适合对运行中的服务做观测但拿不到模型内部的稀疏度信息。3.2 稀疏率怎么算稀疏率是衡量“有多少计算被跳过”的核心指标。一般定义为矩阵中值为零的元素数占总元素数的比例。sparsity_ratio zero_count / total_count例如某一层权重矩阵有 1000 个元素其中 300 个为零那么稀疏度就是 0.3。对于激活值我们通常在经过 ReLU 激活函数之后统计零值比例因为 ReLU 会把负值统一置零形成天然的激活稀疏。在多层模型中我们可以计算每层的稀疏度然后加权平均得到整体稀疏度。注意稀疏度不是越高越好——过高的稀疏度可能意味着模型表达能力下降需要在性能和效果之间找到平衡。3.3 关键指标TTFT、TPOT、TPM 的关系在 Token 提取场景中需要重点关注三个指标TTFTTime to First Token从请求发出到收到第一个 Token 的耗时。通常由 Prefill 阶段计算时间决定。TPOTTime Per Output Token生成每个输出 Token 的平均耗时。由 Decode 阶段计算时间决定。TPMTokens Per Minute每分钟处理的 Token 总数。注意这里通常等于输入 Token 与输出 Token 的总和。三者之间的关系是TPM (输入Token数 输出Token数) / 总耗时(分钟) TTFT 关注首字延迟TPOT 关注生成节奏对优化稀疏性利用服务系统来说这几个指标可以帮助我们判断稀疏优化是缩短了 Prefill 的 TTFT还是缩短了 Decode 的 TPOT或者两者兼而有之。4. 完整实战从服务日志与推理引擎中提取 Token4.1 创建项目结构本实战分为两条采集路径一是通过 Transformers 模型 Hook 提取激活稀疏度二是通过解析 vLLM 日志提取 Token 时间线。先创建项目目录mkdir -p sparseety_demo/output cd sparseety_demo后续代码都放在sparseety_demo目录下。4.2 编写依赖文件创建requirements.txt# 文件路径sparseety_demo/requirements.txt torch2.0.0 transformers4.36.0 pandas2.0.0 numpy1.24.0 matplotlib3.7.0 vllm0.3.0 # 仅当使用 vLLM 时需要安装依赖pip install -r requirements.txt这里需要提醒由于 PyTorch 与 CUDA 的版本组合要求较高如果安装失败请优先检查 PyTorch 与 CUDA 版本是否匹配。4.3 通过模型 Hook 提取激活稀疏度我们先编写一个基于 Transformers 的 Hook 脚本。核心思路是在 Transformer 模型的每一层 FFN 输出之后注册 hook统计激活矩阵中零值比例。# 文件路径sparseety_demo/extract_hooks.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name facebook/opt-1.3b tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16).eval() # 用于保存每层稀疏度的字典 sparsity_record {} def make_hook(layer_idx): def hook_fn(module, input_tensor, output_tensor): # 只统计 ReLU 之后的激活稀疏度 if isinstance(output_tensor, tuple): acts output_tensor[0] else: acts output_tensor # 将激活值展开成二维矩阵方便统计 flat acts.reshape(-1) total flat.numel() zeros torch.sum(flat 0).item() ratio zeros / total if total 0 else 0.0 sparsity_record[layer_idx] ratio return hook_fn # 为模型每一层 FFN 注册 hook以 OPT 模型为例 for idx, layer in enumerate(model.model.decoder.layers): layer.fc2.register_forward_hook(make_hook(idx)) prompt SparSEEty is a framework for extracting tokens from sparsity-exploiting LLM serving systems. inputs tokenizer(prompt, return_tensorspt) with torch.no_grad(): outputs model(**inputs) print(各层激活稀疏度) for layer_idx, ratio in sorted(sparsity_record.items()): print(flayer {layer_idx}: {ratio:.4f}) avg_sparsity sum(sparsity_record.values()) / len(sparsity_record) print(f平均激活稀疏度{avg_sparsity:.4f})这段代码的关键点有三个register_forward_hook可以在不修改模型结构的情况下拿到每一层前向计算的输入和输出。torch.sum(flat 0).item()统计零值个数除以总元素数得到稀疏度。OPT 模型在fc2层之后通常跟着 ReLU 激活所以统计这层的输出可以很好地反映激活稀疏情况。运行脚本python extract_hooks.py预期输出如下数值会根据模型权重和输入文本不同而浮动各层激活稀疏度 layer 0: 0.8781 layer 1: 0.8543 ... 平均激活稀疏度0.7321注意这里统计到的稀疏度是“该输入下模型本身展示出的激活稀疏性”并不是稀疏化剪枝后的权重稀疏性。在实际稀疏性利用服务系统中推理引擎会基于类似的稀疏度预估跳过部分零值计算从而提升效率。4.4 从 vLLM 日志解析 Token 时间线使用 vLLM 启动一个兼容 OpenAI API 的服务python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-2-7b-chat-hf \ --gpu-memory-utilization 0.8 \ --max-model-len 4096启动后vLLM 会输出类似下面的日志INFO: Started server process [12345] INFO: Uvicorn running on http://0.0.0.0:8000 INFO: 127.0.0.1:52314 - POST /v1/completions HTTP/1.1 200 OK INFO: Processed prompts: 100%|████████████████| 1/1 [00:0000:00, 3.73it/s] INFO: Request req_001: prompt_tokens128, generated_tokens256, ttft0.823s, tpot0.041s我们可以编写脚本解析这份日志提取 Token 级别的时间线。不过这里有一个细节vLLM 默认日志不会把每个 Token 单独列出而是生成汇总摘要。如果我们需要逐 Token 的时间戳可以通过 vLLM 的日志参数开启更详细的输出例如--verbose模式或者在应用层通过 SSE 流式接口逐 Token 捕获。下面的脚本演示如何从 vLLM 的摘要日志中提取关键 Token 指标并把它转成便于分析的 DataFrame。# 文件路径sparseety_demo/parse_vllm_logs.py import re import json import pandas as pd from pathlib import Path LOG_FILE vllm.log # 请替换为实际的日志文件路径 def parse_vllm_log(log_text): records [] # 匹配形如Request req_001: prompt_tokens128, generated_tokens256, ttft0.823s, tpot0.041s pattern re.compile( rRequest\s(?Preq_id\S):\s rprompt_tokens(?Pprompt_tokens\d),\s rgenerated_tokens(?Pgenerated_tokens\d),\s rttft(?Pttft[\d.])s,\s rtpot(?Ptpot[\d.])s ) for line in log_text.splitlines(): match pattern.search(line) if match: info match.groupdict() info[prompt_tokens] int(info[prompt_tokens]) info[generated_tokens] int(info[generated_tokens]) info[ttft] float(info[ttft]) info[tpot] float(info[tpot]) # 估算总耗时和 TPM info[total_time] info[ttft] info[generated_tokens] * info[tpot] info[tpm] (info[prompt_tokens] info[generated_tokens]) / (info[total_time] / 60) records.append(info) return pd.DataFrame(records) def main(): log_path Path(LOG_FILE) if not log_path.exists(): print(f日志文件不存在{log_path}) return log_text log_path.read_text(encodingutf-8) df parse_vllm_log(log_text) if df.empty: print(未在日志中找到匹配的请求记录。) return df.to_csv(output/token_timeline.csv, indexFalse) print(解析完成结果已保存到 output/token_timeline.csv) print(df.head()) if __name__ __main__: main()运行python parse_vllm_logs.py生成结果示例req_id prompt_tokens generated_tokens ttft tpot total_time tpm 0 req_001 128 256 0.823 0.041 11.319 2035.87这个 CSV 就是我们后续分析服务性能的重要基础数据。4.5 计算稀疏度与吞吐指标并生成汇总接下来把前面两个脚本的结果汇总计算一个综合报告。这里需要注意Hook 方式拿到的稀疏度是模型内部状态日志方式拿到的是服务指标两者要关联起来比较自然的方式是按模型版本和请求输入进行“快照式”对比而不是在每秒维度上合并。# 文件路径sparseety_demo/analyze_metrics.py import json import pandas as pd def analyze_results(timeline_csvoutput/token_timeline.csv): df pd.read_csv(timeline_csv) if df.empty: print(无数据可分析) return summary { total_requests: len(df), avg_prompt_tokens: round(df[prompt_tokens].mean(), 2), avg_generated_tokens: round(df[generated_tokens].mean(), 2), avg_ttft: round(df[ttft].mean(), 4), avg_tpot: round(df[tpot].mean(), 4), avg_total_time: round(df[total_time].mean(), 4), sum_tpm: round(df[tpm].sum(), 2), } with open(output/summary.json, w, encodingutf-8) as f: json.dump(summary, f, ensure_asciiFalse, indent2) print( 汇总分析 ) for key, value in summary.items(): print(f{key}: {value}) if __name__ __main__: analyze_results()运行python analyze_metrics.py这个脚本本身并不复杂但它把可观测数据沉淀成了可量化的服务指标。在实际生产环境中这类的汇总结果可以接入 Prometheus、Grafana 等监控系统。5. 常见问题与排查思路5.1 Hook 方式拿不到激活输出问题现象常见原因解决思路hook 中 output_tensor 为 None某些层在推理时处于torch.no_grad()或推理引擎做了算子融合检查模型是否处于 eval 模式尝试在其他子模块注册 hook稀疏度全部为 0统计的层使用了 GELU 激活而非 ReLU换成统计 GELU 输出之后接近零的比例或改用更合适的稀疏判定条件补充说明GELU 激活函数不会输出大量精确的 0我们可以用“接近零”阈值来统计稀疏度比如绝对值小于 1e-6 的元素视为零。5.2 vLLM 日志中没有 Request 摘要vLLM 的日志输出格式可能随版本变化。旧版本可能不打印Request req_001这类摘要你需要确认 vLLM 版本查看官方文档中日志格式部分。检查日志级别通常需要开启 INFO 级别日志。如果确实没有摘要可以考虑通过调用 API 时自行记录时间戳或使用 vLLM 的 Metrics 端点获取指标。5.3 稀疏度很高但推理速度没有提升这是最常见也最容易误解的问题。稀疏度只是说明矩阵中存在大量零值并不代表推理引擎真正跳过了这些计算。如果服务端使用的 GPU 不支持稀疏加速或者推理引擎没有启用稀疏算子那么高稀疏度对性能没有帮助。排查顺序确认 GPU 型号检查是否支持稀疏张量加速。确认推理引擎是否启用了稀疏推理模式。在开启/关闭稀疏优化两种条件下分别跑同一组请求对比 TTFT 和 TPOT。5.4 多并发请求下 Token 时间线混乱当并发请求较多时日志中的请求记录会交叉出现。解决方案是为每个请求分配唯一 ID并在日志中打印该 ID。如果使用 vLLM建议在应用层入口给每个请求生成request_id这样日志和监控指标可以按 ID 关联。6. 最佳实践与工程建议6.1 从业务指标到 Token 指标的分层建模不要把 Token 指标直接等同于业务指标。建议建立三层指标模型业务层成功率、错误率、QPS、平均延迟。Token 层TTFT、TPOT、TPM、输入/输出 Token 数量。稀疏层激活稀疏度、权重稀疏度、专家路由分布、KV Cache 命中率。SparSEEty 这类工具的价值就在于打通这三层让“业务变慢”能向下定位到“Token 生成变慢”再进一步定位到“哪一层的稀疏利用效率下降了”。6.2 最小化采集开销Token 级采集是有开销的。在模型层频繁注册 hook 会导致推理性能明显下降。生产环境建议默认只做日志解析和 API 层 Token 捕获不启用模型 Hook。需要做模型内部稀疏分析时通过开关控制只对部分请求开启。采样率建议从 1% 开始逐步调整找到一个平衡点。6.3 稀疏度分析结果要结合生成质量一起看稀疏优化往往以牺牲部分表达能力为代价。当我们发现某个模型层的稀疏度异常偏高时建议同步检查该请求的生成结果质量比如困惑度Perplexity变化、回答长度、关键信息完整度等。不要只看性能指标。6.4 日志格式规范化日志格式一定要结构化。推荐使用 JSON Lines 格式记录 Token 事件{request_id: req_001, event: token_generated, token_id: 123, timestamp: 1700000000.456, tpot: 0.041, seq_idx: 1}结构化日志的好处是可以直接被 Fluentd、Logstash 等采集工具消费也便于后续做更复杂的关联分析。6.5 安全与权限边界当我们在生产环境做 Token 级信息采集时要特别注意数据安全。LLM 服务的输入输出可能包含用户敏感信息。进行日志采集、存储和分析时应遵循最小权限原则尽量不记录完整 Prompt 和完整输出文本。记录 Token ID 即可满足大部分分析需求避免将原始文本落入日志系统。如果是文本需要留痕必须做脱敏处理并对日志系统做访问控制。不要在生产环境把 Token 级日志长期保存在通用存储中。7. 总结本文围绕“从稀疏性利用 LLM 服务系统中提取 Token”这一主题完整梳理了相关概念和实战流程。我们从稀疏性在 LLM 服务系统中的意义讲起区分了权重稀疏、激活稀疏、KV Cache 稀疏和 MoE 专家稀疏接着介绍了 Token 生命周期和 TTFT、TPOT、TPM 等关键指标并通过三个可运行的 Python 脚本演示了如何通过模型 Hook 提取激活稀疏度、如何解析 vLLM 日志得到 Token 时间线、如何汇总服务性能指标。如果你正在搭建 LLM 服务的可观测体系下一步可以从三个方向继续深入第一把本文的采集逻辑封装为常驻服务并接入 Prometheus 指标体系第二把 Token ID 与文本脱敏规则结合起来设计更完善的数据采集策略第三研究不同稀疏优化策略下的 Token 质量变化建立性能与效果的联合监控视图。在项目落地时我最想提醒你的一点是Token 提取的价值不在于监控本身而在于把“服务表现”和“内部计算状态”关联起来。只有当你能够回答“某个 Token 为什么会特别慢”“这一层稀疏度提升了为什么总体吞吐没变化”这类问题时这套观测体系才算真正发挥了作用。如果本文对你有帮助可以收藏备用。你在实际项目里碰到过哪些与 Token 观测或稀疏推理相关的坑欢迎在评论区分享你的排查经验。 稀疏性利用LLM服务系统的Token提取与分析实践
最近在给一个 LLM 推理服务做性能诊断时我碰到一个很尴尬的情况服务端已经用稀疏化技术把推理延迟优化得很好了但从监控面板上只能看到 QPS、平均延迟这类聚合指标完全看不到 Token 在服务系统里到底怎么流转的也看不到稀疏优化到底省了多少计算量。换句话说稀疏性利用系统变成了一只“黑盒”问题定位和成本归因都无从下手。为了把这层窗户纸捅破我在项目里实践了一套面向稀疏性利用 LLM 服务系统的 Token 提取与分析方案并落地了一个轻量观测框架。本文会把我这套完整思路整理出来包含核心概念、环境准备、Token 生命周期采集、稀疏度计算、指标分析、日志解析和常见问题排查。适合正在做 LLM 推理服务性能优化、服务端监控体系建设的开发者阅读也适合想了解 LLM Serving System 内部机制的初学者作为系统化入门。1. 背景与核心概念1.1 从稠密计算到稀疏计算Serving System 的演进背景传统的大模型推理无论是 Prefill 阶段还是 Decode 阶段都要对完整的权重矩阵和激活矩阵做矩阵乘法。这种“每个参数都必须参与计算”的模式称为稠密计算。稠密计算实现简单但计算量巨大。当模型规模到达 7B、13B、70B 甚至更大时显存和算力都会被快速耗尽。于是稀疏性优化被引入到 LLM 服务系统中。这里的“稀疏”指的是矩阵中包含大量零值。在数学上任何数与零相乘结果都是零所以我们可以跳过这些零值对应的计算从而减少浮点运算次数降低延迟和功耗。常见的稀疏化手段包括权重稀疏对已训练模型的权重做剪枝把接近零的参数直接置零。激活稀疏在推理过程中部分神经元对当前输入不敏感输出为零或接近零。KV Cache 稀疏随着生成序列变长历史 KV 缓存中某些位置的键值对重要性降低可以省略计算。MoE 专家稀疏混合专家模型中每个 Token 只激活少量专家天然具备稀疏性。稀疏性利用系统就是在软件层面推理引擎和硬件层面稀疏张量核心、裁剪指令上挖掘这些零值从而让推理更快、更省显存。1.2 稀疏性类型与 Token 流的映射关系那么“从稀疏性利用 LLM 服务系统中提取 Token”是什么意思呢它不是简单地从模型输出里拿几个 token 字符串而是指在一条完整的请求链路中把每个 Token 从输入到输出的生命周期追踪出来并把它与稀疏性事件关联起来。我们可以把 Token 流理解成一条流水线客户端请求 - 文本转 Token IDTokenizer - Prefill 阶段Prompt Token 一次性并行计算 - Decode 阶段每个新 Token 逐步生成 - Token ID 转文本Detokenizer - 流式返回给客户端在传统非稀疏服务系统里我们只需要关注“生成了哪些 Token”“每两个 Token 之间的耗时”就够了。但在稀疏性利用系统中我们还要知道Prefill 阶段当前 Prompt 的激活稀疏度是多少哪些层跳过了一半以上的神经元Decode 阶段每个输出 Token 实际参与计算的权重比例是多少MoE 模型里每个 Token 路由到了几个专家KV Cache 在长上下文场景下的缓存命中率如何SparSEEty 的定位就是针对这些需求而生的 Token 提取与观测工具。它通过采集推理引擎的中间信息把 Token 生命周期数据与稀疏性状态数据合并形成一条可查询、可分析、可可视化的观测链路。1.3 为什么开发者需要掌握 Token 提取能力如果只是调用别人的推理服务可能不需要关注这些细节。但如果你在做以下工作掌握 Token 提取与稀疏性分析能力就非常必要推理成本优化通过稀疏率数据判断当前服务是否真正利用了稀疏特性。性能瓶颈归因定位是 Prefill 慢还是 Decode 慢是注意力计算慢还是 FFN 计算慢。服务容量规划通过 Token 级别的吞吐数据决定部署多少张 GPU、是否需要扩容。算法效果监控有些稀疏化方案可能在计算效率提升的同时影响生成质量需要按 Token 维度进行评估。可观测性建设构建 LLM 服务全链路追踪体系时Token 是最自然的业务语义单元。2. 环境准备与观测思路2.1 运行环境与依赖说明本文示例以常见的本地 GPU 环境为例主要演示思路版本可根据实际情况调整。我们在实践中使用的环境大致如下组件建议版本/说明操作系统LinuxUbuntu 20.04/22.04或 WSL2GPUNVIDIA GPU显存建议 16GB 以上推理引擎vLLM 或 Hugging Face TransformersPython3.10 及以上PyTorch2.xCUDA11.8 或 12.x需与 PyTorch 匹配分析库pandas、numpy、matplotlib这里要特别提醒不同推理引擎的 Token 提取方式不同。vLLM 这类高性能 Serving 引擎对内部细节做了封装不一定能像原生 PyTorch 一样方便地拿到每层激活值。实际项目中我们需要结合“引擎日志解析”“引擎预留接口”“模型 Hook”三种手段来采集数据。2.2 观测目标从请求进入服务到 Token 返回的完整链路我们的目标是拿到这样一组数据请求ID | 阶段 | Token ID | Token 文本 | 时间戳 | 层号 | 稀疏度 | 额外信息以一条请求为例期望的数据形态如下请求ID阶段Token ID时间戳层号稀疏度备注req_001prefill121700000000.123layer.00.45prompt tokenreq_001prefill341700000000.123layer.00.45prompt tokenreq_001decode561700000000.456layer.120.31generated tokenreq_001decode781700000000.789layer.120.28generated token有了这张表我们就可以回答很多问题生成的每个 Token 平均耗时多少哪一层的稀疏度最高稀疏度变化和 Token 生成的语义有没有关联2.3 最小项目结构本文实战部分我们会按下面的目录结构组织代码sparseety_demo/ ├── requirements.txt ├── extract_hooks.py # 通过模型 Hook 提取激活稀疏度 ├── parse_vllm_logs.py # 解析 vLLM 日志提取 Token 时间线 ├── analyze_metrics.py # 计算 TTFT、TPOT、TPM 等指标 ├── output/ │ ├── token_timeline.csv │ ├── sparsity_report.csv │ └── summary.json下面逐步拆解每个文件的作用。3. Token 提取与稀疏性分析核心原理3.1 拦截 Token 生命周期的三种方式想要拿到 Token 级别的数据有三种常见路径方式一模型层 Hook对于基于 Transformers 架构的模型我们可以在模型各层注册 forward hook。当某层执行前向计算时hook 函数会收到该层的输入和输出我们可以在这里统计激活值中零元素的比例从而算出稀疏度。这种方式适合基于 Transformers / PyTorch 的推理服务优点是信息丰富缺点是性能开销相对较大且对 vLLM 等深度优化引擎不一定直接适用。方式二引擎日志解析vLLM 等 Serving 引擎在运行时会输出结构化日志通常包括请求 ID、Prompt Token 数量、生成 Token 数量、平均吞吐等字段。我们可以用脚本定时抓取并解析这些日志提取 Token 生命周期数据。方式三代理层流量捕获在服务入口或出口增加一层代理如自定义中间件从 HTTP 流式响应中按 SSE 协议解析出每个 Token 内容及时间戳。这种方式不侵入推理引擎适合对运行中的服务做观测但拿不到模型内部的稀疏度信息。3.2 稀疏率怎么算稀疏率是衡量“有多少计算被跳过”的核心指标。一般定义为矩阵中值为零的元素数占总元素数的比例。sparsity_ratio zero_count / total_count例如某一层权重矩阵有 1000 个元素其中 300 个为零那么稀疏度就是 0.3。对于激活值我们通常在经过 ReLU 激活函数之后统计零值比例因为 ReLU 会把负值统一置零形成天然的激活稀疏。在多层模型中我们可以计算每层的稀疏度然后加权平均得到整体稀疏度。注意稀疏度不是越高越好——过高的稀疏度可能意味着模型表达能力下降需要在性能和效果之间找到平衡。3.3 关键指标TTFT、TPOT、TPM 的关系在 Token 提取场景中需要重点关注三个指标TTFTTime to First Token从请求发出到收到第一个 Token 的耗时。通常由 Prefill 阶段计算时间决定。TPOTTime Per Output Token生成每个输出 Token 的平均耗时。由 Decode 阶段计算时间决定。TPMTokens Per Minute每分钟处理的 Token 总数。注意这里通常等于输入 Token 与输出 Token 的总和。三者之间的关系是TPM (输入Token数 输出Token数) / 总耗时(分钟) TTFT 关注首字延迟TPOT 关注生成节奏对优化稀疏性利用服务系统来说这几个指标可以帮助我们判断稀疏优化是缩短了 Prefill 的 TTFT还是缩短了 Decode 的 TPOT或者两者兼而有之。4. 完整实战从服务日志与推理引擎中提取 Token4.1 创建项目结构本实战分为两条采集路径一是通过 Transformers 模型 Hook 提取激活稀疏度二是通过解析 vLLM 日志提取 Token 时间线。先创建项目目录mkdir -p sparseety_demo/output cd sparseety_demo后续代码都放在sparseety_demo目录下。4.2 编写依赖文件创建requirements.txt# 文件路径sparseety_demo/requirements.txt torch2.0.0 transformers4.36.0 pandas2.0.0 numpy1.24.0 matplotlib3.7.0 vllm0.3.0 # 仅当使用 vLLM 时需要安装依赖pip install -r requirements.txt这里需要提醒由于 PyTorch 与 CUDA 的版本组合要求较高如果安装失败请优先检查 PyTorch 与 CUDA 版本是否匹配。4.3 通过模型 Hook 提取激活稀疏度我们先编写一个基于 Transformers 的 Hook 脚本。核心思路是在 Transformer 模型的每一层 FFN 输出之后注册 hook统计激活矩阵中零值比例。# 文件路径sparseety_demo/extract_hooks.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name facebook/opt-1.3b tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16).eval() # 用于保存每层稀疏度的字典 sparsity_record {} def make_hook(layer_idx): def hook_fn(module, input_tensor, output_tensor): # 只统计 ReLU 之后的激活稀疏度 if isinstance(output_tensor, tuple): acts output_tensor[0] else: acts output_tensor # 将激活值展开成二维矩阵方便统计 flat acts.reshape(-1) total flat.numel() zeros torch.sum(flat 0).item() ratio zeros / total if total 0 else 0.0 sparsity_record[layer_idx] ratio return hook_fn # 为模型每一层 FFN 注册 hook以 OPT 模型为例 for idx, layer in enumerate(model.model.decoder.layers): layer.fc2.register_forward_hook(make_hook(idx)) prompt SparSEEty is a framework for extracting tokens from sparsity-exploiting LLM serving systems. inputs tokenizer(prompt, return_tensorspt) with torch.no_grad(): outputs model(**inputs) print(各层激活稀疏度) for layer_idx, ratio in sorted(sparsity_record.items()): print(flayer {layer_idx}: {ratio:.4f}) avg_sparsity sum(sparsity_record.values()) / len(sparsity_record) print(f平均激活稀疏度{avg_sparsity:.4f})这段代码的关键点有三个register_forward_hook可以在不修改模型结构的情况下拿到每一层前向计算的输入和输出。torch.sum(flat 0).item()统计零值个数除以总元素数得到稀疏度。OPT 模型在fc2层之后通常跟着 ReLU 激活所以统计这层的输出可以很好地反映激活稀疏情况。运行脚本python extract_hooks.py预期输出如下数值会根据模型权重和输入文本不同而浮动各层激活稀疏度 layer 0: 0.8781 layer 1: 0.8543 ... 平均激活稀疏度0.7321注意这里统计到的稀疏度是“该输入下模型本身展示出的激活稀疏性”并不是稀疏化剪枝后的权重稀疏性。在实际稀疏性利用服务系统中推理引擎会基于类似的稀疏度预估跳过部分零值计算从而提升效率。4.4 从 vLLM 日志解析 Token 时间线使用 vLLM 启动一个兼容 OpenAI API 的服务python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-2-7b-chat-hf \ --gpu-memory-utilization 0.8 \ --max-model-len 4096启动后vLLM 会输出类似下面的日志INFO: Started server process [12345] INFO: Uvicorn running on http://0.0.0.0:8000 INFO: 127.0.0.1:52314 - POST /v1/completions HTTP/1.1 200 OK INFO: Processed prompts: 100%|████████████████| 1/1 [00:0000:00, 3.73it/s] INFO: Request req_001: prompt_tokens128, generated_tokens256, ttft0.823s, tpot0.041s我们可以编写脚本解析这份日志提取 Token 级别的时间线。不过这里有一个细节vLLM 默认日志不会把每个 Token 单独列出而是生成汇总摘要。如果我们需要逐 Token 的时间戳可以通过 vLLM 的日志参数开启更详细的输出例如--verbose模式或者在应用层通过 SSE 流式接口逐 Token 捕获。下面的脚本演示如何从 vLLM 的摘要日志中提取关键 Token 指标并把它转成便于分析的 DataFrame。# 文件路径sparseety_demo/parse_vllm_logs.py import re import json import pandas as pd from pathlib import Path LOG_FILE vllm.log # 请替换为实际的日志文件路径 def parse_vllm_log(log_text): records [] # 匹配形如Request req_001: prompt_tokens128, generated_tokens256, ttft0.823s, tpot0.041s pattern re.compile( rRequest\s(?Preq_id\S):\s rprompt_tokens(?Pprompt_tokens\d),\s rgenerated_tokens(?Pgenerated_tokens\d),\s rttft(?Pttft[\d.])s,\s rtpot(?Ptpot[\d.])s ) for line in log_text.splitlines(): match pattern.search(line) if match: info match.groupdict() info[prompt_tokens] int(info[prompt_tokens]) info[generated_tokens] int(info[generated_tokens]) info[ttft] float(info[ttft]) info[tpot] float(info[tpot]) # 估算总耗时和 TPM info[total_time] info[ttft] info[generated_tokens] * info[tpot] info[tpm] (info[prompt_tokens] info[generated_tokens]) / (info[total_time] / 60) records.append(info) return pd.DataFrame(records) def main(): log_path Path(LOG_FILE) if not log_path.exists(): print(f日志文件不存在{log_path}) return log_text log_path.read_text(encodingutf-8) df parse_vllm_log(log_text) if df.empty: print(未在日志中找到匹配的请求记录。) return df.to_csv(output/token_timeline.csv, indexFalse) print(解析完成结果已保存到 output/token_timeline.csv) print(df.head()) if __name__ __main__: main()运行python parse_vllm_logs.py生成结果示例req_id prompt_tokens generated_tokens ttft tpot total_time tpm 0 req_001 128 256 0.823 0.041 11.319 2035.87这个 CSV 就是我们后续分析服务性能的重要基础数据。4.5 计算稀疏度与吞吐指标并生成汇总接下来把前面两个脚本的结果汇总计算一个综合报告。这里需要注意Hook 方式拿到的稀疏度是模型内部状态日志方式拿到的是服务指标两者要关联起来比较自然的方式是按模型版本和请求输入进行“快照式”对比而不是在每秒维度上合并。# 文件路径sparseety_demo/analyze_metrics.py import json import pandas as pd def analyze_results(timeline_csvoutput/token_timeline.csv): df pd.read_csv(timeline_csv) if df.empty: print(无数据可分析) return summary { total_requests: len(df), avg_prompt_tokens: round(df[prompt_tokens].mean(), 2), avg_generated_tokens: round(df[generated_tokens].mean(), 2), avg_ttft: round(df[ttft].mean(), 4), avg_tpot: round(df[tpot].mean(), 4), avg_total_time: round(df[total_time].mean(), 4), sum_tpm: round(df[tpm].sum(), 2), } with open(output/summary.json, w, encodingutf-8) as f: json.dump(summary, f, ensure_asciiFalse, indent2) print( 汇总分析 ) for key, value in summary.items(): print(f{key}: {value}) if __name__ __main__: analyze_results()运行python analyze_metrics.py这个脚本本身并不复杂但它把可观测数据沉淀成了可量化的服务指标。在实际生产环境中这类的汇总结果可以接入 Prometheus、Grafana 等监控系统。5. 常见问题与排查思路5.1 Hook 方式拿不到激活输出问题现象常见原因解决思路hook 中 output_tensor 为 None某些层在推理时处于torch.no_grad()或推理引擎做了算子融合检查模型是否处于 eval 模式尝试在其他子模块注册 hook稀疏度全部为 0统计的层使用了 GELU 激活而非 ReLU换成统计 GELU 输出之后接近零的比例或改用更合适的稀疏判定条件补充说明GELU 激活函数不会输出大量精确的 0我们可以用“接近零”阈值来统计稀疏度比如绝对值小于 1e-6 的元素视为零。5.2 vLLM 日志中没有 Request 摘要vLLM 的日志输出格式可能随版本变化。旧版本可能不打印Request req_001这类摘要你需要确认 vLLM 版本查看官方文档中日志格式部分。检查日志级别通常需要开启 INFO 级别日志。如果确实没有摘要可以考虑通过调用 API 时自行记录时间戳或使用 vLLM 的 Metrics 端点获取指标。5.3 稀疏度很高但推理速度没有提升这是最常见也最容易误解的问题。稀疏度只是说明矩阵中存在大量零值并不代表推理引擎真正跳过了这些计算。如果服务端使用的 GPU 不支持稀疏加速或者推理引擎没有启用稀疏算子那么高稀疏度对性能没有帮助。排查顺序确认 GPU 型号检查是否支持稀疏张量加速。确认推理引擎是否启用了稀疏推理模式。在开启/关闭稀疏优化两种条件下分别跑同一组请求对比 TTFT 和 TPOT。5.4 多并发请求下 Token 时间线混乱当并发请求较多时日志中的请求记录会交叉出现。解决方案是为每个请求分配唯一 ID并在日志中打印该 ID。如果使用 vLLM建议在应用层入口给每个请求生成request_id这样日志和监控指标可以按 ID 关联。6. 最佳实践与工程建议6.1 从业务指标到 Token 指标的分层建模不要把 Token 指标直接等同于业务指标。建议建立三层指标模型业务层成功率、错误率、QPS、平均延迟。Token 层TTFT、TPOT、TPM、输入/输出 Token 数量。稀疏层激活稀疏度、权重稀疏度、专家路由分布、KV Cache 命中率。SparSEEty 这类工具的价值就在于打通这三层让“业务变慢”能向下定位到“Token 生成变慢”再进一步定位到“哪一层的稀疏利用效率下降了”。6.2 最小化采集开销Token 级采集是有开销的。在模型层频繁注册 hook 会导致推理性能明显下降。生产环境建议默认只做日志解析和 API 层 Token 捕获不启用模型 Hook。需要做模型内部稀疏分析时通过开关控制只对部分请求开启。采样率建议从 1% 开始逐步调整找到一个平衡点。6.3 稀疏度分析结果要结合生成质量一起看稀疏优化往往以牺牲部分表达能力为代价。当我们发现某个模型层的稀疏度异常偏高时建议同步检查该请求的生成结果质量比如困惑度Perplexity变化、回答长度、关键信息完整度等。不要只看性能指标。6.4 日志格式规范化日志格式一定要结构化。推荐使用 JSON Lines 格式记录 Token 事件{request_id: req_001, event: token_generated, token_id: 123, timestamp: 1700000000.456, tpot: 0.041, seq_idx: 1}结构化日志的好处是可以直接被 Fluentd、Logstash 等采集工具消费也便于后续做更复杂的关联分析。6.5 安全与权限边界当我们在生产环境做 Token 级信息采集时要特别注意数据安全。LLM 服务的输入输出可能包含用户敏感信息。进行日志采集、存储和分析时应遵循最小权限原则尽量不记录完整 Prompt 和完整输出文本。记录 Token ID 即可满足大部分分析需求避免将原始文本落入日志系统。如果是文本需要留痕必须做脱敏处理并对日志系统做访问控制。不要在生产环境把 Token 级日志长期保存在通用存储中。7. 总结本文围绕“从稀疏性利用 LLM 服务系统中提取 Token”这一主题完整梳理了相关概念和实战流程。我们从稀疏性在 LLM 服务系统中的意义讲起区分了权重稀疏、激活稀疏、KV Cache 稀疏和 MoE 专家稀疏接着介绍了 Token 生命周期和 TTFT、TPOT、TPM 等关键指标并通过三个可运行的 Python 脚本演示了如何通过模型 Hook 提取激活稀疏度、如何解析 vLLM 日志得到 Token 时间线、如何汇总服务性能指标。如果你正在搭建 LLM 服务的可观测体系下一步可以从三个方向继续深入第一把本文的采集逻辑封装为常驻服务并接入 Prometheus 指标体系第二把 Token ID 与文本脱敏规则结合起来设计更完善的数据采集策略第三研究不同稀疏优化策略下的 Token 质量变化建立性能与效果的联合监控视图。在项目落地时我最想提醒你的一点是Token 提取的价值不在于监控本身而在于把“服务表现”和“内部计算状态”关联起来。只有当你能够回答“某个 Token 为什么会特别慢”“这一层稀疏度提升了为什么总体吞吐没变化”这类问题时这套观测体系才算真正发挥了作用。如果本文对你有帮助可以收藏备用。你在实际项目里碰到过哪些与 Token 观测或稀疏推理相关的坑欢迎在评论区分享你的排查经验。