大模型这波浪潮起来之后我身边不少朋友第一反应都是想玩但没卡。本地跑个 7B 模型光显存就得 8G 起步想微调更是直接劝退租云 GPU 吧按小时计费跑两天钱包就瘪了。于是很多人卡在想搭个自己的 AI 助手这一步迟迟没动手。其实换个思路就通了推理这件事完全可以不放在自己机器上。OpenRouter 这类聚合平台把市面上主流大模型的 API 统一成一个入口注册就能拿到密钥很多模型还带免费额度。你要做的只是写几十行调用代码把对话界面搭起来。整条链路不需要一块独立显卡一台普通笔记本、甚至一台云主机都能跑。这篇就把我从零搭一个零成本大模型助手的完整过程拆开讲包括平台怎么选、密钥怎么管、免费模型怎么挑、代码怎么写、以及那些文档里不会写但一定会踩的坑。1. 先想清楚为什么不买 GPU反而是更聪明的起点1.1 本地部署的真实成本比你想的高很多人对本地跑大模型有种执念觉得数据在自己手里才安心。这个想法没错但得算笔账。一个 7B 参数的模型FP16 精度下光权重就要占约 14GB 显存就算用 4-bit 量化压到 4GB 左右加上 KV Cache 和推理框架本身的开销实际占用往往还要往上浮。这意味着你至少需要一张 8GB 显存的卡才能比较舒服地跑起来12GB 会更稳。再看时间成本。装 CUDA 驱动、配 PyTorch 的 GPU 版本、处理各种版本冲突这一套下来新手折腾一整天是常态。我见过太多人卡在显卡驱动和框架版本对不上这一步最后热情耗尽。而租 GPU 呢按量计费的实例一张中端卡每小时几块到十几块不等你要是想长期挂一个助手服务一个月下来费用相当可观。所以对绝大多数我只是想有个能用的 AI 助手的人来说本地部署的性价比其实很低。除非你有明确的数据合规要求或者就是要做模型微调研究否则没必要一上来就啃硬件这块硬骨头。1.2 API 聚合平台解决的到底是什么问题传统做法是想用 A 家的模型就注册 A 家、充值 A 家、对接 A 家的接口想换 B 家又得重来一遍。每家接口格式还不完全一样有的用messages数组有的字段名不同切换成本很高。OpenRouter 这类聚合平台的价值就在于把多家模型收敛到一个统一的 OpenAI 兼容接口。你只需要一个密钥、一个 base_url就能调用平台上挂载的各种模型切换模型只是改一个字符串参数的事。这对个人开发者和小项目来说省掉的是大量的对接和维护工作。提示聚合平台本质是中间层请求会经过它的服务器转发。所以涉及敏感数据的场景要谨慎评估个人学习、日常问答、内容生成这类用途则完全没问题。1.3 免费额度能撑起一个什么样的助手这是大家最关心的。平台上确实有一批模型提供免费调用额度通常以:free后缀标识。这些免费模型大多是中小参数量的开源模型比如 gemma 系列、一些 7B 到 9B 级别的模型。它们的能力边界在哪日常对话、文本润色、简单代码解释、翻译、信息整理这些任务免费模型完全够用。但你要是让它做复杂推理、长文档深度分析、高质量长文创作就会明显感觉到力不从心——要么答得浅要么中途开始胡言乱语。所以定位要摆正免费额度适合做个人助手、学习练手、轻量工具别指望它替代付费的旗舰模型。2. 平台与模型选型别一上来就挑最贵的2.1 注册与密钥获取的实际流程流程本身不复杂但有几个细节值得说。注册一般支持邮箱或第三方账号登录登录后在账户设置里能找到 API Keys 管理页面点创建就能生成一串以sk-or-开头的密钥。生成后一定要立刻复制保存因为多数平台出于安全考虑密钥只在创建时完整显示一次关掉页面就再也看不到了只能重新生成。密钥的管理是个容易被忽视的点。我的建议是不要硬编码在代码里用环境变量或.env文件管理给不同用途创建不同的密钥比如一个给本地测试、一个给线上服务方便出问题时单独吊销定期轮换尤其是密钥曾经出现在截图、日志或公开仓库里的时候。# .env 文件示例 OPENROUTER_API_KEYsk-or-你的密钥 OPENROUTER_BASE_URLhttps://openrouter.ai/api/v12.2 免费模型怎么挑看三个指标平台上模型列表很长免费的那批怎么选我一般看三个维度。第一是上下文长度。这个直接决定你能喂多长的内容。有的免费模型上下文只有 4K 到 8K token稍微长一点的对话历史就超了会直接报错。有的能到 32K 甚至更高体验就好很多。选之前一定看清楚。第二是参数量与定位。gemma-7b 这类 7B 模型属于轻量级响应快、成本低适合高频简单任务如果平台上有更大的免费模型复杂任务优先用大的。第三是稳定性。免费模型在高峰期经常排队或限流返回 429 或超时是家常便饭。所以实际项目里我通常会配置一个主模型 备用模型的降级策略主模型挂了自动切备用。维度建议标准踩坑提醒上下文长度至少 8K优先 32K太短会导致长对话直接报错参数量简单任务 7B 够用复杂推理别硬上小模型稳定性有备用模型兜底免费模型高峰期限流频繁响应速度首 token 延迟可接受大模型免费版可能很慢2.3 一个容易被忽略的细节模型名的写法调用时模型名是字符串但不同平台的命名规则不一样。有的带厂商前缀比如google/gemma-7b-it有的免费版要加:free后缀。写错模型名是最常见的 400 错误来源之一。报错信息里通常会提示支持的模型名有哪些照着改就行。我建议把常用模型名集中定义成常量别散落在代码各处改起来方便。3. 把调用链路跑通从一次 curl 到完整对话3.1 先用最原始的方式验证密钥写代码之前先用 curl 打一发确认密钥和网络都通。这一步能帮你排除掉一大半到底是密钥问题还是代码问题的纠结。curl https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d { model: google/gemma-7b-it:free, messages: [ {role: user, content: 用一句话解释什么是大模型} ] }如果返回里能看到choices[0].message.content说明链路通了。如果返回 401是密钥问题返回 400多半是模型名或参数格式问题返回 429就是限流了等一会儿再试。3.2 Python 封装把重复逻辑收进一个类验证通过后用 Python 封装一个客户端。核心思路是把发请求、处理异常、重试这些重复逻辑收进一个类里业务代码只管传消息、拿结果。import os import time import requests from dotenv import load_dotenv load_dotenv() class LLMClient: def __init__(self, modelgoogle/gemma-7b-it:free, fallbackNone): self.api_key os.getenv(OPENROUTER_API_KEY) self.base_url os.getenv(OPENROUTER_BASE_URL) self.model model self.fallback fallback def chat(self, messages, temperature0.7, max_retries3): models [self.model] ([self.fallback] if self.fallback else []) for model in models: for attempt in range(max_retries): try: resp requests.post( f{self.base_url}/chat/completions, headers{ Authorization: fBearer {self.api_key}, Content-Type: application/json, }, json{ model: model, messages: messages, temperature: temperature, }, timeout60, ) if resp.status_code 200: return resp.json()[choices][0][message][content] if resp.status_code 429: time.sleep(2 ** attempt) # 指数退避 continue resp.raise_for_status() except requests.RequestException as e: print(f[{model}] 第 {attempt1} 次失败: {e}) time.sleep(1) raise RuntimeError(所有模型均调用失败)这段代码里有几个设计点值得解释。指数退避2 ** attempt是为了应对限流——第一次等 1 秒第二次 2 秒第三次 4 秒避免疯狂重试把额度打得更死。降级策略是主模型失败后自动切备用模型提升整体可用性。超时设置timeout60很重要免费模型偶尔会卡住不返回没有超时的话程序会一直挂着。3.3 多轮对话历史消息怎么管大模型本身是无状态的它不记得你上一句说了什么。所谓多轮对话其实是每次请求都把完整的历史消息一起发过去。所以你需要维护一个messages列表每轮把用户输入和模型回复都追加进去。history [{role: system, content: 你是一个简洁友好的助手}] def ask(user_input): history.append({role: user, content: user_input}) reply client.chat(history) history.append({role: assistant, content: reply}) return reply这里有个坑历史越长token 消耗越大而且迟早会超过模型的上下文上限。免费模型上下文本来就小聊十几轮就可能爆。解决办法是做个简单的截断——只保留最近 N 轮或者当总长度超阈值时把最早的消息丢掉。更讲究的做法是做摘要压缩但对个人助手来说截断就够了。4. 从脚本到助手界面、记忆与流式输出4.1 用 Streamlit 十分钟搭个网页界面命令行能跑通之后下一步是给它一个像样的界面。Streamlit 是我最推荐的选择纯 Python不用写前端几十行就能出一个能用的聊天页。import streamlit as st from client import LLMClient st.title(我的大模型助手) client LLMClient(modelgoogle/gemma-7b-it:free) if messages not in st.session_state: st.session_state.messages [ {role: system, content: 你是一个简洁友好的助手} ] for msg in st.session_state.messages: if msg[role] ! system: with st.chat_message(msg[role]): st.write(msg[content]) if prompt : st.chat_input(说点什么...): st.session_state.messages.append({role: user, content: prompt}) with st.chat_message(user): st.write(prompt) with st.chat_message(assistant): reply client.chat(st.session_state.messages) st.write(reply) st.session_state.messages.append({role: assistant, content: reply})st.session_state是 Streamlit 里保存会话状态的关键页面刷新时消息不会丢。跑起来用streamlit run app.py浏览器自动打开一个能对话的助手就成了。4.2 流式输出让等待不再难熬非流式调用有个体验问题模型要生成完整段落后才一次性返回长回答时用户要盯着空白等好几秒。流式输出streaming能让文字像打字一样一个个蹦出来体感快很多。实现上请求时加stream: true然后逐行读取响应。OpenAI 兼容接口返回的是 SSE 格式每行以data:开头遇到data: [DONE]结束。def chat_stream(self, messages): resp requests.post( f{self.base_url}/chat/completions, headers{Authorization: fBearer {self.api_key}}, json{model: self.model, messages: messages, stream: True}, streamTrue, timeout60, ) for line in resp.iter_lines(): if not line: continue line line.decode(utf-8) if line.startswith(data: ): data line[6:] if data [DONE]: break import json delta json.loads(data)[choices][0][delta] yield delta.get(content, )配合 Streamlit 的st.write_stream就能实现打字机效果。注意流式模式下错误处理会更麻烦因为响应头返回 200 之后才可能中途出错所以要在循环里加 try 捕获。4.3 给助手加点记忆和人设一个光秃秃的问答框用久了会觉得单薄。两个低成本但效果明显的增强系统提示词system prompt决定助手的性格和边界。比如你是一个严谨的技术助手回答尽量给出可执行的步骤不确定的地方要明说比默认的泛泛而谈好用得多。这个提示词放在messages列表最前面每轮都带着。本地记忆可以用一个简单的 JSON 文件存对话历史重启后还能接着聊。再进一步可以把用户偏好、常用信息存成键值对在构造 system prompt 时动态拼进去助手就会显得记得你。注意免费模型的上下文有限记忆别存太多否则每轮请求都塞一大堆历史很快就超限了。我的经验是保留最近 10 轮左右更早的做摘要或直接丢弃。5. 那些文档不写但一定会踩的坑5.1 限流与超时免费额度的代价免费模型最大的问题就是不稳定。高峰期请求排队返回 429 是常态有时候请求发出去了几十秒没响应最后超时。应对策略前面代码里已经体现了指数退避重试 备用模型降级 合理超时。这三板斧基本能覆盖大部分情况。还有个细节不要并发猛打。免费额度通常有每分钟请求数限制你同时发十个请求大概率一半被拒。老老实实串行或者加个简单的节流。5.2 上下文超限报错信息要会读最常见的报错之一就是上下文超限提示类似maximum context length is X tokens。这时候别慌先算一下你的messages总长度。粗略估算一个中文字大约 1 到 2 个 token英文一个单词约 1.3 个 token。如果历史消息堆太多就截断。如果单条输入本身就超长比如贴了一整篇论文那只能换上下文更大的模型或者先做分段处理。5.3 密钥泄露一个真实的风险场景我见过有人把带密钥的代码直接推到公开仓库几小时后额度就被刷光了。密钥泄露的后果是实打实的经济损失如果绑了付费或额度被滥用。防护措施.env文件加进.gitignore代码里永远从环境变量读不写死定期在平台后台检查用量发现异常立即吊销重建给密钥设置额度上限如果平台支持。5.4 模型幻觉与输出格式不稳定免费小模型的幻觉问题比大模型明显尤其是问它事实性问题时可能一本正经地编。另外如果你要求它输出 JSON它经常会在 JSON 外面裹一层解释文字导致解析失败。应对办法是在提示词里明确要求只输出 JSON不要任何其他文字并且在代码里做容错解析——先尝试直接json.loads失败就用正则把{...}抠出来再解析。常见问题典型表现应对方案限流返回 429指数退避 备用模型超时长时间无响应设置 timeout 重试上下文超限400 报错截断历史 / 换大上下文模型密钥泄露额度异常消耗环境变量管理 定期轮换输出格式乱JSON 解析失败提示词约束 容错解析6. 成本控制与后续扩展的几个方向6.1 免费额度用完了怎么办免费额度不是无限的用超了要么等重置要么充值。充值前先想清楚用途如果只是个人日常用免费额度配合降级策略基本够如果要做正式产品那就得评估付费模型的成本按 token 计费的话一次对话几分钱到几毛钱不等量大了也是笔开销。我的建议是先用免费额度把产品逻辑跑通确认有价值再考虑付费别一上来就充钱。6.2 从助手到工具几个自然的扩展跑通基础对话后可以往几个方向延伸。一是接入知识库把本地文档做向量化检索后拼进提示词让助手能回答你私有资料里的问题。二是做成 API 服务用 FastAPI 包一层其他程序就能调用你的助手。三是多模型路由根据任务类型自动选模型——简单问答走免费小模型复杂任务走付费大模型兼顾成本和效果。6.3 关于要不要本地部署的最终判断绕了一圈回到最初的问题。我的结论是除非有硬性的数据合规要求或微调研究需求否则个人用户没必要折腾本地 GPU 部署。API 方案在成本、维护、模型更新上都占优。真到了需要本地的场景再考虑租 GPU 或买卡也不迟。先用最低成本把想法验证出来比什么都重要。我在实际搭这套东西的过程中最大的体会是别追求一步到位。先让 curl 通再让脚本通再加界面再加记忆每一步都能独立验证。这样出问题时你知道是哪一层的事排查起来快得多。反过来一上来就写个几百行的完整应用报错了根本不知道从哪查起。另外免费模型的脾气要摸清——哪个时段稳、哪个模型响应快用几天就有感觉了把这些经验固化成配置助手就越来越顺手。