網易首頁 > 網易號 > 正文申請入駐

ollama v0.22.0 發布：新增 NVIDIA Nemotron 3 Omni 與 Poolside Laguna 模型支持，推理能力再升級！

2026-04-30 00:12:03　來源: moonfdd

北京舉報

分享至

引言

2026年4月29日，Ollama 團隊正式發布了 v0.22.0 版本。本次更新是一次意義重大的版本迭代，不僅引入了兩個重量級的新模型——NVIDIA 的 Nemotron 3 Omni 和 Poolside 的首個開源編碼模型 Laguna XS.2，還在推理控制、模型轉換、量化策略、MLX 后端性能、內置解析器等多個核心模塊進行了深度優化。

本文將基于 v0.22.0 的完整變更日志，為您詳細解讀本次更新的每一個技術細節，幫助開發者全面理解新版本的能力邊界和使用方法。

一、新模型支持：兩大重量級模型登場 1.1 NVIDIA Nemotron 3 Omni

v0.22.0 引入了對 NVIDIA Nemotron 3 Omni 系列模型的原生支持。這是一個多模態模型家族，在代碼中對應的架構標識為nemotron_h_omni。該模型支持：

?文本生成：基于 Nemotron-H 架構的 LLM 核心
?視覺理解：集成了 Vision Transformer（ViT）模塊，支持圖像輸入
?音頻處理：集成了 Parakeet 音頻編碼器，支持語音輸入

在轉換器（converter）層面，新增了convert/convert_nemotron_h.go和convert/convert_nemotron_h_test.go兩個文件（共約 700 行代碼），專門處理 Nemotron 系列模型的權重映射和參數轉換。

關鍵配置參數包括：

?max_sequence_length: 131072（128K 上下文）
?vision.image_size: 512
?vision.patch_size: 16
?audio.sample_rate: 16000

1.2 Poolside Laguna XS.2

Poolside 的首個開源權重編碼模型 Laguna XS.2 也獲得了完整支持。這是一個專注于代碼生成和軟件工程任務的模型，架構標識為LagunaForCausalLM。

新增的模型支持文件包括：

?model/models/laguna/model.go（約 440 行）：Laguna 模型的 MLX 實現
?convert/convert_laguna.go（約 600 行）：GGUF 轉換邏輯
?model/parsers/laguna.go（約 500 行）：專用的輸出解析器
?model/renderers/laguna.go（約 110 行）：模板渲染器

Laguna 模型采用了混合專家（MoE）架構，支持動態稀疏層的推理優化。其配置包括：

? 逐層可變的注意力頭數（head_count 為數組而非固定值）
? 滑動窗口注意力（sliding window）模式
? 旋轉位置編碼（RoPE）支持全維度和 SWA 兩套參數

二、推理控制增強：新增 "max" 思考級別 2.1 API 層面的變更

在api/types.go中，ThinkValue類型現在支持一個全新的字符串值"max"。這意味著思考級別從原來的high/medium/low三個檔位擴展為四個：

// ThinkValue represents a value that can be a boolean or a string ("high", "medium", "low", "max")
type ThinkValue struct {
    Value interface{}
}

驗證邏輯已同步更新：

case string:
    return v == "high" || v == "medium" || v == "low" || v == "max"

2.2 OpenAI 兼容接口映射

在openai/openai.go中，OpenAI 風格的reasoning_effort參數現在也支持"max"值：

if !slices.Contains([]string{"high", "medium", "low", "max", "none"}, effort) {
    return nil, fmt.Errorf("invalid reasoning value: '%s' (must be \"high\", \"medium\", \"low\", \"max\", or \"none\")", effort)
}

當reasoning_effort為"none"時，思考功能被禁用；其他字符串值（包括"max"）則按原樣傳遞。

Responses API 也同步支持了max：

case "low", "medium", "high", "max":
    think = &api.ThinkValue{Value: effort}

2.3 CLI 命令行支持

cmd/cmd.go中的--think參數現在接受max作為合法值：

case "high", "medium", "low", "max":
    opts.Think = &api.ThinkValue{Value: thinkStr}

三、MLX 后端重大改進 3.1 采樣器歷史記錄優化

mlxrunner: track sampler history in a fixed-size ring buffer

采樣器現在使用固定大小的環形緩沖區來追蹤 token 歷史，而不是無限增長的切片。這顯著降低了長時間運行時的內存占用。

3.2 批量采樣優化

mlxrunner: batch the sampler across multiple sequences

采樣器現在支持批量處理多個序列，將多個獨立生成請求的采樣操作合并為一次矩陣運算。這在處理并行請求時能大幅提升吞吐量。

3.3 采樣器核心重構

x/mlxrunner/sample/sample.go進行了大規模重構（+415/-122 行），主要改進包括：

?多槽位（multi-slot）支持：采樣器現在可以管理多個獨立的生成會話，每個槽位有自己的歷史記錄和采樣參數
?批量 Logprob 計算：當多個槽位同時請求 logprobs 時，一次性完成 softmax 和 log 計算
?TopK/TopP 采樣優化：使用 MLX 原生的 argpartition 操作，避免顯式的完整排序

新增的Add(slot int, opts Options, history []int32)方法用于注冊采樣槽位，Sample(slots []int, logits *mlx.Array)方法支持批量采樣。

3.4 新增 Softplus 激活函數

x/mlxrunner/mlx/act.go新增了SoftplusF32函數：

var SoftplusF32 = Compile1(
    "SoftplusF32",
    func(x *Array) *Array {
        dt := x.DType()
        zero := FromValue[float32](0)
        return Logaddexp(x.AsType(DTypeFloat32), zero).AsType(dt)
    },
    Shapeless(),
)

這個函數以 float32 精度計算 softplus，然后轉換回原始數據類型，用于 Laguna 模型的注意力門控機制。

3.5 TensorRT Model Optimizer 導入支持

mlx: Support NVIDIA TensorRT Model Optimizer import

MLX 后端現在可以直接導入由 NVIDIA TensorRT Model Optimizer 導出的 FP8 量化模型。導入器會自動識別并處理F8_E4M3類型的張量及其配套的 scale 張量。

四、Tokenizer 多正則表達式偏移處理修復

tokenizer: fix multi-regex BPE offset handling

這是一個重要的 bug 修復。在tokenizer/bytepairencoding.go中，原來的多正則表達式匹配邏輯在處理重疊匹配時存在偏移量計算錯誤：

修復前：

if offset-m.Index != 0 {
    if !yield(string(r[:m.Index])) {

修復后：

if offset-m.Index != 0 {
    if !yield(string(r[offset:m.Index])) {

這個修復確保在使用多個正則表達式進行 BPE 預分詞時，每個匹配片段都是從正確的偏移位置開始提取的，避免了 token 邊界錯位的問題。

配套的測試用例TestBytePairEncodingSplitMultipleRegexpsPreservesOffsets驗證了修復的正確性。

五、FP8 張量支持全面增強 5.1 Safetensors FP8 讀取

convert/reader_safetensors.go大幅更新（+416/-13 行），新增了對 FP8 格式的完整支持：

? 支持F8_E4M3和F8_E5M2數據類型
? 自動查找配套的 scale 張量（支持*_scale_inv和*_scale兩種命名）
? 讀取模型配置中的compression_config.weight.block_structure獲取分塊大小
? 將 FP8 張量轉換為 BF16/FP32 進行后續處理

5.2 GGUF 輸出標記

在convert/tensor.go中，新增了sourceTensorKV函數，用于在輸出的 GGUF 文件中標記哪些張量來自 FP8 源：

func sourceTensorKV(ts []*ggml.Tensor) KV {
    // ...
    return KV{
        "source_quantization": "hf_fp8",
        "source_fp8_tensors":  slices.Sorted(maps.Keys(sourceFP8)),
    }
}

這些元數據在后續的量化過程中會被讀取，用于決定哪些張量應該被量化、哪些應該保持原始精度。

5.3 量化策略適配

server/quantization.go新增了sourceFP8Tensors跟蹤：

type quantizeState struct {
    // ...
    preserveSourceFP8ToQ8 bool
    preserveSourceQ4      bool
    sourceFP8Tensors      map[string]struct{}
}

當用戶請求Q8_0量化時，只有來自 FP8 源的張量會被量化，其他 BF16 張量保持原樣。當用戶請求Q4_K_M或Q4_K_S時，非 FP8 源張量被提升到Q8_0以保護精度。

六、Nemotron-3-Nano 解析器增強

model/parsers/nemotron3nano.go進行了多項改進：

6.1 前導空格處理

新增skipThinkingLeadingWS標志，用于跳過思考內容開頭的空白字符。當解析器處于Nemotron3NanoCollectingThinking狀態時，會 trim 掉 buffer 中的所有前導空格。

6.2 開標簽邊界情況修復

新增stripOpeningThinkTag()方法，處理標簽跨 chunk 傳輸的場景。當 buffer 中的內容與標簽有部分重疊時，解析器會等待完整標簽到達后再進行處理。

測試用例TestNemotron3NanoParser_Streaming/leading_open_think_tag_split_across_chunks驗證了此場景。

6.3 空思考塊處理

現在解析器能夠正確處理這樣的空思考塊，直接跳過而不產生空內容。

七、渲染器改進 7.1 Nemotron-3-Nano 渲染器

model/renderers/nemotron3nano.go進行了大規模重構（+263/-34 行），主要變更包括：

?工具調用格式修正：函數調用輸出格式調整為 XML 風格，與模型的訓練數據對齊
?思考標簽處理：歷史消息中的 thinking 內容被正確包裹在標簽中
?截斷策略：對于歷史中較早的 assistant 消息，只保留工具調用結果而裁剪思考內容，節省上下文空間

7.2 Laguna 渲染器

新增的LagunaRenderer實現了 Laguna 模型的對話模板：

? 使用〈|EOS|〉作為 BOS 標記
? 系統消息中包含思考模式指令
? 工具調用格式為++的結構
? 用戶消息包裹在標簽中
? 助手消息包裹在標簽中

7.3 Renderer/Detect 自動匹配

在server/create.go中，模型創建時會根據架構自動設置默認的渲染器和解析器：

case "laguna":
    config.Renderer = cmp.Or(config.Renderer, "laguna")
    config.Parser = cmp.Or(config.Parser, "laguna")
case "nemotron_h", "nemotron_h_moe", "nemotron_h_omni":
    config.Renderer = cmp.Or(config.Renderer, "nemotron-3-nano")
    config.Parser = cmp.Or(config.Parser, "nemotron-3-nano")

八、Poolside 集成 8.1 新的 launch 集成

cmd/launch/poolside.go新增了對 Poolside CLI 工具的支持。用戶可以通過以下命令使用：

ollama launch pool
ollama launch pool --model kimi-k2.6:cloud
ollama launch pool -- --help

8.2 環境變量自動配置

集成會自動設置以下環境變量：

?POOLSIDE_STANDALONE_BASE_URL: 指向 Ollama 的 OpenAI 兼容端點
?POOLSIDE_API_KEY: 設置為ollama

8.3 Windows 平臺保護

由于 Poolside 目前不兼容 Windows，在 Windows 系統上該集成會被自動隱藏，調用時會返回明確的錯誤提示。

文檔更新：新增docs/integrations/poolside.mdx，包含安裝和使用說明。

九、Safetensors 導入增強 9.1 新增數據類型支持

x/create/dtype.go新增了 FP8 和 U8/I8 類型的尺寸定義：

case "U8", "I8":
    return 1, nil
case "F8_E4M3", "F8_E5M2", "F8_E4M3FN", "F8_E5M2FNUZ":
    return 1, nil

9.2 Laguna 專用導入轉換器

新增x/create/laguna.go，實現了 Laguna 模型的特殊導入邏輯：

?路由專家權重識別：通過.mlp.experts.路徑識別 MoE 層的路由專家
?NVFP4 導入優化：當請求nvfp4量化時，down_proj權重被保留為mxfp8格式以保持精度
?量化決策：路由專家參與量化，共享專家和注意力層保持 BF16

9.3 導入能力推斷

x/create/client/create.go中的inferSafetensorsCapabilities函數現在會參考解析器的能力：

? 如果解析器支持工具調用，則添加tools能力
? 如果解析器支持思考，則添加thinking能力

十、Logprobs 與內置解析器兼容性

server: preserve generate logprobs with builtin parsers

這是一個重要的用戶體驗修復。之前當使用內置解析器（如 Nemotron-3-Nano 或 Laguna 解析器）時，生成響應中的 logprobs 會被丟棄，因為解析器會緩沖內容直到檢測到完整的語義單元。

修復后，在server/routes.go的 GenerateHandler 中：

if builtinParser != nil {
    // Emit chunks that carry logprobs even if the parser is still buffering
    if res.Response != "" || res.Thinking != "" || res.Done || len(res.ToolCalls) > 0 || len(res.Logprobs) > 0 {
        ch <- res
    }
}

現在只要 chunk 中包含 logprobs，即使沒有新的文本內容，也會被發送給客戶端。

配套測試TestGenerateLogprobsWithBuiltinParser驗證了此功能。

十一、架構兼容性標記 11.1 強制單并行請求

在server/sched.go中，nemotron_h_omni被加入到了需要強制num_parallel = 1的架構列表中：

if slices.Contains([]string{..., "nemotron_h", "nemotron_h_moe", "nemotron_h_omni"}, req.model.Config.ModelFamily) && numParallel != 1 {
    numParallel = 1
}

這是因為多模態模型和 MoE 結構在并行處理時存在狀態同步問題。

11.2 FlashAttention 支持

fs/ggml/ggml.go中，nemotron_h_omni被加入了啟用 FlashAttention 的架構列表：

case "nemotron_h", "nemotron_h_moe", "nemotron_h_omni":
    // FlashAttention enabled

十二、Harmony 后端適配

server/routes.go和server/routes.go中的shouldUseHarmony邏輯進行了調整：

? 當think.Value為字符串"max"時，在傳遞給 Harmony 后端之前映射為"high"
? Harmony 的 Parser 只在未顯式配置時才設置為"harmony"

這確保了 Harmony 后端在接收到max思考級別時不會報錯。

十三、MLX 圖像生成兼容性

x/imagegen/safetensors/safetensors.go中新增了 FP8 數據類型的映射：

case "F8_E4M3", "F8_E5M2", "F8_E4M3FN", "F8_E5M2FNUZ":
    return mlx.DtypeUint8 // FP8 types stored as raw uint8 bytes

這為未來在 MLX 后端支持 FP8 圖像生成模型奠定了基礎。

十四、代碼統計總覽

本次更新共涉及：

?14 個 commits
?90 個文件變更
?5 位貢獻者
?+13,915 行代碼新增
?-1,190 行代碼刪除

主要變更模塊分布：

?convert/: +1,500 行（FP8 支持 + Nemotron/Laguna 轉換）
?model/models/: +2,800 行（Laguna + Nemotron Omni 模型實現）
?x/mlxrunner/: +1,200 行（采樣器重構 + Pipeline 優化）
?x/create/: +900 行（Laguna 導入 + Safetensors 增強）
?cmd/launch/: +200 行（Poolside 集成）

十五、升級建議 15.1 兼容性說明

? 所有 v0.22.0 之前創建的模型均可繼續使用
? 新版本生成的 GGUF 文件與舊版本不兼容（由于新增了source_quantization等 KV 元數據）
? Windows 平臺的 Poolside 集成暫不可用

15.2 推薦使用場景

1.需要更強推理能力的應用：使用think: "max"級別調用 Nemotron 或 Laguna 模型
2.多模態應用：Nemotron 3 Omni 支持圖文語音輸入
3.代碼生成場景：Poolside Laguna 專為代碼任務訓練
4.高吞吐量場景：升級后 MLX 后端的批量采樣能力可提升 2-3 倍

15.3 量化建議

對于從 FP8 源導入的模型：

? 使用Q8_0量化可獲得最佳精度保持
? 使用Q4_K_M時，路由專家使用 Q4，注意力層使用 Q8
? 使用Q4_K_S時，淺層專家的 down_proj 使用 Q5

結語

代碼地址：github.com/ollama/ollama

Ollama v0.22.0 是一次功能密集、質量優先的版本發布。NVIDIA 和 Poolside 兩大模型的支持極大地擴展了 Ollama 的應用邊界，而 MLX 后端的采樣器重構、FP8 導入的完善、以及解析器/渲染器的增強，都體現了項目對生產級穩定性和用戶體驗的重視。

我們相信人工智能為普通人提供了一種“增強工具”，并致力于分享全方位的AI知識。在這里，您可以找到最新的AI科普文章、工具評測、提升效率的秘籍以及行業洞察。歡迎關注“福大大架構師每日一題”，發消息可獲得面試資料，讓AI助力您的未來發展。

特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.