备婚刷题之余，我拿Llama和GPT-4o比了比深度学习框架

上周五晚上十点半，我还在公司调试一个模型部署的bug，婚庆策划师刚发来第三版婚礼流程表，而我的LeetCode打卡还差两道Hard题。说实话，那会儿真想把MacBook合上，躺平到明年——但转念一想，下个月就要面试新东家了，得把“熟悉主流AI框架”这条写进简历里，不能光靠嘴说。

于是，趁着周末老公去试西装的空档（他以为我在选捧花，其实我在跑PyTorch脚本），我搞了个小实验：用几个热门深度学习框架，分别跑Llama和调用GPT-4o API，看看它们在真实业务场景下的表现差异。这篇文章就是我的实战手记，新手友好，带点自嘲，也带点干货。

---

起因：老板说“我们要有自己的大模型能力”

事情得从上个月说起。我们团队做的是电商智能客服系统，之前全靠调OpenAI的API，成本高不说，响应延迟还受制于人。产品经理在周会上拍桌子：“竞品都上Llama了，我们还在用GPT-4？这不行！”

技术总监点点头：“那就自己微调个7B参数的Llama，部署到私有云。”
我弱弱举手：“那……框架选哪个？PyTorch？TensorFlow？还是Hugging Face Transformers直接上？”

没人回答我。散会后，运维大哥幽幽地说：“你要是能把推理速度压到200ms以内，我就给你在服务器上多开两个GPU slot。”

行吧，这活儿落我头上了。

---

实验设计：三个选手，一个任务

我定了个小目标：用相同的业务数据集（5万条用户-客服对话，标签是“是否需人工介入”），分别用以下三种方式训练/调用模型：

1. 本地微调 Llama-2-7b（通过 Hugging Face + PyTorch）
2. 本地微持 Llama-3-8b（用 vLLM 加速推理）
3. 直接调用 GPT-4o 的 function calling 能力

注意：这里没用 TensorFlow，不是它不好，而是我们团队早就全面转向 PyTorch 生态了——毕竟 Mac 上开发体验太香，Windows 只用来测兼容性 bug（比如那次因为路径分隔符炸掉的 CI 流水线，别提了）。

数据预处理很简单：清洗、分词、截断到512 token。标签二分类，正样本约12%。评估指标看准确率、F1，还有最关键的——P99 延迟。

---

选手一：PyTorch + Transformers，经典但有点重

先说最熟悉的组合：transformers 库 + accelerate + PyTorch。

from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b-hf")
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf")
tokenizer.pad_token = tokenizer.eos_token

训练脚本跑起来没问题，但 Mac M2 Pro 的 32GB 内存根本扛不住 full fine-tuning。只能上 LoRA（Low-Rank Adaptation），把可训练参数压缩到不到1%。用了 peft 库，几行代码搞定：

from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=8,
    lora_alpha=16,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.1,
    bias="none",
    task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)

训练8个epoch，A100上跑了快5小时。最终验证集 F1 是 0.82，看起来不错。但问题出在推理阶段。

本地用 Flask 部署，单请求平均延迟 1.2 秒，P99 直接飙到 2.5 秒。用户等三秒就挂电话了，这哪行？

我试过量化（bitsandbytes 的 4-bit），延迟降到 800ms，但准确率掉了 3 个点。产品经理看了直摇头：“这还不如直接用 GPT-4。”

---

选手二：vLLM + Llama-3，推理快如闪电

听说 vLLM 最近火得不行，号称“吞吐量提升10倍”。正好 Llama-3 刚开源，我决定试试。

vLLM 的安装有点坑，依赖一堆 CUDA 版本，还好我用 Docker 搞定：

docker run --gpus all -p 8000:8000 vllm/vllm-openai:latest \
  --model meta-llama/Meta-Llama-3-8B \
  --dtype auto \
  --max-model-len 1024

然后直接用 OpenAI 兼容的 API 调：

import openai
client = openai.OpenAI(base_url="http://localhost:8000/v1", api_key="token-abc")
response = client.chat.completions.create(
    model="meta-llama/Meta-Llama-3-8B",
    messages=[{"role": "user", "content": "用户问：订单还没发货..."}],
    max_tokens=100
)

效果惊艳！同样 Llama 架构，vLLM 的 P99 延迟压到了 180ms，吞吐量实测每秒能处理 45 个请求。而且因为用了 PagedAttention，显存占用比 Hugging Face 推理低了 40%。

但训练还是得回 Transformers。vLLM 只负责推理，训练仍要 LoRA 微调。我把 Llama-3 用同样方式微调后，F1 提升到 0.85，延迟还更低。

运维大哥看完监控面板，难得夸了句：“可以啊，这次没把 GPU 跑满到报警。”

---

选手三：GPT-4o，省事但贵得肉疼

最后是 GPT-4o。它支持 function calling，我写了个简单的 JSON schema：

{
  "name": "classify_ticket",
  "parameters": {
    "type": "object",
    "properties": {
      "needs_human": {"type": "boolean"},
      "confidence": {"type": "number"}
    }
  }
}

调用代码极简：

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "用户消息..."}],
    tools=[{"type": "function", "function": func_schema}],
    tool_choice={"type": "function", "function": {"name": "classify_ticket"}}
)

结果？F1 高达 0.89，延迟平均 600ms（国内访问 OpenAI 网络波动大），但最大的问题是成本。

按每天 50 万次调用算：

• GPT-4o 输入 $5/1M token，输出 $15/1M token
• 平均每次 300 tokens → 单次成本约 $0.006
• 月成本 ≈ $9000

而 Llama-3 + vLLM 部署在 2 张 A10 上，月成本不到 $2000（含电费和折旧）。

老板看完账单，默默把“全面替换为自研模型”的 OKR 提上了日程。

---

框架横向对比：到底该怎么选？

我把关键指标整理成表格，方便大家参考：

方案	模型	训练灵活性	推理延迟 (P99)	准确率 (F1)	月成本（50万次）	适合场景
PyTorch + Transformers	Llama-2-7b	⭐⭐⭐⭐⭐	2500ms	0.82	~$1800	快速原型、研究实验
vLLM + Llama-3-8b	Llama-3-8b	⭐⭐⭐（需外部训练）	180ms	0.85	~$2000	高并发生产环境
GPT-4o API	GPT-4o	⭐（不可训练）	600ms	0.89	~$9000	MVP验证、非核心业务

几点心得：

• 如果你在备婚+跳槽+刷题三线作战，别碰 full fine-tuning，LoRA 是你的朋友。
• vLLM 真香，尤其适合需要低延迟的在线服务。但它不解决训练问题，得和 Transformers 配合用。
• GPT-4o 虽强，但别被它的效果迷惑——成本和数据隐私是硬伤。我们法务部上周刚发邮件说“禁止在生产环境传用户数据到第三方模型”。

---

性能优化的小技巧

顺便分享几个我在折腾中总结的优化点：

1. Token 截断策略：别一刀切512，用 percentile(95) 确定长度，省显存又不丢信息。
2. 批处理（batching）：vLLM 自动做 continuous batching，但自己写服务时记得攒请求。
3. 量化别乱用：4-bit 对 Llama 效果尚可，但对小模型可能崩。先在 dev 集上跑 ablation。
4. 监控 P99，不是平均值：用户感知的是最慢的那次，不是“平均很快”。

---

最后：技术之外

写完这篇时，已经是凌晨一点。明天还要早起试婚纱，但心里踏实多了——至少简历上的“精通大模型部署”不算吹牛了。

其实做这行久了你会发现，没有银弹，只有权衡。Llama 开源免费，但你要搭人力维护；GPT-4o 开箱即用，但钱包受不了。框架也一样：PyTorch 灵活，TensorFlow 稳定，JAX 快但陡峭……选哪个，取决于你此刻站在什么位置。

我现在的位置是：一个想跳槽涨薪、又不想婚礼超预算的程序媛。所以，我选择了 vLLM + Llama-3 —— 性能够用，成本可控，还能跟面试官聊半小时推理优化。

如果这篇能帮你少踩一个坑，或者让你在相亲对象面前多一句谈资（“我会调大模型哦”），那我就没白熬这个夜。

对了，下篇打算写《LeetCode Hard 题和婚礼座位表，哪个更难排？》，敬请期待（如果我没累趴的话）。