SF Compute CEO 提出了一个判断每家公司都将成为前沿实验室。粗看这是商业叙事但从工程视角看这个判断背后有几个正在发生的变化开源模型权重可以直接下载算力可以按小时购买、按抢占价格获取微调工具链也已经封装到普通工程师能直接上手。过去做一次前沿实验意味着专用集群、算法团队和多年经验现在一个十人左右的技术团队用一台 24GB 显存的 GPU就能在业务数据上完成领域模型的微调闭环。这篇文章把“前沿实验室”从概念拆成可执行的工程实践核心覆盖五部分一个团队要准备哪些能力模块算力市场怎么选最小训练环境怎么搭LoRA 微调怎么跑通多卡训练和算力调度有哪些坑最后补充常见故障排查和可以复用的清单。适合正在把 AI 能力落地到业务的中小团队也适合想系统掌握模型微调工程链路的开发者。1. 先把“前沿实验室”拆成五个可以落地的能力模块“实验室”这个词容易让人想到论文和纯研发但在工程语境下一个能做前沿 AI 实验的团队核心能力可以收敛为五件事数据工程、算力获取、训练调优、实验管理、效果评估。五件事缺任意一件实验都很难产出可信结果更不要说上线。1.1 数据工程实验质量的上限由数据决定模型训练的第一份输入是数据而不是代码。业务系统里的工单、对话记录、操作日志、文档资料都需要清洗成模型能学习的格式。常见步骤包括去重避免同一段文本反复出现导致过拟合过滤噪声去掉识别错误的 OCR 文本和无意义回复脱敏移除手机号、身份证号、内部账号等敏感信息。对于指令微调数据最终要整理成 prompt 和 response 成对出现的 JSONL 文件例如{prompt: 什么是模型微调, response: 模型微调是在预训练模型基础上用特定领域数据继续训练让模型适应目标场景。} {prompt: 写一段 Python 读取 CSV 的代码, response: import pandas as pd\ndf pd.read_csv(data.csv)}每条样本都要单独成行。训练前还需要把全量数据按比例切分成训练集、验证集和测试集比例参考 90%、5%、5%测试集最好来自分布略有差异的时段或渠道用来判断模型是否真的泛化而不是死记硬背。注意不要只清洗训练集。验证集和测试集同样需要走一遍脱敏和去重流程否则评估结果会被脏数据掩盖。1.2 算力获取这是资源问题也是调度问题算力决定了“这个实验能不能跑得动”也决定了“跑一次要花多少钱”。对大多数领域模型微调场景显存比单卡算力更关键。一张 24GB 显存的消费级或专业级 GPU配合 QLoRA 量化微调已经可以处理 7B 量级模型的微调任务。算力获取方式不能只锁定一种要根据任务阶段灵活切换这部分在第二章专门展开。1.3 训练调优微调、LoRA 与超参对中小团队来说从零预训练大模型既不经济也不必要。更现实的做法是拿到开源权重在领域数据上做全参数微调或 LoRA 微调。LoRA 通过冻结原模型、只训练低秩适配参数能显著降低显存占用和训练成本。超参中最先关注学习率、批大小、训练轮数和最大序列长度。学习率过大会导致 loss 震荡过小则收敛缓慢序列长度受显存限制训练前就要确认数据里有没有超长文本会被截断。1.4 实验管理可复现比“跑通”更重要训练过程中必须记录三样东西代码和依赖版本、超参配置、数据版本。实际项目里一个隐藏的成本是“这个结果怎么复现出来的”。建议每次实验固定随机种子保存完整超参把代码、数据、模型权重、日志放到同一份实验目录下。很多问题不是“训练不出来”而是“上次明明可以这次改了什么导致不行”。1.5 效果评估训练 loss 不等于业务效果训练 loss 下降只代表模型在训练分布上优化不能直接证明业务场景可用。评估至少两层第一层用验证集 loss 和自动指标如 BLEU、ROUGE、F1做横向比较第二层用真实业务样本做人工评估重点看错误类型例如是否答非所问、是否泄露训练数据、是否在敏感问题上乱说。没有第二层评估模型上线后很容易在边界场景出问题。2. 算力获取已经从“买卡”变成四种模式并存的市场算力采购方式直接影响实验