从Prompt工程到Llama落地：一个深圳小厂后端的摸爬滚打
上周五晚上十点半，我盯着屏幕上一行 OOMKilled 的日志，差点把咖啡杯捏碎。这已经是本周第三次因为大模型推理服务内存溢出导致线上接口超时了。产品经理在钉钉群里@我：“明天上线前能不能搞定？客户那边催得紧。” 我深吸一口气，默默关掉终端，打开 VS Code——又是一个熟悉的“深夜修 Bug”剧本。
我是深圳一家百来人规模互联网公司的后端开发，独立负责一条核心业务线。说“独立负责”，其实也就意味着：需求分析、架构设计、编码、部署、运维、甚至半夜被 PagerDuty 叫醒查线上问题，全是我一个人扛。公司就在南山科技园，旁边就是腾讯大厦，每天上下班都能看到鹅厂员工排着长队进食堂，而我只能啃着便利店饭团改代码。不过好处是，没人管你技术栈怎么选，只要你能把活干出来。
最近半年，AI 热潮席卷全行业，我们这条业务线也被要求“快速接入智能能力”。领导一句话：“别的公司都在用大模型提效，我们不能落后！” 于是，Prompt 工程、Llama、DeepSeek 这些词，一夜之间成了我日常工作的关键词。
起点：不是所有 AI 都叫“通义千问”
一开始，团队天真地以为直接调用 OpenAI API 就完事了。结果一算成本，当场傻眼——按我们日均百万级的请求量，一个月光 API 费就得六位数。老板眉头一皱：“能不能自建？”
行吧，那就自己搞。但问题来了：开源大模型那么多，选哪个？
- Llama 3：Meta 出品，社区生态好，但中文支持一般，需要微调
- DeepSeek：国产新秀，中文强，还专门针对代码场景优化，文档也友好
- Qwen：阿里系，中文顶流，但模型太大，部署成本高
我们业务场景主要是用户输入自然语言，生成结构化查询条件（比如“上个月销售额超过10万的客户” → 转成 SQL WHERE 条件）。对中文理解要求高，但不需要太复杂的推理能力。综合考虑，DeepSeek-Coder 成了首选——它在 HumanEval 上表现不错，而且 7B 参数版本能在 24G 显存的 A10 上跑起来，对我们这种小厂来说，性价比拉满。
📌 小厂生存法则：能跑在消费级显卡上的模型，才是好模型。
第一关：Prompt 工程不是“写提示词”那么简单
很多人以为 Prompt 工程就是“多写几个例子，加点 instruction 就行”。实则不然。我最初写的 Prompt 是这样的：
你是一个智能查询助手，请将以下自然语言转为 SQL WHERE 条件：
输入：上个月销售额大于10万的客户
输出：sales > 100000 AND month = '2024-05'
结果模型经常把“上个月”理解成“去年”或者“本月”，甚至有一次把“10万”识别成“10”。更离谱的是，它有时会返回完整 SQL，而不是我们要的 WHERE 子句。
后来我才意识到：Prompt 是系统的一部分，不是魔法咒语。我开始做三件事：
- 结构化输入：强制用户输入包含时间范围、指标、阈值等字段，减少歧义
- 输出格式约束：用 JSON Schema 限制输出格式，比如：
{ "filter": "sales > 100000", "time_range": "last_month" } - Few-shot 示例 + 错误修正：收集线上 bad case，加入 Prompt 作为反例
最终的 Prompt 模板长这样：
你是一个严谨的查询条件生成器。请严格按以下规则处理：
输入格式：
{
"query": "自然语言描述",
"available_fields": ["sales", "customer_id", "month"]
}
输出格式（JSON）：
{
"filter_expression": "合法的 WHERE 条件表达式，仅使用 available_fields 中的字段",
"time_context": "解析出的时间上下文，如 'last_month', 'this_quarter'"
}
示例：
输入：{"query": "上个月销售额超过10万的客户", "available_fields": ["sales", "month"]}
输出：{"filter_expression": "sales > 100000", "time_context": "last_month"}
注意：
- 不要生成 SELECT 或 FROM
- 数字必须保留原始单位（10万 → 100000）
- 时间必须标准化
现在请处理以下输入：
{input}
效果立竿见影。bad case 率从 35% 降到 8% 以下。Prompt 工程的本质，是给模型划边界、定规则，而不是求它“聪明”。
第二关：Llama 本地部署，K8s 救我狗命
既然决定用 DeepSeek，那肯定得本地部署。但小厂没 GPU 集群，只有一台 4*A10 的服务器（还是蹭运维闲置资源申请的）。怎么办？
我第一个想到的就是 Kubernetes + vLLM。
vLLM 是 Llama 生态里目前最火的推理引擎，支持 PagedAttention，内存效率比 HuggingFace Transformers 高 2-3 倍。配合 K8s，我们可以实现：
- 自动扩缩容（HPA 基于 QPS）
- 多副本负载均衡
- GPU 资源隔离（通过 nvidia-device-plugin）
部署配置如下（简化版）：
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deepseek-inference
spec:
replicas: 2
template:
spec:
containers:
- name: vllm
image: vllm/vllm-openai:latest
args:
- "--model=deepseek-ai/deepseek-coder-7b-instruct-v1.5"
- "--tensor-parallel-size=2" # 2张卡并行
- "--max-model-len=2048"
resources:
limits:
nvidia.com/gpu: 2
ports:
- containerPort: 8000
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: deepseek-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: deepseek-inference
minReplicas: 1
maxReplicas: 4
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
但坑还是来了：vLLM 启动时加载模型要 10 分钟！每次发布新版本，服务不可用时间太长。后来我用了 预热脚本 + readinessProbe 延迟检查，确保 Pod 完全 ready 才加入流量。
readinessProbe:
exec:
command: ["curl", "-f", "http://localhost:8000/health"]
initialDelaySeconds: 600 # 等10分钟再检查
periodSeconds: 30
虽然土，但有效。毕竟小厂没那么多 fancy 的 CI/CD 流水线，能跑就行。
第三关：面试题挑战？不，是线上事故复盘
说到“面试题挑战”，其实我们内部搞了个“AI Hack Day”——每人用 Llama/DeepSeek 解一道经典算法题，看谁的 Prompt 能让模型一次 AC。
我选了 LeetCode 239：滑动窗口最大值。本以为加个“请用单调队列实现”就能搞定，结果模型返回了一堆暴力解法。后来我改 Prompt：
你正在参加一场编程面试。面试官要求你用 O(n) 时间复杂度实现滑动窗口最大值。
请使用单调队列（Monotonic Queue）方法，并写出完整可运行的 Python 代码。
不要解释，只输出代码。
这次终于对了。但现实比面试残酷得多——线上环境没有“重试”按钮。
有一次，我们把模型输出直接拼接到 SQL 里，结果某用户输入了 ' OR '1'='1，差点造成注入。虽然加了过滤，但那次事故让我明白：任何 AI 输出，都必须当“不可信输入”处理。
现在我们的流程是：
- 用户输入 → 2. Prompt 处理 → 3. 模型输出 → 4. 结构化解析 + 校验 → 5. 安全执行
校验层用 Pydantic 做 schema validation，非法字段直接 reject。宁可少功能，也不能出安全问题。
性能对比：DeepSeek vs Llama 3 中文场景实测
为了说服老板继续投入，我做了个简单 benchmark。测试集：500 条中文查询语句，指标：准确率、延迟、显存占用。
| 模型 | 准确率 | 平均延迟 (ms) | 显存占用 (GB) | 是否需微调 |
|---|---|---|---|---|
| Llama-3-8B-Instruct | 68% | 320 | 18 | 是 |
| DeepSeek-Coder-7B | 82% | 280 | 16 | 否 |
| Qwen-7B-Chat | 85% | 350 | 20 | 否 |
结论很明显：在中文结构化生成任务上，DeepSeek 开箱即用效果最好，且资源消耗更低。Llama 3 虽然通用能力强，但中文需要大量 SFT（Supervised Fine-Tuning），对我们这种没人手做数据标注的小团队不现实。
写在最后：技术探索不是炫技，是解决问题
回过头看，从去年双11临时抱佛脚研究 vLLM，到现在稳定支撑日均 50 万次 AI 查询，中间踩过的坑比我写过的代码还多。但每次看到用户一句“这个功能真智能”，就觉得值了。
在深圳这个卷王之都，小厂开发者没有大厂的资源和光环，但我们有快速试错、快速落地的自由。Prompt 工程不是玄学，Llama 也不是银弹，DeepSeek 更不是终点。技术探索的意义，从来不是为了追新，而是用最低的成本，解决最痛的问题。
顺便说一句，最近在刷面经，发现好多公司开始问“如何优化 LLM 推理性能”、“Prompt 设计原则”——看来我这些踩坑经验，说不定真能帮我跳槽涨薪（笑）。
如果你也在小厂挣扎，不妨试试：别怕用开源模型，别迷信大厂方案，你的业务场景，才是最好的技术指南针。
作者：深圳某小厂后端，坐标南山，常驻腾讯大厦对面便利店。
技术栈：Go + K8s + Llama（勉强能跑），梦想是有一天不用加班。
评论 0