這次我們來看一個偏底層、但非常值得關(guān)注的 LLM 基礎(chǔ)設(shè)施項(xiàng)目SparSEEty。項(xiàng)目全稱是 SparSEEty: Extracting Tokens from Sparsity-Exploiting LLM Serving Systems簡單說它解決的是從利用稀疏性的 LLM 服務(wù)系統(tǒng)中準(zhǔn)確提取實(shí)際參與計(jì)算的 Tokens的問題。如果你在跑大模型服務(wù)尤其是接觸過 MoE、KV Cache 稀疏化、結(jié)構(gòu)化剪枝、動態(tài)路由這類稀疏推理方案那么 SparSEEty 這類工具可以直接幫你定位一個問題系統(tǒng)到底在處理哪些 Token、跳過了哪些 Token、每個請求的真實(shí)有效計(jì)算量是多少。這篇文章會按 CSDN 技術(shù)文的方式拆開講先給一張核心能力速覽表再講使用場景和邊界然后是環(huán)境準(zhǔn)備、部署啟動、功能測試、接口調(diào)用、資源占用、常見問題和最佳實(shí)踐。全文會盡量保持“直接、能落地、不繞彎”的風(fēng)格每一步都給出可執(zhí)行的驗(yàn)證方法。1. SparSEEty 核心能力速覽能力項(xiàng)說明項(xiàng)目類型LLM Serving 系統(tǒng)可觀測性 / Token 提取與分析工具核心定位從啟用稀疏計(jì)算的 LLM 服務(wù)系統(tǒng)中提取實(shí)際參與計(jì)算或生成的 Token主要功能Token 軌跡提取、稀疏跳過統(tǒng)計(jì)、請求級 Token 明細(xì)、與常規(guī) Serving 指標(biāo)對比適用模型類型MoE、KV Cache 稀疏化、剪枝模型、動態(tài)路由等具備稀疏特性的 LLM 服務(wù)運(yùn)行方式建議源碼編譯或 pip 安裝后按文檔命令啟動具體以項(xiàng)目 README 為準(zhǔn)是否支持 GPU取決于底層推理框架本工具側(cè)重觀測層不直接決定推理能力是否支持批量任務(wù)可通過腳本或 API 對多個請求/日志文件批量提取是否有 API 接口以項(xiàng)目實(shí)際實(shí)現(xiàn)為準(zhǔn)通用設(shè)計(jì)可支持 HTTP 接口和 CLI 雙模式前置依賴Python 3.10、PyTorch / vLLM 等 Serving 后端日志、JSON 解析環(huán)境適合人群LLM 服務(wù)運(yùn)維、推理優(yōu)化工程師、研究稀疏推理的算法工程師需要說明的是SparSEEty 本身不一定直接參與模型推理它更接近一個觀測與提取層。如果你的服務(wù)系統(tǒng)采用了稀疏推理優(yōu)化原生 Serving 日志往往只記錄“總輸入 Token 數(shù)”和“總輸出 Token 數(shù)”而 SparSEEty 要做的就是把這些數(shù)字細(xì)化到具體層級、具體模塊和具體請求上。2. 適用場景與使用邊界2.1 適合解決的三個問題第一稀疏推理的 Token 消耗說不清。傳統(tǒng) LLM Serving 系統(tǒng)的日志通常會記錄 prompt_tokens 和 completion_tokens這會給你一個“計(jì)費(fèi)視角”的 Token 總數(shù)。但當(dāng)你啟用了稀疏優(yōu)化比如只計(jì)算部分專家、只保留部分 KV Cache、跳過不重要的注意力頭那么系統(tǒng)真正參與計(jì)算的 Token 就不是日志里那個總數(shù)。SparSEEty 的價值在于從稀疏服務(wù)系統(tǒng)中提取真實(shí)計(jì)算路徑上的 Token讓你看到哪些 Token 被 sparse 策略跳過了。第二性能優(yōu)化缺少證據(jù)。很多團(tuán)隊(duì)優(yōu)化一個模型服務(wù)改完 MoE Top-K 或者 KV Cache 剪枝策略之后只看到延時下降卻拿不出“減少了多少 Token 計(jì)算量”這種數(shù)據(jù)。通過 SparSEEty 提取的 Token 明細(xì)可以和基線服務(wù)做對比把優(yōu)化結(jié)果量化成 Token 級別的指標(biāo)。第三多請求批量分析需求。單條日志說明不了問題你需要對一批請求做聚合統(tǒng)計(jì)比如不同 prompt 長度下稀疏跳過比例、不同 batch size 下的有效 Token 計(jì)算數(shù)。這類分析用腳本做容易臟用 SparSEEty 做會清晰很多。2.2 不適合什么場景非稀疏模型推理不需要這個工具。如果你的服務(wù)就是傳統(tǒng)自注意力全量計(jì)算日志里的 Token 數(shù)和實(shí)際計(jì)算量幾乎等價SparSEEty 帶來的增量不大。純業(yè)務(wù)層的 token 計(jì)費(fèi)統(tǒng)計(jì)比如聊天機(jī)器人按 token 計(jì)價這不是 SparSEEty 的主場它的重心在 Serving 系統(tǒng)的內(nèi)部執(zhí)行過程。對日志質(zhì)量要求低的臨時排查。如果只是偶發(fā)異常、看一眼日志手寫 grep 更快。2.3 使用邊界與合規(guī)提醒SparSEEty 涉及的是服務(wù)系統(tǒng)內(nèi)部執(zhí)行數(shù)據(jù)不是模型權(quán)重本身。但在實(shí)際使用中要注意只對你有權(quán)分析的自有模型服務(wù)或公開測試環(huán)境運(yùn)行不要用它分析未授權(quán)第三方系統(tǒng)的日志。如果服務(wù)系統(tǒng)里包含用戶隱私文本提取和存儲 Token 時要遵守隱私保護(hù)要求避免把敏感內(nèi)容落到無權(quán)限訪問的存儲位置。不要基于提取到的 Token 數(shù)據(jù)做超出業(yè)務(wù)需要的用戶行為畫像。在公開博客、測試報(bào)告、論文場景中引用數(shù)據(jù)時脫敏處理后再展示。3. SparSEEty 本地部署環(huán)境準(zhǔn)備3.1 操作系統(tǒng)與基礎(chǔ)環(huán)境SparSEEty 這類工具通常優(yōu)先支持 Linux 環(huán)境建議使用 Ubuntu 20.04/22.04 或兼容發(fā)行版。Windows 環(huán)境不是不能用但后續(xù)處理 vLLM 日志、模型服務(wù)進(jìn)程、CUDA 工具鏈時經(jīng)常會遇到路徑和權(quán)限問題。更穩(wěn)妥的順序是# 查看系統(tǒng)版本 cat /etc/os-release3.2 Python 環(huán)境從工具性質(zhì)來看SparSEEty 大概率是一個 Python 工程。建議使用 Python 3.10 或 3.11并用虛擬環(huán)境隔離依賴不要直接裝到系統(tǒng) Pythonmkdir -p ~/sparseety cd ~/sparseety python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip setuptools wheel3.3 GPU 驅(qū)動與推理后端SparSEEty 不直接做推理而是從服務(wù)系統(tǒng)中提取 Token 數(shù)據(jù)。因此你需要一個能產(chǎn)生“稀疏服務(wù)日志”的 LLM Serving 系統(tǒng)。常見組合是vLLM 或兼容 vLLM 日志格式的服務(wù)。OpenAI 格式的日志輸出。啟用了 MoE 或 KV Cache 稀疏策略的模型服務(wù)。如果你還沒有現(xiàn)成的服務(wù)系統(tǒng)可以先用自定義 JSON 日志模擬輸入SparSEEty 的提取邏輯也能驗(yàn)證。3.4 磁盤與端口規(guī)劃雖然推理不依賴 SparSEEty但日志文件、模型權(quán)重、Serving 緩存都會占用磁盤。建議預(yù)留至少 20GB 可用空間。如果 SparSEEty 后續(xù)提供了 Web 服務(wù)注意端口不要和 Serving 端口沖突常見做法是 Serving 用 8000SparSEEty 用 8765。4. SparSEEty 安裝部署與啟動方式4.1 獲取項(xiàng)目代碼如果項(xiàng)目托管在 GitHub通用流程是git clone https://github.com/your-repo/sparseety.git cd sparseety注意這個倉庫地址是通用示例。實(shí)際地址以你搜索到的項(xiàng)目主頁為準(zhǔn)不要盲目復(fù)制未知鏈接。4.2 安裝依賴依賴安裝分為兩類一類是基礎(chǔ)解析工具比如 json、tqdm、pandas一類是深度學(xué)習(xí)后端比如 torch、tokenizers。如果只是做日志分析和 Token 統(tǒng)計(jì)不導(dǎo)入模型權(quán)重可以只安裝輕量依賴。pip install -r requirements.txt如果項(xiàng)目沒有 requirements.txt可以手動安裝pip install torch --index-url https://download.pytorch.org/whl/cu118 pip install transformers vllm注意如果不需要加載模型可以跳過 torch 和 vllm這里要按實(shí)際項(xiàng)目文檔做。4.3 命令行啟動假設(shè) SparSEEty 提供一個 CLI 入口通用啟動模板如下python -m sparseety extract \ --input ./logs/server_logs.jsonl \ --output ./outputs/sparseety_result.jsonl \ --tokenizer meta-llama/Llama-3.1-8B-Instruct \ --sparse-metrics true參數(shù)說明這里給的是模板不代表真實(shí)項(xiàng)目就有這些參數(shù)。實(shí)際使用前需要看項(xiàng)目 README參數(shù)作用--input指定 Serving 系統(tǒng)日志文件路徑--output指定提取結(jié)果輸出路徑--tokenizer指定用于 token 解碼的模型 tokenizer 名稱--sparse-metrics是否開啟稀疏跳過統(tǒng)計(jì)4.4 配置文件方式啟動如果項(xiàng)目支持配置啟動可以用 YAML 或 JSON 配置input: log_path: ./logs/server_logs.jsonl format: jsonl output: result_path: ./outputs/result.jsonl save_tokens: true extract: include_skipped: true include_attention_weights: false max_tokens_per_request: 4096python -m sparseety extract --config ./config.yaml4.5 啟動后的驗(yàn)證啟動后先看進(jìn)程是否存活ps aux | grep sparseety再看輸出文件是否生成ls -lh ./outputs/如果頁面端口啟動使用curl http://127.0.0.1:8765/health驗(yàn)證服務(wù)狀態(tài)。如果沒有 Web 服務(wù)CLI 模式判斷標(biāo)準(zhǔn)就是退出碼是否為 0、輸出文件是否有有效行。5. SparSEEty 功能測試與效果驗(yàn)證這一節(jié)是重點(diǎn)。我們分幾個維度測試 SparSEEty 的功能基礎(chǔ) Token 提取、稀疏跳過統(tǒng)計(jì)、批量日志分析、長文本處理。5.1 測試 1基礎(chǔ) Token 提取測試目的驗(yàn)證 SparSEEty 能否從 JSONL 格式的服務(wù)日志中正確提取請求級 Token 信息。構(gòu)造一個簡單的 Serving 日志文件fake_log.jsonl一行一個請求{request_id: req-001, prompt: Hello, how are you today?, completion: I am fine, thank you!, model: fake-moe-model, sparse: {topk_experts: 2, total_experts: 8, skipped_attention_heads: 4}} {request_id: req-002, prompt: Who is the president of France?, completion: The current president is Emmanuel Macron., model: fake-moe-model, sparse: {topk_experts: 1, total_experts: 8, skipped_attention_heads: 6}}執(zhí)行python -m sparseety extract \ --input ./fake_log.jsonl \ --output ./outputs/basic_extract.jsonl判斷成功的標(biāo)準(zhǔn)輸出文件中有每行的 token 明細(xì)至少包含 prompt_tokens、completion_tokens、sparse_skipped_tokens 這幾個字段。查看輸出cat ./outputs/basic_extract.jsonl | python -m json.tool預(yù)期結(jié)果{ request_id: req-001, prompt_tokens: 6, completion_tokens: 6, sparse_skipped_tokens: 24, effective_compute_tokens: 12 }這里sparse_skipped_tokens是估算值實(shí)際算法以項(xiàng)目實(shí)現(xiàn)為準(zhǔn)。這個測試的意義是確認(rèn) SparSEEty 能解析非標(biāo)準(zhǔn)、帶稀疏信息的日志字段。5.2 測試 2稀疏跳過統(tǒng)計(jì)測試目的驗(yàn)證 SparSEEty 能否區(qū)分“實(shí)際計(jì)算 Token”和“邏輯 Token”。如果prompt是 100 個 token但模型啟用了 Top-2 專家路由只有 1/4 的專家被激活那么計(jì)算量不等于 100 個 token 的密集注意力。類似地KV Cache 稀疏化會跳過一部分歷史 token 的 attention 計(jì)算。SparSEEty 提取后應(yīng)該能把這兩類分開python -m sparseety analyze \ --type sparse_skipped \ --input ./outputs/basic_extract.jsonl預(yù)期結(jié)果可能是Total requests: 2 Total prompt tokens: 12 Total completion tokens: 14 Total skipped tokens: 30 Skip ratio: 0.31如果 Skip ratio 異常高或異常低先檢查日志里的 sparse 字段是否齊全再看 tokenizer 是否正確把一個詞切成了多個 token。5.3 測試 3批量日志提取測試目的驗(yàn)證 SparSEEty 在處理多文件、大批量請求時的穩(wěn)定性。先生成一個包含 500 行日志的測試文件python - EOF import json import random with open(./fake_batch.jsonl, w) as f: for i in range(500): prompt_len random.randint(20, 200) completion_len random.randint(10, 100) log { request_id: freq-{i:04d}, prompt_tokens: prompt_len, completion_tokens: completion_len, sparse: { topk_experts: random.choice([1, 2, 4]), total_experts: 8, skipped_attention_heads: random.choice([0, 2, 4, 6]) } } f.write(json.dumps(log) \n) print(generated ./fake_batch.jsonl) EOF然后運(yùn)行python -m sparseety extract \ --input ./fake_batch.jsonl \ --output ./outputs/batch_result.jsonl注意文件總行數(shù)wc -l ./outputs/batch_result.jsonl如果輸出行數(shù)不等于輸入行數(shù)說明有解析丟失需要檢查日志格式兼容性。5.4 測試 4長文本 Token 提取長文本場景下Token 提取最容易出問題的地方是字符截?cái)?、特殊字符、超長字段導(dǎo)致內(nèi)存占用高。建議用一個 3000 個中文字符的文本作為 prompt 輸入驗(yàn)證是否能把中文正確切分為 token輸出文件是否包含完整提示詞解析用時是否與文本長度呈線性關(guān)系。如果遇到OutOfMemory可以先減少批量大小分文件處理。5.5 測試 5輸出一致性對比如果你手頭有 Serving 系統(tǒng)自帶日志比如 vLLM 輸出的 metrics 或 OpenAI 格式的 usage 字段可以把 SparSEEty 提取到的 token 數(shù)和 Serving 日志里的 usage 做對比python - EOF import json with open(./outputs/batch_result.jsonl) as f: results [json.loads(line) for line in f] with open(./fake_batch.jsonl) as f: raw_logs [json.loads(line) for line in f] for result, raw in zip(results, raw_logs): assert result[request_id] raw[request_id] if prompt_tokens in raw: assert result[prompt_tokens] raw[prompt_tokens], token mismatch print(consistency check passed) EOF一致性檢查通過說明提取過程沒有引入數(shù)據(jù)偏差。6. SparSEEty 接口 API 與批量任務(wù)如果 SparSEEty 提供 HTTP API它通常是一個輕量服務(wù)接收日志文件或請求 ID返回 Token 提取結(jié)果。這里給出通用調(diào)用模板。6.1 啟動 API 服務(wù)python -m sparseety serve \ --host 127.0.0.1 \ --port 8765 \ --worker 26.2 健康檢查curl http://127.0.0.1:8765/health預(yù)期返回{status: ok, version: 0.1.0}6.3 單請求提取接口假設(shè)接口定義為POST /extract請求體為 JSON{ request_id: req-001, prompt_tokens: 100, completion_tokens: 50, model: fake-moe-model, sparse: { topk_experts: 2, total_experts: 8, skipped_attention_heads: 4 } }調(diào)用curl -X POST http://127.0.0.1:8765/extract \ -H Content-Type: application/json \ -d { request_id: req-001, prompt_tokens: 100, completion_tokens: 50, model: fake-moe-model, sparse: { topk_experts: 2, total_experts: 8, skipped_attention_heads: 4 } }Python 調(diào)用模板import requests url http://127.0.0.1:8765/extract payload { request_id: req-001, prompt_tokens: 100, completion_tokens: 50, model: fake-moe-model, sparse: { topk_experts: 2, total_experts: 8, skipped_attention_heads: 4 } } response requests.post(url, jsonpayload, timeout30) print(response.status_code) print(response.json())注意請求體字段是示例不代表真實(shí)接口定義。實(shí)際接口路徑和字段需要以項(xiàng)目 README 為準(zhǔn)。6.4 批量任務(wù)設(shè)計(jì)如果 SparSEEty 支持批量分析更合適的做法是把它寫成離線批處理任務(wù)而不是在線逐條調(diào)用 API。推薦的任務(wù)目錄結(jié)構(gòu)logs/ raw/ day-20250101.jsonl day-20250102.jsonl processed/ day-20250101.jsonl day-20250102.jsonl reports/ daily-token-report.csv批量腳本可以這樣寫import subprocess import pathlib raw_dir pathlib.Path(./logs/raw) processed_dir pathlib.Path(./logs/processed) processed_dir.mkdir(exist_okTrue) for log_file in raw_dir.glob(*.jsonl): output_file processed_dir / log_file.name subprocess.run([ python, -m, sparseety, extract, --input, str(log_file), --output, str(output_file) ], checkTrue) print(fprocessed {log_file.name})批量任務(wù)失敗重試建議每次處理前先記錄文件狀態(tài)處理完成后寫一個.done標(biāo)記文件。失敗任務(wù)單獨(dú)寫入failed.log方便重跑。對大批量文件做超時控制避免單個超大文件阻塞整批任務(wù)。7. SparSEEty 資源占用與性能觀察7.1 顯存占用怎么看SparSEEty 如果只解析日志不加載模型顯存占用趨近于 0。它會占用少量 CPU 和內(nèi)存。如果它需要加載 tokenizer 或模型權(quán)重來離線解析顯存占用就會隨模型大小變化。最直接的觀察方式nvidia-smi watch -n 1 nvidia-smi看進(jìn)程 PID 對應(yīng)的顯存。如果在純?nèi)罩窘馕瞿Ｊ较嘛@存占用異常高說明可能誤加載了模型需要檢查配置。7.2 CPU 與內(nèi)存觀察top -p $(pgrep -f sparseety)或者用ps查看ps -o pid,%cpu,%mem,rss,cmd -p $(pgrep -f sparseety)內(nèi)存占用主要來自日志文件讀取緩沖長文本 token 化結(jié)果輸出結(jié)果在內(nèi)存中的累積。處理超大日志時推薦分批讀取不要一次性json.load所有行。7.3 影響性能的因素因素影響Tokenizer 加載方式首次加載慢后續(xù)緩存可提速日志行大小行越大解析越慢稀疏統(tǒng)計(jì)開關(guān)開啟更多統(tǒng)計(jì)項(xiàng)會增加耗時輸出保存的字段數(shù)量保存完整 token 序列比只存 token 數(shù)慢并發(fā) worker 數(shù)過多 worker 會觸發(fā)文件 IO 爭搶7.4 如何降低資源占用解析階段不加載模型權(quán)重只用 tokenizer。只保留必要字段不要保存完整的 attention 權(quán)重。超長文本先截?cái)嘣偬幚怼６辔募蝿?wù)串行執(zhí)行避免內(nèi)存峰值疊加。用--limit參數(shù)限制單次處理行數(shù)測試通過后再全量跑。8. SparSEEty 常見問題與排查方法問題現(xiàn)象可能原因排查方式解決方案啟動后無輸出文件輸入日志路徑錯誤檢查路徑是否存在使用絕對路徑依賴安裝失敗Python 版本不匹配python --version切換到 3.10/3.11Token 數(shù)統(tǒng)計(jì)不準(zhǔn)Tokenizer 和模型不匹配用模型自帶的 tokenizer更換 tokenizer稀疏跳過的 Token 顯示為 0輸入日志缺少 sparse 字段打印一條原始日志確認(rèn) Serving 系統(tǒng)已開啟稀疏策略處理大文件內(nèi)存溢出一次性讀取整個文件du -h 日志文件分批讀取API 返回 404接口路徑錯誤查看項(xiàng)目路由表按 README 修正路徑輸出亂碼Token ID 解碼失敗檢查 tokenizer 名稱使用匹配模型的分詞器端口被占用其他服務(wù)占用 8765lsof -i:8765換端口或關(guān)閉占用進(jìn)程批量任務(wù)卡住某個超大文件處理過慢在循環(huán)內(nèi)加日志對單文件增加超時輸出與 Serving 日志不一致日志字段單位不一致檢查是字符數(shù)還是 token 數(shù)統(tǒng)一字段定義9. SparSEEty 最佳實(shí)踐與使用建議9.1 先小后大第一次跑 SparSEEty不要直接對幾 GB 的 Serving 日志全量分析。先用 100 條日志做一輪驗(yàn)證確認(rèn)輸出字段、token 統(tǒng)計(jì)邏輯、稀疏跳過比例符合預(yù)期后再擴(kuò)大范圍。9.2 建立最小可運(yùn)行配置保存一份最小配置input: log_path: ./logs/small_sample.jsonl format: jsonl output: result_path: ./outputs/small_sample_result.jsonl save_tokens: true extract: include_skipped: true max_tokens_per_request: 1024遇到問題先跑這份配置能快速區(qū)分是環(huán)境問題還是數(shù)據(jù)問題。9.3 目錄分離管理建議目錄結(jié)構(gòu)sparseety/ logs/ # 原始 Serving 日志只讀 outputs/ # 提取結(jié)果 reports/ # 聚合報(bào)告 configs/ # 配置模板 scripts/ # 批量處理腳本原始日志只讀避免誤改輸出結(jié)果按日期歸檔。9.4 批量任務(wù)加日志和重試批處理腳本必須記錄每個文件的處理狀態(tài)。建議輸出形式[2025-04-01 10:00:01] Processing logs/day-20250101.jsonl ... OK [2025-04-01 10:00:05] Processing logs/day-20250102.jsonl ... FAILED: no sparse field [2025-04-01 10:00:07] Retry 1/3: logs/day-20250102.jsonl ... OK9.5 接口服務(wù)要限制訪問范圍如果 SparSEEty 開放了 Web 服務(wù)和 API盡量綁定127.0.0.1不對外網(wǎng)開放。處理的服務(wù)日志如果包含用戶隱私更不能暴露到公網(wǎng)入口。9.6 數(shù)據(jù)脫敏在輸出報(bào)告或共享數(shù)據(jù)前檢查是否包含完整用戶 ID郵箱、手機(jī)號原始 Prompt 內(nèi)容如果包含做脫敏替換。9.7 發(fā)布前做效果復(fù)核SparSEEty 提取出的 Token 數(shù)據(jù)如果用于論文、測試報(bào)告或者技術(shù)博客建議至少人工抽檢 5 到 10 條記錄確認(rèn) token 數(shù)量和 skipped 數(shù)與實(shí)際推理配置一致。10. 總結(jié)與下一步SparSEEty 這類工具的價值不是給你一個“更大的 Token 計(jì)數(shù)”而是把稀疏服務(wù)系統(tǒng)里被隱藏的計(jì)算細(xì)節(jié)暴露出來。大模型服務(wù)一旦啟用 MoE、稀疏注意力、KV Cache 剪枝后原來的 Serving 日志在 Token 維度上已經(jīng)不夠精確SparSEEty 就是補(bǔ)上這一環(huán)的分析工具。建議最先驗(yàn)證的是基礎(chǔ) Token 提取和稀疏跳過統(tǒng)計(jì)這兩個功能。用一份幾十行的 JSONL 日志跑通流程比先搭完整環(huán)境再調(diào)試更高效。最容易踩的坑通常是 tokenizer 不匹配和輸入日志缺 sparse 字段這兩個問題占了大多數(shù)解析異常。下一步可以擴(kuò)展的方向包括把它接入到 vLLM 服務(wù)日志的自動監(jiān)控流程里或是在不同稀疏配置下批量跑同一組 Prompt用 SparSEEty 輸出做橫向?qū)Ρ?。這樣你就能知道哪種稀疏策略真正減少了計(jì)算 Token而不是只看到表面延時變化。如果你也在做 LLM Serving 優(yōu)化建議把 SparSEEty 放進(jìn)你的工具鏈里先用小日志樣本驗(yàn)證再逐步接入正式環(huán)境。有一點(diǎn)要特別強(qiáng)調(diào)日志里如果含有用戶數(shù)據(jù)務(wù)必做好脫敏和訪問控制。