/images/avatar.jpg

Kiosk Studio (2022)

设计模式(Design Pattern)

设计模式(Design pattern)代表了最佳的实践,通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

从Kubernetes理解调度

在当今的计算领域,随着集群规模的扩大和对快速响应变化需求的期望,传统的单体集群调度架构面临着诸多挑战。这些挑战限制了新功能的部署速度,降低了效率和资源利用率,最终可能制约集群的进一步发展。为应对这些问题,谷歌提出了一种新颖的调度架构:Omega。该架构利用并行性、共享状态和无锁的乐观并发控制,旨在提高调度的灵活性和可扩展性。 调度器简介 最早的调度器是单机系统里的批处理调度器,通过对计算机资源的分时复用来增加资源的利用率。 调度器是指在大规模计算集群中负责将作业(jobs)分配到机器上,这个过程称为调度(scheduling)。文章指出,随着集群规模的增长和工作负载的多样化,调度问题变得更加复杂。调度器需要考虑不同的需求和策略,例如资源利用率、用户指定的放置约束、快速决策制定以及公平性和业务重要性等。 单机调度器的演变,可以总结出调度器设计的三个基本需求: 资源的有效利用 信号的实时响应 调度策略的灵活配置 这三个需求,某些场景下会相互掣肘,很难同时满足。 相比单机系统,在分布式系统中,还存在以下的一些困难: 集群资源状态同步:单机系统里,利用共享内存和锁机制可以很好的实现资源状态同步,保证任务的并发运行。但是在分布式系统中,网络通讯的不可靠性,使得在所有机器上达成状态的一致性非常困难。我们甚至不能保证所有机器上基准时钟的一致性。 容错性问题:单机系统里,任务规模、资源规模有限,出错的概率和成本比较低,但是分布式系统集群规模可能非常大,任务之间的依赖关系更加复杂,出错的概率大大增加,出现错误以后,恢复的成本也很高。调度器层面,对于错误的识别和恢复能力要足够快速准确。 可扩展性:分布式系统里,任务的类型远比单机系统下要多,不同任务的调度需求是不同的,一套调度器很难适应所有情况,同时待调度的资源规模不断扩大,可能存在上千、上万个节点;一方面要应对资源的不稳定,一万个节点,每天故障一个是很正常的概率,另一方面,要处理多元的调度需求,对调度器的可扩展性提出了很高的需求。 谷歌的论文《Omega: flexible, scalable schedulers for large compute clusters 》里把分布式系统的调度器分为了三种类型,这里简单介绍下。 单体调度器 (monolithic scheduler) 单体调度器(Monolithic Scheduler) 是一种集中式的调度架构,广泛应用于大规模计算集群中。它使用单一的、集中式的调度算法来处理所有作业,通常在高性能计算(HPC)环境中较为常见。以下是单体调度器的详细介绍: 核心思想 单体调度器的核心思想是: 集中式调度:所有调度决策由一个中央调度器完成,调度器负责管理整个集群的资源,并将任务分配到合适的机器上。 单一调度算法:调度器使用单一的调度算法来处理所有类型的作业,无论是批处理作业还是服务作业。 架构设计 单体调度器的架构设计相对简单,主要包括以下组件: 中央调度器:负责整个集群的资源管理和任务调度。调度器维护集群的全局状态,并根据调度算法做出调度决策。 作业队列:所有作业请求首先进入作业队列,调度器按照一定的优先级顺序从队列中取出作业并进行调度。 资源管理器:调度器负责管理集群中的所有资源(如CPU、内存、存储等),并根据作业的需求分配资源。 工作流程 单体调度器的工作流程如下: 作业提交:用户提交作业到调度器,作业进入作业队列。 调度决策:调度器从作业队列中取出作业,并根据调度算法和集群的当前状态做出调度决策。 资源分配:调度器将作业分配到合适的机器上,并分配所需的资源。 任务执行:作业在分配的机器上执行,调度器监控任务的执行状态。 资源释放:任务完成后,调度器释放资源,并将资源重新分配给其他作业。 优点 单体调度器具有以下优点:

Linux容器网络-vxlan

Linux 是支持 VXLAN 的,我们可以使用 Linux 搭建基于 VXLAN 的 overlay 网络,下面的文章将记录相关的一些内容。

网速变慢?你可能需要先设置好 DNS

有没有觉得 kiosk007.top 最近访问变快了?没错,我的主站最近接入了 腾讯云的 EO(EdegeOne),当然只是14天体验版,体验过后还是会改会直连模式,毕竟是要收费的。不过能使得访问质量得到加速,第一个重要原因就是我们的请求被指向了就近节点,实现了就近访问。其中就依赖一个重要的底层技术 - DNS

LLM大模型 - langchain应用技术介绍

一个本地大模型,ChatGPT3.5 或 ChatGPT 4 都有这样一些问题。

数据缺少及时性,不能直接帮我们编辑 Word 或者 PDF 文件。大模型目前主要还是基于文本的交互等。

这样的场景非常多,因为大模型的核心能力是 意图理解与文本生成,而在我们实际应用过程中,输入数据和输出数据不仅仅是纯文本等。

针对大型语言模型效果不好的问题,之前人们主要关注大模型再训练、大模型微调、大模型的Prompt增强,但对于专有、快速更新的数据却并没有较好的解决方法,为此检索增强生成(RAG)的出现,弥合了LLM常识和专有数据之间的差距。

ollama 本地AI大模型

自 OpenAI 公司于 2022 年 11 月 30 日发布 ChatGPT 以来,经过 23 年一整年的发展之后,大语言模型的概念已逐渐普及,各种基于大语言模型的周边产品,以及集成层出不穷,可以说已经玩出花来了。

在这个过程中,也有不少本地化的模型应用方案冒了出来,针对一些企业知识库问答的场景中,模型本地化是第一优先考虑的问题,因此如何在本地把模型调教的更加智能,就是一个非常重要的技能了。