大模型接入实战:模型选型、API 调用、流式输出、成本控制
掌握大模型 API 接入的完整工程实践:模型选型、API 调用、流式输出(SSE)、错误处理、重试、限流、成本控制、密钥安全,结合朋友好学 App 的服务端中继实战
- 了解主流大模型的能力差异和选型维度:质量、速度、成本、上下文长度、多模态、函数调用
- 就讲OpenAI兼容格式的大模型API标准调用,核心搞懂messages结构,分system、user、assistant三种角色就行。
- 掌握流式输出(SSE)的实现原理和代码,理解打字机效果对用户体验的重要性
- 就讲错误处理和重试策略:429 限流、5xx 服务端错误、超时、指数退避
- 掌握成本控制的核心手段:模型分级、Token 计数、缓存、上下文压缩、批量处理
- 理解 API 密钥安全:密钥不能写前端、必须走后端代理、环境变量管理、密钥轮换
- 朋友好学 App 用的是「后端优先 + 服务端级联中继」双通道:前端零密钥、内置的只是作者托管后端地址,这是实战内容。
大模型选型:没有最好的模型,只有最合适的
2024-2026 年,大模型市场已经从「一家独大」变成「百花齐放」。不同模型在质量、速度、成本、上下文长度、多模态、函数调用等方面各有优劣。选型不是选「最强的」,而是选「最适合你的场景的」。
质量:能不能把任务做对?用真实测试集评测,别只看排行榜;速度:用户能等多久?对话场景首 token 延迟 < 1s 比较理想,简单任务用快模型;成本:预算能撑多少用户?简单任务用便宜模型,复杂任务才用贵模型——80% 的任务用便宜模型就能搞定;上下文长度:输入有多长?普通对话 8K 够,长文档总结需要 32K+,整本书分析需要 100K+;功能支持:需要多模态(图片/音频)、函数调用(Function Calling)、JSON 模式、结构化输出吗?不是所有模型都支持。选型策略:简单任务(分类/摘要/翻译)用便宜快模型(豆包/DeepSeek/Qwen/GPT-4o-mini),复杂任务(推理/代码/复杂写作)用好模型(GPT-4o/Claude/GPT-4.1),按场景分级,别所有任务都用最贵的模型。本课程的朋友好学 App 用豆包 Seed 2.0,因为中文好、价格低、国内访问快、对学习场景的对话质量足够。
API 调用标准格式:OpenAI 兼容已成事实标准
目前几乎所有大模型厂商都用 OpenAI 兼容的 API 格式(/v1/chat/completions),包括 OpenAI、Anthropic(通过兼容层)、Google Gemini(兼容模式)、字节豆包(火山方舟)、DeepSeek、阿里通义、智谱、月之暗面等。你写一套调用代码,切换 base_url 和 api_key 就能换不同模型,不用给每个厂商写一套代码。
// 标准大模型 API 调用(OpenAI 兼容格式,Python 示例)
// import requests
//
// response = requests.post(
// "https://ark.cn-beijing.volces.com/api/v3/chat/completions", # 豆包火山方舟的 endpoint
// headers={
// "Content-Type": "application/json",
// "Authorization": "Bearer ark-your-api-key-here" # 替换成你的密钥
// },
// json={
// "model": "doubao-seed-2-1-turbo-260628", # 模型 ID
// "messages": [ # 对话消息列表,按时间顺序
// {"role": "system", "content": "你是一个耐心的 Python 编程老师,用简洁易懂的语言回答问题。"},
// {"role": "user", "content": "什么是列表推导式?给我一个例子。"},
// # {"role": "assistant", "content": "..."} # AI 的回复,可以继续追加形成多轮对话
// ],
// "temperature": 0.7, # 随机性:0=确定性,1=最随机,创意写作0.8,代码0.2
// "max_tokens": 2000, # 最大生成 token 数
// "stream": False, # 是否流式输出
// }
// )
//
// result = response.json()
// answer = result["choices"][0]["message"]["content"]
// usage = result["usage"] # {"prompt_tokens": 50, "completion_tokens": 120, "total_tokens": 170}
// print(answer)
// print(f"消耗: {usage}")messages 结构:三种角色
messages 是一个数组,每个元素有 role 和 content。三种 role:system(系统提示词):设定 AI 的身份、语气、规则,在整个对话中生效,通常放在第一条;user(用户消息):用户输入的内容;assistant(AI 回复):AI 之前的回复,用于形成多轮对话的上下文。多轮对话就是不断往 messages 数组里追加 user 和 assistant 消息。messages 总长度不能超过模型的上下文窗口(如 128K token),超长需要做上下文管理(截断/摘要/滑动窗口)。
system prompt 是控制 AI 行为的核心。好的 system prompt 能提升输出质量,要写这些内容:设定身份(「你是一个有10年经验的Python老师」);设定语气风格(「用简洁易懂的语言,多用例子」);设定规则(「如果用户问的不是Python相关问题,礼貌地引导回Python学习」);设定输出格式(「用Markdown格式,代码块用三个反引号加 python 标注语言」);设定边界(「不要给出完整的作业答案,只给提示和思路」)。system prompt 是 AI 产品的「灵魂」,得反复迭代优化,别只写一句「你是一个助手」。
流式输出(SSE):让用户不再干等
非流式调用是等 AI 全部生成完再一次性返回。如果 AI 要生成 1000 字,用户可能要等 5-10 秒才能看到任何内容,体验很差。流式输出(Streaming)是 AI 生成一个字就推一个字,用户能看到文字逐字出现(打字机效果),首字延迟通常 < 1 秒,体验好很多。几乎所有对话类 AI 产品都用流式输出。本课程的朋友好学 App AI 助手就是 SSE 流式输出。
// 流式输出实现(SSE,Python FastAPI 示例)
// from fastapi import FastAPI
// from fastapi.responses import StreamingResponse
// import requests, json
//
// app = FastAPI()
//
// @app.post("/api/ai/chat")
// async def chat(request: dict):
// messages = request["messages"]
//
// def generate():
// resp = requests.post(
// "https://ark.cn-beijing.volces.com/api/v3/chat/completions",
// headers={"Authorization": "Bearer ark-your-key"},
// json={
// "model": "doubao-seed-2-1-turbo-260628",
// "messages": messages,
// "stream": True, # 关键:开启流式
// },
// stream=True # requests 流式读取
// )
// for line in resp.iter_lines():
// if line:
// line = line.decode("utf-8")
// if line.startswith("data: "):
// data = line[6:]
// if data == "[DONE]": # 流结束标记
// break
// chunk = json.loads(data)
// delta = chunk["choices"][0]["delta"]
// if "content" in delta:
// yield delta["content"] # 逐字推给前端
//
// return StreamingResponse(generate(), media_type="text/event-stream")
//
// 前端用 EventSource 或 fetch + ReadableStream 接收,逐字追加到页面SSE(Server-Sent Events):服务器单向推送给客户端,基于 HTTP,简单轻量,适合 AI 流式输出(服务器推数据,客户端不需要发消息)。WebSocket:双向通信,客户端和服务器都能发消息,适合聊天(双向)、实时协作、游戏。AI 对话场景:如果是「用户发一次消息,AI 流式回复一次」,SSE 足够(更简单);如果需要「AI 回复过程中用户能中断/修改」或「多轮实时交互」,用 WebSocket。本课程的朋友好学 App 用 SSE,因为简单且够用。注意:SSE 默认只支持 GET,POST 需要用 fetch + ReadableStream 手动解析(EventSource 不支持 POST)。
错误处理和重试:AI API 不稳定是常态
大模型 API 不是 100% 稳定的——会遇到 429(限流,请求太频繁)、5xx(服务端错误,模型过载)、超时(网络或模型慢)、连接重置等。生产环境必须做错误处理和重试,不能一次失败就给用户报错。
不要无限重试:最多3-5次,否则会把故障放大(雪崩);不要固定间隔重试:用指数退避+随机抖动(jitter),避免所有客户端同时重试打垮服务端;重试要幂等:重试的请求不能产生副作用(如重复下单、重复扣费),写操作要加幂等键(idempotency key);不要重试400/401/403:这些是客户端错误,重试也不会成功,只会浪费资源;注意重试的token消耗:每次重试都会重新消耗input token,大上下文重试成本高。
成本控制:AI 是按 token 计费的,不控制会烧钱
大模型 API 按 token 计费,input token 加 output token,一般 output 更贵。不做成本控制,一个热门功能可能一天烧几千块。成本控制的核心手段:
先做模型分级:我见过太多产品所有任务都用 GPT-4,成本是必要的 5-10 倍。把任务分类:简单分类/提取用 GPT-4o-mini/豆包/DeepSeek(便宜 10-20 倍),复杂推理/代码才用 GPT-4o/Claude。上下文管理是最大的成本项:多轮对话如果保留全部历史,第 20 轮对话的 input token 是第 1 轮的 20 倍。用滑动窗口(最近 5-10 轮)+ 旧对话摘要,能把 input token 减少 70%+。缓存:FAQ、常见问题、固定格式的任务,缓存结果能省 30-50% 的调用。设置预算告警:月度预算到 80% 时告警,到 100% 时自动降级(切换到便宜模型或返回缓存),不要等账单出来才发现超支。本课程的朋友好学 App 用豆包,价格本身就低(比 GPT-4 便宜 10 倍以上),加上用户量不大,成本可控。如果用户量上来,再考虑模型分级和缓存。
密钥安全:API Key 绝对不能写前端
这是 AI 产品最常见的安全漏洞——把 API Key 写在前端代码里(React/Vue 组件、JS 文件)。前端代码会被打包到用户的设备上,任何人都能通过浏览器开发者工具或反编译 APK 提取 Key。Key 泄露后,别人可以用你的 Key 调用 API,账单算你的——可能一夜之间烧光你的预算。
// 正确架构:后端代理(Key 只存在服务器)
//
// 前端 App ──请求──▶ 你的后端服务器 ──带Key调用──▶ 大模型 API
// (Key存在环境变量/密钥管理服务)
//
// 前端只知道你的后端地址,不知道大模型 Key
// 后端验证用户身份/限流/计费后,用自己的 Key 调用大模型
// 大模型的响应通过后端返回给前端
//
// 环境变量(.env,不进 Git):
// ARK_API_KEY=ark-your-secret-key-here
// ARK_BASE_URL=https://ark.cn-beijing.volces.com/api/v3
// ARK_MODEL=doubao-seed-2-1-turbo-260628
//
// 后端代码读取环境变量:
// const apiKey = process.env.ARK_API_KEY; // 从环境变量读,不写死在代码里朋友好学 App 用的是「前端零密钥 + 后端级联中继」架构:App 端不保存任何火山方舟密钥,优先连作者托管的后端 server.js,由后端带着 Key 调火山方舟、再把 SSE 流回传给 App;主后端连不上时会自动级联到其它后端候选,整条链路都由服务端中继,Key 永远不下发到安装包,从根上消除反编译盗 Key 的面。代价是断网、或所有后端都不可达时 AI 不可用——这是安全优先的主动取舍。只有用户主动在「自带 Key」档位填自己的密钥时,前端才会临时使用它。商业产品就该这么做:密钥只放服务端,再配好限流和预算告警,防止被盗刷。
Key 存在环境变量或密钥管理服务(AWS Secrets Manager、阿里云 KMS、Vercel Environment Variables),不写在代码里;.env 文件加入 .gitignore,不进版本控制;不同环境用不同 Key(开发/测试/生产),生产 Key 权限最小化;定期轮换 Key(每 1-3 个月),泄露后立即吊销换新;后端做限流和配额(每个用户/IP 的调用次数限制),防止单个用户刷爆;设置预算告警和自动降级(超预算切换到便宜模型或暂停);不要在日志、错误信息、前端响应里打印完整 Key(只打印后 4 位用于排查);尽量不要在客户端存 Key;只有用户主动填写自己密钥这类场景才在本地保存,要做好本地加密、限流和预算告警。
本节小结
大模型选型五维度:质量、速度、成本、上下文长度、功能支持;就按模型分级来,简单任务用便宜模型,复杂任务用贵的,80%的任务用便宜模型就能搞定。API调用用OpenAI兼容格式(/v1/chat/completions),messages分三个角色:system、user、assistant,system prompt是AI产品的灵魂,得反复迭代。流式输出(SSE)能让用户看到打字机效果,首字延迟<1s,比非流式体验好太多。错误处理:可恢复错误(429/5xx/超时)用指数退避加随机抖动重试,最多3-5次;不可恢复错误(400/401/403)不重试,所有情况失败后都降级。成本控制七手段:模型分级、Token计数限制、缓存、上下文压缩(滑动窗口加摘要)、批量处理、限流配额、自部署开源模型。密钥安全:API Key绝对不能写前端,必须走后端代理,存在环境变量里,定期轮换,还要做限流预算告警。朋友好学 App用「后端优先+服务端级联中继」双通道:前端零密钥、内置作者托管后端地址,Key只在服务端。下一节讲RAG与Agent——大模型接入后,怎么让它拥有你的私有知识和执行工具的能力。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验,点卡片展开
纯网页包壳容易被应用商店以“最小功能不足”驳回,关键在于用原生能力补足 Web 做不到的部分:权限申请(麦克风/摄像头)、安全键盘与键盘高度、状态栏与安全区、文件与分享、版本更新、扫码等。让 Web 负责快速迭代的内容与 UI,原生负责系统能力与体验兜底,这种混合架构才是套壳 App 的合规且高体验形态。