西方自找的没落（转型DEEPSEEK讨论楼

星花

qratosones1337 发表于 2025-1-21 16:56
我怀疑是故意的

我觉得 是产地问题。

naihs

其实还有个旁证来说明这玩意的水平

搜一下 梁文峰 最近的新闻

alixsander

机吉斯卡 发表于 2025-1-21 16:45
这个模型这么厉害了吗？

如何落地变化为产能？

理想的说，一方面幻方可以给OAI和Anthropic放血，让他们损失用户和数据飞轮。另一方面，国内的院所和公司利用幻方API或者本地部署代码助手，论文翻译，会议摘要（包括V3的应用范围），之前因为信息安全肯定是没法铺开的。

然后就是智能客服，这个国内各种银行，ISP，电商早就在推进了。

盈利是不可能的，R1的API实际收费可能是O1的1/4，因为R1的思维链效率比O1低很多。我是不知道幻方怎么能在网页端免费开放的，R1应该推理用的也是H800，我看他们的推理优化也是针对H800的。不知道他们怎么能协调那么多用于推理。 910推理是不太行，HBM带宽太低算力浪费了。

当然不管是幻方还是阿里，还是美国那几个其实都不在意盈利，手上根本不缺资金。

OAI刚刚给政府做了闭门会议，然后又放出“内幕”说内部达成了innovator能力。美国是把冲AGI当成新时代曼哈顿计划来做的。
O和A又和Anduril和Palantir有合作，可以说新的MIC雏形把。
未来国家竞争最激烈的部分应该就在AI，具身智能（包括自动驾驶）这几个产业上了

机吉斯卡

alixsander 发表于 2025-1-21 17:18
理想的说，一方面幻方可以给OAI和Anthropic放血，让他们损失用户和数据飞轮。另一方面，国内的院所和公司 ...

AI落地也不知道是哪一个方向

反正看起来都是有人付钱就行

a4ac7

R1:我大概落后o1一年

针对DeepSeek-R1的现有缺陷，以下是从技术实现角度提出的系统性升级方案，分为四个核心模块进行优化：

**1. 实时知识增强系统**
- 架构双向数据通道：
  - 实时流处理层：集成Apache Kafka实现实时数据管道，对接权威数据源（如Wolfram Alpha、统计局API）
  - 动态知识图谱：构建基于Neo4j的时序知识图谱，支持增量更新和版本回溯
- 混合检索机制：
  - 向量检索：采用FAISS实现亿级向量实时检索
  - 传统检索：Elasticsearch构建全文索引
  - 检索融合模块：基于BERT-Whitening的语义匹配算法

**2. 多模态处理引擎**
- 文件解析矩阵：
  - 结构化数据处理：集成Apache POI（Office文件）、PDFBox（PDF）
  - 非结构化处理：基于LayoutParser的文档布局分析
  - 二进制流处理：实现自适应文件类型检测算法（基于Magic Number识别）
- 视觉认知系统：
  - 多模态Transformer架构：采用Vision-Language Pre-training框架
  - 图像特征提取：集成CLIP-ViT-L/14视觉编码器
  - 跨模态对齐：改进的ALBEF对比学习策略

**3. 生成式增强体系**
- 复合生成架构：
  - 文本生成分支：延续现有语言模型架构
  - 图像生成通道：集成Stable Diffusion XL Turbo引擎
  - 跨模态转换器：设计基于Attention的模态桥接层
- 生成控制模块：
  - 内容安全网关：多层级过滤系统（关键词、语义、视觉多模态检测）
  - 风格迁移组件：实现参数化的生成风格控制

**4. 系统级优化方案**
- 分布式计算架构：
  - 微服务化改造：基于Kubernetes的模块化部署
  - 计算资源调度：实现GPU资源的动态分配策略
- 隐私安全增强：
  - 联邦学习框架：采用差分隐私的数据处理方法
  - 文件沙箱系统：基于eBPF实现的隔离执行环境

**实施路线图**：
1. 第一阶段（6个月）：构建实时数据管道和文件解析基础框架
2. 第二阶段（9个月）：实现多模态编码器和基本图像生成能力
3. 第三阶段（12个月）：完成全系统集成和性能优化

**关键技术指标**：
- 实时数据延迟：<500ms
- 文件格式支持：覆盖98%常见办公文档格式
- 多模态推理速度：<3s（V100 GPU环境）
- 系统吞吐量：提升300%以上

该方案通过架构级重构实现能力跃升，同时保持核心语言模型优势，建议采用渐进式迭代开发策略，优先解决企业用户的高频需求。

o1:附议

以下是一份示例性实施路线图（约12个月的周期）供参考，涵盖从近期到中期的主要升级目标和对应的里程碑。实际项目中可根据研发进度、资源投入和业务需求作动态调整。

阶段 0：规划与准备（第0~1个月）
        1.        需求和资源评估
        •        明确目标功能和技术可行性；
        •        评估现有技术栈、团队能力和硬件资源；
        •        制定具体的研发计划、预算和人力投入。
        2.        架构设计与技术选型
        •        决定多模态模型方案（自行研发或集成成熟开源方案）；
        •        确定实时搜索引擎解决方案（如 Elasticsearch、Milvus + 爬虫 或 API 检索 等）；
        •        梳理支持多类型文件解析的插件或库；
        •        为后续多轮迭代打下架构基础。

输出物：
        •        详细的技术文档、实施方案与项目计划；
        •        基础的代码仓库与持续集成/交付（CI/CD）管线搭建；
        •        团队分工与时间排期表。

阶段 1：实时数据检索与插件体系初步落地（第2~3个月）
        1.        实时检索 & 知识库搭建
        •        对接外部搜索引擎或搭建企业内知识库（含简单的爬虫 + 向量数据库）；
        •        实现最基础的问答：在对话时能够调用检索模块查询最新信息；
        •        建立缓存机制与知识更新机制，以保证结果相对实时和准确。
        2.        插件/工具体系雏形
        •        为后续多功能拓展（如文件解析、多模态识别、行业插件等）打下基础；
        •        提供简单的插件管理界面或 API 接口；
        •        输出插件开发指南和规范。

输出物：
        •        能够调用检索服务并融合结果的对话 Demo；
        •        完成初步插件化的框架及文档；
        •        检索结果的处理逻辑、缓存策略等技术说明。

阶段 2：多类型文件阅读 & OCR 能力集成（第4~5个月）
        1.        文件解析功能
        •        优先实现常见格式的解析：PDF、Word、Excel、TXT 等；
        •        支持基础的文本提取，并能够在对话时根据指令进行内容总结、对比或批注；
        •        对 Excel/CSV 等表格型数据要提供基础的数据分析和可视化描述。
        2.        OCR 集成
        •        用于识别扫描版 PDF 或图像中的文本（如发票、截图等）；
        •        结合已有的文档处理流程，实现对 OCR 结果的语义理解。

输出物：
        •        能够读取主流文件格式的插件，并将结果纳入对话上下文；
        •        对部分图片/扫描件文本实现自动识别并可交互式分析；
        •        优化文件解析的精度与稳定性。

阶段 3：多模态生成与识图原型（第6~7个月）
        1.        图像生成模块对接
        •        选型已有成熟的图像生成模型（如 DALL·E、Stable Diffusion），或基于开源项目进行二次开发；
        •        在对话中支持简单的“文本到图像”命令，如“画一只小猫”或“生成产品概念图”等；
        •        优化模型推理性能，考虑 GPU/TPU 等硬件部署方式。
        2.        初步图像识别功能
        •        集成开源模型（如 CLIP、Vision Transformer 等）以实现基础识图；
        •        支持提取图像的主元素或标签，并在对话中输出相应的文字描述；
        •        测试典型用例：物品识别、场景描述、人脸模糊等。

输出物：
        •        简单的文本到图像功能 Demo；
        •        识别并描述图片内容的原型；
        •        多模态模型在推理层面的集成方案与性能报告。

阶段 4：功能整合与性能优化（第8~9个月）
        1.        多模态 & 检索 & 文件解析的深度整合
        •        流程串联：在同一轮对话中可使用检索、文件解析、图像识别/生成等多功能；
        •        优化上下文管理，保证跨功能调用时的状态保持与结果传递准确。
        2.        模型压缩与推理加速
        •        引入量化、剪枝或知识蒸馏等技术，减少模型尺寸；
        •        使用高效推理框架（如 TensorRT、ONNX Runtime）进行加速；
        •        结合分布式推理策略，满足大规模并发的需求。
        3.        插件生态的扩展
        •        推出简单的插件市集/管理平台，鼓励第三方开发者贡献更多功能；
        •        强化权限与安全策略，如对敏感或高危插件的调用进行审核或沙箱隔离。

输出物：
        •        多功能融合 Demo 和正式API/SDK；
        •        关键性能指标（响应时间、并发量、资源使用）显著改善；
        •        插件生态基础雏形与开发者文档/教程。

阶段 5：专业领域适配与生态建设（第10~11个月）
        1.        行业知识库 & 微调
        •        针对重点行业（如金融、法律、医疗、制造），构建或接入领域专业知识库；
        •        进行微调或强化学习，使 R1 更加贴合专业领域场景；
        •        考虑合规和隐私要求（如 HIPAA、GDPR、数据安全法规等）。
        2.        场景化解决方案打包
        •        将常用功能与行业特定需求相结合，封装成可复用的解决方案；
        •        优化对话模型在专业场景下的准确性和解释性。

输出物：
        •        针对若干行业的专业功能Demo或样例；
        •        在专业语料上微调后的模型版本；
        •        合规性与数据安全评审报告。

阶段 6：正式发布与持续迭代（第12个月）
        1.        大规模内部/外部测试
        •        从功能、性能、安全多维度验证；
        •        收集用户反馈并进行Bug修复与功能完善。
        2.        版本发布 & 维护
        •        发布 deepseek-R1 升级后的正式版本；
        •        建立长线的运营维护机制与常态化迭代计划；
        •        与合作伙伴或社区协作，持续扩充插件和功能。

输出物：
        •        稳定版模型和平台；
        •        明确的社区或商业化路线；
        •        后续功能与技术迭代计划草案。

关键注意点
        •        资源保障：多模态模型和实时检索功能往往对计算资源要求较高，需要在 GPU/TPU 服务器或云平台上进行部署；
        •        安全与隐私：对接实时网络检索和多类型文件时，要注意数据安全和版权合规；
        •        用户体验：尤其要重视多功能融合后的对话结构和交互设计，保证用户能够自然地完成多步骤、多模态的对话任务。
        •        可持续迭代：一年内完成上述核心功能后，还需在后续维护中加入新的插件、优化模型效果与强化专业领域知识，以形成正向循环和竞争壁垒。

这份路线图覆盖了从基础规划到功能集成、性能优化，再到专业领域落地和生态建设的关键阶段，时间节点可结合实际研发进度适当微调，确保每个阶段都能既有独立成果，又为下一阶段奠定基础。

—— 来自 鹅球 v3.3.96

alixsander

机吉斯卡 发表于 2025-1-21 17:20
AI落地也不知道是哪一个方向

反正看起来都是有人付钱就行

哪个方向都能落地

就是
1.不知道使能千行万业，还是行业百草枯
2.什么时候

stanzgy

看了眼reddit上几个相关sub，首页几乎全是deepseek

论坛助手,iPhone

sql710

naihs 发表于 2025-1-21 17:00
其实还有个旁证来说明这玩意的水平

搜一下 梁文峰 最近的新闻

艹。。。已经到这种高度了么

overflowal

alixsander 发表于 2025-1-21 17:18
理想的说，一方面幻方可以给OAI和Anthropic放血，让他们损失用户和数据飞轮。另一方面，国内的院所和公司 ...

怎么就盈利是不可能的，之前V2时api的定价Deepseek都说是赚钱的，这次计算量实在提高了才提价。
实际收费是O1的1/4，思维链效率比O1低又是怎么估计出来的啊？什么玩意。

qratosones1337

alixsander 发表于 2025-1-21 17:18
理想的说，一方面幻方可以给OAI和Anthropic放血，让他们损失用户和数据飞轮。另一方面，国内的院所和公司 ...

扯吧，推理要是真有那么大的带宽要求，KV Cache磁盘缓存不就没法用了？MLA本身在设计上就是为了降低KVCache的存储和通信负载的，不然搞这么一出增加系统复杂度但是没减少实际算力需求，不就是画蛇添足么？

目前有传言说DeepSeek自己的推理服务用的就是Atlas800I，这个虽然没法用公开消息佐证，但是V3开源的同一天就首发了MindIE推理镜像，这个是公开可查的

2017.05.04

机吉斯卡 发表于 2025-1-21 16:45
这个模型这么厉害了吗？

如何落地变化为产能？

很多人现在都在用个商业方案辅助工作，无论是付费的还是免费的
产能提升早就有了

alixsander

qratosones1337 发表于 2025-1-21 17:43
扯吧，推理要是真有那么大的带宽要求，KV Cache磁盘缓存不就没法用了？MLA本身在设计上就是为了降低KVCach ...

没啥好扯的虽然是和MindIE友情联动的
但是推理主要用的就不是800I
要上也是未来上超节点

他们用的是32P 320D GPU ALL TO ALL

KV swap当然可以，推理慢了而已。本质上910没有什么不能做的，计算访存比太高了，太卡访存瓶颈了，很浪费。尤其MoE计算量小的特点更明显(虽然MLA相比GQA又降了几倍KV Cache)。另外Ascend不亲和FP8

alixsander

overflowal 发表于 2025-1-21 17:41
怎么就盈利是不可能的，之前V2时api的定价Deepseek都说是赚钱的，这次计算量实在提高了才提价。
实际收费 ...

https://www.reddit.com/r/LocalLLaMA/s/ocUEwqmk0P


I calculated the effective cost of R1 Vs o1 and here's what I found

In order to calculate the effective cost of R1 Vs o1, we need to know 2 things:

1. how much each model costs per million output tokens.
2. how much tokens each model generates on average per Chain-of-Thought.

You might think: Wait, we can't see o1's CoT since OpenAI hides it, right? While OpenAI does hide the internal CoTs when using o1 via ChatGPT and the API, they did reveal full non-summarized CoTs in the initial announcement of o1-preview ([Source](https://openai.com/index/learning-to-reason-with-llms/)). Later, when o1-2024-1217 was released in December, OpenAI stated,

>o1 uses on average 60% fewer reasoning tokens than o1-preview for a given request

([Source](https://openai.com/index/o1-and-new-tools-for-developers/)). Thus, we can calculate the average for o1 by multiplying o1-preview’s token averages by 0.4.

The Chain-of-Thought character count per example OpenAI showed us is as follows, as well as the exact same question on R1 below:

o1 - \[(16577 + 4475 + 20248 + 12276 + 2930 + 3397 + 2265 + 3542)\*0.4\]/8 = 3285.5 characters per CoT.  
R1 - (14777 + 14911 + 54837 + 35459 + 7795 + 24143 + 7361 + 4115)/8 = 20424.75 characters per CoT.

20424.75/3285.5 ≈ 6.22

R1 generates 6.22x more reasoning tokens on average than o1 according to the official examples average.

R1 costs $2.19/1M output tokens.  
o1 costs $60/1M output tokens.

60/2.19 ≈ 27.4

o1 costs 27.4x more than R1 price-per-token, however, generates 6.22x fewer tokens.

27.4/6.22 ≈ 4.41

# Therefore in practice R1 is only 4.41x cheaper than o1

(note assumptions made):  
If o1 generates x less characters it will also be roughly x less tokens. This assumption is fair, however, the precise exact values can vary slightly but should not effect things noticeably.  
This is just API discussion if you use R1 via the website or the app its infinitely cheaper since its free Vs $20/mo.

lactone

之前gpt和sora刚发布就破圈，各种杂谈建政up主瞎吹

到现在国内烤出来吊打sora的视频生成模型和最好的开源llm后，只有圈内人在狂欢

这舆论上的差距真不是一丁点

—— 来自 S1Fun

overflowal

alixsander 发表于 2025-1-21 18:15
https://www.reddit.com/r/LocalLLaMA/s/ocUEwqmk0P

这个人算的也是逗，全是猜的。OpenAI的真正token数量根本就是黑箱。这人连实际实验都没做过就用几个openAI自己给的数据，然后做了一堆不牢靠的假设估了一把。114514数字论证的水平。
R1生成6倍于O1的推理token，这特么真有人信？那O1是怎么在做到对同一个prompt用更强的推理硬件平均耗时却比R1普遍更多的？因为O1的token生成速度比R1慢几十倍吗

alixsander

overflowal 发表于 2025-1-21 18:37
这个人算的也是逗，全是猜的。OpenAI的真正token数量根本就是黑箱。这人连实际实验都没做过就用几个openAI ...

这个很有可能啊

Deepseek特点就是极致低时延，推的爆快

有心可以比一下V3和4O在一样的上下文长度下的tbt(DS应该是小于10毫秒)

MeursaulT

清风伴明月 发表于 2025-1-21 16:23
目前所有下联都不对

上联是一到十，下联就不能是一到十。要么十到一，要么个到秭 ...

上联：一艘两攻共三架飞机四款新品搞得五角大楼六神无主七上八下酒后加班十分难受  
下联：十拿九稳凑八家作坊七拼六就忽悠**三教九流二话不说一锤定音

赏析：这幅下联以“十拿九稳”起头，与上联的“一艘两攻”形成数字对应，整体平仄协调。通过“凑八家作坊七拼六就”等词，展现了多方努力与整合的意象，与上联的复杂情境相呼应。结尾“二话不说一锤定音”简洁有力，为整个对联画上圆满句号。

这个对是对了，但感觉缺乏娱乐性

qratosones1337

alixsander 发表于 2025-1-21 18:41
这个很有可能啊

Deepseek特点就是极致低时延，推的爆快

拉倒吧你，deepseek啥时候跟快能沾上关系了？它的低成本很大程度上就是通过牺牲推理延时实现的，从来都不是以快为卖点。

—— 来自 鹅球 v3.3.96

qratosones1337

alixsander 发表于 2025-1-21 18:12
没啥好扯的虽然是和MindIE友情联动的
但是推理主要用的就不是800I
要上也是未来上超节点

1，H800的带宽跟A800一样就400G，并没有比910B全连接高多少。而且就算真有需要的话NV这边恰好还有个H20，大带宽大显存，算力弱鸡但是正好MoE前向激活参数也少，真是刚需N卡推理也应该上H20。
2，V3技术报告里cite了一篇论文叫HiFloat8，恰好就是华为的。与此同时V3使用的FP8格式也一样是自己实现的，H800硬件并不支持

总的来说推理成本高是站不住脚的

—— 来自 鹅球 v3.3.96

riin2

有没有啥文章视频能说清楚为啥这样一个名不见经转的投资公司能把LLM研究的这么成功的

tonyunreal

riin2 发表于 2025-1-22 01:35
有没有啥文章视频能说清楚为啥这样一个名不见经转的投资公司能把LLM研究的这么成功的 ...

顶楼引用的那个公众号专访可以看一看
https://mp.weixin.qq.com/s/Cajwfve7f-z2Blk9lnD0hA
https://mp.weixin.qq.com/s/r9zZaEgqAa_lml_fOEZmjg

作为外人来看DeepSeek不一定是最终成功的那个
但是事在人为和开源第一的精神是值得学习的，也是现在的美国人远不如中国同行的原因

蓳白

qratosones1337 发表于 2025-1-21 17:43
扯吧，推理要是真有那么大的带宽要求，KV Cache磁盘缓存不就没法用了？MLA本身在设计上就是为了降低KVCach ...

他们自己也卖910b的一体机，应该不是传言

quadrozeke

LilithMardin 发表于 2024-12-27 20:44
所以西方对制造业的没落到底是什么造成的？国内明明有那么多人口需要饭碗，我知道他们生活成本高人工高所以 ...

资本主义阵营在冷战中最大的战果就是建立了一套普世的“你不干有得是人干”的体系。

alixsander

qratosones1337 发表于 2025-1-22 01:25
1，H800的带宽跟A800一样就400G，并没有比910B全连接高多少。而且就算真有需要的话NV这边恰好还有个H20， ...

1、OK我看了下DeepSeek V3的API统计，TTFT是1.9s，吞吐是50tokens/s。首token比sonnet低，增量吞吐和sonnet是差不多的。起码在API使用上说巨快是不客观的，但是也没有什么组超大batch搞出来很大TTFT和TBT的迹象。网页端没有统计，统计的话可能需要看E2E，吐字现在可能都是假流式。
2、我没有说推理成本高，我说的是R1免费账户一天50次我不知道它们怎么挣钱。还有怎么能弄到那么多H800（H20/A100当然也有可能）还可以用来部署推理集群。
3、技术报告里写的很清楚最低要求是32卡prefill 320卡decode的GPU，decode阶段用了 IBGDA。幻方本身也是第一个做超大集群推理的。之前华子设想的都是70B以下模型跑在800I单机上，根本还没搞过超大推理集群，所以是不可能在当前作为幻方的推理硬件被部署的。

qqks

alixsander 发表于 2025-1-22 02:38
1、OK我看了下DeepSeek V3的API统计，TTFT是1.9s，吞吐是50tokens/s。首token比sonnet低，增量吞吐和sonne ...

幻方不是有名的量化公司吗，在缅a割韭菜割得那么爽，还怕亏钱？

这家能做起来，大方的开源，真的要感谢广大a股韭菜的无私贡献啊。

股市吸血投资者反哺研究界与制造业，真是世界奇观

coldhot3

qqks 发表于 2025-1-22 06:11
幻方不是有名的量化公司吗，在缅a割韭菜割得那么爽，还怕亏钱？

这家能做起来，大方的开源，真的要感谢广 ...

你忘了瑞幸？

qqks

coldhot3 发表于 2025-1-22 06:25
你忘了瑞幸？

瑞幸好歹还是个投资，至少能赌未来。这家在a股上量化交易是真的从韭菜手里抢钱啊

coldhot3

qqks 发表于 2025-1-22 06:42
瑞幸好歹还是个投资，至少能赌未来。这家在a股上量化交易是真的从韭菜手里抢钱啊 ...

我的意思是瑞幸也是美股融了很多钱，退市坑死一堆韭菜，但是给国内留下一个很有意思的咖啡店

工口兔

OpenAI看来真急了，直接宣布砸4000亿刀开始Stargate计划

yoki42

突然想起中国2185和超新星纪元，我们的最高领导层里有刘慈欣粉丝大家都知道，那么有没有可能他们真的对“人民大会管理软件”“大量子”这样的高级人工智能有极大兴趣？

—— 来自 鹅球 v3.3.96

枯风瘦雪

naihs 发表于 2025-1-21 17:00
其实还有个旁证来说明这玩意的水平

搜一下 梁文峰 最近的新闻

这个旁证价值不大，区块链技术在国内受捧也是类似的路径，最后也没真的做出啥玩意
我反正觉得deepseek的好是因为它搞出来一条算力受限前提下进行大模型训练和开发的技术路线，而且全程开源接收行业验证也拥抱生态

猫屎盆子

riin2 发表于 2025-1-22 01:35
有没有啥文章视频能说清楚为啥这样一个名不见经转的投资公司能把LLM研究的这么成功的 ...

塔基搭得足够高，那么每一块砖都是塔尖

猫屎盆子

yoki42 发表于 2025-1-22 08:26
突然想起中国2185和超新星纪元，我们的最高领导层里有刘慈欣粉丝大家都知道，那么有没有可能他们真的对“人 ...

把“可能”去掉。前几年开始到处铺开建设智慧城市、数字孪生……塔是真的很希望弄出一套次世代管理体系来的

Fuero

还在订着Chatgpt Pro，但感觉还是这个可玩性高一些，今年想凑个两台Project DIGITS做本地部署玩玩，但不知道溢价多少。。。

枯风瘦雪

猫屎盆子 发表于 2025-1-22 08:42
把“可能”去掉。前几年开始到处铺开建设智慧城市、数字孪生……塔是真的很希望弄出一套次世代管理体系来 ...

要说还有雄安的规划，是真的按下一代城市管理系统试验场来做的，毕竟这种管理系统和政府的治理诉求算是高度相辅相成的

qratosones1337

alixsander 发表于 2025-1-22 02:38
1、OK我看了下DeepSeek V3的API统计，TTFT是1.9s，吞吐是50tokens/s。首token比sonnet低，增量吞吐和sonne ...

赚钱的大头靠的是API，网页端的作用是引流+摊薄成本。实际上DeepSeek对chat产品一直都不怎么上心，手机App一直到最近才上架。

—— 来自 鹅球 v3.3.96

qratosones1337

枯风瘦雪 发表于 2025-1-22 08:31
这个旁证价值不大，区块链技术在国内受捧也是类似的路径，最后也没真的做出啥玩意
我反正觉得deepseek的 ...

业界真正应该反思的问题是过剩算力到底有没有用——meta的算力十倍于阿里，结果现在llama眼看着要落后于qwen了。另外最著名的例子是马斯克，XAI是最早开始吹十万卡集群的，结果Grok基本上就是个CJB

—— 来自 鹅球 v3.3.96

枯风瘦雪

qratosones1337 发表于 2025-1-22 09:05
业界真正应该反思的问题是过剩算力到底有没有用——meta的算力十倍于阿里，结果现在llama眼看着要落后于q ...

是的，现在硅谷的科技新贵利益联盟都是捆绑着鼓吹“算力=大模型=AI”，且AI可以沿着当前路线无限迭代发展最终通向“通用人工智能”和“技术奇点”的，随着deepseek用受限的算力和有限的成本做出来差距不大的成果，硅谷科技新贵鼓吹的路线会持续受到质疑和调整，而预期真正破灭的时候也是大戏上场的时候

qratosones1337

魔法酪饼 发表于 2025-1-22 09:12
问题不是程序员老哥对制造业的厌弃，这问题其实有点人性。。。
非技术导向公司会有典型的劣币驱逐良币问题 ...

非常搞笑的是，国内乃至全球的AI top玩家，其中一个是Qwen，属于阿里集团…
现在已经基本上压过了llama

—— 来自 鹅球 v3.3.96