CNCF在2023年底举办第一次的Wasm大调查，来了解开发者怎么运用这项技术，调查发现，6成开发者用Wasm打造Web应用，35%用于资料视觉化处理，也有3成2用于IoT环境。（图片来源／CNCF）
前篇报导请见：Wasm是云原生技术的下一步发展，更是GAI实现快速推论关键助力
2023年是WebAssembly快速起飞的一年，CNCF和Wasm社群联手，开始大力推广这项技术，为了方便各界进行导入评估，他们盘点了相关专案和工具链，在第一届WasmCon大会上正式发表了Wasm生态地图（Wasm Landscape）第一版，后来也整合到原本的云原生生态地图中，成为其中一项子类别。
CNCF在生态地图中强调，WebAssembly的特性是一个安全的沙盒，可以提供一个轻量、快速、安全、跨语言、跨平台的应用程式执行环境。这项技术快速成了云原生技术的其中一项关键技术。
Wasm的跨硬体环境、跨平台和高效能计算能力，在这两年爆红的生成式AI浪潮中，也找到了新的应用场景，开始受到生成式AI开发社群和企业的重视。
专门提供Wasm平台服务的新创Fermyon技术长Radu Matie指出，许多AI开发者爱用容器技术来部署各式各样的AI推论，就是希望能用更快的方式来回应模型推论的结果。但是，「容器化AI冷启动最大的挑战是，数GB的容器映像档和LLM模型资料。」他强调。
想要用GPU硬体来执行一只AI推论程式，除了开发者自己的程式码之外，还需要Nvidia的CUDA runtime，以及AI技术框架像是PyTorch、TensorFlow等函式库，这样的容器映像档至少要4.8GB大小，再加上所用的LLM模型档案大小可能高达10～50GB，想要建立一个容器化的AI推论应用，至少要15GB，也拖慢冷启动的速度，往往需要30秒，甚至好几分钟，开发者多半得先启动一只AI推论服务来待命，这也限制了AI推论可部署和执行的模式。
Radu Matie指出，若改用Wasm来封装AI推论应用程式码，只需要数MB档案大小，而不需要数GB的容器映像档，冷启动速度可以大幅缩短到几毫秒，也就千分之几秒，可以切割出短暂的GPU算力，来提供「刚好即时（Just in time）」的AI推论回应。「不需要将GPU绑定到特定容器来待命，可以简化和更善用GPU基础架构的算力。」这正是吸引GAI开发者和相关技术专案开始尝试Wasm的关键。
甚至今年也出现了专门用Wasm打包的AI推论框架LlamaEdge，包括了一套10亿参数量的Llama 2模型，档案大小只有30ＭＢ，可以提供GPU原生应用执行速度，也能快速部署到Docker和K8s丛集中。
CNCF举行首次Wasm大调查
CNCF在2023年底举办第一次的Wasm大调查，来了解开发者怎么运用这项技术，调查了255位有Wasm实战经验的开发者。调查发现，Wasm应用范围早已扩散到各类型的应用需求，不局限于Web应用。6成开发用来打造Web应用，35%用于资料视觉化处理，也有3成2用于IoT环境，结合Wasm和AI应用的开发者也高达3成，这是最常见的四大类应用场景，也可以反映出Wasm技术目前最适合的四类场景。其他应用需求，像是游戏、边缘运算、加密、伺服器端服务也都有1～2成的采用比例。
目前约有4成开发者高度愿意继续用于浏览器环境，而有2成6则愿意用于非浏览器环境，不过，也有2成开发者担心这项技术还在发展中，保持观望态度，还没决定未来是否要跟进采用。甚至有5~7％开发者更为谨慎，决定还没有到可以采用的程度。
CNCF在2023年底公布首次Wasm大调查，显示Wasm应用范围已扩散到各类型的应用需求，6成开发者用来打造Web应用，35%用于资料视觉化处理，也有3成2用于IoT环境，结合Wasm和AI应用的开发者也高达3成。图片来源／CNCF
Wasm技术最吸引开发者的特色，包括了超快启动速度，可以用于探索新应用，以及可跨专案共享程式码、可提高JavaScript效能、满足高运算任务的需求、可到处执行的二进位档等等。这些都是吸引开发者，让他们愿意，甚至很想用的原因。
开发者打造Wasm应用所用的开发语言排名，JavaScript理所当然是第一名，高达45%，几乎有一半的Wasm应用采用了JavaScript，其次则是C#（31%）、C++（30%）、Python（29%）和Java（29%）。特别的是，用COBOL这个老牌语言来打造Wasm的开发者竟然也高达15%。超过34%的开发者在开发专案中开始采用WASI，另有34%开发者预计未来一年会采用。
对于可以提供元件模式的WASI专案，多数Wasm开发者都知道这项专案，目前有34%的开发者正在用，也有3成预计未来一年会开始采用。吸引开发者采用WASI的主要原因，高达四成看上了WASI能让Wasm程式码具有可移动性（Portability），也能大幅简化Wasm的部署。另外减少复杂度、提高WebAssembly原生能力和Runtime独立性，都是WASI受到青睐的原因。目前WASI专案也计划比照Wasm，申请成为W3C标准，正在提案讨论过程中。Wasm开发者最期待WASI未来可以增加HTTP、IO/streams、SQL这三项能力。
根据CNCF在2023年底公布的Wasm大调查，开发者头号痛点是除错困难，像是现有除错工具的支援还不够，第二项困难是不同Runtime的效能差异很大，导致开发者得自行挑选适合自己应用场景的runtime，增加开发专案管理的复杂度。图片来源／CNCF
不过，从这次调查中，也可以看到目前Wasm开发的挑战和相关工具还不够成熟，有待发展之初。Wasm开发者最头痛的三大困难，高达2成开发者认为除错非常困难，像是现有除错工具的支援还不够或是得自己寻找除错作法，第二项困难是不同Runtime的效能差异很大，这就导致开发者得自行挑选适合自己应用场景的runtime，或是针对不同场景采用不同的runtime，这也增加了开发专案管理的复杂度。第三个挑战也是runtime的问题，高达15%的Wasm开发者认为现有Wasm runtime的开发者体验落差太多，彼此的操作习惯，命令语法差异很大，得学习不同套的作法，提高了不少学习门槛和开发复杂度。其他开发挑战还有像是，缺乏了更完整的工具、学习资源不足、特定浏览器有相容问题、需要不少程式码客制等挑战。
这些困难都是Wasm目前技术发展的挑战，也是相关Wasm工具链未来的机会。
WASI小组加速发展元件模式，要让不同语言的Wasm元件直接互动
Cosmonic技术长Bailey Hayes也是WASI小组共同主席。这位将Wasm推广到浏览器以外世界的关键推手，在今年初KubeCon欧洲大会的演讲中，她介绍了WASI最新的元件模式，目前是预览第二版，也就是0.2版，吸引了云原生社群的高度关注。这个WASI元件模式，可以让不同开发语言所编译的Wasm程式，有一套标准的输入输出方式，互相沟通，甚至放到同一个更大的Wasm元件中互动。举例来说，用Go语言写的Wasm元件，和用Rust语言写的Wasm元件，有共同的标准输入输出方式，就像用同一种语言开发的元件一样，甚至可以把这两个元件，放入一个更大的Wasm元件中混用。这个元件模型，让Wasm具备了跨各种语言的能力。
Bailey Hayes指出，元件模式将会限制不同元件只能用标准输入、输出管道来确保安全性，但也可以在元件内部建立全域式变数和记忆体，用同一个runtime的跨元件间呼叫速度，甚至可以短到奈秒等级的超高速回应。她预告，新版WASI 0.2版草案标准即将完成，就会纳入这个全新的元件模式。
不只如此，WASI在0.2版中，也将开始支援网路能力，换句话说，Wasm元件不只是可以在单一应用环境中彼此沟通，未来也看好能与外部环境，甚至网际网路上的第三方应用元件相互沟通，有了网路沟通能力，也可以让Wasm元件更适合用来打造一支支微服务程式码，甚至建立一个全用Wasm元件组成的微服务架构。
下一步，Bailey Hayes预告，WASI预览第三版的0.3版，要进一步开始让WASI支援原生的非同步能力，让浏览器外的wasm元件，可以用非同步的方式，来彼此呼叫和协作，这是2025年接下来的发展重点。