尧图网页设计 
简介《智慧城市低成本方案DeepSeek-V3微调实现交通流量预测》是一份面向智慧城市交通管理、AI应用开发与大数据分析学习者的27页PDF技术文档聚焦在预算受限条件下如何借助DeepSeek-V3大模型完成交通流量预测。文档从智慧城市与交通流量预测背景切入系统梳理DeepSeek-V3的架构原理、优势与相关应用并完整覆盖数据收集与清洗、特征工程、数据划分、模型加载与微调参数设置、训练循环与评估等流程同时给出模型融合、部署与实时预测、超参数调优及低成本硬件与数据成本控制策略。包内仅含1个PDF文件大小约1.9MB页面与图表目录显示正常便于逐章查阅。资源已有74人学习适合希望以较低成本把大模型微调落地到交通预测场景的研究人员、工程师与研究生参考可据此理解从数据预处理到微调、评估与部署的完整项目链路。1. 预算只有一张卡时交通流量预测为什么还值得动 DeepSeek-V3一个地级市的信号配时优化项目两百多个路口15 分钟粒度的卡口过车数据要做未来 1 到 8 个时段的短时流量预测。预算表里没有八卡集群只有一台带 4090 或 A6000 的推理机。这类活儿以前交给 LightGBM 加一堆手工特征MAPE 压到 12% 上下就卡住了碰上节假日和突发降雨误差能翻三倍。近两年跑出来的另一条路是把「历史流量序列 天气 星期 节假日标记」写成一整段指令让模型做序列补全直接吐出未来若干时段的数值再在交通数据上做 LoRA 参数高效微调。样本构造、评测方式和传统时序模型完全不同但算力门槛被 LoRA 拉到了单卡能碰的高度。下面写给手里有交通卡口数据、有智慧城市交付压力、算力却不宽裕的一线工程师。2. 把路网流量改写成 DeepSeek-V3 能吃的指令样本2.1 智慧城市路网数据里三种序列切分的取舍原始数据通常长这样intersection_id, timestamp, flow, lane_count, weather, is_holiday。切样本的方式直接决定模型能学到什么常见的有三种选错了后面调参全是白费功夫。切分方式单路口年样本量级优势风险适用场景滑窗切分3 万条以上样本多训练收敛快相邻样本高度自相关验证集虚高快速验证方案可行性按天切分365 条左右天然对齐日周期样本太少长尾覆盖差路口数量多时按路口聚合事件切分几十到几百条覆盖节假日、降雨、事故样本量最小必须与滑窗混用补齐长尾误差我的习惯是滑窗为主、事件为辅按 7:1:2 的比例混合。单纯用滑窗模型会在工作日平峰上表现很好一到国庆就歇菜单纯用事件切分样本量根本撑不起一次微调。2.2 15 分钟粒度流量的 prompt 模板与字段设计输入侧不要让模型去数逗号分隔的数字把它结构化成 JSON 更稳输出也约束成 JSON后处理省一半力气。import json def build_sample(history, future, meta): history: list[float] 过去 8 个时段的流量2 小时 future: list[float] 未来 4 个时段的流量1 小时推理时为空 meta: dict 天气、星期、节假日、路口编号 prompt { task: traffic_flow_forecast, intersection: meta[intersection_id], interval_minutes: 15, history_flow: history, # 长度固定为 8 weekday: meta[weekday], # 1-7 is_holiday: meta[is_holiday], # 0/1 weather: meta[weather] # clear / rain / snow / fog } answer {future_flow: future} # 长度固定为 4 # sharegpt 格式兼容 LLaMA-Factory 的格式化器 return { messages: [ {role: user, content: json.dumps(prompt, ensure_asciiFalse)}, {role: assistant, content: json.dumps(answer, ensure_asciiFalse)} ] }序列长度固定有两个好处一是cutoff_len好设二是模型不会因为历史长度变化而改变输出节奏。interval_minutes写进 prompt 是为了让同一套权重能同时服务 5 分钟和 15 分钟两种粒度代价是推理时必须在 prompt 里显式给出漏了就默认按 15 分钟处理。2.3 时间序列做监督微调时最容易踩的数据泄漏排第一的是标准化。用全量数据算均值和方差再归一化等于把未来信息灌进了训练集离线指标会好看得离谱上线就崩。正确做法是只用训练时间段的统计量验证和测试阶段复用同一组参数上线后按季度滚动重算。排第二是随机 shuffle。流量序列的划分必须按时间切训练集取前 70% 的日期验证集中间 10%测试集最后 20%。一旦随机打乱模型见过「明天」再去预测「今天」MAE 能低到 0.5纯属自欺欺人。排第三是特征穿越。prompt 里写了「未来 1 小时是否降雨」实际预测时天气预报的准确率根本到不了这个程度。天气字段只能用当前时刻实测值或者用预报值但训练时也统一用预报值两边口径必须一致。注意数据泄漏在时序任务里很少是显式的 bug多数时候是流程顺序错了——先划分再处理永远比先处理再划分安全。3. LoRA 微调 DeepSeek 系列的显存账与最小可跑配置3.1 先算显存DeepSeek-V3 本体为什么不适合低成本 LoRALoRA 省的是梯度、优化器状态和一部分激活主干的权重和激活照样要驻留显存。DeepSeek-V3 是 MoE 架构总参数 671B 量级BF16 权重本身就要 1.3TB 上下这不是「一张卡能不能跑」的问题是「一台机器装不装得下」的问题。把账算清楚选型就不会走偏。模型规模BF16 权重全参微调AdamWLoRA 冻结主干单卡可行性7B~14GB~110GB~20GB24GB 卡可跑14B~28GB~220GB~36GB48GB 卡可跑32B~64GB~500GB~80GB需 2×80GBDeepSeek-V3MoE~1.3TB不现实权重仍需 1.3TB单机不可行所以标题里的「低成本」落地时通常拆成两条路一是用 DeepSeek-V3 的接口批量生成高质量样本把它当老师蒸馏到 7B / 14B 这一档模型上做 LoRA二是直接对 DeepSeek 官方放出的蒸馏系列Qwen、Llama 底的 7B、14B、32B做 PEFT。前者成本在 API 调用和标注清洗后者成本在租几小时多卡。两条我都做过路口数少于 500 的场景第一条更划算。3.2 LoRA 的秩、目标模块与 MoE 层的坑LoRA 用两个低秩矩阵近似权重更新量rank决定表达能力alpha决定缩放强度实际生效的缩放系数是alpha / rank。交通流量这种数值回归味道很重的任务rank16到rank32就够了再大只会过拟合到某个路口的特有模式上。MoE 模型有个容易被忽略的点lora_target设成all会把专家层的 FFN 也挂上适配器可训练参数会膨胀好几倍而收益往往不明显。我一般只挂注意力部分的q_proj, k_proj, v_proj, o_proj先把这部分调透再说。参数推荐值说明lora_rank16数值任务足够超过 32 收益递减lora_alpha32取 rank 的两倍缩放系数为 2lora_dropout0.05交通数据噪声大留一点正则learning_rate1e-4LoRA 常用起点崩了就降到 5e-5num_train_epochs3超过 3 轮基本开始背样本cutoff_len204884 个时段加 meta512 都够留余量3.3 用 LLaMA-Factory 跑一次交通流量 LoRA 微调一站式微调平台省掉了手写训练循环的功夫数据注册和启动各一个文件。// data/dataset_info.json 里追加一条 { traffic_flow_sft: { file_name: traffic_flow_sft.jsonl, formatting: sharegpt, columns: { messages: messages } } }# train_traffic_lora.yaml model_name_or_path: /models/deepseek-distill-14b # 已下载到本地的底座 stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 lora_target: q_proj,k_proj,v_proj,o_proj # MoE 不挂专家层 dataset: traffic_flow_sft template: deepseek cutoff_len: 2048 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 # 等效 batch 16 learning_rate: 1.0e-4 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.05 bf16: true gradient_checkpointing: true # 用时间换显存 output_dir: /out/traffic_lora logging_steps: 10 save_steps: 200启动命令llamafactory-cli train train_traffic_lora.yamlgradient_accumulation_steps是显存不够时唯一正确的补偿手段不要靠调大per_device_train_batch_size硬顶14B 模型在 48GB 卡上单卡 batch 超过 4 就很容易 OOM。gradient_checkpointing会拖慢 20% 到 30% 的训练速度换来接近一半的激活显存单卡场景基本必开。template必须和底座匹配填错了模型学不到东西loss 会一直平在 2.0 附近不动。3.4 不用一站式平台时的 peft 最小脚本如果环境不允许装额外依赖直接上peft也没多少代码。import torch, json from datasets import load_dataset from peft import LoraConfig, get_peft_model from transformers import (AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer) MODEL /models/deepseek-distill-14b tok AutoTokenizer.from_pretrained(MODEL, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( MODEL, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue) cfg LoraConfig( r16, lora_alpha32, lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj], task_typeCAUSAL_LM) model get_peft_model(model, cfg) model.print_trainable_parameters() # 先看可训练参数占比0.1%~1% 是正常区间 def tokenize(ex): text tok.apply_chat_template(ex[messages], tokenizeFalse) out tok(text, truncationTrue, max_length2048, paddingmax_length) out[labels] out[input_ids].copy() # 因果语言建模labels 等于输入 return out ds load_dataset(json, data_filestraffic_flow_sft.jsonl, splittrain) ds ds.map(tokenize, remove_columnsds.column_names) args TrainingArguments( output_dir/out/traffic_lora, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate1e-4, num_train_epochs3, bf16True, gradient_checkpointingTrue, logging_steps10, save_steps200, save_total_limit3) Trainer(modelmodel, argsargs, train_datasetds).train() model.save_pretrained(/out/traffic_lora/final)labels复制input_ids表示对整段序列算损失包括 user 部分。想只对回答算损失就得把 user 段 token 置为 -100多数场景不改也能收敛但样本很短时会把大量容量浪费在拟合输入上。save_total_limit3是防止几十个 checkpoint 把盘塞满LoRA 权重虽然只有几十兆checkpoint 目录里往往还带着优化器状态。4. 交通流量预测的评测与五种典型崩法4.1 MAE、RMSE、MAPE 的代码实现与口径统一指标口径不统一是返工的头号原因。MAPE 在夜间低流量时段会炸分母接近 0 时单独几个点就能把均值拉上天实际汇报时我一般同时给 MAE 和按流量分档的 MAPE。import numpy as np def metrics(y_true, y_pred, eps1e-3): y_true/y_pred: shape [N, 4]4 个预测时段 y_true, y_pred np.asarray(y_true), np.asarray(y_pred) mae np.abs(y_true - y_pred).mean() rmse np.sqrt(((y_true - y_pred) ** 2).mean()) # 只对真实流量大于 30 辆/15min 的样本算 MAPE避免低流量时段失真 mask y_true 30 mape np.abs((y_true[mask] - y_pred[mask]) / np.maximum(y_true[mask], eps)).mean() * 100 return {MAE: round(mae, 2), RMSE: round(rmse, 2), MAPE: round(mape, 2)}阈值 30 不是拍脑袋取决于路口等级。主干道平峰 15 分钟流量普遍在 100 以上取 30 只滤掉深夜次干道和支路要降到 10否则样本被滤掉一大半指标失去统计意义。这个阈值必须在训练前和业务方敲定不要等评测完再调。4.2 大模型做数值预测的五种崩法崩法表现根因处理量纲漂移输出 3200 而不是 320训练样本里混入了小时级流量统一粒度prompt 里写明单位输出重复四个时段数字完全相同训练样本里平峰段过多按流量分档重采样拒绝回答回一句「数据不足」指令样本里混入过问答类数据清洗数据集只留单一任务格式跑偏不是合法 JSON未做输出约束加正则抽取与重试长尾塌陷节假日一律预测成平峰事件样本占比过低事件样本提到 20% 以上量纲漂移是最隐蔽的一种训练时看不出来因为 loss 照样在降只是模型学到了「输出三到四位数」这个错误先验。跑第一轮之后一定要人工抽 20 条看原始输出别只盯 loss 曲线。4.3 用结构化输出和后处理把预测拉回可用区间推理侧不要完全信任模型的自律加一层解析和兜底。import json, re def parse_forecast(text, last_hist, horizon4): 从模型输出里抠出 JSON失败则退化为保持上一时刻流量 m re.search(r\{.*\}, text, re.S) if m: try: arr json.loads(m.group())[future_flow] arr [float(x) for x in arr][:horizon] # 物理约束流量非负且相邻时段跳变不超过上一时刻的 3 倍 cap max(last_hist) * 3 50 arr [min(max(v, 0.0), cap) for v in arr] if len(arr) horizon: return arr except (json.JSONDecodeError, KeyError, TypeError, ValueError): pass return [float(last_hist[-1])] * horizon # 兜底持续性预测后处理里的cap是硬约束防止模型在极端天气下吐出明显违背物理规律的尖峰。持续性预测做兜底虽然朴素但它在短时流量预测里是个不弱的基线兜底值至少不会比它差太多。上线时建议把兜底触发次数单独打点触发率高说明模型在某类输入上稳定失效比看平均指标有用得多。5. 把单次预测成本压到可接受的两招5.1 量化与批推理单次预测成本能降到什么程度14B 模型 BF16 推理大约要 28GB 显存换成 INT8 量化掉到 15GB 左右INT4 能到 9GB代价是 MAE 通常上升 3% 到 8%。交通流量预测对绝对精度没那么敏感因为它只是信号配时的一个输入项最终还要过一遍配时优化算法。我一般先跑 INT8误差超标再回退 BF16。精度显存占用相对 BF16 的 MAE 变化单卡并发路口的量级BF16~28GB基准单条流式INT8~15GB3% ~ 5%8 到 16 路批推理INT4~9GB6% ~ 8%16 到 32 路批推理批推理的收益比量化更大。15 分钟一个预测周期全市 200 个路口如果逐个串行调用单次 800ms 也要 160 秒看起来够用但一旦要回算历史做回溯评测串行就会变成几小时的等待。把同一时段的路口请求拼成一个 batch实测吞吐能提 6 到 10 倍。拼 batch 时注意按 prompt 长度分桶长短混在一起会被 padding 拖垮。5.2 增量更新与在线回流的节奏交通流量的分布是缓慢漂移的新开通的道路、地铁施工、学校寒暑假都会改变某个路口的模式但整体路网结构一年内变化不大。天天重训是浪费一季度不动又会明显掉点。我的做法是分两层每天凌晨用前一天的真实流量回算一次误差按路口聚合误差超过基线 15% 的路口进白名单每周取白名单路口加最近两周的新样本做一次 1 个 epoch 的增量 LoRA学习率降到 2e-5只更新适配器不碰底座每季度再做一次全量重训顺便把累积的事件样本合并进去。增量训练的 checkpoint 可以直接和旧适配器做权重插值插值系数取 0.3 到 0.5能有效抑制单周样本带来的抖动。回流的样本要先过一遍清洗把预测值当标签是循环论证必须用真实检测器数据检测器本身有 1% 到 3% 的丢包和漂移超阈值的数据段整段丢弃而不是插值插值会把错误平滑成「合理」的曲线反而教坏模型。本文还有配套的精品资源点击获取 单卡LoRA微调DeepSeek-V3做短时交通流量预测
简介《智慧城市低成本方案DeepSeek-V3微调实现交通流量预测》是一份面向智慧城市交通管理、AI应用开发与大数据分析学习者的27页PDF技术文档聚焦在预算受限条件下如何借助DeepSeek-V3大模型完成交通流量预测。文档从智慧城市与交通流量预测背景切入系统梳理DeepSeek-V3的架构原理、优势与相关应用并完整覆盖数据收集与清洗、特征工程、数据划分、模型加载与微调参数设置、训练循环与评估等流程同时给出模型融合、部署与实时预测、超参数调优及低成本硬件与数据成本控制策略。包内仅含1个PDF文件大小约1.9MB页面与图表目录显示正常便于逐章查阅。资源已有74人学习适合希望以较低成本把大模型微调落地到交通预测场景的研究人员、工程师与研究生参考可据此理解从数据预处理到微调、评估与部署的完整项目链路。1. 预算只有一张卡时交通流量预测为什么还值得动 DeepSeek-V3一个地级市的信号配时优化项目两百多个路口15 分钟粒度的卡口过车数据要做未来 1 到 8 个时段的短时流量预测。预算表里没有八卡集群只有一台带 4090 或 A6000 的推理机。这类活儿以前交给 LightGBM 加一堆手工特征MAPE 压到 12% 上下就卡住了碰上节假日和突发降雨误差能翻三倍。近两年跑出来的另一条路是把「历史流量序列 天气 星期 节假日标记」写成一整段指令让模型做序列补全直接吐出未来若干时段的数值再在交通数据上做 LoRA 参数高效微调。样本构造、评测方式和传统时序模型完全不同但算力门槛被 LoRA 拉到了单卡能碰的高度。下面写给手里有交通卡口数据、有智慧城市交付压力、算力却不宽裕的一线工程师。2. 把路网流量改写成 DeepSeek-V3 能吃的指令样本2.1 智慧城市路网数据里三种序列切分的取舍原始数据通常长这样intersection_id, timestamp, flow, lane_count, weather, is_holiday。切样本的方式直接决定模型能学到什么常见的有三种选错了后面调参全是白费功夫。切分方式单路口年样本量级优势风险适用场景滑窗切分3 万条以上样本多训练收敛快相邻样本高度自相关验证集虚高快速验证方案可行性按天切分365 条左右天然对齐日周期样本太少长尾覆盖差路口数量多时按路口聚合事件切分几十到几百条覆盖节假日、降雨、事故样本量最小必须与滑窗混用补齐长尾误差我的习惯是滑窗为主、事件为辅按 7:1:2 的比例混合。单纯用滑窗模型会在工作日平峰上表现很好一到国庆就歇菜单纯用事件切分样本量根本撑不起一次微调。2.2 15 分钟粒度流量的 prompt 模板与字段设计输入侧不要让模型去数逗号分隔的数字把它结构化成 JSON 更稳输出也约束成 JSON后处理省一半力气。import json def build_sample(history, future, meta): history: list[float] 过去 8 个时段的流量2 小时 future: list[float] 未来 4 个时段的流量1 小时推理时为空 meta: dict 天气、星期、节假日、路口编号 prompt { task: traffic_flow_forecast, intersection: meta[intersection_id], interval_minutes: 15, history_flow: history, # 长度固定为 8 weekday: meta[weekday], # 1-7 is_holiday: meta[is_holiday], # 0/1 weather: meta[weather] # clear / rain / snow / fog } answer {future_flow: future} # 长度固定为 4 # sharegpt 格式兼容 LLaMA-Factory 的格式化器 return { messages: [ {role: user, content: json.dumps(prompt, ensure_asciiFalse)}, {role: assistant, content: json.dumps(answer, ensure_asciiFalse)} ] }序列长度固定有两个好处一是cutoff_len好设二是模型不会因为历史长度变化而改变输出节奏。interval_minutes写进 prompt 是为了让同一套权重能同时服务 5 分钟和 15 分钟两种粒度代价是推理时必须在 prompt 里显式给出漏了就默认按 15 分钟处理。2.3 时间序列做监督微调时最容易踩的数据泄漏排第一的是标准化。用全量数据算均值和方差再归一化等于把未来信息灌进了训练集离线指标会好看得离谱上线就崩。正确做法是只用训练时间段的统计量验证和测试阶段复用同一组参数上线后按季度滚动重算。排第二是随机 shuffle。流量序列的划分必须按时间切训练集取前 70% 的日期验证集中间 10%测试集最后 20%。一旦随机打乱模型见过「明天」再去预测「今天」MAE 能低到 0.5纯属自欺欺人。排第三是特征穿越。prompt 里写了「未来 1 小时是否降雨」实际预测时天气预报的准确率根本到不了这个程度。天气字段只能用当前时刻实测值或者用预报值但训练时也统一用预报值两边口径必须一致。注意数据泄漏在时序任务里很少是显式的 bug多数时候是流程顺序错了——先划分再处理永远比先处理再划分安全。3. LoRA 微调 DeepSeek 系列的显存账与最小可跑配置3.1 先算显存DeepSeek-V3 本体为什么不适合低成本 LoRALoRA 省的是梯度、优化器状态和一部分激活主干的权重和激活照样要驻留显存。DeepSeek-V3 是 MoE 架构总参数 671B 量级BF16 权重本身就要 1.3TB 上下这不是「一张卡能不能跑」的问题是「一台机器装不装得下」的问题。把账算清楚选型就不会走偏。模型规模BF16 权重全参微调AdamWLoRA 冻结主干单卡可行性7B~14GB~110GB~20GB24GB 卡可跑14B~28GB~220GB~36GB48GB 卡可跑32B~64GB~500GB~80GB需 2×80GBDeepSeek-V3MoE~1.3TB不现实权重仍需 1.3TB单机不可行所以标题里的「低成本」落地时通常拆成两条路一是用 DeepSeek-V3 的接口批量生成高质量样本把它当老师蒸馏到 7B / 14B 这一档模型上做 LoRA二是直接对 DeepSeek 官方放出的蒸馏系列Qwen、Llama 底的 7B、14B、32B做 PEFT。前者成本在 API 调用和标注清洗后者成本在租几小时多卡。两条我都做过路口数少于 500 的场景第一条更划算。3.2 LoRA 的秩、目标模块与 MoE 层的坑LoRA 用两个低秩矩阵近似权重更新量rank决定表达能力alpha决定缩放强度实际生效的缩放系数是alpha / rank。交通流量这种数值回归味道很重的任务rank16到rank32就够了再大只会过拟合到某个路口的特有模式上。MoE 模型有个容易被忽略的点lora_target设成all会把专家层的 FFN 也挂上适配器可训练参数会膨胀好几倍而收益往往不明显。我一般只挂注意力部分的q_proj, k_proj, v_proj, o_proj先把这部分调透再说。参数推荐值说明lora_rank16数值任务足够超过 32 收益递减lora_alpha32取 rank 的两倍缩放系数为 2lora_dropout0.05交通数据噪声大留一点正则learning_rate1e-4LoRA 常用起点崩了就降到 5e-5num_train_epochs3超过 3 轮基本开始背样本cutoff_len204884 个时段加 meta512 都够留余量3.3 用 LLaMA-Factory 跑一次交通流量 LoRA 微调一站式微调平台省掉了手写训练循环的功夫数据注册和启动各一个文件。// data/dataset_info.json 里追加一条 { traffic_flow_sft: { file_name: traffic_flow_sft.jsonl, formatting: sharegpt, columns: { messages: messages } } }# train_traffic_lora.yaml model_name_or_path: /models/deepseek-distill-14b # 已下载到本地的底座 stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 lora_target: q_proj,k_proj,v_proj,o_proj # MoE 不挂专家层 dataset: traffic_flow_sft template: deepseek cutoff_len: 2048 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 # 等效 batch 16 learning_rate: 1.0e-4 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.05 bf16: true gradient_checkpointing: true # 用时间换显存 output_dir: /out/traffic_lora logging_steps: 10 save_steps: 200启动命令llamafactory-cli train train_traffic_lora.yamlgradient_accumulation_steps是显存不够时唯一正确的补偿手段不要靠调大per_device_train_batch_size硬顶14B 模型在 48GB 卡上单卡 batch 超过 4 就很容易 OOM。gradient_checkpointing会拖慢 20% 到 30% 的训练速度换来接近一半的激活显存单卡场景基本必开。template必须和底座匹配填错了模型学不到东西loss 会一直平在 2.0 附近不动。3.4 不用一站式平台时的 peft 最小脚本如果环境不允许装额外依赖直接上peft也没多少代码。import torch, json from datasets import load_dataset from peft import LoraConfig, get_peft_model from transformers import (AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer) MODEL /models/deepseek-distill-14b tok AutoTokenizer.from_pretrained(MODEL, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( MODEL, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue) cfg LoraConfig( r16, lora_alpha32, lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj], task_typeCAUSAL_LM) model get_peft_model(model, cfg) model.print_trainable_parameters() # 先看可训练参数占比0.1%~1% 是正常区间 def tokenize(ex): text tok.apply_chat_template(ex[messages], tokenizeFalse) out tok(text, truncationTrue, max_length2048, paddingmax_length) out[labels] out[input_ids].copy() # 因果语言建模labels 等于输入 return out ds load_dataset(json, data_filestraffic_flow_sft.jsonl, splittrain) ds ds.map(tokenize, remove_columnsds.column_names) args TrainingArguments( output_dir/out/traffic_lora, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate1e-4, num_train_epochs3, bf16True, gradient_checkpointingTrue, logging_steps10, save_steps200, save_total_limit3) Trainer(modelmodel, argsargs, train_datasetds).train() model.save_pretrained(/out/traffic_lora/final)labels复制input_ids表示对整段序列算损失包括 user 部分。想只对回答算损失就得把 user 段 token 置为 -100多数场景不改也能收敛但样本很短时会把大量容量浪费在拟合输入上。save_total_limit3是防止几十个 checkpoint 把盘塞满LoRA 权重虽然只有几十兆checkpoint 目录里往往还带着优化器状态。4. 交通流量预测的评测与五种典型崩法4.1 MAE、RMSE、MAPE 的代码实现与口径统一指标口径不统一是返工的头号原因。MAPE 在夜间低流量时段会炸分母接近 0 时单独几个点就能把均值拉上天实际汇报时我一般同时给 MAE 和按流量分档的 MAPE。import numpy as np def metrics(y_true, y_pred, eps1e-3): y_true/y_pred: shape [N, 4]4 个预测时段 y_true, y_pred np.asarray(y_true), np.asarray(y_pred) mae np.abs(y_true - y_pred).mean() rmse np.sqrt(((y_true - y_pred) ** 2).mean()) # 只对真实流量大于 30 辆/15min 的样本算 MAPE避免低流量时段失真 mask y_true 30 mape np.abs((y_true[mask] - y_pred[mask]) / np.maximum(y_true[mask], eps)).mean() * 100 return {MAE: round(mae, 2), RMSE: round(rmse, 2), MAPE: round(mape, 2)}阈值 30 不是拍脑袋取决于路口等级。主干道平峰 15 分钟流量普遍在 100 以上取 30 只滤掉深夜次干道和支路要降到 10否则样本被滤掉一大半指标失去统计意义。这个阈值必须在训练前和业务方敲定不要等评测完再调。4.2 大模型做数值预测的五种崩法崩法表现根因处理量纲漂移输出 3200 而不是 320训练样本里混入了小时级流量统一粒度prompt 里写明单位输出重复四个时段数字完全相同训练样本里平峰段过多按流量分档重采样拒绝回答回一句「数据不足」指令样本里混入过问答类数据清洗数据集只留单一任务格式跑偏不是合法 JSON未做输出约束加正则抽取与重试长尾塌陷节假日一律预测成平峰事件样本占比过低事件样本提到 20% 以上量纲漂移是最隐蔽的一种训练时看不出来因为 loss 照样在降只是模型学到了「输出三到四位数」这个错误先验。跑第一轮之后一定要人工抽 20 条看原始输出别只盯 loss 曲线。4.3 用结构化输出和后处理把预测拉回可用区间推理侧不要完全信任模型的自律加一层解析和兜底。import json, re def parse_forecast(text, last_hist, horizon4): 从模型输出里抠出 JSON失败则退化为保持上一时刻流量 m re.search(r\{.*\}, text, re.S) if m: try: arr json.loads(m.group())[future_flow] arr [float(x) for x in arr][:horizon] # 物理约束流量非负且相邻时段跳变不超过上一时刻的 3 倍 cap max(last_hist) * 3 50 arr [min(max(v, 0.0), cap) for v in arr] if len(arr) horizon: return arr except (json.JSONDecodeError, KeyError, TypeError, ValueError): pass return [float(last_hist[-1])] * horizon # 兜底持续性预测后处理里的cap是硬约束防止模型在极端天气下吐出明显违背物理规律的尖峰。持续性预测做兜底虽然朴素但它在短时流量预测里是个不弱的基线兜底值至少不会比它差太多。上线时建议把兜底触发次数单独打点触发率高说明模型在某类输入上稳定失效比看平均指标有用得多。5. 把单次预测成本压到可接受的两招5.1 量化与批推理单次预测成本能降到什么程度14B 模型 BF16 推理大约要 28GB 显存换成 INT8 量化掉到 15GB 左右INT4 能到 9GB代价是 MAE 通常上升 3% 到 8%。交通流量预测对绝对精度没那么敏感因为它只是信号配时的一个输入项最终还要过一遍配时优化算法。我一般先跑 INT8误差超标再回退 BF16。精度显存占用相对 BF16 的 MAE 变化单卡并发路口的量级BF16~28GB基准单条流式INT8~15GB3% ~ 5%8 到 16 路批推理INT4~9GB6% ~ 8%16 到 32 路批推理批推理的收益比量化更大。15 分钟一个预测周期全市 200 个路口如果逐个串行调用单次 800ms 也要 160 秒看起来够用但一旦要回算历史做回溯评测串行就会变成几小时的等待。把同一时段的路口请求拼成一个 batch实测吞吐能提 6 到 10 倍。拼 batch 时注意按 prompt 长度分桶长短混在一起会被 padding 拖垮。5.2 增量更新与在线回流的节奏交通流量的分布是缓慢漂移的新开通的道路、地铁施工、学校寒暑假都会改变某个路口的模式但整体路网结构一年内变化不大。天天重训是浪费一季度不动又会明显掉点。我的做法是分两层每天凌晨用前一天的真实流量回算一次误差按路口聚合误差超过基线 15% 的路口进白名单每周取白名单路口加最近两周的新样本做一次 1 个 epoch 的增量 LoRA学习率降到 2e-5只更新适配器不碰底座每季度再做一次全量重训顺便把累积的事件样本合并进去。增量训练的 checkpoint 可以直接和旧适配器做权重插值插值系数取 0.3 到 0.5能有效抑制单周样本带来的抖动。回流的样本要先过一遍清洗把预测值当标签是循环论证必须用真实检测器数据检测器本身有 1% 到 3% 的丢包和漂移超阈值的数据段整段丢弃而不是插值插值会把错误平滑成「合理」的曲线反而教坏模型。本文还有配套的精品资源点击获取