我在组里跑Llama踩过的那些坑

组里搞大模型落地快两年了。我们选型Llama系列，看中它开源、社区活跃且不被厂商绑定。

架构设计上的第一次翻车

初期我们错误地把大模型当普通微服务部署，A100单卡加载Llama就吃掉40多G显存。后来重新设计：模型常驻GPU，包一层gRPC服务，上层用轻量调度层处理排队、超时和缓存。

class InferenceEngine:
    def __init__(self, model_path: str, device_map: str = "auto"):
        self.model = LlamaForCausalLM.from_pretrained(
            model_path,
            torch_dtype=torch.float16,
            device_map=device_map,
            load_in_8bit=True  # 显存不够，量化来凑
        )
        self.tokenizer = LlamaTokenizer.from_pretrained(model_path)
        
    @torch.no_grad()
    def generate(self, prompt: str, **kwargs) -> str:
        inputs = self.tokenizer(prompt, return_tensors="pt")
        outputs = self.model.generate(**inputs, **kwargs)
        return self.tokenizer.decode(outputs[0])

为调优max_batch_size和max_queue_delay，我们靠线上真实流量压测才找到甜点区。

微调的那些事

全量微调8张A100跑三天，过拟合严重。换成LoRA后参数量降至千分之一，训练仅六小时，泛化反而更好。但对强逻辑推理任务，LoRA效果不佳，最终采用前几层全量微调加后几层LoRA的混合方案才解决。

线上事故回忆录

去年双十一前，推理服务频繁OOM。原因是新业务方未限制prompt长度，有人传入近8000 token上下文，而Llama显存占用与序列长度呈平方关系。紧急上了2048 token截断逻辑才恢复。

此后我们加了几层防护：前置prompt校验、动态显存监控和基于队列长度的自动降级。这些实为在线服务基本素养，只是当时被大模型光环迷惑。

一些不成熟的思考

大模型落地，技术选型只是第一步，真正挑战在于工程化和持续迭代。模型版本管理、AB实验框架、效果评估体系这些“不高级”的事，反而决定项目存亡。另外，AI同学写代码常较奔放，但长期维护必须遵循工程规范。技术之路越走越觉无知，但每天八点继续看日志。