run-llm.sh,一键在本地跨平台运行大语言模型
由 Second State 开发的 run-llm.sh
脚本是一个命令行工具,用于让你快速在本地设备使用 CLI 和与 OpenAI 兼容的 API 服务器运行开源大型语言模型(LLMs)。这个命令行应用程序会自动下载并安装 WasmEdge runtime、模型文件以及用于推理的可移植 Wasm 应用程序。用户只需按照命令行提示选择所需的选项即可。
运行 run-llm.sh
bash <(curl -sSfL 'https://code.flows.network/webhook/iwYN1SdN3AmPgR5ao5Gt/run-llm.sh')
按照提示安装 WasmEdge Runtime 并下载你喜欢的开源大模型。然后,你将被询问是否希望通过命令行界面或通过 web 界面与模型进行交流。
-
命令行界面:只需留在终端。当你看到一个
[USER]
提示符,就可以提问了! -
Web UI:在安装本地 web 应用程序和本地 web 服务器(用 Rust 编写,并在 WasmEdge 中运行)后,你将被要求从浏览器打开 http://127.0.0.1:8080。
点击查看Web UI 视频
就是这样啦。
背后的机制
run-llm.sh
脚本使用可移植 Wasm 应用程序在 WasmEdge Runtime 中运行大语言模型。这些应用程序是可移植的,所以你可以简单地将 wasm 二进制文件复制到另一台具有不同 CPU 或 GPU 的设备上,它完全可以顺利运行。CLI 和基于 web 的聊天用户界面使用了不同的 wasm 应用程序。
命令行界面
llama-chat.wasm
应用程序为大语言模型提供了一个基于命令行的聊天界面。它是用简单的 Rust 编写的,你可以在这里找到其源代码。无论你使用什么设备,都可以按照以下方式下载 Wasm 应用程序。
curl -LO https://github.com/second-state/llama-utils/raw/main/chat/llama-chat.wasm
脚本使用以下命令来运行 Wasm 应用程序。-p
参数表示模型需要的聊天模板,用于格式化聊天消息。你可以在这里找到模型及其相应聊天模板名称的列表。
wasmedge --dir .:. --nn-preload default:GGML:AUTO:llama-2-7b-chat.Q5_K_M.gguf llama-chat.wasm -p llama-2-chat
Web UI
llama-api-server.wasm
应用程序为大语言模型创建了一个支持基于 API 的或基于 web 的聊天界面的 web 服务器。它是用简单的 Rust 编写的,你可以在这里找到其源代码。无论你使用什么设备,都可以按照以下方式下载 Wasm 应用程序。
curl -LO https://github.com/second-state/llama-utils/raw/main/api-server/llama-api-server.wasm
脚本使用以下命令来运行 Wasm 应用程序。-p
参数表示模型需要的聊天模板,用于将聊天消息变成特定格式。可以在这里找到模型及其相应聊天模板名称的列表。
wasmedge --dir .:. --nn-preload default:GGML:AUTO:llama-2-7b-chat.Q5_K_M.gguf llama-api-server.wasm -p llama-2-chat
技术栈
可以看到,run-llm.sh
应用程序是用 Rust 编写并编译为 Wasm,从而实现跨平台部署。它提供了一个强大的替代基于 Python 的 AI 推理的方案。这样,我们就不需要安装复杂的 Python 包或 C++ 工具链。
Rust 程序管理用户输入、跟踪对话历史、将文本转换为 LLM 的特定聊天模板,并使用 WASI NN API 运行推理操作。Rust 是 AGI 的语言。Rust + WasmEdge 堆栈提供了一个统一的云计算基础设施,从 IoT 设备到边缘云,再到本地服务器,再到公共云。主要好处如下。
- 轻量。总运行时大小为 30MB,与 Python 的 4GB 和 Ollama 的 350MB 相比。
- 快速。在 GPU 上实现全本机速度。
- 可移植。在不同 CPU、GPU 和操作系统上的单一跨平台二进制文件。
- 安全。在不受信任的设备上沙箱化和隔离执行。
- 轻松接入容器。在 Docker、containerd、Podman 和 Kubernetes 中得到支持。
- 与 OpenAI 兼容。无缝集成到 OpenAI 工具生态系统中,如 langchain、Llamaindex 和 flows.network。
无论你是开发者、研究人员还是 AI 爱好者,run-llm.sh
都提供了一种高效且易于访问的方式,让你在自己的设备上利用最先进的语言模型的强大能力。快来试试看吧!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
周鸿祎:鸿蒙原生必将成功
360集团创始人、董事长周鸿祎今日在微博宣布,360 浏览器等应用完成了鸿蒙原生核心版本的开发。并表示,未来还会把全线产品转移到鸿蒙生态里。 我在直播里很多次旗帜鲜明地表态,任何情况下都会支持华为,不能只停留在口号。今天我们正式宣布360浏览器等应用完成了鸿蒙原生核心版本的开发,未来我们还会把全线产品转移到鸿蒙生态里。我相信鸿蒙会成为中国最大的操作系统,鸿蒙原生必将成功。
- 下一篇
GaussDB(DWS)中的分布式死锁问题实践
本文分享自华为云社区《GaussDB(DWS)中的分布式死锁问题实践》,作者: 他强由他强 。 1、什么是分布式死锁 分布式死锁是相对于单机死锁而言,一个事务块中的语句,可能会分散在集群里多个节点(CN/DN)执行,在不同节点上可能都会持有锁,当并发事务进行时可能会导致分布式(全局)死锁,如下图所示,会话SESSION1持有了DN1上的lock1资源后再去请求DN2上的lock2,会话SESSION2持有了DN2上的lock2资源后再去请求DN1上的lock1,两个会话形成互相等待。出现分布式死锁现象后,如果没有外部干预,通常是一方等待锁超时报错后,事务回滚清理持有锁资源,另一方可继续执行。 2、常见的分布式死锁场景 一般来说,分布式死锁的产生与在不同节点上的并发时序或持锁顺序有关,所以现网实际发生概率较低,分布式死锁通常都是RegularLock类型,下面是几种常见的分布式死锁场景,举例说明两个并发事务产生的分布式死锁: 1)锁升级 # 集群两个CN,两个DN create table mytable(a int, b int); insert into mytable valu...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8安装Docker,最新的服务器搭配容器使用
- Linux系统CentOS6、CentOS7手动修改IP地址
- 2048小游戏-低调大师作品
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7,8上快速安装Gitea,搭建Git服务器