MiniMax-M3 开源实测:部署、推理与基准测试全记录

MiniMax M3国产开源模型本地部署实战指南 大语言模型的本地化部署是实现数据安全、可控推理与垂直领域深度适配的关键路径。其核心原理在于绕过黑盒API,直接操作模型权重、显存调度与Tokenizer行为,从而获得对推理稳定性、上下文管理及多模态对齐能力的真实掌控。技术价值体现在可复现性、可控性、可解释性与可扩展性四大工程维度,支撑RAG知识库接入、嵌入式故障诊断、代码审查等高价值场景。本文以MiniMax发布的M3模型为实证对象,聚焦1M context的Block-wise KV缓存机制、GGUF量化部署、STM32救砖等工业级任务,揭示国产开源模型 阅读详情

MiniMax-M3 是 MiniMax 最新开源的原生多模态大模型,约 428B 总参数 / 23B 激活参数,原生支持 1M 上下文。本文基于 GPUStack 与 vLLM,演示从镜像与权重准备、模型部署、对话实测到基准测试的完整流程,并实测了基于 EAGLE3 的投机解码加速。

MiniMax 于 6 月 1 日宣布 MiniMax-M3 正式发布,并在 6 月 12 日(上周五) 于 HuggingFace 与 ModelScope(魔搭) 上正式开源权重。

MiniMax-M3 是一款原生多模态大模型,采用 MoE 架构,约 428B 总参数 / 23B 激活参数,原生支持 1M(百万级)上下文,并提供 thinking(思考) 与 non-thinking(非思考) 两种推理模式,可根据复杂推理、Agent 任务或低延迟对话/代码补全等不同场景灵活切换。官方推荐的采样参数为 temperature=1.0、top_p=0.95、top_k=40。

本文使用的是其 MXFP8 量化版本 MiniMax-M3-MXFP8,在保持精度的同时显著降低显存占用,更适合在有限卡数上部署。

核心亮点:

  • 原生多模态:从训练第一步就进行混合模态训练,在文本、图像、视频之间实现更深层的语义融合,而非后期拼接的「外挂式」多模态。
  • 稀疏注意力扩展长上下文(MSA):M3 引入了自研的 MiniMax Sparse Attention(MSA) 高性能稀疏注意力算子。官方数据显示,在 1M 上下文下,相比上一代 M2 实现了约 9× prefill / 15× decode 的加速,单 token 计算量降至约 1/20,在大幅降低注意力计算与显存开销的同时保持模型质量。
  • 代码与协作(Cowork)能力:在长程 Agentic 基准上达到前沿水平,在编码与协作类任务上表现突出。

技术报告:https://arxiv.org/abs/2606.13392

官方给出了 MiniMax-M3 与多款主流模型的对比,在编码、Cowork、GUI、多模态与推理等多个维度均具备竞争力,其中 OmniDocBench(91.6)、SpreadSheetBench-v1(89.4)、VideoMME(85.4)、Video-MMMU(84.6)、BrowseComp(83.5) 等多模态与协作类任务表现尤为亮眼,编码上 SWE-Bench Verified 也达到 80.5。

伴随权重开源,两大主流推理引擎也第一时间放出了 MiniMax-M3 的专用镜像:

推理引擎镜像标签时间
vLLMvllm/vllm-openai:minimax-m36 月 12 日(开源当天)
SGLanglmsysorg/sglang:dev-minimax-m36 月 15 日

需要说明的是,目前两者均为针对 MiniMax-M3 的专用/开发镜像,两大引擎主线版本对 M3 的正式支持仍需等待一段时间。本文采用 vLLM 的专用镜像进行部署与测试。

vLLM 官方镜像地址为 vllm/vllm-openai:minimax-m3,我们已第一时间同步至国内镜像,方便大家拉取:

swr.cn-south-1.myhuaweicloud.com/gpustack/vllm-openai:minimax-m3

本文的测试环境与配置如下:

项目内容
测试环境四卡 NVIDIA H20-3e 141G(Driver 590.48.01 / CUDA 13.1)
测试模型MiniMax/MiniMax-M3-MXFP8
草稿模型(投机解码)Inferact/MiniMax-M3-EAGLE3
参考文档https://recipes.vllm.ai/MiniMaxAI/MiniMax-M3?variant=mxfp8

全文分为以下几个部分:

  1. 环境准备 —— GPUStack 安装
  2. 下载权重与镜像
  3. 添加 vLLM 版本
  4. 部署 MiniMax-M3
  5. 对话实测
  6. 基准测试
  7. 小结

一、环境准备 —— GPUStack 安装

GPUStack 是一个开源 GPU 集群管理与 AI 模型服务平台,旨在高效部署 AI 模型。它可以配置并编排多种推理引擎——如 vLLM、SGLang、TensorRT-LLM,甚至自定义引擎——以在 GPU 集群上实现最佳性能。核心功能包括多异构 GPU 集群池化调度、可插拔推理引擎架构、Day 0 模型支持、性能优化配置(低延迟/高吞吐),以及企业级运维能力,如故障恢复、负载均衡、监控与权限管理。

在部署 MiniMax-M3 之前,需先完成 GPUStack 控制面的安装,并将 GPU 节点纳入管理。本文不再展开安装细节,可参考下方教程完成部署:

TODO: <在公众号编辑器中插入 之前已发布的《GPUStack v2.1.2 安装教程》的链接>

完成安装并接入 GPU 节点后,即可进入下一步,准备 MiniMax-M3 的权重与镜像。

二、下载权重与镜像

国内环境推荐从 ModelScope(魔搭) 下载权重。本文使用 MXFP8 量化版本以适配四卡 H20-3e 的显存与性能。

下载主模型权重:

本文同时使用 EAGLE3 草稿模型进行投机解码加速,因此一并下载草稿模型:

拉取 vLLM 专用镜像(国内同步地址):

docker pull swr.cn-south-1.myhuaweicloud.com/gpustack/vllm-openai:minimax-m3

也可使用 vLLM 官方镜像 vllm/vllm-openai:minimax-m3,国内网络环境下推荐使用上述同步地址以加速拉取。

三、添加 vLLM 版本

GPUStack 支持可插拔的推理引擎架构,允许自定义推理后端及其版本,用于引入 GPUStack 未内置的 vLLM / SGLang / MindIE 版本,或接入其他自定义推理引擎镜像。

由于 MiniMax-M3 当前依赖 vLLM 的专用镜像,这里将其作为 vLLM 的自定义版本添加到 GPUStack 的推理后端中。

在推理后端菜单,编辑 vLLM,在版本配置中选择添加版本,按实际情况填写镜像地址:

配置值
版本minimax-m3
镜像名称swr.cn-south-1.myhuaweicloud.com/gpustack/vllm-openai:minimax-m3
入口点(Entrypoint)vllm serve
运行命令(Run Command){{model_path}} --port {{port}} --host {{worker_ip}} --served-model-name {{model_name}}
框架CUDA

其中 {{model_path}}、{{port}}、{{worker_ip}}、{{model_name}} 为 GPUStack 的模板变量,部署时会自动注入,无需手动修改。

也可以切换到 YAML 模式,直接导入以下配置:

version_configs:
  minimax-m3:
    image_name: swr.cn-south-1.myhuaweicloud.com/gpustack/vllm-openai:minimax-m3
    run_command: "{{model_path}} --port {{port}} --host {{worker_ip}} --served-model-name {{model_name}}"
    entrypoint: "vllm serve"
    custom_framework: cuda
    env: {}

注意:如果当前已有其它自定义版本,需要将其它版本一同写入 version_configs 中一起导入。

四、部署 MiniMax-M3

GPUStack 支持从 Hugging Face、ModelScope 在线下载并部署,也支持从本地路径部署(离线环境推荐此方式)。本文使用前面已下载到本地的权重进行部署。

导航到模型文件页面,点击前面下载的模型权重右侧的小火箭部署按钮,即可开始部署:

在部署配置中,推理后端选择 vLLM,版本选择前面添加的 minimax-m3 自定义版本:

接着参考 vLLM Recipes 文档 配置后端启动参数。本文在四卡 H20-3e 上采用张量并行,并启用基于 EAGLE3 的投机解码,参数示例如下:

--tensor-parallel-size=4
--enable-auto-tool-choice
--tool-call-parser=minimax_m3
--reasoning-parser=minimax_m3
--block-size=128
--speculative-config '{"method":"eagle3","model":"/var/lib/gpustack/cache/model_scope/Inferact/MiniMax-M3-EAGLE3","num_speculative_tokens":3,"attention_backend":"FLASH_ATTN"}'
--gpu-memory-utilization=0.96
--max-model-len=64K
--disable-access-log-for-endpoints=/health,/metrics,/ping
--mm-encoder-attn-backend=FLASHINFER
--mm-processor-cache-type=shm
--mm-encoder-tp-mode=data

各组参数的作用简述如下:

  • 张量并行:--tensor-parallel-size=4 将模型切分到四张 H20-3e 上并行推理。
  • 工具调用与思考解析:--enable-auto-tool-choice 配合 --tool-call-parser=minimax_m3 启用工具调用能力;--reasoning-parser=minimax_m3 用于解析模型的思考(thinking)内容。
  • 投机解码(EAGLE3):--speculative-config 启用基于 EAGLE3 草稿模型的投机解码,以提升解码速度,其中 num_speculative_tokens 为每步推测的 token 数。
  • 显存与上下文:--gpu-memory-utilization=0.96 控制显存占用上限,--max-model-len=64K 设置上下文长度(M3 原生支持 1M,可按需调大,但会相应增加显存开销)。
  • 多模态编码器:--mm-encoder-tp-mode=data 让体量较小的视觉编码器采用数据并行而非张量并行,避免不必要的 TP 通信开销;--mm-processor-cache-type=shm 启用基于主机共享内存的多模态处理器缓存;--mm-encoder-attn-backend=FLASHINFER 指定编码器注意力后端(NVIDIA 上使用 FlashInfer,AMD 上对应 AITER FlashAttention)。

关于草稿模型路径:--speculative-config 中的 model 需填写 EAGLE3 草稿模型的实际路径。本文中的 /var/lib/gpustack/cache/model_scope/Inferact/MiniMax-M3-EAGLE3 是前文通过 GPUStack 从 ModelScope 下载后的默认缓存位置,请按你的实际下载路径填写。

以上参数为示例,量化方式、并行规模、投机解码 token 数、上下文长度(--max-model-len)、显存占用(--gpu-memory-utilization)等请结合实际硬件,并以 https://recipes.vllm.ai/MiniMaxAI/MiniMax-M3?variant=mxfp8 的最新说明为准。

采样参数方面,官方推荐 temperature=1.0、top_p=0.95、top_k=40。这些可在请求中传入,也可在 GPUStack 试验场中配置;若实测效果不理想,建议优先向官方推荐值对齐。

关于上下文长度(--max-model-len)的说明:本文设置为 64K,主要是受限于显存——在开启多模态功能的情况下,实测剩余显存已不足以支撑一个 128K 上下文的请求,故演示中设为 64K。当前推理镜像尚不支持 --kv-cache-dtype=fp8 来节省 KV Cache 显存,待 vLLM 推出支持该特性的新版本后,大家可自行尝试,以在开启多模态的同时获得更长的上下文。

此外,在当前版本的实际使用中,对于 Agent 场景 64K 往往是不够的。如果你的场景以文本为主、不需要多模态,推荐关闭多模态支持以释放显存换取更长上下文:去掉上面三项 --mm-* 参数,并添加 --language-model-only。在此配置下,实测可支持 256K 的上下文长度。

关于参数中的 k 与 K:vLLM 参数里小写 k 表示 1000,大写 K 表示 1024。例如 --max-model-len=64K 即 64 × 1024 = 65536。

部署后可在操作中点击查看日志,实时观察启动过程:

当模型实例状态显示为 Running 时,说明已成功启动,可进行后续测试:

完整的模型启动日志附在文末,供需要排查启动问题的读者参考。

五、对话实测

GPUStack 提供了多种类型模型的试验场,可进行基础对话测试与推理速度观察。

测试方式有两种:

  1. 在模型部署操作菜单中选择打开试验场;
  2. 直接打开对话试验场,在右侧模型选择框中选择 MiniMax-M3。

在对话框中输入内容进行测试:

测试中我们发现,模型的思考内容分隔符与标准 OpenAI API 格式不一致,导致试验场中思考内容显示异常——通过 cURL 直接调用 API 也能看到,思考内容会被混入 content 字段中。

查看模型的 chat_template.jinja 文件,果然其中使用了两个独特的思考标记。我们将其手动替换为标准的 <think> / </think>:

- {%- set think_begin_token      = '<mm:think>'                     -%}
- {%- set think_end_token        = '</mm:think>'                    -%}
+ {%- set think_begin_token      = '<think>'                     -%}
+ {%- set think_end_token        = '</think>'                    -%}

这是一个临时解决方案,后续进展可关注此 issue:https://github.com/vllm-project/vllm/issues/45687

修改后,在模型实例菜单中点击删除重建,使改动生效:

实例重建后再次测试,思考内容已能正常解析与显示:

一切正常。以上为开启投机解码的效果,下面再附一张未开启投机解码的效果作为对比:

六、基准测试

GPUStack 内置基准测试功能,可针对模型实例进行多种类型的测试,例如吞吐、延迟、长上下文等场景,并支持根据实际需求灵活调整测试参数。

七、小结

MiniMax-M3 在开源当天即获得 vLLM 的专用镜像支持,而 GPUStack 借助可插拔的推理后端架构,能够灵活接入自定义引擎版本,从而具备 Day 0 模型支持能力——这让我们得以在第一时间把这款全新的多模态模型部署、跑通并完整实测。

本文基于 GPUStack 演示了从环境准备、vLLM 自定义版本接入,到模型部署、对话实测、投机解码加速与基准测试的完整流程。在四卡 H20-3e 上,EAGLE3 投机解码带来的加速效果相当明显:未开启时约为 126 tokens/s,开启后提升至约 200 tokens/s,提速接近 60%,对实际推理体验的改善立竿见影。

可以看到,借助 GPUStack,不仅能更方便地统一管理推理引擎与模型实例,更能在专用镜像、自定义版本、投机解码等尚未进入主线支持的「尝鲜」阶段,快速把新模型跑起来、测起来;后续也能平滑扩展到多节点、生产化与团队协作场景。

如果你也在关注 MiniMax-M3,不妨亲自部署体验一下。

附录:MiniMax-M3 启动日志

以下为本次 MiniMax-M3 在四卡 H20-3e 上的完整启动日志,可用于对照排查环境、并行、投机解码及多模态相关的加载情况:

【开源地址】:github.com/gpustack/gpustack

本地部署MiniMax M3模型:打造Claude Code的离线代码助手 在软件工程实践中,大型语言模型(LLM)已成为提升开发效率的重要工具。其核心原理是通过海量代码和文本数据训练,学习编程语言的语法、逻辑与模式,从而具备代码生成、解释和调试等能力。这类模型的技术价值在于能够辅助开发者快速完成重复性编码任务、进行代码审查以及生成测试用例,显著降低开发成本。在实际应用场景中,开发者常面临云端模型服务的网络延迟、使用限制和成本问题,尤其对于需要处理私有代码库或进行深度静态分析的场景。为此,本地部署开源模型成为一种可行的解决方案,它能够在可控环境中提供稳定的辅助能力。本文聚焦于如何将 阅读详情

相关推荐

本地部署MiniMax M3代码模型:替代Claude Code的完整实践指南

代码生成模型作为人工智能在软件开发领域的重要应用,通过理解自然语言描述自动生成、补全或优化代码片段,其核心原理基于大规模代码语料训练的大语言模型。这类技术能显著提升开发效率,减少重复劳动,并帮助开发者快速探索新技术栈。在实际应用中,开发者常面临云端服务的数据隐私、网络依赖和成本控制等挑战。开源、可本地部署的代码模型如MiniMax M3,为解决这些问题提供了新思路。它允许开发者在自有硬件环境运行,确保数据不出本地,同时通过Ollama等工具链实现便捷部署,并能与VS Code等主流IDE集成,为处理敏感代码

weixin_29062255的博客 380

NVIDIA H20-3e 141G Docker LLaMA Factory 训练与vllm 推理实战:解锁 Qwen2.5-14B 与 DeepSeek-R1-FP8 671B 的性能潜力

本文深度解析基于 NVIDIA H20-3e 141G GPU 的 AI 开发全流程,重点呈现其相比前代 H20 在硬件架构、显存容量(141GB vs 96GB)及计算效率上的跨越式升级。通过 LLaMA Factory 框架实现 Qwen2.5-14B 模型的监督微调(SFT)训练,结合 Transformer 引擎与多实例 GPU 技术,突破传统显存限制,实现混合精度训练吞吐量提升。在推理环节,vllm 引擎借助 H20-3e 的 FP8 计算核心与更快的 NVLink 互联,使 DeepSeek-R

aosudh的博客 5573

ComfyUI集成MiniMax H3模型实战:构建智能AI绘画工作流

大型语言模型(LLM)通过理解自然语言指令生成结构化文本,其核心原理基于Transformer架构的注意力机制,能够捕捉长距离语义依赖。在AI生成内容(AIGC)领域,LLM的技术价值在于将模糊创意转化为机器可执行的精确指令,极大提升了工作流的自动化与智能化水平。这一特性在Stable Diffusion等图像生成场景中尤为重要,模型可根据简单描述自动生成高质量、细节丰富的提示词(Prompt)。通过将LLM与可视化编程工具结合,开发者能够构建可定制、可追溯的智能创作流水线,实现从文本理解到图像生成的无缝衔

weixin_29056701的博客 1144

NVIDIA H 系列 GPU与deepseek开源FlashMLA

H20概述: H20 是 NVIDIA 为中国市场设计的特制 GPU,基于 Hopper 架构。由于出口限制,它是 H100 的削减版,平衡了合规性与 AI 性能。规格: 96GB HBM3 内存,带宽 4 TB/s,FP8 精度下约 296 TFLOPS。特点: 计算能力不如 H100,但内存带宽优异,推理任务(如 70B 参数模型)表现突出,延迟比 H100 低约 20%。现状: 已于 2024 年底量产。

weixin_40941102的博客 4476

MiniMax M3 本地工程化部署与调优实战

在本地部署大语言模型时,最让人头疼的往往不是模型本身的复杂度,而是如何让它在有限的硬件资源上稳定跑起来。很多开发者在尝试将开源模型引入实际业务时,常常卡在显存不足、环境依赖冲突或是推理速度无法满足实时需求这些具体问题上。尤其是当我们需要在消费级显卡甚至单卡服务器上运行参数量较大的模型时,如何平衡精度与资源消耗,成为了一个必须面对的技术挑战。其实,只要掌握正确的量化选型策略和环境配置方法,大部分硬件适配问题都能迎刃而解。

csdn 简介2025 25 线 768

用Python+LLM实现小说自动转剧本:从爬取到生成的完整实战指南(附GitHub源码)

本文提供了一份完整的实战指南,详细介绍了如何利用Python和大语言模型(LLM)构建一个自动化的小说转剧本工具。文章从网络爬虫获取文本开始,逐步讲解了使用LLM进行智能解析与结构化、集成专业模型进行情绪分析与动作生成,最终合成并输出格式规范的剧本文档。通过模块化架构设计和附带的GitHub源码,帮助开发者掌握从数据获取到内容生成的全流程,实现高效的小说剧本转换器。

xray4的博客 410

MiniMax-M3 开源实测:vLLM 与 GPUStack 部署、推理引擎调优与基准测试全记录

MiniMax-M3 开源后如何本地跑通?本文实测四卡 H20-3e 部署 MXFP8 量化版,用 GPUStack 编排 vLLM 推理引擎,EAGLE3 投机解码把吞吐从 126 提到 200 tokens/s。含可复制启动参数、基准测试脚本与 401 等报错排查,并通过 TaoToken 统一 API 通道接入调用,详见 https://taotoken.net/?utm_source=taotoken_aicg_blog_end

weixin_42602368的博客 24

H医药公司配送中心布局仿真优化

新增2个Source,Source1命名为“货物到达”,用来进行仿真供应商原料到达,Source2命名为“订单到达”,用来进行仿真客户需求订单的到达,如下图是设置两个发生器的具体参数。通过主操作界面上的各个实体工具,如发生器、暂存区、货架、处理器、吸收器等实体工具对初始模型和优化后的方案模型进行仿真建模,建立优化前后的模型图如下图所示。通过下表可以看出,优化前操作员的总运行距离为132.11km,而优化后操作员的总运行距离为128.17km,运行距离缩短,操作员的疲劳强度降低。

m0_72514516的博客 2529

ax-M3 开源实测:部署、推理与基准测试全记录

并提供与两种推理模式,可根据复杂推理、Agent 任务或低延迟对话/代码补全等不同场景灵活切换。官方推荐的采样参数为top_p=0.95top_k=40。本文使用的是其,在保持精度的同时显著降低显存占用,更适合在有限卡数上部署。技术官方给出了 MiniMax-M3 与多款主流模型的对比,在编码、Cowork、GUI、多模态与推理等多个维度均具备竞争力,其中等多模态与协作类任务表现尤为亮眼,编码上也达到。需要说明的是,目前两者均为,两大引擎主线版本对 M3 的正式支持仍需等待一段时间。

qgknOU8y2的博客 243

机器人运动不流畅?手把手教你用ACCSET调整ABB/FANUC点位加速度

本文针对ABB和FANUC工业机器人运动不流畅、拐角抖动、到位震颤等常见问题,提供了详细的解决方案。核心在于使用ACCSET指令(ABB)或ACC选项(FANUC)调整机器人的点位加速度与减速度参数。文章通过实战案例与系统化调试流程,手把手指导工程师优化运动性能,实现平稳、精准的机器人运动控制。

gpu4optimizer的博客 284

Silvaco TCAD实战 | SiC MOSFET工艺仿真与关键参数DOE分析

本文详细介绍了使用Silvaco TCAD进行SiC MOSFET工艺仿真与关键参数DOE分析的实战方法。通过外延生长建模、离子注入工艺调试等步骤,结合DOE分析优化器件性能,帮助工程师在设计阶段预判电学特性,提升产品可靠性。文章还分享了网格划分、界面态建模等实用技巧,助力实现从仿真到产品的闭环验证。

weixin_30235225的博客 505

MiniMax-M3 开源实测:vLLM 部署、EAGLE3 投机解码与基准测试全记录

MiniMax-M3 本地部署实测:四卡 H20-3e 上用 vLLM 专用镜像跑 MXFP8 版,叠加 EAGLE3 投机解码后吞吐从 126 提升到约 200 tokens/s,提速近 60%。文中给出可复制的启动参数、GPUStack 自定义版本 YAML 与思考分隔符修复方案,日常调用可经 TaoToken 统一 Key 与 Base URL,详见 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 。

weixin_28931449的博客 158

[游戏排查] Baldur‘s Gate 3 加载完成即崩溃?五步排查帮你快速定位问题

《博德之门3》加载崩溃问题解决方案:针对游戏进度条走完后闪退的情况,提供五步排查法。首先清除LevelCache缓存(成功率最高),其次检查Mod兼容性,然后切换Vulkan/DX11渲染API,再排查存档损坏问题,最后可删除配置目录(需备份存档)。重点提示Steam验证无法解决此类问题,建议按步骤顺序排查,多数情况下前两步即可解决问题。

技术小甜甜:传播可落地技术,帮助个人和企业降低解决真实场景问题的成本 3258

MiniMax M3 深度评测:参数解析与实战表现全记录

最近接手了一个新的内容生成项目,团队在选型大语言模型时犯了难。市面上模型层出不穷,宣传语一个比一个响亮,但真正落到实际业务场景中,往往会出现“买家秀”和“卖家秀”的巨大落差。有的模型聊家常还行,一让它写代码就逻辑崩坏;有的擅长长篇大论,却在多轮对话中频频失忆,忘记前文的关键约束。对于开发者和技术决策者来说,如何透过营销迷雾,看清一个模型的真实能力边界,成了当下最迫切的需求。我们不再满足于看厂商发布的基准测试分数,那些经过精心调优的数据集往往无法反映真实世界的复杂性。

ab977a1081268482的博客 448

OpenGL 进阶系列10 - 光线跟踪实现简介(Ray Tracing)

OpenGL 实现光线跟踪(Ray Tracing)是一个相对复杂但有趣的挑战,通常用于生成高度逼真的图像效果,如反射、折射、阴影等。OpenGL 本身并不是为光线跟踪设计的,但可以通过结合计算着色器和现代 OpenGL 功能实现光线跟踪。光线跟踪的基本思路是从相机(或视点)出发,发射光线并计算这些光线与场景中物体的交点。光线与场景中物体相交的计算。计算交点的光照(基于表面法线、光源位置、材质等)。反射和折射的处理(如果物体是透明或反射的)。

GPU全栈博主 1534

自定义View系列教程04--Draw源码分析及其实践

通过之前的详细分析,我们知道:在measure中测量了View的大小,在layout阶段确定了View的位置。 完成这两步之后就进入到了我们相对熟悉的draw阶段,在该阶段真正地开始对视图进行绘制。按照之前的惯例,我们来瞅瞅View中draw( )的源码 public void draw(Canvas canvas) { final int privateFlags = mPriv

谷哥的小弟 2万+

基于MiniMax M2大模型构建全流程软件开发智能体:从需求到部署的完全指南

基于MiniMax M2构建全流程软件开发智能体摘要 MiniMax M2是中国AI公司推出的新一代大模型,专为代码生成和Agent工作流设计,在全球测评中位列前五。本文详细介绍了如何基于该模型构建从需求分析到部署的全流程软件开发智能体,实现高度自动化的软件开发。 文章包含以下核心内容: 模型优势:128K超长上下文、强大工具调用能力,成本仅为同类产品的8% 环境配置:提供API调用、Claude Code集成和本地部署三种方案 架构设计:模块化系统包含需求分析、项目规划、代码生成等6个核心模块 流程实现:

Liudef06的博客 9020

PCL 提取两片点云的非重叠部分【2025最新版】

PCL 提取两片点云的非重叠部分。博客长期更新,本文最近一次更新时间为:2025年9月1日。

点云侠的博客 36万+

开源新王MiniMax -M1 vLLM本地部署教程:百万级上下文支持成大模型领域新标杆!

MiniMax-M1 型号可以在配备 8 个 H800 或 8 个 H20 GPU 的单个服务器上高效运行。在硬件配置方面,配备 8 个 H800 GPU 的服务器可以处理多达 200 万个令牌的上下文输入,而配备 8 个 H20 GPU 的服务器可以支持高达 500 万个令牌的超长上下文处理能力。,凭借其百万级上下文支持、超高效计算性能和突破性成本表现,成为大模型领域的新标杆。为了保证部署环境的一致性和稳定性,我们建议使用 Docker 进行部署。💡 如果您使用的是其他环境配置,请参阅。

SJJS_1的博客 3168

SIMATIC S7-1200, S7-1500 PID 控制[手册]

SIMATIC S7-1200, S7-1500 PID 控制[手册]

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

调查研究-163-MiniMax M3 正式发布:1M 上下文、多模态、Coding Agent 与 Sparse Attention 到底意味着什么?

MiniMax M3是一款面向编码和智能体场景的新一代语言模型,支持1M tokens的长上下文窗口和原生多模态输入。其核心技术是MiniMax Sparse Attention(MSA),通过两步式稀疏注意力机制降低长上下文计算成本。M3强调工程闭环能力,适用于代码仓库理解、长文档分析和多轮任务执行。官方称其为"open-weight"模型,但商用授权条款仍需确认。该模型将前沿的Coding Agent能力与可开放权重结合,为开发者提供了新的工具选择。

谢谢你的喜欢 我们一起无限进步 965

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

上一篇: 没有 GPU,还能跑大模型吗?vLLM vs llama.cpp 实测对比
下一篇: GPUStack v2.2 MaaS+GPUaaS:从模型服务到 Token 工厂,从算力池化到 GPU 运营
GPUStack
博客等级 码龄2年 150粉丝 65原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值