我的碎碎念

不为繁华易匠心,不舍初心得始终。

0%

大家好,我是男秀。

最近,开智社群开了一门「零基础 AI 大模型研发训练营」课程。作为一名有着多年经验的 Python 工程师兼开智铁粉,这波羊毛……啊不,这门硬核课程必须第一时间加入。

经过“七七四十九天”的疯狂折磨,今天终于可以正式宣告:我亲手微调并上线了自己的第一个小模型!

2026 年初 OpenClaw 爆火,之后又出现了 Hermes。但只要你深入用过就会发现,这些项目本质上都是在代码层面为 AI 搭建外部环境。

AI 生态工具变化太快了,几个月甚至几周就会迭代一轮。天天去追这些随时可能被替代的脚手架。不如把精力收回来,去学习未来三到五年都不会变的底层知识——而大模型研发与微调的底层逻辑,恰恰就属于这一类。

费曼说过:“我不能创造的东西,我就不理解。”对大模型祛魅的最好方式,就是亲自去创造它。 这也是我深度参与大模型训练营的初衷。

开智的课程一如既往地保持着高信息密度的传统,也有很多必须动手的作业。

作为打工人,我的时间几乎全部分散在上班工作、照顾家庭等等日常琐事中,留给课程学习的时间极少。如果没有 AI 的配合,单靠肉身我几乎完成不了这些作业。

不过,成年人社会没有标准答题操作,我有我自己的破局之道:我的本地电脑本身接入了一块 NVIDIA RTX 4060 显卡。为了充分利用这个显卡,我在本地电脑部署了一个国产的 OpenClaw工具,然后将其对接到了飞书,加上deepseek最近发布了v4-pro版本,成本和效果达到了预期。

通过国产OpenClaw、飞书和4060显卡,我拉起了一套自动化训练流,直接通过飞书发送命令给OpenClaw工具,让它帮我执行:于是出现了这样的画风:我在公司上班的时候,OpenClaw 在后台跑训练;我晚上睡觉的时候,OpenClaw 还在跑训练。

并且每次睡觉前我给飞书发任务时,我老婆还吐槽我是个资本家+周扒皮,哈哈。

另外,相比于需要盯着余额的云平台,使用本地显卡最大的好处,是拥有了“大胆试错”的安全感。别人是大胆假设小心求证,我是大胆假设大胆求证。 这次数据集微调出来的效果不行,大不了就重新再训一遍!

工程这块,懂的不难,不懂才难。只有真正上手做过,才会形成自己的“行动知识”。

正如课程讲师提到,微调模型最重要的还是数据集。想要模型效果符合预期,至少需要 3000 条高质量的数据集。

在构建这 3000 多条数据的过程中,我实践下来最重要的一个心得就是:蒸馏大于爬取。 利用大模型的能力蒸馏出来的数据,质量远比直接去网上抓取的数据要高得多。

当然,工程上也有小技巧。盲目堆数据很容易浪费精力,我参考了一些做法:先精选 30 条核心的”黄金数据集”进行冒烟测试,验证方向没问题后,再扩充到 300 条微调,最后才逐步往上增加。

到这一步,前面提到的”本地显卡放心大胆试错”的心理优势就彻底闭环了——正是因为有 4060 在后面顶着,不计成本,我才可以放开手脚去迭代数据。一次效果不行?删掉重训。方向跑偏了?砍掉一半再试。这是一种大胆试错的安全感,与在云平台盯着余额跑训练的心理是不一样的。

怎么构建高质量的数据集?技术之外,最核心的其实是熟悉业务领域知识

在这次微调我的“咖啡师小模型”时,我遇到的最大难点,不是技术知识不足,而是我根本不知道一个真实的吧台咖啡师,到底需要哪些核心知识。

在模型早期的内测评估阶段,因为我对业务不够懂,只能全靠大模型的能力去进行数据蒸馏。小模型是能够微调出来了,但是我很难评估它的准确性,所以我让更厉害的模型去评估的时候,总是会出现一些冲煮参数不准确的硬伤。

比如模型会把冲煮水温写成”245°C”——水都烧干了。这种低级错误,不靠懂咖啡的人来纠正是发现不了的。

这一点让我对微调模型有了更深的体会:大模型可以让不懂业务的人,轻易达到60分或者70分,但是想要达到90分甚至更高的分数,还是需要业务专家的参与。

我最终微调出来的,是一个“吧台咖啡师”的垂直场景模型。

用户进入网站,就好像访问了一家真实的咖啡店。在吧台里,有一位咖啡师在随时和你对话。

为了还原这种场景感,我特地调整了语气风格:

  • 去百科化: 它的输出不会像 ChatGPT 那样,一开口就是一股标准、冰冷、充满教科书感的 AI 味。
  • 带点小情绪小动作: 我在数据集里特意加了一点咖啡师的小动作和小情绪。比如每次对话开头可能会有“调了调冷萃壶的水温”这样的小动作。
  • 压缩思考窗口:小模型的”脑容量”有限。我让它只记关键词(比如”深烘|水温|85-90°C”),不做长篇推理。用最少的信息锚定正确的答案。

体验地址已经上线,欢迎大家去我的“吧台”坐坐: 

🔗 体验地址https://coffee-master.zeabur.app

训练出自己的小模型之后,我一直在思考一个问题:大模型能替代 Agent 吗?

这次完整地走完微调、量化到部署的一整套流程后,我找到了答案:哪怕把小模型微调得炉火纯青,依然替代不了 Agent 开发。

因为大模型最擅长的是“推理”,而不是“搞琐事”。

像最基础的会话 Session 状态保持、复杂的业务流控制(Workflow)、以及特定敏感话题的拦截与拒绝回答功能,这些工程层面的脏活累活,天然就不是大模型擅长的舞台。大刀阔斧的业务框架,必须由 Agent 来死死守住。

最近我看到一篇风向标新闻:一家团队通过「后训练 + Agent」的深度结合,拿下了特定垂直领域的最高分。

结合这次微调经历,我预测:未来的技术大趋势,必然是后训练与 Agent 开发的深度结合。

未来计划是对我的小模型加上小agent,模型负责”聊天语气”和”咖啡知识”,Agent 负责拦截敏感问题、管理会话状态等——各司其职。

课程结尾有一句金句:“当你学会创作大模型,你就不再是 AI 的旁观者,而是成为 AI 的掌控者。”

从最开始学习底层理论、拆解 Token,到后来亲手搞定准备数据、预训练、后训练、量化以及最终的部署,我完整地走了一遍大模型研发的全流程。这种把控感,让我真正拥有了创作属于自己的小模型作品的能力。

按照玩游戏的成就体系来看:

  • 今日成就已达成: 成功训练并上线自己的第一个大模型。
  • 主线任务进行中: 后面还要再多折腾几次,通过高频迭代让模型成为我真正的技术代表作。

期待早日通关,拿下「模型家」这个称号。

大家好,我是男秀。这一期和大家聊聊 AI 智能体(AI Agent)。

在实际开发 AI 应用的过程中,我们常常会碰到一些复杂任务,它们无法仅靠一次和大模型的简单对话完成。比如生成一份包含多步骤的市场报告、自动处理数据并保存结果,或是协调多个 AI 角色共同完成一项任务。这类需求往往需要一个连贯的工作流程,并且可能需要调用外部工具——而这正是 AI 智能体所擅长的。

虽然 LangChain 在这方面很强大,但对于想快速实现上述需求的开发者来说,它有太多的概念需要学习了。我一直希望找到一个更简单直接的框架,直到我深入接触了 OpenAI 官方推出的 openai-agents。它轻量、概念清晰、上手快,对大多数任务来说刚刚好。

智能体的核心概念

那么,openai-agents 是如何实现这些能力的呢?根据官方文档,我总结了三个核心概念。理解了它们,你就掌握了开发 AI 智能体的关键。

第一个是Agent(代理)。它是框架的核心,你可以把它看作一个”AI小助手”。通过配置,我们能定义它的角色、所用的模型和可调用的工具。主要包括:

  • 指令(Instructions):描述它的角色和任务,比如”你是一位文案专家”;
  • 模型(Model):指定使用哪个大模型,比如gpt-4o-mini;
  • 工具(Tools):赋予它调用外部函数或API的能力。比如把结果保存到本地文件中。

第二个概念是 Handoff(交接),这是实现多智能体协作的关键机制。Handoff 本身是一种特殊工具,当一个 Agent 调用它时,就意味着它已完成当前任务,并将”接力棒”及处理结果交给下一个指定的 Agent。这正是构建工作流的基础。

第三个概念是 Tool Calling(工具调用),它使得大模型能够调用开发者提前编写好的函数,来完成特定任务,如查询数据库、读写文件或调用 API。例如,当大模型被要求”把今天的天气保存到文件里”,它不会自己去写文件,而是调用一个名为 save_to_file 的工具来完成操作。这极大扩展了 Agent 的能力边界。

快速上手

如果你使用uv或者pip,可以使用以下命令快速安装openai-agents

1
2
3
4
5
# 使用 uv
uv pip install openai-agents

# 或者使用 pip
pip install openai-agents

安装完成后,我们可以用下面这段”Hello World”代码快速体验:

1
2
3
4
5
from agents import Agent, Runner

agent = Agent(name="Assistant", instructions="你是一位有帮助的助手", model="gpt-4o-mini")
result = Runner.run_sync(agent, "写一首关于编程中递归的俳句。")
print(result.final_output)

代码非常简洁,参数也很直观。在创建 Agent 对象时:

  • name 是智能体的名称,建议使用英文;
  • instructions 是系统提示词,用于定义其角色;
  • model 可指定使用的大模型。

如果你需要使用国内支持 OpenAI SDK 格式的大模型,可以在代码开头进行如下配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import os
from dotenv import load_dotenv
from openai import AsyncOpenAI
from agents import set_default_openai_client, set_default_openai_api

load_dotenv()

base_url = os.getenv('OPENAI_BASE_URL')
api_key = os.getenv('OPENAI_API_KEY')

custom_client = AsyncOpenAI(base_url=base_url, api_key=api_key)
set_default_openai_client(custom_client) # 设置openai客户端
set_default_openai_api("chat_completions") # 设置api格式

# 创建Agent
agent = Agent(name="Assistant", instructions="你是一位有帮助的助手", model="gpt-4o-mini")

常见代理模式

在掌握了基础用法之后,我们来看几种常见的代理模式如何用 openai-agents 实现。

调用工具模式

这是最基本也是最常用的模式,让 Agent 能够与外部环境互动。例如,我们可以定义一个工具函数,让 Agent 将生成的文案保存为本地文件。

首先,使用 function_tool 装饰器定义一个工具函数:

1
2
3
4
5
6
7
8
9
10
from agents import function_tool

@function_tool
def save_to_file(filename: str, content: str) -> str:
try:
with open(filename, 'w', encoding='utf-8') as f:
f.write(content)
return f"成功将内容保存到文件: {filename}"
except Exception as e:
return f"保存文件失败: {e}"

然后定义一个文件处理助手 Agent,并将工具传入:

1
2
3
4
5
6
file_saver_agent = Agent(
name="文件处理助手",
instructions="你是一个能写诗,并且能将诗歌保存到文件的助手。",
model='gpt-4o-mini',
tools=[save_to_file], # 传入工具函数
)

最后调用该 Agent:

1
2
3
4
5
prompt = "写一首关于夏日夜晚的短诗,并将其保存到名为 'summer_night.txt' 的文件中。"
result = Runner.run_sync(file_saver_agent, prompt)

# Agent的最终输出通常是确认信息
print(result.final_output)

执行完成后,你可以在项目目录中找到新生成的 summer_night.txt

工作流模式

也称为”流水线模式”,适用于多步骤任务。每个步骤由专门的 Agent 处理,上一个的输出作为下一个的输入。

比如我们要写一篇完整的营销文案,可以拆分为三个步骤,对应三个Agent:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
from agents import Agent

# 选题 Agent
topic_agent = Agent(
name="选题策划人",
instructions="你是一个爆款选题策划,请为'AI Agent'这个主题想出3个吸引人的标题。",
model="gpt-4o-mini",
)

# 大纲 Agent
outline_agent = Agent(
name="大纲规划师",
instructions="根据给定的选题,生成一份结构清晰、有逻辑的文章大纲。",
model="gpt-4o-mini",
)

# 文案 Agent
writer_agent = Agent(
name="文案撰写师",
instructions="根据提供的大纲,写一篇生动有趣、吸引人的文案。",
model="gpt-4o-mini",
)

按顺序调用它们:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
from agents import Runner

input_prompt = input("请输入你想要的文案主题:")

# 生成选题
topic_result = Runner.run_sync(
topic_agent,
f"请为'{input_prompt}'这个主题想出3个吸引人的标题。",
)
print("=== 选题策划结果 ===")
print(topic_result.final_output)

# 生成大纲
outline_result = Runner.run_sync(
outline_agent,
f"请根据以下选题生成一份简短的文案大纲,不要超过100字:\n{topic_result.final_output}",
)
print("=== 大纲规划结果 ===")
print(outline_result.final_output)

# 撰写文案
writer_result = Runner.run_sync(
writer_agent,
f"请根据以下大纲写一篇简短的文案,不要超过300字:\n{outline_result.final_output}",
)
print("=== 最终文案 ===")
print(writer_result.final_output)

最终就能实现选题→写大纲→写文案这么一个流程。

路由模式

该模式类似一个”任务调度员”,它本身不处理任务,而是根据内容类型将请求分发给专门的 Agent。

我们用文案生成的例子来说明:假设我们有三个专门的文案生成器,分别用于不同平台。

  • 小红书文案生成器
  • 口播(抖音/视频号)文案生成器
  • 朋友圈文案生成器

比如我们定义三个专业的文案生成Agent:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
from agents import Agent

# 小红书风格
xiaohongshu_agent = Agent(
name="xiaohongshu_agent",
instructions="用小红书风格写一篇种草文案。",
model="gpt-4o-mini",
)

# 口播稿风格
douyin_agent = Agent(
name="douyin_agent",
instructions="用口语化的风格写一个引人入胜的视频口播稿。",
model="gpt-4o-mini",
)

# 朋友圈风格
wechat_agent = Agent(
name="wechat_agent",
instructions="用简洁、有感染力的风格写一段朋友圈文案。",
model="gpt-4o-mini",
)

再定义一个路由 Agent,将上述 Agent 设为可交接对象:

1
2
3
4
5
6
7
# 定义路由Agent
router_agent = Agent(
name="文案任务路由器",
instructions="根据用户的请求,判断应该将任务交接给哪个文案生成器。不要自己生成文案,只做分发。",
model="gpt-4o-mini",
handoffs=[xiaohongshu_agent, douyin_agent, wechat_agent],
)

最后通过循环处理用户输入,实现自动路由:

1
2
3
4
5
6
7
8
9
10
11
12
13
agent = router_agent
msg = input("您好!请告诉我您的需求,我可以帮您生成小红书、抖音或朋友圈文案。")
user_messages = [{"content": msg, "role": "user"}]

while True:
result = Runner.run_sync(agent, user_messages)
print(result.final_output)
user_messages = result.to_input_list()
print("\n")

agent = router_agent
user_msg = input(f"当前 Agent 是:{agent.name},请输入消息:")
user_messages.append({"content": user_msg, "role": "user"})

生成器-评估器模式

这个模式很好理解,就是”一个写,一个改”。通俗地说,是让一个Agent(生成器)生成内容,然后让另一个Agent(评估器)扮演裁判或评论家的角色,去评估内容的质量。

我们定义两个 Agent:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
from agents import Agent

story_outline_generator = Agent(
name="story_outline_generator",
instructions=(
"你根据用户输入生成一个非常简短的故事大纲。"
"如果有反馈,请根据反馈改进大纲。"
),
model='gpt-4o-mini',
)

evaluator = Agent(
name="evaluator",
instructions=(
"你需要评估一个故事大纲,并判断它是否足够好。"
"如果不够好,请给出需要改进的反馈。"
"第一次绝不能通过。在5次尝试后,如果大纲足够好可以通过——不必追求完美。"
"\n请按以下JSON格式回复:\n"
'{"score": "pass|needs_improvement|fail", "feedback": "你的反馈内容"}'
),
model='gpt-4o-mini',
)

设定好Agent后,我们还需要编写解析函数,用于提取评估结果中的评分和反馈:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
def parse_evaluation(text: str) -> dict:
"""解析评估文本,提取评分和反馈"""
import json

try:
# 尝试直接解析JSON
data = json.loads(text.strip())
return {
"feedback": data.get("feedback", ""),
"score": data.get("score", "needs_improvement")
}
except json.JSONDecodeError:
return {
"feedback": "解析失败,请重试",
"score": "needs_improvement"
}

最后是主流程。同样的,我们从获取终端的用户输入,然后组装到user_messages里。然后在一个死循环里面,使用Runner.run方法调用生成故事大纲Agent后,获取其响应值作为评判Agent的输入。循环几次后,当评判Agent通过了,就输出最终的故事大纲。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
msg = input("你想听什么样的故事?")
user_messages: list[TResponseInputItem] = [{"content": msg, "role": "user"}]

latest_outline: str | None = None

while True:
story_outline_result = Runner.run_sync(
story_outline_generator,
user_messages,
)

user_messages = story_outline_result.to_input_list()
latest_outline = ItemHelpers.text_message_outputs(
story_outline_result.new_items)
print("已生成故事大纲")
print(latest_outline)

evaluator_result = Runner.run_sync(evaluator, user_messages)
evaluation_text = ItemHelpers.text_message_outputs(
evaluator_result.new_items)

# 手动解析评估结果
result = parse_evaluation(evaluation_text)
print(f"裁判评分: {result['score']}")
print(f"裁判反馈: {result['feedback']}")

if result['score'] == "pass":
print("故事大纲已足够好,流程结束。")
break

print("根据反馈重新生成大纲")

user_messages.append(
{"content": f"反馈: {result['feedback']}", "role": "user"})

print(f"最终故事大纲: {latest_outline}")

总结

这一期我们聊的openai-agents框架,最大的特点就是简单

它没有引入过多复杂的概念或抽象层,核心组成(Agent、Handoff、Tool)清晰直观,代码写起来也很自然,能让我们快速将想法落地。无论是构建简单的内容生成流水线,还是实现稍复杂的任务分发系统,它都提供了一个轻量而强大的解决方案。

如果你也希望快速实现多智能体协作,又不愿陷入繁杂的配置和概念中,那么 openai-agents 绝对值得一试。

大家好!我是男秀。上一期文章《uv:解放 Python 开发者的大脑内存》和大家聊了一下为什么使用uv,这一次和大家聊聊怎么使用uv,以及其常用的命令。

一、uv 是什么?为什么你需要它?

作为 Python 初学者,你一定已经接触过 pipvenvpip 用来安装各种第三方库(比如 requestsnumpy),venv 用来创建独立的 Python “工作区”(我们称之为虚拟环境),确保不同项目的依赖包互不干扰。

这套组合很经典,但有一个痛点:操作繁琐,速度偏慢

想象一下你的标准操作流程:

1、python -m venv .venv(创建虚拟环境)

2、source .venv/bin/activate(激活环境)

3、pip install requests numpy pandas (一个一个安装依赖)

4、pip freeze > requirements.txt (导出依赖列表,还得手动清理不需要的包)

每次新建项目都要重复这一套流程,不仅步骤多,而且当依赖包很多时,pip 的解析和安装速度也常常让人等到花儿都谢了。

这时候,我就非常推荐你使用uv。

uv 是由 Ruff 的作者(也就是用 Rust 大神级重写 Python Linter 的那位)推出的新一代 Python 包管理工具。它同样使用 Rust 编写,目标就是 “快” 和 **”简单”**。

它将 pipvenv 的功能合二为一,并提供了比它们快 10-100倍 的速度。用上它,你会发现原来 Python 的环境管理可以如此丝滑!

二、如何安装 uv

如果你选择uv,那么就非常简单,它本身也可以通过 pip 来安装。这就像用一把旧钥匙,去打开一扇通往新世界的大门。

无论是Windows 用户,还是 macOS / Linux 用户,在安装好Python环境后,打开你的终端或PowerShell,输入以下命令:

1
pip install uv

是的,你没看错,就这么简单!安装完成后,你可以通过以下命令来验证 uv 是否安装成功:

1
uv --version

如果你看到了类似 uv 0.6.16 的版本号输出,恭喜你,uv 已经成功安装在你的电脑上了。

三、uv的核心工作流

uv 的设计理念是让你忘记繁琐的命令,专注于代码本身。它的核心工作流非常直观:

第一步:初始化项目

当你创建好项目文件夹后,进入该目录的终端,使用 uv init 初始化。

1
2
3
4
# 举个例子
mkdir my-fastapi-project
cd my-fastapi-project
uv init

之后,uv 会在当前目录下创建以下文件:

1
2
3
4
├── .python-version
├── README.md
├── main.py
└── pyproject.toml # 现代Python项目的配置文件
  • .python-version:记录了你的 Python 版本。如果你的全局环境是 Python 3.11,那么这个文件就会写入 3.11。当你把项目分享给别人,或者在另一台电脑上使用时,uv 会自动寻找或下载 Python 3.11 版本来创建环境,保证了环境的一致性。
  • pyproject.toml:这是你项目的”身份证”,所有依赖包都会被记录在这里。

第二步:添加依赖包

现在,我们来安装项目需要的库。告别 pip install,迎接 uv add。

1
2
uv add fastapi
uv add "uvicorn[standard]" # 安装带额外功能的包

你会发现,uv 的安装速度快得惊人!几乎是瞬间完成。而且,uv 会自动将 fastapi 和 uvicorn 添加到 pyproject.toml 文件中,你再也不用手动维护 requirements.txt 了。

第三步:运行你的项目

最神奇的地方来了!你不需要手动激活虚拟环境 (source .venv/bin/activate)。直接使用 uv run 命令,它会自动找到并使用项目内的虚拟环境来执行你的脚本。

1
2
3
4
5
# 假设你的 main.py 里写了一个 FastAPI 应用
uv run uvicorn main:app --reload

# 或者,运行一个普通的 Python 脚本
uv run python main.py

之后,你的工作流就简化为:需要新包时用 uv add,运行代码时用 uv run。uv 会在后台为你打理好一切,是不是感觉无比轻松?

四、uv 常见命令详解:让你的工作流更顺滑

除了核心三步曲,uv 还提供了一些非常实用的命令,让你能更灵活地管理项目。

卸载依赖:uv remove

想删除一个不再需要的包?uv remove 就像是 uv add 的逆操作。

1
uv remove fastapi

这个命令会做两件事:

1、从当前虚拟环境中卸载 fastapi 及其相关依赖。

2、自动从 pyproject.toml 中移除该依赖记录,保证项目配置永远干净、准确。

同步环境:uv sync

这是团队协作的神器!当你的同事拉取项目代码后,只需在项目根目录运行:

1
uv sync

uv 就会读取 pyproject.toml(或 uv.lock 锁文件),像变魔术一样,极速安装所有依赖,完美复刻一个与你一模一样的开发环境。这能彻底杜绝”在我电脑上明明是好的”这类经典难题。

如果访问官方 PyPI 源(pypi.org)速度不理想,你可以在同步时临时指定一个国内的镜像源,比如阿里云。这非常简单:

1
uv sync -i https://mirrors.aliyun.com/pypi/simple/

加上 -i (或 --index-url) 参数后,uv 会在本次操作中从阿里云镜像下载所有包,速度会得到质的飞跃。

每次都手动输入 -i 参数还是有些麻烦。更推荐的做法是,直接将镜像源配置写入项目的 pyproject.toml 文件中,一劳永逸。

打开 pyproject.toml,在末尾添加以下内容:

1
2
[tool.uv.pip]
index-url = "https://mirrors.aliyun.com/pypi/simple/"

保存后,这个项目之后所有的 uv 命令(包括 uv add, uv sync 等)都会自动使用阿里云镜像,无需再加任何参数。将这个改动提交到 Git,整个团队都能享受到加速福利!

管理虚拟环境:uv venv

虽然 uv 大部分时候会自动管理虚拟环境,但如果你想手动操作它(比如,想激活环境后使用交互式 Shell),uv venv 就派上用场了。

1
2
# 在项目目录下,创建或复用虚拟环境
uv venv

执行后,它会确保 .venv 文件夹存在且配置正确。然后你就可以像以前一样激活它:

1
2
3
4
5
# macOS / Linux
source .venv/bin/activate

# Windows
.venv\Scripts\activate

激活后,你的命令行提示符前面会出现 (.venv),此时你就可以直接运行 python、pip 等命令了,它们都将指向这个独立的虚拟环境。

切换 Python 版本:uv venv -p

uv 能轻松地为项目指定并切换 Python 版本。当你需要升级项目(比如从 3.10 到 3.12)时,执行:

1
uv venv -p 3.12

uv 会自动:

1、用你系统中已安装的 python3.12 重建虚拟环境

2、自动更新 .python-version 文件内容为 3.12,将版本变更固化到配置中。

你只需将修改后的 .python-version 文件提交到 Git,团队其他成员在 uv sync 时,uv 就会自动为他们切换到正确的 Python 版本,实现无缝同步。

导出依赖:uv export

虽然 uv 很先进,但我们有时仍需与传统工具链协作。uv export 就是连接新旧世界的桥梁:

1
uv export > requirements.txt

这会生成一份标准的 requirements.txt 文件,用于部署或与其他工具集成。

当然,有导出就有导入。如果你手头有一个只使用 requirements.txt 管理的老项目,想用 uv 来接管,也非常简单。

只需要使用 uv pip install 命令来安装依赖:

1
uv pip install -r requirements.txt

不过,这样做只是安装了包,并没有将它们记录到 pyproject.toml 中。为了让项目完全由 uv 管理,推荐的做法是直接将 requirements.txt 里的核心依赖通过 uv add 添加一遍

比如,你的 requirements.txt 内容如下:

1
2
3
4
5
# requirements.txt
fastapi==0.104.1
uvicorn[standard]==0.24.0
pandas>=2.0.0
# ...后面可能还有很多子依赖

你只需要把核心包(fastapi, uvicorn, pandas)重新 add 一次即可:

1
2
# 假设你的核心依赖是 fastapi, uvicorn, pandas
uv add fastapi "uvicorn[standard]" pandas

uv 会智能解析所有子依赖并完成配置。至此,你的老项目就成功迁移到现代化的 uv 工作流了!

那么有没有更简单的方法呢?还是有的,如果你是使用macOS / Linux系统,并且你的 requirements.txt 文件很干净(没有注释、-e 等复杂行),可以尝试用下面这个命令一次性添加所有依赖:

1
uv add `cat requirements.txt`

五、总结

让我们回顾一下 uv 带来的革命性改变:

  • 极速体验:基于 Rust,无论是安装、卸载还是同步依赖,速度都远超 pip。
  • All-in-One:一个 uv 命令,同时搞定包管理 (pip) 和虚拟环境管理 (venv),甚至还包含了 pip-tools 的部分功能。
  • 智能自动化:uv add/remove 自动更新配置文件,uv run 自动使用正确的虚拟环境,让你告别繁琐的手动操作。
  • 团队友好:uv sync 轻松同步团队成员的开发环境,保证一致性。

uv 还是一个非常年轻的项目,但它的发展势头迅猛,社区活跃,其作者在 Python 工具链领域的声誉也让它备受期待。它所代表的不仅仅是一个工具,更是一种更现代、更高效的 Python 开发哲学。

还在为管理 Python 环境而烦恼吗?不妨在你的下一个个人项目中尝试一下 uv,感受一下飞一般的速度吧!

一、你的大脑正在内存溢出

“认知负荷”——听起来像个学术术语?本质上,它就是你的大脑 RAM。和计算机一样,这块内存有限。试图同时塞进太多东西?恭喜,系统崩溃,效率归零。优秀的工具,如同高效的代码,核心目标之一就是降低这种负荷——释放宝贵的脑细胞,去处理真正需要创造力的难题,而不是在配置地狱里挣扎。

二、依赖管理:独行侠与团队的鸿沟

为什么需要依赖管理工具?这不是 Python 的专利,是所有语言的宿命。想想你的项目:

1、独行侠脚本:写点一次性小玩意儿,只用标准库,就在自己机器上跑?没问题。全局 Python 环境是你的游乐场,尽情撒野。

2、团队作战项目:涉及复杂业务、一堆第三方库、最终要部署到服务器?或者你想让别人也能轻松运行你的代码?这时,全局环境就成了灾难现场。

三、无管理,即混乱:三重地狱

甩开包管理工具?准备好迎接这些“惊喜”:

1、“新电脑,新绝望”:项目搬到新机器?手动装依赖吧!祈祷你记得所有包名。出错?欢迎加入“看报错->猜依赖->装依赖->再看报错”的死亡循环。

2、版本迷雾:电脑 A 用了库 X 的 1.0 版,电脑 B 用了 2.0 版。谁对谁错?鬼知道。结果?你的代码在 A 上跑得像法拉利,在 B 上瘫得像废铁。

3、依赖战争:全局环境是唯一的王座。项目 A 需要库 Y 的 1.0,项目 B 却需要 2.0。你选谁?安装 1.0,B 项目原地爆炸;安装 2.0,A 项目寿终正寝。恭喜,你成了项目的掘墓人。

四、工具进化史:从石器时代到曙光?

为了解决这些问题,我趟过了 Python 依赖管理的泥潭:

1、pip (石器时代):Python 自带,无处不在。优点:简单粗暴(pip install)。缺点:也太简单了。创建虚拟环境?手动。导出精确依赖?靠pip freeze和祈祷。它只是个搬运工,不是管家。

2、pipenv (青铜时代?也许是坑):号称解决一切!自动虚拟环境,自动生成Pipfile。听起来很美?现实很骨感。它有个恶习:偷偷更新你的依赖版本。想象一下:一个月前项目跑得飞起,新电脑pipenv install后,它自作主张把依赖升到最新版——你的代码瞬间暴毙。这不是工具,是定时炸弹。

3、poetry (铁器时代):更优雅,pyproject.toml是未来。但…它也并非圣杯。复杂性增加,偶尔也有诡异的 bug 让你挠墙。

4、uv (曙光?):然后,我遇到了 uv。它由构建 ruff 的那群效率狂魔打造。快,快得离谱。并且,它似乎汲取了前辈们的教训。

五、终极推荐:pip 与 uv 的生存组合

经过这场工具大逃杀,我只推荐两个:

1、pip:你的瑞士军刀/终极备胎。为什么保留它?因为它绑定 Python,无处不在。当uv(或其他花哨工具)万一崩掉,或者你需要在一个极其原始的环境操作时,pip + venv 是你的诺亚方舟。它是兜底方案。

2、uv:现代开发的利刃。它解决了核心痛点:极致的速度和可靠的依赖锁定。它大幅降低了“安装依赖”和“环境一致性”带来的认知负荷。

六、pip + venv 的生存四步曲(必会!)

即使你用uv,理解这个基础流程也至关重要(就像画家懂素描):

1、筑墙(创建虚拟环境): python -m venv .venv - 在项目根目录建个隔离区.venv。

2、入墙(激活隔离区):

1
2
Unix (Mac/Linux/Bash): source .venv/bin/activate
Windows PowerShell: .venv\Scripts\activate.ps1

3、搬砖(安装依赖): pip install fastapi - 依赖只装进墙内。

4、留清单(冻结依赖): pip freeze > requirements.txt - 记录墙内所有砖头(包)的精确型号(版本)。在新环境,靠pip install -r requirements.txt 复刻这堵墙。

七、虚拟环境:你的项目专属“沙盒”

全局 Python?那是操作系统的领地。虚拟环境(.venv)是你为单个项目开辟的独立王国。王国里有自己的 site-packages(存放第三方库的仓库),与外界(全局环境)和其他王国(其他项目)互不侵犯。依赖冲突?版本混乱?在各自的王国里,它们被终结了。

八、uv 之道:简洁即美

pip + venv 四步曲有效,但重复劳动就是认知负荷!每个项目都来一遍?这是对生命的浪费。uv 的目标就是让这流程消失。

怎么用?简单得像呼吸:

1、奠基 (uv init): 在你的项目目录下,一声令下:

1
2
3
4
├── .python-version  # 记录所用Python版本
├── README.md # 你的项目宣言(可选)
├── main.py # 起点(可选)
└── pyproject.toml # **项目宪法!**

pyproject.toml 示例:

1
2
3
4
5
6
7
8
9
[project]
name = "uv-demo"
version = "0.1.0"
description = "解放大脑内存从这里开始"
readme = "README.md"
requires-python = ">=3.12" # Python 版本要求
dependencies = [ # 依赖声明
"fastapi>=0.115.12",
]

2、添砖加瓦 (uv add): 需要 requests?uv add requests。魔法发生了:

uv.lock 文件诞生:精确锁定所有依赖及其子依赖的版本。

pyproject.toml 的 dependencies 自动更新。

3、无缝迁移 (uv add -r): 已有 requirements.txt?uv add -r requirements.txt。一键导入,告别过去。

结语

优秀的工具不是增加复杂性,而是消除摩擦。uv 通过极致的速度和可靠的设计(尤其是 uv.lock),显著降低了 Python 依赖管理带来的认知负荷。它让你从环境配置的泥沼中挣脱出来,把宝贵的大脑内存——那真正稀缺的资源——留给创造、逻辑和解决问题本身。这不正是我们编程的初衷吗?停止折腾工具链,开始创造价值。试试 uv,让你的大脑轻装上阵。

前言

几个月前在V2EX吐槽,我的python依赖包管理,从pip开始,为了方便,切换到pipenv,之后pipenv安装依赖有点问题,之后学习了poetry,但是peotry又出现了一些依赖问题,最后还是用回了pip。

之后看到有人回复推荐rye和uv,于是又继续学习了新的依赖包管理器。下面做了一个命令速查表,方便使用。

如何安装rye

windows可以从这里下载 https://rye.astral.sh/guide/installation/

macos和linux只需要输入下面命令即可:

1
curl -sSf https://rye.astral.sh/get | bash

下载安装完后,需要把rye主目录下的Shims路径添加进环境变量

1
echo 'source "$HOME/.rye/env"' >> ~/.bashrc

如何设置代理

可以为rye设置代理:

1
2
rye config --set proxy.http=http://127.0.0.1:7890
rye config --set proxy.https=http://127.0.0.1:7890

如何取消代理:

1
2
rye config --unset proxy.http
rye config --unset proxy.https

如何启用uv

uv 是一款用 Rust 编写的,性能优秀的 Python 包安装和解析工具,被设计用于替代 pip 和 pip-tools。

1
rye config --set-bool behavior.use-uv=true

如何列出所有可用的 Python 版本

1
rye toolchain list --include-downloadable

如何初始化项目

1
rye init

如果需要特定版本的python,可以使用-p参数指定特定版本python

1
rye init -p cpython@3.11

PS:python3.11比之前版本的python的性能要好。

如果想创建一个脚本型项目,需要加上--script参数

1
rye init --script

如果想为你的脚本或web创建项目,可以加上--virtual参数。

1
rye init --virtual

虚拟项目是本身不是可安装的Python包的项目,但会同步它们的依赖项。它们像pyproject.toml中的普通python包一样声明,但它们不创建包。相反,tool.rye.virtual键设置为true

这也是我最常用初始化rye项目的方式。

如何初始化依赖

初始化项目后,可以使用rye sync指令初始化依赖,此时就会在当面目录下创建一个.venv文件夹:

1
rye sync

如何添加依赖包

使用rye add命令安装依赖包,例如安装django的命令:

1
rye add django

如何移除依赖包

使用rye remove命令移除依赖包:

1
rye remove django

如何运行rye项目中的的命令

使用rye run可以运行.venv中提供的脚本或应用程序,也可以运行Rye特定的脚本。

1
rye run django-admin

在不带参数的情况下打开它以查看所有可用的脚本,例如:

1
2
3
4
5
6
$ rye run
flask
hello
python
python3
python3.9

如何添加pypi镜像

使用rye config --show-path命令取得配置文件路径。用文本编辑器打开配置文件,并添加如下内容:

1
2
3
[[sources]]
name = "default"
url = "https://mirrors.aliyun.com/pypi/simple/"

此外,也可以在项目文件 pyproject.toml 中进行设置:

1
2
3
[[tool.rye.sources]]
name = "default"
url = "https://mirrors.aliyun.com/pypi/simple/"

最近使用gunicorn部署python web应用,发现了一些异常。比如无法同时多个大模型聊天等等。现在重新学习gunicorn的工作模式。

根据gunicorn的官方文档,有以下几种工作模式:

sync

sync:这是默认的模式。优点是最简单,缺点是每个 worker 进程一次只能处理一个请求,并发性能较低。我一开始就是使用这个模式部署,并且设置了worker=1,所以无法同时多个大模型聊天。

gthread

gthread:优先推荐的模式。优点是适用于 I/O 密集型应用,内存占用相对较低,支持多线程处理请求,可以利用多核 CPU 的优势。缺点是会受GIL限制。这个模式基本适用django和flask应用了。

下面以一个启动示例来讲解:

1
gunicorn --worker-class gthread --workers 3 --threads 2 myproject.wsgi:application

这个配置启动 3 个 worker 进程,每个 worker 进程有 2 个线程,这样总共可以处理 6 个并发请求。

部署后,可以根据需要监控gunicorn的性能指标,比如CPU和内存,并根据实际情况调整 worker class 和相关参数。

gevent/eventlet

gevent/eventlet:这是非常适合高并发的模式,能够处理大量并发连接,性能优于 gthread。但是缺点是需要修改代码,以确保与 gevent/eventlet 兼容,配置复杂,并且可能会出现 monkey-patching 相关的问题。

我在部署一个有后台长时间运行的线程的时候,需要设置gunicorn的preload的配置,提前加载app来启动后台线程,但是部署的时候,就出现了monkey-patching。查了github的issue,这个问题至今也没解决,参见:https://github.com/benoitc/gunicorn/issues/927

如何选择

那么如何选择?首先尝试使用 gthread,并根据服务器资源和应用负载调整 workersthreads 的数量。如果并发量非常高,并且 gthread 无法满足性能需求,可以考虑使用 geventeventlet,但需要注意代码兼容性问题。最后避免在生产环境中使用 sync,除非你的应用负载非常低。

之前帮某社群干活的时候,做了一点向量数据库的性能评测,选择了几个常见的向量数据库:qdrant、milvus和pgvector。压测下来,发现qdrant性能最好,pgvector并发最不行。

因此后面有需要使用向量数据库的场景,我都是使用qdrant。那么什么是qdrant?qdrant是一个高性能、大规模的向量数据库和向量搜索引擎。它使用rust语言编写。提供HTTP接口使用。

闲话少说,那么如何一键部署qdrant向量数据库呢?

如果你有自己的服务器并且会docker,可以使用docker命令,如下:

1
2
3
docker run -d --name qdrant -p 6333:6333 -p 6334:6334 \
-v $(pwd)/qdrant_storage:/qdrant/storage:z \
qdrant/qdrant

其中6333端口是qdrant的HTTP API,直接调用这个端口即可使用qdrant。

另外 http://<IP>:6333/dashboard 是qdrant的dashboard地址,部署之后可以访问该路径看到管理页面。

如果你没有服务器也不会docker,但想快速体验一下qdrant,可以试试zeabur云平台的一键部署。什么是zeabur可以参考这篇文章,这里不再赘述。我在zeabur平台做了一个qdrant的部署模板,可以一键快速部署,只需要点击下面图片即可。

Deploy on Zeabur

如果图片显示不正常,也可以点击下面链接部署:https://zeabur.com/templates/1DAD45

在nuxt.config.ts设置nitro的值即可,例如:

1
2
3
4
5
6
export default defineNuxtConfig({
...
nitro: {
devProxy: { '/api': `http://127.0.0.1:${ process.env.SERVER_PORT || 8080 }/api` },
},
});

这样就会把/api路径下的请求转发到另一个本地端口。

注意,nuxt3不需要安装什么@nuxtjs/proxy,直接配置nitro代理即可。

参考资料:https://github.com/nuxt-community/proxy-module/issues/116

OpenAI

o1-preview

发布于2024年9月13日,o1模型标志着 OpenAI 以在推理能力上的重大进展,相比较之前的GPT-4o,o1-preview在多个方面表现得更加出色,尤其是在编写代码和解决复杂问题的能力上,通过采用全新的优化算法和专门定制的新训练数据集,使得模型在准确性和推理能力上有了显著提升。

o1-mini

与o1-preview同时推出,是o1系列中的小尺寸版,价格比o1-preview便宜80%,虽然存在使用次数的限制,但其在生成和调试复杂代码方面表现出色,特别适合开发人员使用。

gpt-4o-2015-05-13

2024年5月13日, OpenAI 正式发布其大模型新版本 GPT-4o,“o”代表Omni,即全能的意思,凸显了其多功能的特性,从多模态端到端实时推理,无需转换,响应延迟大幅缩短。

gpt-4o

GPT-4o可以将文本、音频、图像和视频的任意组合作为输入,并将文本、音频和图像的任意组合作为输出;可以在最短232毫秒,平均320毫秒的时间,对音频做出响应,这与人类在对话中的响应时间相似。

gpt-4o-mini-2024-07-18

于2024年7月18日推出,该模型是GPT-4o的一个分支,其在保留了GPT-4功能的同时,体积上比GPT-4o等大模型要小得多,成本价格上也更加便宜。

gpt-4-plus

是GPT-4的升级版,在GPT-4的基础上升级了一些功能,包括更精确的文本表示、更先进的情感分析和更高的语义理解能力等,在自然语言理解和生成方面的表现更加出色。

gpt-4o-2024-08-06

于2024年8月6日上线,是多模态模型GPT-4o的更新版,在其API中引入一项突破性功能——结构化输出,确保了模型生成的输出能够完全符合开发人员提供的JSON架构,从而显著提升了API的可靠性和应用的精确度。

chatgpt-4o-latest

于2024年8月15日发布,是GPT-4o的最新版本,在编码、指令遵循和硬提示方面都有显著提高,最大支持128K上下文输出,最大输出Tokens达16K,在推理方面与GPT-4o相比有较大提升。

gpt-4-turbo

于2024年4月正式推出,模型功能更强大、更便宜,并支持128K上下文窗口;平台中新的多模态功能,包括视觉、图像创建和文本转语音;知识库更新上,其现实世界知识截止时间现在是2023年4月;价格上输入代币比GPT-4便宜3倍,输出代币便宜2倍。

gpt-4-turbo-preview

GPT-4-Turbo预览模型,在2023年11月6日亮相,之后有0125版本更新,其不仅在性能上有所提升,还修复了一个影响非英文UTF-8生成的漏洞,增加了模型的稳定性和多语言支持。

gpt-3.5-turbo-0125

GPT-3.5-turbo的最新模型,在按请求格式回应时具有更高的准确性,并修复了一个错误,该错误导致非英语语言函数调用时出现文本编码问题,在稳定性和准确性都提高的同时,gpt-3.5-turbo-0125价格相比之前也降低了。

gpt-4

于2023年3月14日由OpenAI正式发布,它是GPT系列模型的第四代,具有更强的语言理解和生成能力、多模态处理能力、更大的模型规模、改进的安全性和伦理性等,可应用于如对话系统、内容生成、代码编写、数据分析、教育和研究等各种领域。

Gemini

gemini-1.5-pro-002

谷歌发布于2024年9月25日,相比其他1.5系列模型的其他版本,新版的1.5 Pro整体素质提高,数学、长上下文和视觉上有大幅增加,能够更好地理解更加复杂和具有细微差异的指令,价格上降低>50%,速率限制提高了约3倍,输出速度提高2倍,延迟降低3倍。

gemini-1.5-flash-002

与gemini-1.5-pro-002共同发布,虽然是一个较为轻量的模型,但其在多模态推理能力方面依然表现出色,擅长摘要制作、聊天应用、提供图说和视频字幕,以及从长篇文件和表格中提取数据等任务,且在响应速度方面有了极大的改进。

gemini-1.5-pro

第一代模型由谷歌发布于2024年2月15日,为Gemini-1.0-Pro的升级版本,支持超长上下文内容,能够稳定处理高达100万token(相当于1小时的视频、11小时的音频、超过3万行代码或70万个单词);支持多模态输入,能够分析、总结、处理多种形式,包括图片、文档、视频和音频。

gemini-1.5-pro-0801

是gemini-1.5-pro的实验版本,擅长多语言任务,并在数学、复杂提示和编码等技术领域表现出色,其另一个突出特点是其高达 200 万个token的扩展上下文窗口,已经远远超过了市面上许多的AI模型。

gemini-1.5-flash-001

谷歌于5月15日推出,1.5 Flash是通过API提供的速度最快的Gemini模型,在具备突破性的长文本能力的情况下,针对大规模地处理高容量、高频次任务进行了优化,在总结摘要、聊天应用、图像和视频字幕生成以及从长文档和表格中提取数据等方面表现出色。

ANTHROPIC

claude-3.5-soonet-20241022

Anthropic最新推出的升级版,各项能力全面胜过之前版本,其中代码能力提升显著,能够根据用户指令移动光标、点击相应位置以及通过虚拟键盘输入信息,模仿人类与计算机的交互方式。

claude-3.5-sonnet-20240620

Anthropic公司于2024年6月20日发布的LLM大语言模型,属于Claude3.5系列模型中的先遣版本,在理解细微差异、幽默感和复杂指令方面表现得更为出色,书写风格也更自然、更具亲和力,擅长解释图表、图形。

claude-3-opus

Opus是Claude3系列中最先进的模型,在高度复杂的任务上表现出了市场上最好的性能,它能够轻松应对各种开放式提示和未知场景,并以出色的流畅度和人类般的理解能力完成任务。

claude-3-haiku

是Anthropic速度最快、体积最小的模型,能够提供几乎即时的响应能力,可以极快地解答简单的问题和响应请求,Haiku的定价是每百万token输入0.25美元、输出1.25 美元,相当便宜。

Perplexity AI

pplx-8b-online

由Perplexity AI公司推出,是一款基于大语言模型(LLM)的在线模型,它利用实时互联网数据提供即时、精确的查询响应,通过API提供,能够实现对查询的即时响应,标志着首次通过API公开访问在线LLMs。

pplx-70b-online

基于Llama2-70B基础模型构建,这款在线模型的主要特点是能够实时访问互联网数据,从而提供最新的信息,它通过Perplexity Labs的内部搜索基础设施,优先访问高质量和权威的网站,并采用先进的排名机制来实时呈现相关和可靠的信息片段。

智谱AI

GLM-4

GLM-4是智谱AI于2024年1月16日发布的基座大模型,可以支持128k的上下文窗口长度,单次提示词可以处理的文本可以达到300页,同时在多模态能力方面,文生图和多模态理解都得到了增强。

GLM-4-Long

专为处理超长文本和记忆型任务设计的模型,支持超长输入,上下文长度最高为1M,约150-200万字,具备长文本推理能力,处理百万字文本响应时间可控,是处理大规模文本数据的强大工具。

GLM-4-Plus

发布于8月29日,GLM-4-Plus基座模型,在多个关键指标上实现了大幅提升,尤其是在语言理解能力、指令遵循能力和长文本处理能力方面,通过多种方式构造出了海量高质量数据,并利用 PPO等多项技术,有效提升了模型推理、指令遵循等方面的表现,能够更好地反映人类偏好。

GLM-4-Air

综合性能接近GLM-4,但价格仅为1元100万token,非常适合大规模应用,是性价比很高的版本,具有128k上下文,速度快,价格实惠。

GLM-4-Airx

GLM-4-Air的高性能版本,效果不变,推理速度达到2.6倍,具有8k上下文。

CodeGeeX-4

CodeGeeX是智谱AI旗下的代码生成大模型,2022年9月发布第一代模型,2024年7月5日发布CodeGeeX-4,作为最新一代的CodeGeeX系列模型,大幅提高了代码生成能力,单一模型即可支持代码补全和生成、代码解释器、联网搜索、工具调用、仓库级长代码问答及生成等功能。

GLM-4V

GLM-4V具备视觉理解能力,实现了视觉语言特征的深度融合,支持视觉问答、图像字幕、视觉定位、复杂目标检测等各类图像理解任务。

GLM-4V-Plus

智谱AI发布的新一代图像/视频理解模型,具备卓越的图像理解能力,并具备基于时间感知的视频理解能力,其在图像理解方面表现出色,能够理解并分析复杂的视频内容,同时具备超强的时间感知能力,不仅可以理解网页内容并将其转换为html代码,还能精准描述视频中的动作和场景变化。

阿里云

Qwen-Max

是由阿里云自主研发的大语言模型,它是通义千问系列的一部分,用于理解和分析用户输入的自然语言,其适合处理复杂、多步骤的任务,提供了多个模型版本,包括qwen-max-longcontext,支持长达30,000字的上下文,满足了需要处理长文档或复杂逻辑的任务需求。

Qwen-VL-Max

是阿里开源模型Qwen-VL的升级版,其大幅提升图像相关的推理能力,以及对图中细节和文字的识别、提取和分析能力,并支持百万像素以上的高清分辨率图和各种长宽比的图像,在中文问答、中文文字理解相关的任务上表现出色。

Qwen-Math-Plus

通义千问数学模型是专门用于数学解题的语言模型,致力于解决复杂、具有挑战性的数学问题,其技术原理包括大规模预训练、专用语料库、指令微调、奖励模型、二元信号和PPO优化等,该模型在多个数学基准测试中表现出色,尤其在数学竞赛题目的解答上超越了多个领先的开闭源模型。

腾讯

Hunyuan-Lite

百亿参数规模,Hunyuan-腾讯混元大模型是腾讯全链路自研的万亿参数大模型,Hunyuan-Lite升级为MOE结构,上下文窗口为256k,在NLP、代码、数学、行业等多项评测集上领先众多开源模型。

Hunyuan-Standard

千亿参数规模,采用更优的路由策略,同时缓解了负载均衡和专家趋同的问题,长文方面,大海捞针指标达到99.9%,hunyuan-standard-32K性价比相对更高,在平衡效果、价格的同时,可对实现对长文本输入的处理;hunyuan-standard-256K在长度和效果上进一步突破,极大的扩展了可输入长度。

Hunyuan-Pro

万亿参数规模,当前混元模型中效果最优版本,在各种benchmark上达到绝对领先的水平,复杂指令和推理,具备复杂数学能力,支持functioncall,在多语言翻译、金融法律医疗等领域应用重点优化。

Hunyuan-Code

混元最新代码生成模型,经过200B高质量代码数据增训基座模型,迭代半年高质量SFT数据训练,上下文长窗口长度增大到 8K,五大语言代码生成自动评测指标上位居前列;五大语言10项考量各方面综合代码任务人工高质量评测上,性能处于第一梯队。

Hunyuan-Vision

混元最新多模态模型,支持图片+文本输入生成文本内容,包括图片基础识别、图片内容创作、图片多轮对话、图片知识问答、图片分析推理、图片OCR等能力。

百川

Baichuan3-Turbo

针对企业高频场景优化,效果大幅提升,高性价比,相对于Baichuan2模型,内容创作提升20%,知识问答提升17%,角色扮演能力提升40%。

Baichuan4

百川智能于2024年5月22日发布的最新一代基座大模型,其在通用能力、数学和代码处理能力上都有所提升,在处理知识百科、长文本和创作生成等中文任务时都展现出了优秀的能力,在国内权威大模型评测机构SuperCLUE的评测中,Baichuan4的模型能力排名国内第一,业内水准算第一梯队了。

kimi

Moonshot-v1-8k

Moonshot-v1是Moonshot AI推出的一款千亿参数的语言模型,具备优秀的语义理解、指令遵循和文本生成能力,Moonshot-v1-8k是一个长度为8k的模型,支持8K上下文窗口,适用于生成短文本。

零一万物

Yi-Ligtning

10月16日零一万物正式发布新旗舰模型Yi-Lightning,其理速度有大幅提升,首包时间提升一倍,最高生成速度提速近四成,在多轮对话、数学、代码等多个分榜成绩出众,价格方面也极具优势,已上线Yi大模型开放平台,每百万token仅需0.99元。

Yi-Large

零一万物公司发布于2024年5月13日的一款千亿参数规模的闭源大模型,其主要特点包括超强的文本生成和推理能力,适用于复杂推理、预测和深度内容创作等场景。

Yi-Vision

零一万物发布的开源多模态语言大模型,Yi-Vision基于Yi语言模型开发的,具备高性能图片理解、分析能力,可服务基于图片的聊天、分析等场景。

Deepseek

Deepseek-Chat

DeepSeek是“深度探索”公司开发的模型,基于DeepSeek-V2模型,是一款集成了2千亿参数量的MoE模型的AI技术产品,其特点是经济的训练和高效的推理,支持128K上下文的开源模型,而其对话官网/API则支持32K上下文,提供即刻接入、能力卓越、价格低廉的服务,并且兼容OpenAI API接口,为用户带来丝滑的体验。

Deepseek-Coder

DeepSeek-Coder是一个智能编码辅助工具,能够理解编程问题的描述,并自动生成相关的解决方案或代码片段,其训练数据量高达2T,涵盖87%的代码和13%的自然语言,包括英语和汉语,从1B到33B的不同模型版本,可满足了各种规模项目的需求。

百度

ERNIE-4.0-8k

ERNIE-4.0-8k是百度自研的旗舰级超大规模大语言模型,相较ERNIE3.5实现模型能力全面升级,广泛适用于各领域复杂任务场景;支持自动对接百度搜索插件,保障问答信息时效,支持5K tokens输入+2K tokens输出。

ERNIE-4.0-Turbo

于2024年6月28日发布,是2023年10月推出的 Ernie-4.0模型的升级版,是文心系列最新旗舰版大模型,将输入tokens长度从2K提升至128K,AI生成图像分辨率从512×512提高到1024×1024,在生成速度和效果上都有大幅提升。

阶跃星辰

Step-1V-8k

国内大模型公司阶跃星辰推出的Step-1V是一款千亿参数的多模态大模型,拥有强大的图像理解能力,暂时只开放文本和图像输入,且仅支持文本生成,Step-1V-8k是指上下文长度为8k。

Step-2-16k

2024年7月4日阶跃星辰发布了Step-2模型,这是一个拥有万亿参数的巨型深度学习模型,采用了MoE结构,在数学、逻辑、编程、知识、创作、多轮对话等方面,Step-2的能力体感全面逼近GPT-4,Step-2-16k是指上下文长度为16k。

讯飞

Spark Max

讯飞星火认知大模型是科大讯飞发布的大模型,Spark Max是旗舰级大语言模型,具有千亿级参数,核心能力全面升级,具备更强的数学、中文、代码和多模态能力,适用于数理计算、逻辑推理等对效果有更高要求的业务场景。

Spark Ultra

最强大的大语言模型版本,文本生成、语言理解、知识问答、逻辑推理、数学能力等方面实现超越GPT 4-Turbo,优化联网搜索链路,提供更精准回答。

Spark Lite

轻量级大语言模型,具有更高的响应速度,适用于低算力推理与模型精调等定制化场景,可满足企业产品快速验证的需求。

开源模型

Llama3.2-90B

9月25日正式推出,Meta最先进的模型,擅长常识、长文本生成、多语言翻译、编码、数学和高级推理,还引入了图像推理功能,可以完成图像理解和视觉推理任务。

Llama3.2-11B

非常适合内容创建、对话式人工智能、语言理解和需要视觉推理的企业应用,该模型在文本摘要、情感分析、代码生成和执行指令方面表现出色,并增加了图像推理能力,用例与 90B 版本类似:图像标题、图像文本检索、视觉基础、视觉问题解答和视觉推理,以及文档视觉问题解答。

Qwen2.5-72B

9月19日推出,支持高达128K的上下文长度,可生成最多8K内容,支持超29种语言,基于 18T token 数据预训练,相比Qwen2,Qwen2.5整体性能提升18%以上,拥有更多的知识、更强的编程和数学能力,72B 是足够用于工业级、科研级场景的性能王者。

Qwen2.5-Coder-7B

Qwen2.5-Coder是Code-Specific Qwen大型语言模型的最新系列,是一个专门用于代码生成和编程相关任务的大型语言模型,采用了基于Transformer的架构,并引入了特定的优化技术,如分组查询注意力(GQA)和双块注意力(DCA),以优化推理性能和长文本处理能力。

Llama3.1-405B

Llama3是Meta最新开源的大语言模型,405B适用于合成数据、大语言模型 (LLM) 作为评判者或蒸馏,支持128K token 的上下文长度和 8 种语言,允许使用模型输出来改进其他LLM。

Llama3.1-70B

70B适合大规模 AI 原生应用,拥有70亿个参数,支持8种语言的文本生成,采用优化的Transformer架构,并通过监督式微调和人类反馈强化学习进一步优化,以符合人类对帮助性和安全性的偏好。

Llama3.1-8B

8B适用于需要在多种语言环境下进行自然语言处理和对话系统开发的研究人员和开发者,包含8B大小的版本,支持8种语言,专为多语言对话用例优化。

Llama3-70B

Llama3是Meta于2024年4月18日推出,有8B和70B两个版本,70B拥有700亿个参数,这种复杂性的增加转化为各种NLP任务的增强性能,包括代码生成、创意写作,甚至多态应用程序,它也需要更多的计算资源,需要具有充足内存和GPU能力的强大硬件设置。

Llama3-8B

Llama3-8B型号在性能和资源需求之间取得了平衡,它拥有80亿个参数,提供令人印象深刻的语言理解和生成功能,同时保持相对轻量级,使其适用于具有适度硬件配置的系统。

Mistral-Large-2

2024年7月26日,法国AI初创公司Mistral AI发布了最新模型Mistral-Large-2,拥有1230亿参数,尤其擅长代码和数学推理,上下文窗口128k,支持数十种自然语言以及80+编程语言,特别在MMLU上,其预训练版本更是达到了84.0%的准确率。

Mixtral-8x7B

Mixtral-8x7B是首个开源的MoE大模型,具有8个7B参数的专家和高效的稀疏处理,该模型在每一层都由8个前馈块(即“专家”)组成,通过路由网络为每个令牌选择两个专家进行处理,并将它们的输出结合起来,这种架构允许模型在保持较低计算成本的同时,访问更多的参数。

Gemma-7B

Gemma是谷歌研发的AI大模型,Gemma-7B拥有70亿参数,旨在高效部署和开发,适用于消费级GPU和TPU,在7B参数级别的模型中性能可与最佳模型相媲美,包括Mistral-7B。

Gemma2-9B

Gemma2是谷歌于2024年6月发布的最新开源模型,相比较第一代,Gemma2推理性能更高、效率更高,并在安全性方面取得了重大进步,Gemma2-9B的性能在同类产品中也处于领先地位,超过了Llama3-8B和其他同规模的开源模型。

Gemma2-27B

Gemma2-27B在同类产品中性能最佳,甚至能挑战规模更大的模型,27B模型可用于在单个谷歌Claude TPU主机或NIVIDIA H100 GPU上以全精度高效运行推理,从而在保持高性能的同时大幅降低成本。

Command R+

Cohere公司最新推出的模型,这是Command R系列中最强大的模型,总计拥有1040亿个参数,其独特之处在于其强大的生成能力和先进的检索功能,可以让模型根据给定的上下文信息,从外部知识源中检索相关内容,并将其融合到生成的响应中,有效缓解模型的”幻觉”问题。

Command R

Command-R拥有35B的模型参数,提供了强大的语言理解和生成能力,模型支持高达128K的上下文窗口,大大超越了行业标准,使其能够处理更复杂的文本和生成更连贯的内容。

Qwen2-72B

于2024年6月7日发布,是阿里云研发的通义千问大模型系列之一,72B指令微调版模型,还增大了上下文长度支持,最高可达128k token,其具有大规模高质量训练语料、强大的性能、覆盖更全面的词表等特点。

Qwen2-7B

Qwen2是阿里通义推出的新一代多语言预训练模型,包含0.5B、1.5B、7B、57B-A14B和72B共5个尺寸,其中Qwen2-7B支持更长的上下文长度,最高可达128K tokens,在中文和英语的基础上,新增27种语言的高质量训练数据。

Llama-3.1-nemotron

是英伟达NVIDIA开发的一系列大型语言模型,基于Llama-3.1-70B开发而成,它采用了一种新颖的神经架构搜索(NAS)方法,从而建立了一个高度准确和高效的模型。在高工作负荷下,该模型只需一个英伟达H100 GPU 即可运行,因此更易于使用,也更经济实惠。

其他模型

farui-plus

由阿里云推出的一个法律大模型产品,它基于通义千问大模型,经过法律行业的数据和知识专门训练,具有法律智能对话、法律文书生成、法律知识检索、辅助案情分析、法律文本阅读和解析、合同条款审查等功能。

XuanYuan-70B

轩辕是国内首个开源的千亿级中文对话大模型,同时也是首个针对中文金融领域优化的千亿级开源对话大模型,轩辕70B(度小满中文金融对话大模型)是由度小满金融开发的中文金融对话大模型,针对金融场景中的长文本业务,它将上下文长度扩展到了8k和16k,在保持中英文通用能力的同时,显著提高了金融理解能力。

ChatLaw

由北京大学信息工程学院袁粒课题组与北大-兔展AIGC联合实验室联合发布的中文法律大模型,于2023年7月发布,其是基于各种中文法律条文、实际案例、判决条文所训练出来的法律大模型,可借助 AI实现法律合同撰写、案例介绍、条款讲解、司法问题咨询等场景。

Qwen2-Math-72B

阿里巴巴于8月8日再次开源了Qwen2-Math系列模型,这是一个专注于数学推理能力的模型,在Math上的评测结果表明,Qwen2-Math-72B超越了最先进的模型,包括GPT-4o、Claude-3.5-Sonnet、Gemini-1.5-Pro和Llama-3.1-405B。

grok-2

发布于2024年8月13日,是xAI公司推出的一款先进的人工智能语言模型,包括Grok-2和Grok-2 mini两个版本,具有聊天、编码和推理等功能,该模型拥有3140亿个参数,是迄今为止参数量最大的开源模型,这使得它在处理复杂任务和生成高质量文本方面具备了更强的能力。

上一篇我已经介绍过什么是zeabur了,这一次就简单记录下怎么在zeabur部署我的第一个hexo博客。

什么是hexo?

Hexo 是一个快速、简洁且高效的博客框架。它使用markdown语法编写博客,然后解析你的文章,就可以生成静态网页。

使用Hexo需要先准备按两个工具:git和nodejs。如果没有安装,请先找其他资料自行安装。下面直接从命令行开始。

如何安装hexo

使用npm install命令安装hexo命令行工具:

1
npm install -g hexo-cli

之后就可以初始化一个博客,我这里使用hexo-demo作为文件夹名,你可以换成你喜欢的文件夹名:

1
hexo init hexo-demo

初始化的时候要访问github,如果出现网络问题,打开梯子再运行该命令比较好。之后进入该文件夹,安装npm依赖环境

1
2
cd hexo-demo
npm install

github创建仓库

之后我们需要把这个目录下的代码提交到github,再在zeabur上使用github方式,以serverless方式部署,即可完成。

注册好github后,点击这个链接进入创建github仓库的页面:https://github.com/new

填写仓库名称,我这里使用hexo-demo作为示例,仓库可设为Private模式,不公开访问。

最后点击绿色的按钮创建仓库即可。

提交到github

回到前面创建hexo目录下的命令行,使用下面命令提交代码

1
2
3
git init
git add .
git commit -m "first commit"

之后设置远程仓库并提交上去,注意,{your-username}是你的github仓库用户名:

1
2
git remote add origin https://github.com/{your-username}/hexo-demo.git
git push -u origin master

使用https方式提交可能还需要输入你的帐号密码,按提示输入就行。

提交之后,刷新一个github页面,有代码显示就表示成功了。

zeabur部署

之后就可以到zeabur部署博客。

登录注册zeabur之后,进入 https://dash.zeabur.com/projects 项目页面,在右上角点击【创建项目】

选择一个你喜欢的地区服务器,建议国外服务器。

之后会跳转到添加服务弹窗,选择第一个【从Github仓库部署】。

选择你刚刚创建的博客仓库,如果没有,需要去【配置github】,授予权限。

选中仓库 后,下一步是【构建计划预览】,简单看一下,这个预览表示是使用serverless方式部署,如果是docker部署会显示容器方式部署。最后点击【部署】就行了。

以上步骤就完成了一次部署。

部署完之后,那么如何访问博客呢?zeabur也提供了它的子域名。

在服务页面往下拉,找到【网络】菜单,点击【生成域名】,填入你喜欢的域名,我这里使用的是hexo-example,之后会生成 https://hexo-example.zeabur.app/ 域名,最后【确认绑定】,完成。

访问测试一下 https://hexo-example.zeabur.app/ ,如果成功了,你的第一个hexo博客就搭建好了。