今年 6 月，我一直在做一个自己的练手项目。

项目本身不算复杂，我想做一个校园内部知识库问答系统。简单来说，就是上传学校通知、课程安排、实验室文档，然后让用户像聊天一样直接提问，系统根据文档内容返回对应答案。

一开始我觉得这个项目实现起来应该不会太难。

因为整体技术路线我已经提前规划好了。

前端直接用 Flask 写接口，向量检索部分用 FAISS，文档切片用 LangChain，最后调用大模型完成生成。

真正开始开发之后，我很快发现，项目里最麻烦的问题并不是代码逻辑，而是大模型调用方案到底怎么选。

最开始，我并没有考虑云平台

项目开始时间大概是 6 月初。

我最开始的想法其实很直接。

既然很多模型都开源了，那我完全可以自己本地部署。

当时我先用 Ollama 测试了几个模型。

主要测试的是 DeepSeek 和 Qwen。

本地部署最大的问题很快就出现了。

我电脑显卡是 RTX4060 Laptop，8GB 显存。

一开始我以为做普通文本生成应该没问题。

但真正跑长上下文的时候，推理速度明显下降。

有时候一次回答需要等待二十多秒。

而且连续运行之后显存占用一直维持在高位。

如果同时开 VSCode、本地数据库和浏览器调试页面，整台电脑会明显变卡。

那时候我第一次意识到。

大模型项目真正消耗资源的地方，比我想象中更严重。

后来我尝试租服务器，结果大部分时间都在处理环境问题

本地部署效果不理想之后，我开始考虑直接租 GPU 服务器。

我原本以为问题会解决。

但事实证明我还是低估了环境配置的复杂程度。

第一天部署 CUDA。

第二天处理 Python 依赖冲突。

第三天安装推理框架。

后来又因为 transformers 版本问题连续报错。

我印象特别深。

有一天晚上我花了接近四个小时，一直在看终端报错日志。

结果真正写业务代码的时间不到半小时。

后来我甚至专门算了一下。

从项目开始到那时候，我大概 70% 时间都花在环境配置，而不是开发本身。

这时候我开始认真考虑另一个问题。

有没有必要继续自己部署。

我第一次开始尝试直接调用 API

大概 6 月中旬，我决定换一种方案。

不再自己部署模型，而是直接调用云端 API。

最开始我尝试了几个不同平台。

但测试过程中我遇到一个比较麻烦的问题。

接口并不统一。

有些平台参数格式不一样。

有些平台文档写得非常简单。

很多字段说明并不完整。

比如 stream 参数到底怎么传。

max_tokens 最大值是多少。

返回结果里面 token usage 应该怎么统计。

很多时候只能一边看文档一边反复测试。

说实话，这个过程并不比自己部署轻松多少。

接触蓝耘之后，我第一次感觉调用模型这件事变简单了

后来我偶然接触到了蓝耘元生代平台。

一开始吸引我的其实不是模型本身。

而是它的 MaaS 平台。

我打开控制台之后第一眼注意到的是模型广场。

GLM-5.2、GLM-5.1、DeepSeek-V3.2、MiniMax-M2.5 这些我之前测试过的模型基本都能看到。

这一点让我印象挺深。

因为以前我测试不同模型，经常要在多个平台来回切换。

申请不同 API Key。

看不同接口文档。

有些平台甚至连请求格式都不一样。

而蓝耘把多个模型直接整合到了同一个控制台。

至少在管理层面方便很多。

API 文档完整度，比我想象中重要得多

真正开始接入之后，我最先看的其实不是控制台，而是蓝耘的 API 文档。

这一点我反而想专门写一下。

因为我之前接过一些第三方接口，经常遇到文档写得不完整的问题。

开发者最怕的其实不是代码难。

而是接口文档模糊。

你不知道参数应该怎么传，也不知道报错到底是哪里出了问题。

蓝耘这点给我的感受确实不错。

文本模型接口地址直接统一：

https://maas-api.lanyun.net/v1/chat/completions

鉴权方式也比较直接。

使用 API Key Bearer Token 就能调用。

而且官方文档把参数说明整理得很完整。

例如：

stream：控制是否流式返回

max_tokens：控制最大生成长度

frequency_penalty：减少重复生成

presence_penalty：增加新主题生成概率

包括最终返回结果中的 token usage 统计也写得比较清楚。

这一点看起来很小。

但实际开发过程中真的能减少很多排查时间。

我第一次请求几乎没有踩坑

以前我接一些模型 API，经常第一次请求就报错。

要么 Authorization Header 不对。

要么 body JSON 格式错误。

要么 model id 填写错误。

但这次按照蓝耘文档里的示例，我第一次请求基本就成功返回了结果。

我当时直接用 Python 写了一个简单测试脚本。

import requests

url = "https://maas-api.lanyun.net/v1/chat/completions"

headers = {
    "Authorization":"Bearer YOUR_API_KEY",
    "Content-Type":"application/json"
}

data = {
    "model":"/maas/deepseek-ai/DeepSeek-R1",
    "messages":[
        {
            "role":"user",
            "content":"介绍一下人工智能发展趋势"
        }
    ]
}

response = requests.post(url,headers=headers,json=data)

print(response.json())

整个请求过程基本没有额外排查问题。

相比之前我自己测试其他接口反复看报错信息，这次确实省了很多时间。

后来我开始关注成本问题

项目逐渐稳定之后，我开始注意另一个现实问题。

成本。

以前我租固定 GPU 服务器。

费用一个月接近 700 到 800 元。

但问题是我项目并不是全天运行。

很多时候一天真正测试时间可能只有几个小时。

大量 GPU 资源其实一直空闲。

后来我开始测试蓝耘 GPU 算力资源。

我比较喜欢的一点是按实际使用计费。

不用长期占用固定服务器。

这一点对于个人开发者其实很重要。

至少对我来说，不需要为了偶尔测试项目长期承担固定服务器成本。

做完这个项目之后，我改变了以前的一个看法

以前我一直觉得。

做 AI 项目最重要的是模型能力。

谁模型参数大，谁推理效果好，谁就更值得用。

但最近这个项目做下来之后，我越来越觉得自己以前忽略了一件事。

真正影响开发效率的，并不是模型本身。

而是围绕模型存在的一整套基础设施。

接口稳定性。

文档是否完整。

算力成本是否合理。

模型接入流程是否统一。

这些东西看起来不起眼。

但真正做项目的时候，往往比模型参数本身更重要。

至少对我这次项目来说。

蓝耘元生代平台并没有让我觉得“某个模型突然变得更强”。

它真正帮我解决的问题是另外一件事。

我终于不用再把大量时间浪费在环境配置和接口排查上。

以前我总感觉自己在维护开发环境。

现在我终于感觉，自己真正是在开发项目本身。

这可能才是我这次做项目最大的收获。