外观
作品集项目
推理部署岗位的简历上，写得最闪光的不是"用过 vLLM"，而是"我自己从零搭了一个 RAG 服务，并发 50、p99 800ms"——一句话能讲半小时的那种项目。
推理部署岗位的面试有个奇怪现象：能说清自己项目的人，比能背 vLLM 参数的人更稀缺。原因很简单：vLLM 参数谁都能背，但从零做一个端到端推理服务、把它跑稳、把瓶颈找出来、把数字测准——这套能力只能在真实项目里磨出来。本文给出 5 个推理部署方向最具代表性的作品集项目，每个项目都满足三条：有动机（解决真实问题）、有产出物（代码 + 报告 + 演示）、有可拿出来说的卖点（面试时讲 30 分钟不虚）。
本文的定位
本文是 从零部署一个推理服务 的"扩展路线"——build-your-own 是单模型三版渐进的端到端项目，本文把它扩展到五个不同方向、可独立做成作品集的工程。每个项目都假设你已经能跑通 build-your-own 的 v2（vLLM + 单卡服务），并在此基础上做延伸。求职导向的完整解读见 能力对标：简历该突出什么。
一、五个项目速览
| 项目 | 主要技术 | 难度 | 工作量 | 求职加分点 |
|---|---|---|---|---|
| 1. RAG 推理服务 | embedder + 向量库 + reranker + LLM | ★★ | 1–2 周 | "我把 RAG 全栈跑通" |
| 2. 多模型路由 | 小模型 + 大模型 + 路由策略 | ★★★ | 2 周 | "我把成本砍 70%" |
| 3. 流式对话 API | SSE + vLLM 流式 + 客户端 | ★★ | 1 周 | "我懂 token-level 流式" |
| 4. 量化模型对比 benchmark 平台 | 多引擎多量化对比 + 报告生成 | ★★★ | 2–3 周 | "我有量化决策框架" |
| 5. 端侧 LLM App | llama.cpp + iOS/Android + GGUF | ★★★★ | 3–4 周 | "我能搞定端侧部署" |
选项目按"求职目标 → 现有能力 → 工作量预算"三步匹配。如果你的目标是云端推理工程师，1/2/4 是首选；如果你的目标是端侧 / Mobile AI，5 是首选；如果你想覆盖最广，1+2+4 三件套最能讲故事。
二、项目一：RAG 推理服务
1. 动机
RAG（Retrieval-Augmented Generation）是 LLM 落地最常见的形态——任何"基于企业知识库问答"的需求本质都是 RAG。它的工程挑战不在 LLM 本身，而在把 embedder、向量检索、reranker、LLM 四个推理服务串成一条流水线，还要保证端到端延迟。这个项目把 从零部署一个推理服务 的"单 LLM"扩展到"多模型流水线"，是云端推理工程师最该有的项目。
2. 技术栈
用户请求 ──→ embedder (BGE-M3) ──→ 向量库 (Qdrant/Milvus)
│
▼
top-K 检索 (K=10)
│
▼
reranker (bge-reranker)
│
▼
top-N 重排 (N=3)
│
▼
LLM (Llama-2-7B-Chat via vLLM)
│
▼
答案 + 引用| 组件 | 推荐选型 | 备选 | 备注 |
|---|---|---|---|
| Embedder | BGE-M3 / bge-large-en-v1.5 | sentence-transformers, OpenAI embedder | 用 ONNX Runtime 部署，详见 ONNX Runtime 跨平台 |
| 向量库 | Qdrant | Milvus, Weaviate, pgvector | 单机起步选 Qdrant，简单稳定 |
| Reranker | bge-reranker-large | Cohere rerank API | 用 transformers 直接跑，或导 ONNX |
| LLM | Llama-2-7B-Chat via vLLM | Qwen2.5-7B-Instruct | 详见 从零部署一个推理服务 |
| 编排 | Python + FastAPI | LangChain, LlamaIndex | 不建议用 LangChain 编排生产——直接写 FastAPI 更可控 |
3. 产出物
rag-inference-service/
├── README.md # 架构图、性能基准、复现指南
├── docker-compose.yml # 一键启动 Qdrant + vLLM + API
├── configs/
│ ├── embedder.yaml
│ ├── retriever.yaml
│ └── llm.yaml
├── src/
│ ├── embedder.py # ONNX 推理
│ ├── retriever.py # Qdrant 客户端
│ ├── reranker.py # transformers 推理
│ ├── llm.py # vLLM 客户端
│ ├── pipeline.py # 把四者串成 FastAPI
│ └── eval.py # ragas 评测
├── data/
│ └── docs/ # 测试用知识库（公开 wiki 摘录）
├── bench/
│ ├── bench_e2e.py # 端到端延迟
│ └── bench_quality.py # 回答质量评测
└── reports/
└── bench_2024-08-22.md4. 拿出来说的卖点
- "我把 RAG 全栈跑通了"：embedder + 向量库 + reranker + LLM 四个推理服务，每个都做了精度与延迟优化
- "我有端到端 SLA"：测出"单查询 TTFT < 500ms、p99 < 2s、吞吐 30 QPS"
- "我有评测集"：用 ragas 跑 faithfulness、answer_relevancy、context_precision 三指标，得到"召回率 0.85、答案准确率 0.78"
- "我懂选型 trade-off"：为什么选 Qdrant 不选 Milvus（部署复杂度），为什么 BGE-M3 不选 OpenAI embedder（成本与隐私）
- "我懂瓶颈分析"：profile 出 reranker 占 60% 端到端延迟，于是把它转成 ONNX INT8，整体延迟砍半——这是 部署设计原则 的"模型+算子+系统三层都要查瓶颈"
三、项目二：多模型路由
1. 动机
LLM 成本是 SaaS 公司的核心 KPI——一个用 GPT-4 处理所有请求的服务，月成本百万美元级。但真实请求分布里只有 20% 真的需要 GPT-4 级别的能力，80% 用 7B 模型就够。多模型路由就是：根据请求难度，把简单请求分给小模型，难的留给大模型。这个项目展示的是 模型服务化与编排 与 批处理与请求调度 的进阶应用。
2. 技术栈
用户请求
│
▼
┌─────────────────┐
│ 路由分类器 │ ← 用一个轻量分类模型（如 BERT-tiny）
│ (复杂度评估) │ 或基于规则的启发式
└────────┬────────┘
│
┌────────┴────────┐
▼ ▼
简单请求 80% 难请求 20%
│ │
▼ ▼
Llama-2-7B Llama-2-70B / GPT-4
(本地 vLLM) (API 或本地)| 组件 | 选型 |
|---|---|
| 路由分类器 | BERT-tiny + 规则（长度、关键词、上下文复杂度） |
| 小模型 | Llama-2-7B-Chat via vLLM（本地） |
| 大模型 | Llama-2-70B（本地 4 卡 TP）或 GPT-4 API |
| 路由框架 | Triton Inference Server + ensemble 模型 |
| 监控 | Prometheus + Grafana，监控两路流量、错误率、降级率 |
3. 产出物
multi-model-router/
├── README.md
├── configs/
│ ├── router.yaml
│ ├── small_model.yaml
│ └── large_model.yaml
├── src/
│ ├── router.py # 路由分类器
│ ├── clients.py # 两个 LLM 客户端
│ ├── orchestrator.py # FastAPI 主服务
│ ├── fallback.py # 大模型超时降级到小模型
│ └── metrics.py # Prometheus 指标
├── triton/
│ └── model_repository/
│ ├── router_bert/
│ ├── llama2-7b/
│ └── ensemble/
├── bench/
│ ├── bench_routing.py # 路由准确率
│ └── bench_cost.py # 成本对比
└── reports/
└── cost_saving_2024-08-22.md4. 拿出来说的卖点
- "我把成本砍 70%"：测出 80% 流量走小模型，平均成本是只用大模型的 30%
- "我有路由准确率评测"：用 1000 条人工标注"难度"的数据，路由准确率 0.82
- "我有降级机制"：大模型超时 / 限流时自动降级到小模型，保证可用性
- "我有灰度发布"：用 Triton 的多版本机制，新路由策略先跑 5% 流量，24 小时后扩到 100%
- "我懂为什么不用 LangChain Router"：LangChain Router 是 prompt-based 路由（让 LLM 自己决定），每次路由都要花一次 LLM 调用，反而更贵；本方案用轻量分类器，路由本身只需 5ms
这是 部署设计原则 中"灰度发布先 5% 流量"的典型应用，也是 常见陷阱与反模式 中"在线推理开大 batch"的反面教材（路由分类器要保持小 batch、低延迟）。
四、项目三：流式对话 API
1. 动机
聊天场景的"用户耐心"以秒计——3 秒首字不出，用户认为"卡死了"。流式输出（streaming）是降低首字延迟的核心手段，但很多团队还在用"等模型生成完一次性返回"的非流式接口，TTFT 拉满。这个项目展示的是 延迟、吞吐与并发 中"流式优于等结果"的工程落地。
2. 技术栈
浏览器 / App
│
│ SSE (Server-Sent Events)
▼
FastAPI (async stream)
│
│ vLLM stream API
▼
vLLM (Llama-2-7B-Chat)
│
│ token-level 流式生成
▼
逐 token 返回给客户端| 组件 | 选型 |
|---|---|
| 推理引擎 | vLLM 0.6+（原生支持 stream） |
| 协议 | SSE（Server-Sent Events），不用 WebSocket |
| Web 框架 | FastAPI + sse-starlette |
| 客户端 | 浏览器 EventSource / Python httpx |
| 监控 | TTFT 分布、单请求 TPOT、并发数 |
3. 产出物
streaming-chat-api/
├── README.md
├── src/
│ ├── server.py # FastAPI + SSE
│ ├── vllm_client.py # async stream 客户端
│ ├── backpressure.py # 背压控制
│ └── metrics.py
├── client/
│ ├── web.html # 浏览器 EventSource demo
│ └── python_cli.py # CLI 客户端
├── bench/
│ ├── bench_ttft.py # TTFT 分布
│ └── bench_concurrent.py # 并发流式
└── docker/
└── Dockerfile4. 拿出来说的卖点
- "我懂 SSE 与 WebSocket 的 trade-off"：流式输出用 SSE 而不是 WebSocket——SSE 是单向、自动重连、HTTP 兼容，WebSocket 是双向但更复杂
- "我测出 TTFT 与 TPOT 的差距"：流式接口让用户感知到的"首字延迟"从 2s 降到 200ms，但实际生成速度不变——这是体验工程的精髓
- "我懂背压控制"：客户端收慢了服务端不能无限堆积 token，要有 backpressure 机制
- "我懂多用户公平"：32 个流式请求同时来，不能让先到的请求独占 GPU——continuous batching + 公平调度
- "我懂流式测试方法"：流式接口的延迟不是"请求-响应"模式，要用"chunk-level 延迟"测——详见 推理基准测试实践
这是 常见陷阱与反模式 中"流式响应没用 SSE 而是 polling"的反面教材，也是 部署设计原则 中"流式优于等结果"的典型实现。
五、项目四：量化模型对比 benchmark 平台
1. 动机
量化是 LLM 推理成本优化的核心手段，但量化方案太多（AWQ、GPTQ、SmoothQuant、INT8、INT4、FP8...），模型太多（Llama、Qwen、Mistral...），引擎太多（vLLM、TRT-LLM、SGLang...）——任何团队都要做"选哪个量化方案"的决策，但没有统一对比平台就只能凭感觉。这个项目把 推理基准测试实践 方法论做成自动化平台，是非常硬核的工程作品。
2. 技术栈
配置 (YAML)
│
▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 量化模块 │ → │ 推理引擎 │ → │ 性能采集 │
│ (autoawq, │ │ (vLLM, │ │ (nvidia-smi│
│ auto-gptq, │ │ TRT-LLM, │ │ + 自定义) │
│ smoothquant│ │ SGLang) │ │ │
│ ) │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
│
▼
┌─────────────┐
│ 质量评测 │
│ (lm-eval- │
│ harness) │
└─────────────┘
│
▼
┌─────────────┐
│ 报告生成 │
│ (Markdown + │
│ HTML 可视化)│
└─────────────┘| 组件 | 选型 |
|---|---|
| 量化库 | AutoAWQ、AutoGPTQ、SmoothQuant、llm-compressor |
| 引擎 | vLLM、TensorRT-LLM、SGLang |
| 性能采集 | vLLM bench、trtllm-bench、nvidia-smi、Nsight Systems |
| 质量评测 | lm-evaluation-harness（MMLU、HellaSwag、HumanEval 等） |
| 编排 | Python + Click CLI |
| 报告 | Jinja2 模板 → Markdown + HTML |
3. 产出物
quant-bench-platform/
├── README.md
├── configs/
│ ├── awq_llama2_vllm.yaml
│ ├── gptq_llama2_trtllm.yaml
│ └── ... (几十个组合)
├── src/
│ ├── quantize/
│ │ ├── awq_runner.py
│ │ ├── gptq_runner.py
│ │ └── smoothquant_runner.py
│ ├── engines/
│ │ ├── vllm_runner.py
│ │ ├── trtllm_runner.py
│ │ └── sglang_runner.py
│ ├── metrics/
│ │ ├── perf.py
│ │ └── quality.py
│ └── report.py
├── reports/
│ ├── 2024-08-22_llama2_quant.md
│ └── 2024-08-22_llama2_quant.html
└── cli.py # 主入口：python cli.py run --config xxx.yaml4. 拿出来说的卖点
- "我有完整的量化决策框架"：测出 AWQ vs GPTQ vs SmoothQuant 在 Llama-2-7B 上的吞吐、显存、MMLU 三维对比，给出"什么时候该选哪个"的决策树
- "我有跨引擎对比"：同一个 AWQ 模型在 vLLM / TRT-LLM / SGLang 三引擎上的性能差异
- "我有可复现平台"：别人用你的 cli.py + 配置文件，能在他机器上跑出同样的数字——这是 推理基准测试实践 报告模板的工程化
- "我懂防作弊"：每个 benchmark 都做了 cold/warm start 区分、CPU-GPU overlap 处理、padding 显式声明
- "我有可视化报告"：HTML 报告里嵌交互式图表（用 Plotly），面试官能现场点开看
这是把 模型量化基础 与 权重量化与混合精度 的理论变成可操作决策的工程实现，也是 推理引擎选型对比 的"数据后端"。
六、项目五：端侧 LLM App
1. 动机
端侧 LLM 是 2024–2025 年最热的方向——iOS 18、Android 15、Windows Copilot+ 都在把 LLM 搬到本地。端侧部署的挑战完全不同于云端：内存预算紧（iPhone 15 Pro 只有 8GB）、电量敏感、算力受限、要兼容多 SoC（Apple Silicon / Snapdragon / MediaTek）。这个项目是端侧 / Mobile AI 岗位最对口的工程作品。
2. 技术栈
iOS App / Android App
│
▼
llama.cpp (C++)
│
▼
GGUF 量化模型 (Q4_K_M)
│
▼
Metal (iOS) / OpenCL (Android) 后端
│
▼
流式生成 + 上下文管理| 组件 | 选型 |
|---|---|
| 推理引擎 | llama.cpp（详见 llama.cpp 与 GGUF） |
| 量化格式 | GGUF Q4_K_M（4bit，质量与大小平衡） |
| iOS 后端 | Metal Performance Shaders |
| Android 后端 | OpenCL / Vulkan |
| 模型 | Qwen2.5-1.5B-Instruct（小到能跑在手机） |
| App 框架 | SwiftUI (iOS) / Jetpack Compose (Android) |
| 上下文管理 | 滑动窗口 + 上下文压缩 |
3. 产出物
on-device-llm-app/
├── README.md
├── ios/
│ ├── LlamaApp/ # SwiftUI App
│ ├── llama.cpp/ # git submodule
│ └── build_scripts/
├── android/
│ ├── app/ # Jetpack Compose
│ ├── llama.cpp/
│ └── build.gradle
├── models/
│ └── qwen2.5-1.5b-instruct-q4_k_m.gguf # 不入仓，README 给下载脚本
├── bench/
│ ├── bench_ios.sh # 在 iPhone 上跑基准
│ └── bench_android.sh # 在 Android 上跑基准
└── docs/
├── ios_memory_budget.md # iPhone 各型号内存预算分析
├── android_soc_matrix.md # 各 SoC 性能矩阵
└── battery_test.md # 电量影响测试4. 拿出来说的卖点
- "我能在 iPhone 15 Pro 上跑 1.5B 模型，TTFT 1.2s、TPOT 80ms"：这是真实可演示的端侧性能
- "我懂电量优化"：测出连续对话 30 分钟掉电 X%，给出"低电量模式降生成速度"的策略
- "我懂模型选择"：为什么选 1.5B 不选 7B（手机内存预算），为什么选 Qwen 不选 Llama（中文场景质量更高）
- "我懂跨 SoC 适配"：在 Apple A17、Snapdragon 8 Gen 3、天玑 9300 三个 SoC 上的性能差异，给出"运行时检测 SoC 选 backend"的方案
- "我懂端侧独特挑战"：内存预算、热限频、电池管理、隐私合规——这些都是云端没有的问题
详见 llama.cpp 与 GGUF 与 移动端部署，也是 部署设计原则 中"显存预算先算清"的极端场景。
七、项目组合建议
不是每个项目都要做——选 2–3 个做深，比 5 个都浅尝好。下面是三种组合建议：
组合 A：云端推理工程师（最常见）
- 项目 1（RAG 服务）：覆盖多模型流水线
- 项目 2（多模型路由）：覆盖成本优化与编排
- 项目 4（量化 benchmark 平台）：覆盖量化与决策
这套组合覆盖云端推理的三大核心能力：端到端流水线、成本优化、量化决策。面试时三件套全能讲，详见 能力对标：简历该突出什么。
组合 B：端侧 / Mobile AI 工程师
- 项目 5（端侧 LLM App）：核心
- 项目 3（流式对话 API）：补云端经验
- 项目 1（RAG 服务）：补流水线经验
端侧岗位简历上项目 5 必须有，否则第一关过不了。补项目 3 与 1 是因为端侧工程师经常要与云端协同（端云混合架构），不懂云端推理会有短板。
组合 C：性能优化 / 加速器岗位
- 项目 4（量化 benchmark 平台）：核心
- 项目 2（多模型路由）：覆盖系统级调度
- 自定义项目：CUDA kernel 优化（本文不展开，可参考 算子融合与自定义核）
性能优化岗位的核心能力是"测量与决策"，项目 4 是最直接的体现。再加一个系统级（多模型路由）与一个底层级（kernel），构成完整的"测量→决策→底层"能力链。
八、每个项目都要有的"标配"
无论选哪个项目，下面 5 件标配不能少——这是 部署设计原则 在作品集上的落地：
- README 写得像论文：动机、架构图、技术选型理由、性能数字、复现命令——少一项就不及格
- 基准报告独立成文：在
reports/下放完整的 推理基准测试实践 报告模板 - 可复现的 docker-compose：面试官能
docker compose up一键跑起你的项目 - 演示视频或截图：纯代码没法让人 30 秒理解你的项目，演示比代码更有说服力
- 面试讲稿：提前写下"如果面试官让我讲 5 分钟，我要讲什么"——详见 面试题库 的 STAR 框架
九、延伸阅读
- 从零部署一个推理服务 —— 五个项目的共同基础
- 推理引擎选型对比 —— 项目 1/2/4 的引擎选择依据
- 推理基准测试实践 —— 五个项目的性能报告方法论
- 部署设计原则 —— 五个项目的设计纪律
- 常见陷阱与反模式 —— 五个项目避坑清单
- 模型服务化与编排 —— 项目 1/2/3 的理论基础
- llama.cpp 与 GGUF —— 项目 5 的核心引擎
- 移动端部署 —— 项目 5 的延伸
- 能力对标：简历该突出什么 —— 项目组合与简历呈现
- 面试题库 —— 项目讲稿的参考
参考资料
- Qdrant Documentation —— 项目 1 向量库
- bge-reranker —— 项目 1 reranker
- Ragas: RAG Evaluation —— 项目 1 评测
- FastAPI + SSE —— 项目 3 服务框架
- sse-starlette —— 项目 3 SSE 实现
- AutoAWQ —— 项目 4 量化
- AutoGPTQ —— 项目 4 量化
- lm-evaluation-harness —— 项目 4 评测
- llama.cpp —— 项目 5 端侧引擎
- GGUF Format —— 项目 5 量化格式
- Triton Inference Server: Model Ensemble —— 项目 2 多模型编排